Rota management method and system

Abstract

A method is provided for automatically producing an optimised rota for a service provider providing a plurality of services. Various data inputs are provided, with service-provision-requirement data for each of the plurality of services includes a plurality of service-provision-quality thresholds. Assignment of personnel members to the plurality of services is based on a combination of a personnel pool data input, a personnel requirement data input, and a rota assignment-prioritisation data input to generate an optimised rota.

Description

[0001] Rota Management Method and System

[0002] The present invention relates to a method of automatically calculating a rota for a service provider providing a plurality of services, each of the plurality of services having different requirements for personnel and perhaps also equipment, for instance in a medical or healthcare setting, such as a hospital. The invention further relates to a system for automatically producing an optimised rota for a service provider providing a plurality of services.

[0003] Rota management is challenging, particularly in industries with wide ranges of skill-sets. Doctors are a highly heterogeneous group, with varying skills, specialities, and seniorities. Services, in the UK and other territories, provide healthcare to patients, and in order for services to operate effectively, the right quantity and mix of staffing, skills, and key equipment must be provided. Healthcare staff work a variety of shift patterns, including day shifts, night shifts, and late shifts, and determining when staff are available and how to allocate staff to maintain service functionality, is currently performed by a dedicated rota co-ordinator.

[0004] Rota co-ordination is challenging. The number of potential allocations of even a small number of staff to fill roles is vast. For example, a team of fifteen doctors working six services has over 302 billion possible staff-to-service combinations on a rota. Rota co-ordinators are also under severe time pressure due to the nature of pressures on the services and staff alterations, and thus optimisation of rostering is usually impossible, resulting in persistent sub-optimal rostering and underutilising of a team’s potential to deliver quality care.

[0005] Furthermore, rota co-ordination is complicated by the non-fungibility of staff. Differences in seniority, skills, and experience means that the rota co-ordinator needs vast amounts of ancillary information to determine whether potential rota placements are viable to provide a service. Working restrictions also complicate matters, in that staff cannot work constantly without rest. It is not possible for a staff member to conduct a night shift immediately followed by a day shift, for instance.

[0006] As a result, healthcare rotas are inefficient and inflexible. This leads to avoidable understaffing of services, particularly in the event of staff absence. Staff morale is also damaged by the impositions placed on staff by an inflexible rota, damaging their personal lives and / or mental health. Healthcare providers also face increased costs when locum hiring is required to fill rota gaps, and / or must postpone or cancel service provision.

[0007] In the UK healthcare system, most rota management is either conducted via spreadsheet, which has very limited scope to monitor all staff members concurrently, often leading to prioritisation of on-call services, with remaining services forced to spontaneously organise based on remaining staff skillsets. This results in there being no written record of which staff member was working on which service, making dangerous understaffing almost impossible to pre-empt. Some rostering software is commercially available, which improves the display and circulation of rotas, though largely which mirror the functionality of spreadsheets.

[0008] Quality rostering is also vitally important for communication. If, for example, an emergency procedure requires the calling in of non-resident staff, then any inaccuracies on the rota will deprive the team of the knowledge of the right person to contact. This can have potentially devastating consequences for the patients.

[0009] Equally, key equipment has an impact on service provision in a similar way to staffing. There is a finite pool of it available, and each item can only be in one place at a time. Insufficient or damaged equipment is a common reason for service cancellation, though if key items were rostered in the same way as staff, these gaps could be pre-empted and services arranged to minimise this disruption.

[0010] It is an object of the present invention to obviate or overcome the above-referenced difficulties.

[0011] According to a first aspect of the invention, there is provided a method of automatically producing a rota for a service provider providing a plurality of services, each of the plurality of services having different personnel requirements, the method comprising the steps of: a] providing a personnel pool data input, wherein the personnel pool data input comprises at least rota-availability data of personnel members of a personnel pool to be entered into the rota; b] providing a personnel requirement data input, wherein the personnel requirement data input comprises service-provision-requirement data associated with each of the plurality of services, wherein the service-provision-requirement data for each of the plurality of services includes a plurality of service-provision-quality thresholds; c] providing a rota assignment-prioritisation data input indicative of a prioritisation sequence for each of the plurality of service-provision-quality thresholds for each of the plurality of services; d] calculating an optimised assignment of the personnel members to the plurality of services based on a combination of the personnel pool data input, the personnel requirement data input, and the rota assignmentprioritisation data input; e] generating a rota based on an output of step d]; and f] publishing the rota; g] providing a personnel choice data input for personnel to modify their rota-availability data; h] identifying potential rota amendments based on the modified rota-availability data, wherein there is provided a rota change indicator indicative of a net effect to the rota based on the potential rota amendments; i] re-calculating the assignment of the personnel members based on the potential rota amendments; ]] generating a modified rota based on an output of step i]; and k] publishing the modified rota.

[0012] The present invention achieves the technical leap of automating the generation of an optimised rota by attributing specific service-provision-quality thresholds to specific services to be rostered from a pool of staff members. This allows for quantification of an allocation algorithm which according to the service provider’s requirements, which is otherwise an unknown element in the rota generation process at present, requiring dedicated staff for rota management. Unsafe working conditions can, within the present system, be largely eliminated, with consequential benefits for patient safety, quality of care, and service efficiency, for example, within a healthcare setting. Staff members using the present system also have a greater level of engagement and flexibility with their working patterns, potentially eliminating many of the undesirable aspects of arbitrary rota assignment. The provision of this system also allows for a decentralisation of rota management; there is no need for a dedicated rota co-ordinator to make all of the requisite evaluations and decisions; instead, the system automatically generates rota updates based on staff or system feedback. Indeed, all rota functions can be set to either require manual authorisation, or the system may have permission to apply automatic modifications. Advantageously, the latter scenario allows for complete automation of the rostering process, eliminating the need for a dedicated rota co-ordinator.

[0013] The ability to automatically re-allocate the rota using small modifications to the rota whilst still being able to monitor compliance with the service-provision-quality thresholds ensures that any changes made do not significantly or deleteriously affect the provision of the service. This of course may be desired personnel choice, as not all combinations of leave request may be viable within a given specialty. Any or all of these steps may be performed automatically. The method is uniquely suited to permitting re-calculation of rota data, based on inputs which are supplied directly by the end user. Since the system is capable of pre-emptively determining beneficial rota swaps in advance, which can be identified to the end user, the end user can request desirable swaps which can result in improvements to the overall service operation. This provides end users with greater flexibility over their personal lives. Furthermore, this allows staff to use the platform to directly anticipate the consequences of arranging certain rota swaps in advance to a complete request being presented to a rota co-ordinator. Whilst this increases the number of times the underlying rota swap algorithm would need to run, this enables direct planning to occur between staff members.

[0014] Optionally, the personnel pool data input may further comprise personnel specialism data.

[0015] Specialisms are one of the key criteria for dividing out staff and allocating them to their competencies in order to construct a workable rota.

[0016] Preferably, the service provider may be a medical service provider.

[0017] Medical rotas, particularly those for doctors, are extremely inflexible due to the 24-hour nature of the work involved, and the high degree of specialism required to be a qualified medic. This present system has been developed with medical professionals in mind. In one embodiment, there are at least three service-provision-quality thresholds for each of the plurality of services, and more preferably are five service-provision-quality thresholds for each of the plurality of services.

[0018] The granulation of the service-provision-quality thresholds allows for graded prioritisation of how to fill the rota to be generated, in accordance with the service requirements expected.

[0019] During step f], the rota may be published to all of the personnel members.

[0020] Full disclosure of the rota, ideally direct to user devices, ensures that changes to the rota are fully transparent, reducing issues with morale if staff feel they are being treated unfairly. Where this occurs direct to user devices, this can be in the form of push notifications, and can require either automated or a manual acknowledgement of the staff member having received the notification.

[0021] Preferably, the rota assignment prioritisation data input may further comprise a priority ruleset indicative of an overall prioritisation sequence for the plurality of services, based on the said prioritisation sequence for each of the plurality of service-provision-quality thresholds.

[0022] The priority ruleset provides a mechanism for service-provider level decisions to be implemented, as some individual services or services categories will be more critical than others.

[0023] During step e], the generated rota may be selected from a plurality of generated rotas, each of the plurality of generated rotas fulfilling the overall prioritisation sequence. Similarly, during step i], the modified rota may be selected from a plurality of modified rotas, each of the plurality of modified rotas fulfilling the overall prioritisation sequence.

[0024] The initiation of a metaset, that is, a combination of all information regarding all requirements from active services, gives flexibility to the system to utilise further evaluation criteria to determine a truly optimal rota for both the service provider and the personnel.

[0025] Optionally, during step e], at least one further evaluation criterion may be applied to the plurality of generated rotas to select the generated rota.

[0026] The further evaluation criteria may help to reduce the size of the metaset in order to rationalise which rota is the most optimal for all parties involved.

[0027] The at least one further evaluation criterion may comprise historical or future service implementation data to reduce service discontinuities.

[0028] One consideration which should be accounted for is whether there is information loss from personnel entering or leaving mid service-provision. The present method can project forward and backward in order to reduce the number of potential losses of information. Additionally, or alternatively, the at least one further evaluation criterion may comprise rostering fairness data.

[0029] Fairness is a criterion which is quite difficult to otherwise quantify, but the present system is capable of importing personnel data which is indicative of distribution of service experience.

[0030] Optionally, the personnel pool data input may comprise a placeholder or phantom entity indicative of locum or supply personnel.

[0031] The use of a placeholder or phantom can allow for computation of the rota to a higher level than would otherwise be feasible by the pool of staff available, modelling the behaviour sought when supply or locum staff would be engaged.

[0032] In a preferred embodiment, the phantom entity may be characterized during step d) to improve compliance with at least one of the service-provision-quality thresholds.

[0033] The integration of a placeholder or phantom entity in the system which provides compliance with a potential optimised prioritisation sequence allows for a rota co-ordinator to pre-emptively identify missing characteristics which are impeding the quality of service, and make hiring decisions for permanent or supply personnel accordingly.

[0034] The method may further comprise a step of assigning a digital baton to a user account of the assigned personnel members for the plurality of services during a live period of the rota, the digital baton being transferrable between user accounts as responsibility for the plurality of services changes between personnel members.

[0035] A digital baton provides a mechanism fortracking a responsible person relating to a particular service, with the user being in ready communication range via their own personal user device. This, in the medical context, allows for elimination of pagers or bleepers.

[0036] There may preferably further be a step of applying a global rota modifier, based on a pre-determined operational condition.

[0037] Global rota modifiers can be used to apply specific conditions to all or part of the system, for examples, identifying changes to the rota protocols during emergency or unprecedented demand situations. This then requires minimal real-time planning for how to adapt the rota to accommodate such pressures.

[0038] Preferably, there may further comprise a step prior to step d] of providing an equipment data input, wherein the equipment data input comprises at least rota-availability data of equipment to be entered into the rota, and wherein step d] further comprises calculating an optimised assignment of the personnel members and equipment to the plurality of services based on a combination of the personnel pool data input, the personnel requirement data input, the equipment data input, and the rota assignment-prioritisation data input.

[0039] The provision of service-specific equipment, which may be derived from a limited pool, is also crucial to providing specific services. It is therefore highly advisable to simultaneously roster both personnel and equipment as part of the present method.

[0040] Optionally, during step e] the generation of the rota may be based on a rota template.

[0041] In one preferable alternative, during step e], the generation of the rota may comprise altering shift patterns of the personnel members to generate a novel rota.

[0042] The use of template rotas may simplify the generation and processing of the new rota, whereas novel rota generation, where shift patterns can be swapped around, allows for gaps in service provision to be identified and pre-emptively filled, based on personnel availability. Indeed, novel rota generation allows for the system to effectively work from a list of staff members from the personnel pool data input, and then automatically calculate their shifts, and automatically placing them onto the relevant services. Novel rota generation allows for complete automation to be provided.

[0043] Optionally, at least steps d] and e] may be performed automatically, preferably by artificial intelligence or machine learning algorithm.

[0044] Whilst manual and conditional automation may be feasible within the system, it is anticipated that the present invention may eliminate the need for a dedicated human rota co-ordinator.

[0045] According to a second aspect of the invention, there is provided a computer program product configured for implementing the method in accordance with the first aspect of the invention.

[0046] It is anticipated that the present methodology be fully implemented as a computer software application, for ease of interaction for users, typically staff and rota co-ordinators who collectively represent the end users.

[0047] According to a third aspect of the invention, there is provided a system for automatically producing a rota for a service provider providing a plurality of services, each of the plurality of services having different personnel requirements, the system comprising: a personnel pool data input, wherein the personnel pool data input comprises at least rota-availability data of personnel members of a personnel pool to be entered into the rota; a personnel requirement data input, wherein the personnel requirement data input comprises service-provision-requirement data associated with each of the plurality of services, wherein the service-provision-requirement data for each of the plurality of services includes a plurality of service-provision-quality thresholds; a rota assignment-prioritisation data input indicative of a prioritisation sequence for each of the plurality of service-provision-quality thresholds for each of the plurality of services; and a processor configured to calculate an assignment of the personnel members to the plurality of services based on a combination of the personnel pool data input, the personnel requirement data input, and the rota assignment-prioritisation input, and subsequently generate and publish a rota based on the said calculation.

[0048] A system capable of implementing the previously described method is advantageously able to provide a vastly improved rostering service, compared with arrangements known in the art. This provides improved flexibility and lifestyle control for the users thereof, but most importantly guarantees a maximised quality of service is being delivered by the available pool of resource, both staffing and equipment.

[0049] Preferably, the system may be accessible via a user interface of a personal computing device associated with each of the plurality of personnel.

[0050] A specific advantage of the present system is that the end users are able to interact directly with the rota management software directly through their personal computing devices, via which they may input their own preferences and pertinent information.

[0051] Optionally, the processor may be provided as part of a central server.

[0052] It is preferred that the processor be located in a central location, from which all rota management can be co-ordinated, even if this is not necessarily co-located with the service provider.

[0053] According to a fourth aspect of the invention, there is provided a method of automatically producing a rota for a service provider providing a plurality of services, each of the plurality of services having different personnel requirements, the method comprising the steps of: a] providing a personnel pool data input, wherein the personnel pool data input comprises at least rota-availability data of personnel members of a personnel pool to be entered into the rota; b] providing a personnel requirement data input, wherein the personnel requirement data input comprises service-provision-requirement data associated with each of the plurality of services, wherein the service-provision-requirement data for each of the plurality of services includes a plurality of service-provision-quality thresholds; c] providing a rota assignment-prioritisation data input indicative of a prioritisation sequence for each of the plurality of service-provision-quality thresholds for each of the plurality of services; d] calculating an optimised assignment of the personnel members to the plurality of services based on a combination of the personnel pool data input, the personnel requirement data input, and the rota assignmentprioritisation data input; e] generating a rota based on an output of step d]; and f] publishing the rota.

[0054] The invention will now be more particularly described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 shows a pictorial representation of system for automatically producing a rota for a service provider providing a plurality of services, in accordance with the second aspect of the invention, and which is suitable for implementing a method of automatically producing a rota for a service provider providing a plurality of services, in accordance with the first aspect of the invention;

[0055] Figure 2 shows a pictorial representation of a plurality of potential data inputs to the processor of the system of Figure 1 ;

[0056] Figure 3 shows a pictorial representation of first tier of rota data;

[0057] Figure 4 shows a pictorial representation of a second tier of rota data;

[0058] Figure 5 shows a pictorial representation of a third tier of rota data;

[0059] Figure 6 shows a pictorial representation of rota data required in order to trigger an initial allocation algorithm of the method of automatically producing a rota for a service provider providing a plurality of services, in accordance with the first aspect of the invention;

[0060] Figure 7 shows a pictorial representation of five service-provision-quality thresholds used in a method of automatically producing a rota for a service provider providing a plurality of services, in accordance with the first aspect of the invention;

[0061] Figure 8A shows a pictorial representation of a requirement ruleset fora service to be operated used in a method of automatically producing a rota for a service provider providing a plurality of services, in accordance with the first aspect of the invention;

[0062] Figure 8B shows a pictorial representation of the requirement ruleset of Figure 8A having had its requirement statements validated to produce a service quality indicator output;

[0063] Figure 9 shows a pictorial representation of a generic priority ruleset for an indicative multiservice sector or speciality used in a method of automatically producing a rota for a service provider providing a plurality of services, in accordance with the first aspect of the invention;

[0064] Figure 10 shows a pictorial representation of a specific priority ruleset for a medical speciality having multiple services, of the generic type outlined in Figure 9;

[0065] Figure 11 shows a pictorial representation of an exemplary speciality to be rostered, having five operational services, grouped by service categories;

[0066] Figures 12Ato 12E show pictorial representations of the requirement rulesets for the individual services of Figure 11 ; Figure 13 shows a pictorial representation of a specific priority ruleset for the exemplary speciality of Figure 11 ;

[0067] Figure 14 shows a pictorial representation of a possible staffing assignment for the exemplary speciality of Figure 11 , prior to a full rota being generated;

[0068] Figure 15A shows a pictorial representation of a first-level metaset implemented for the rota based on the priority ruleset of Figure 13;

[0069] Figure 15B shows a pictorial representation of a second-level metaset implemented for the rota based on the priority ruleset of Figure 13;

[0070] Figure 15C shows a pictorial representation of a sixth-level metaset implemented for the rota based on the priority rule set of Figure 13;

[0071] Figure 16 shows a pictorial representation of a pre-emptive rota reallocation, indicating a summary of allocation calculations required to perform a potential rota swap;

[0072] Figure 17 shows a pictorial representation of a user interface of a user device, indicating the desirability of potential rota swaps from the pre-emptive rota reallocation of Figure 16;

[0073] Figure 18 shows three pictorial representations of potential shift swaps which can be determined using a method of automatically producing a rota fora service provider providing a plurality of services, in accordance with the first aspect of the invention; and

[0074] Figure 19 shows a pictorial representation of two possible rota generation techniques using a method of automatically producing a rota for a service provider providing a plurality of services, in accordance with the first aspect of the invention.

[0075] Referring to Figure 1 , there is shown a system, referenced globally at 10, which is suitable for implementing a method of automatically producing a rota for a service provider providing a plurality of services, typically but not necessarily exclusively within the medical sector.

[0076] There is provided a processor 12 which is here shown as part of a remote server 14, which receives several data inputs. There is a rota database stored on, or associated with, the remote server 14. Whilst these inputs are indicated as solitary sources of information, it will be apparent that, in practice, each data input will likely be comprised of multiple data streams.

[0077] Whilst a remote server 14 is illustrated, this could be provided as a single physical server, in which case it could be located at the site of the service provider, such as a hospital. Equally, it could be a distributed server, such as a cloud server. The rota database is made available from the remote server 14 via a platform 15 such as a web-based interface to end users 16, typically being accessible to view via their own user devices 18, such as smartphones, laptop computers, tablet computers, or desktop computers. Other users, typically rota co-ordinators, may access the system through their own separate devices 18’; however, the rota coordinator would likely have privileged access to the remote server 14 as well, in order to perform administrative functions, whilst still using the main platform 15 to interact with end users 16.

[0078] In terms of workflow interaction, there are various methods available. An end user 16 might request, for example, to swap a shift via the main platform 15 accessed through their user device. The processor 12 determines a viability of a shift swap associated with the request, through one or more other end users 16 or via a rota co-ordinator. Once authorised, an updated rota can be produced, which is outlined in more detail below. The updated rota is then published to all end users 16.

[0079] Alternatively, the rota co-ordinator can access the main platform where an enforced change may be required. The system 10 interacts with the necessary end users 16, and once an agreement is mediated through the system, an updated rota can be generated and published, as above.

[0080] The system 10 can also be configured, prior to publication of the rota, to pre-empt any staffing gaps. This can be performed by the processor 12 evaluating a current version of a shift pattern, and perform iterative swap requests between end users 16 without ever making the end users 16 aware of this activity. This can then be used to create an automatically optimised rota prior to general publication. Again, this will be discussed in more detail below.

[0081] Figure 2 shows indicative types of data which may be introduced to the processor 12: a personnel pool data input PPDI, which may typically comprise static personnel data sPD and dynamic personnel data dPD; a personnel requirement data input PRDI; and a rota assignment-prioritisation data input RAPDI. In some embodiments, it may also be advisable to include an equipment data input EDI.

[0082] The user devices 18 are also capable of data transmission back to the remote server 14, and user information can be fed into the personnel pool data input PPDI to make changes to the rota database rapidly. The users 16 can see notifications which identify changes to rostering, directly on their user devices 18, and are able to work more flexibly, as the automated rostering system is far more flexible than existing methods. This also allows for instant notification and / or communication to users 16 when a change is made, as well as the transfer of unambiguous information.

[0083] The rota database comprises entries required for the method to operate. This includes service definitions, timings, locations, and requirements for services, for example. A specific operations mode may also be set, which changes global parameters for the system 10. In essence, this breaks down into several data inputs. There is the personnel pool data input PPDI, which provides data relating to personnel. This will include intrinsic information relating to the personnel, such as their identity or some other unique identifier associated therewith, thereby forming the static personnel data. This may include characteristic data such as skillset data, specialism data, or seniority data. There will also be additional data, comprising rota-availability data, that is, when the personnel are available for entry into the rota, and may include absence, leave, or sickness information. This constitutes dynamic personnel data dPD.

[0084] Data is tiered within the rota database, and structured tiers of data are shown in Figures 3, 4, and 5. It will be appreciated that the types of tiering may well be dependent on the industry in question. The data tier structure outlined here is specific to a medical context. A first data tier T 1 identifies rotation data for doctors overa year. This is provided as part of the personnel pool data input PPDI, most likely as static rota data sRD. This provides core information regarding the working patterns of the doctors.

[0085] A second data tier T2 identifies shift data, that is, when specifically a doctor is working, but not where or what the doctor is working on. This is dynamic rota data dPD within the personnel pool data input PPDI, since leave or absence will necessitate changes to the rota. Shift data in the second data tier T2 is a measure of staff availability, in that the presence of a staff member on shift makes them accessible to the allocation or re-allocation process during structuring of the third data tier T3.

[0086] A third data tier T3 identifies service data, that is, which service each doctor is working on, for each determined interval of the day.

[0087] The first data tier T 1 is largely immutable, other than in the event of staff turnover. Staff will be aware of this information prior to generation of a rota. The second data tier T2 can change, but is generally publicly available information to all end users 16 in advance, even at present. However, the present system 10 is capable of automating and optimizing the manipulation of third data tier T3 information into a full and complete rota.

[0088] In general terms, and as will be described in more detail hereafter, the system 10 implements an allocation algorithm which takes existing second data tierT2 information to generate the third data tier T3 information. In other words, the system takes the shifts that the staff are working on, and then makes a series of downstream service and / or equipment allocations.

[0089] Service allocation is determined in part by the personnel requirement data input PRDI in the rota database, which is data relating to the service to be rostered. The personnel requirement data input PRDI comprises service-provision-requirement data, which is the specific requirement for each service to meet a pre-determined level. As such, this will not only include data indicative of the service itself, and therefore the requirements intrinsic to the type of service, such as timing or location data, but also to the staffing requirements, that is, what type of personnel are needed to operate the service. This is quantified by the attribution of a plurality of service-provision-quality thresholds SPQT for each service, indicative of what personnel would be required to reach particular service quality levels.

[0090] The personnel requirement data input PRDI may take the form of a requirement ruleset REQR which is has requirement statements REQS indicative of the personnel requirements for the service for each of the plurality of service-provision-quality thresholds SPQT.

[0091] For example, a requirement ruleset REQR might have the following structure:

[0092] Note that the Role parameter here is the staff member’s role in the organisation, and is presented as an example only. Parameters may refer to any pertinent metric of the staff member which falls within the general category of personnel pool input data PPDI which might be a relevant determinant of staff assignment.

[0093] The requirement is cumulative, that is, the threshold levels must be completely fulfilled before the next threshold can be considered. Here, to meet the first service-provision-quality threshold SPQT at least one doctor of at least registrar seniority must be present for the service to operate, and a consultant must be contactable, though not necessarily present. For the second service-provision-quality threshold SPQT to be met, at least two doctors must be present of at least senior house officer (SHO) seniority, though this could include the doctor present for the first threshold requirement. For the third service-provision-quality threshold SPQT to be met, three doctors must be present, though for the previous service-provision-quality threshold SPQT, at least two SHO grade doctors are already required, so this is only an additional requirement of one further doctor.

[0094] Equipment data input EDI represents non-personnel requirements for service operation, and this may be as crucial as the personnel pool data input PPDI. For example, in the medical context, there are many different services with competing demands for equipment, such as: X-ray C-arms, fluoroscopes, and image intensifiers; high-fidelity or anatomically-specific ultrasound machines; or target controlled infusion (TCI) pumps.

[0095] Byway of example only, many C-arms have a clear progression of quality, and some surgery is unsafe without the highest-quality imaging apparatus, such as prosthetic re-do surgery. Other surgery many necessitate the best fluoroscope, for instance, but less complex surgery may suffice with older or lower-specification machines. As such, there is an optimisation of the allocation of equipment to be performed.

[0096] Similarly, some specialised infusion pumps have the ability to calculate different pharmacokinetic dynamic models, e.g., the Marsh model or Minto model. These are Custom Parameters for the pump, and some theatres may require that they have a pump for one or both of these models.

[0097] In essence, the collection of key medical equipment therefore forms its own effective specialty, with each item being equivalent to a staff member. The given array of Services then places demand on taking these items.

[0098] Equipment never goes on leave, or has to worry about worktime restrictions. However, should an item develop a fault, it is effectively placed on an equivalent of Leave whilst it is repaired. Insufficient key equipment might make a service Unsafe to continue; this is one reason why some services are cancelled. This cancellation can then be fed back to all other specialties working within the service via more conventional rota means.

[0099] Similarly, location data input may also be important, forexample, if there are a finite number of surgical theatres. This could also be factored in as a potential data input.

[0100] The personnel pool data input PPDI and the personnel requirement data input PRDI provide the raw information to evaluate rota feasibility and in turn generate a rota; that is, what is available and what is to be rostered. As noted above, for this medical context, this is the generation of the third data tier T3. A representation of this core data, including equipment data input EDI, is represented in Figure 6.

[0101] The assignment of the personnel to services is controlled by the provision of a third input, which is a rota assignment-prioritisation data input RAPDI indicative of a prioritisation sequence for each of the plurality of service-provision-quality thresholds SPOT for each of the plurality of services.

[0102] The plurality of service-provision-quality thresholds SPOT are defined according to the service in question. For a healthcare service, such as an emergency ward or cancer clinic, there will the plurality of service-provision-quality thresholds SPOT which are indicative of the safety and quality of care which can be provided. As shown in Figure 7, there may be five service-provision-quality thresholds SPOT for a service.

[0103] The plurality of service-provision-quality thresholds SPOT include: Unsafe, in which patients are at risk from critically lacking staff numbers and / or essential skills. An acute ward without a doctor of at least senior house officer (SHO) seniority may be deemed unsafe, for instance; Minimal, in which patient safety can be secured, but the operational team is unlikely to have sufficient capacity to provide anything other than the bare minimum of care to the patients; Adequate, where a good quality of care is provided, but the service may struggle to operate in a timely manner where service demand increases; Optimal, where safe and high-quality care is provided efficiently, and the service can react effectively to high-demand situations; and Overstaffed, where the service has more staff than necessary to deliver optimal care, even when training allowances are accounted for. The maximum service-provision-quality threshold SPOT reached for a given service then can yield a service quality indicator output SQIO associated with the said service.

[0104] At a most basic implementation of the invention, an assignment of the personnel members to the plurality of services can be calculated based on a combination of the personnel pool data input PPDI, the personnel requirement data input PRDI, and the rota assignment-prioritisation data input RAPDI. These data inputs provide instructions for the solution of the optimum rota by the processor 12, for whatever the combination of staff shifts and services might be.

[0105] The personnel pool data input PPDI, personnel requirement data input PRDI, and rota assignmentprioritisation data input RAPDI largely comprise static data, that is, data which is known prior to the generation of a first rota.

[0106] Once a rota is generated from the personnel pool data input PPDI, personnel requirement data input PRDI, and rota assignment-prioritisation data input RAPDI, there will also be live rota data associated with the rota, which will be far more dynamic in nature. This may be configured in a tiered data structure. In the present implementation of the invention, the live rota data may comprise first tier data T 1 , which stores information about which personnel are currently rostered to specific posts within a specialty. For example, this could be information about which doctors are occupying which posts within a specialty. Second tier data T2 may then comprise shift data, which stores information about which shifts the personnel are working within the post; this may include timing information such as shift start time and shift end time. Third tier data T3 may then be more granular data, which stores information for smaller time periods, typically intervals of a day, and thus the pairing between staff and services. This could be, for example, broken down at the level of morning, which is 8AM to 12.30PM, or late evening, which is 7PM to 10PM, and so on. This provides overlap information for services, where shifts for personnel are non-aligned. This is merely exemplary, however, and intervals will be specific to the service in question, and would typically be pre-determined by the operator.

[0107] To generate the rota, the system will utilise the rota assignment-prioritisation data input RAPDI. Each service-provision-quality threshold SPOT may include one or more requirement statement REQS associated therewith, collectively forming a requirement ruleset REQR. Examples of requirement statements REQS may include: “There are at least two doctors with the advanced trauma life support qualification”; “There is at least one contactable consultant”; “There are at least three doctors above a given seniority”; “There are at least two doctors from a specific sub-grouping”; “There are at least five doctors”; “A specific named doctor is present”. Anything that can be fed into a requirement statement REQS can thus be defined as a parameter. Within the current implementation of the system, a requirement statement REQS has the structure of:

[0108] {Parameter} {Operator} {Value} {Status} {Count}

[0109] Parameters are drawn from the static personnel data sPD of the personnel pool data input PPDI, and may include details such as name, grade, role, and qualifications, which can be read by the processor for calculations. Custom parameters may be feasible.

[0110] A generic requirement ruleset REQR for a speciality or department, typically operating a plurality of different services, is indicated in Figure 8A. The various service-provision-quality thresholds SPQT are indicated as black lines, with the one or more requirement statements REQS underneath each service-provision-quality threshold SPQT showing the requirements to achieve the next service- provision-quality threshold SPQT. In the depicted arrangement, for instance, there are three requirement statements REQS to progress from the Unsafe threshold to the Minimal threshold, and since there are no intermediate requirement statements REQS, the Adequate threshold would be automatically reached. There are then four further requirement statements REQS needed to meet the Optimal threshold, and one further requirement statement REQS needed to meet the Overstaffed threshold.

[0111] Figure 8B indicates the consequences of evaluation of the ruleset against an interval where staff are assigned to the service, showing how the Adequate threshold has been met. The first three requirement statements REQS have been completed, as has the single requirement statement REQS to meet the Overstaffed threshold; however, since only two of the four intermediate requirement statements REQS for the Optimal threshold have been met, only Adequate service quality indicator output SQIO can be attributed.

[0112] These requirement statements REQS can be defined in programmatic terms, using the following structure: {Parameter}{Operator}{Value}{Status}{Count}. An example requirement statement REQS could therefore be {Qualification}{=}{ATLS}{Present}{2}, or {Role}{=}{Consultant}{Contactable}{1}. Data of these types could be parameterised as Boolean data, ordered list data, unordered list data, or numerical data, such as integer data, for instance, and the skilled person will be able to identify the most appropriate data type in a given context. It will be apparent that the requirement statements REQS for each service-provision-quality threshold SPQT may involve more complicated operator logic. One example might be ( {Role}{>}{Registrar}{Present}{1 } ) <OR> ( {Role}{>}{SHO}{Present}{2} <AND> {Qualification}{=}{EPALS}{Present}{1 } ).

[0113] The rota assignment-prioritisation data input RAPDI will then further have a priority statement PRIS, which has the following structure {Service or Service Category}{Staffing Indicator}. A typical priority ruleset PRIR has a series of the priority statements PRIS and might have a structure in keeping with that shown in Figure 9. The priority ruleset PRIR is structured in the same manner as for the requirement ruleset REQR, but instead of utilising the pre-determined service-provision-quality thresholds SPQT, a plurality of possible levels is set. Typically, these levels would be user-defined in accordance with internal policy guidelines, for example, introducing requirements in keeping with statute or regulatory requirements. The level achieved is provided as a priority indicator output PRIO; level 5 in Figure 9.

[0114] An exemplary priority ruleset PRIR is shown in Figure 10, and is also reproduced here for ease.

[0115] The level indicators do not specifically carry information, but are merely sequencing for the priority statement PRIS. It is also possible for a different type of statement to exist within an overarching priorities ruleset, which creates a separate requirement that then counts the number of services which fulfil the requirement. This may be necessary where numerous small teams operate simultaneously.

[0116] To form Tier 3 of the rota, there is an allocation algorithm. The personnel pool data input PPDI, personnel requirement data input PRDI, and rota assignment-prioritisation data input RAPDI provide the necessary information about when staff are working, and the algorithm then assigns the staff to exactly what they should be working. How the algorithm achieves this is performed by analysis of service quality, continuity, and fairness, which will be described in more detail. There are, however, typically large numbers of possible solutions to create the rota to provide optimised service quality, and it is at that point that the actual rota is generated by reviewing continuity, and fairness.

[0117] To optimise service quality, all of the prepared requirement rulesets REQR and priority ruleset PRIR are combined to produce an expanding metaset, which is outlined in detail in Figures 11 to 15C. Figure 11 shows a representation of an exemplary specialty 20 which has five services Si , S2, S3, S4, S5, and which are grouped by service category Ci , C2, C3. Said services Si , S2, S3, S4, S5 may have different statuses as to whether staff working on them are contactable. It is noted that Figure 6 shows some services on which any staff working on are deemed contactable by staff working on other services.

[0118] There is a requirement ruleset REQR(A), REQR(B), REQR(C), REQR(D), REQR(E) associated with each of the services Si , S2, S3, S4, S5, as shown in Figures 12A to 12E, and which illustrate the various requirement statements REQS to meet the service-provision-quality thresholds SPQT. The content of the requirement statements REQS illustrated makes for a drastically more soluble problem, and therefore simpler for the reader to understand. It will be apparent, however, that a true requirement ruleset REQR will likely be far more complex.

[0119] Figure 13 shows the overarching priority ruleset PRIR for the specialty, and reproduced below:

[0120] To reach level 1 , the first service Si must meet the Minimal threshold. To reach level 2, the second service category C2 must meet the Minimal threshold. This is applied for the entire priority ruleset PRIR. Level 5 shows a slightly different requirement, since a single requirement statement REQS has been included in lieu of a specific service-provision-quality threshold SPQT. Said requirement statement REQS is an evaluation against a subset of services.

[0121] Figure 14 shows an indicative starting position for generating a third tier data T3 of a rota. Notably, there is pre-existing information relating to personnel already working in specific services; this may have arisen due to pre-existing shift instructions, and therefore places an additional limitation on the allocation algorithm. The remaining personnel are unassigned at present. This information forms the dynamic part dPD of the personnel pool data input PPDI.

[0122] The example here considers that the only parameter of relevance is {Role}, where Cons>Reg>SHO>FY1 . It will of course be apparent that this is merely instructive for the purpose of the present example, and that in practice a wide range of different parameters are available.

[0123] A first-level metaset 22(A) is produced by substituting the requirements for any operational service into the priority ruleset PRIR one level at a time. In the present example, as indicated in Figure 14, the fourth service S4 is not operating during the interval this evaluation is taking place. This first-level metaset 22(A) is shown in Figure 15A. There are numerous ways in which the first service S1 can be filled with at least one consultant and two other lower-seniority personnel; this is the first, Minimal, service-provision-quality threshold SPQT for the first service Si. In total, there are 3124 possible allocations; the algorithm would typically not count the total number of solutions, however, only identifying that the metaset 22(A) is solvable.

[0124] The second-level metaset 22(B) is shown in Figure 15B, in which the second level criteria are met. This requires the second category C2 to meet the first, Minimal, service-provision-quality threshold SPQT, which in practice means that both the second and third services S2, S3 must meet said service- provision-quality threshold SPQT.

[0125] This process continues until a level is reached in the priority ruleset PRIR which cannot be fulfilled. Here, as shown in Figure 15C, the sixth-level metaset 22(C) can be generated, with a total of 120 possible solutions, but the seventh-level metaset cannot be filled.

[0126] This allocation process therefore results in the generation of possible viable rotas. At present, the allocation process is determined by dynamic programming with bipartite graph methodology.

[0127] It is noted that the ‘Overstaffed’ requirement may not be added to the metaset in the present invention, on the presumption that all personnel must be allocated. The ‘Overstaffed’ indicator would then be applied to the final rota, as applicable.

[0128] However, if there is a paucity of a particular grouping of personnel, for instance, there were few or no doctors of a particular seniority, then this can limit the progress of the metaset generation. In this instance, the allocation algorithm may have the capacity to generate a phantom entity which is assignable to the metaset. This phantom entity has the advantage of allowing further allocation of personnel at higher levels, and then identifying automatically where supply or locum personnel are required for an otherwise optimised rota. This pre-emptive identification of phantom entities is extremely valuable to rota co-ordinators, as this information would not be traditionally visible until after the rota had been filled. Within the present system architecture, there is a differentiation between a phantom and a placeholder. A phantom is a temporary user added during the operation of an allocation algorithm for a given interval. It is only added if progression through the metaset is halted by a shortage. No phantoms are required if a metaset stops when all doctors are allocated. The phantom does not appear in the rota itself, but represents the exact specifications for locum staff to be hired.

[0129] A placeholder is a temporary user that is created for the duration of a rotation, that is, within the first data tier T1 . It is a marker for an anticipated hire. The placeholder would then be visible in the rota itself.

[0130] Once the initial allocation process is complete, there will be a plurality of equally valid potential solutions to a metaset. Rationalising which solution of the metaset is selected for the finalised rota requires further data evaluation.

[0131] Optimisation based on service quality may be evaluated on an interval-by-interval basis, with an intention to identify and minimise discontinuities, where information may be lost from a service by the transition of personnel between services. This is achieved by comparison of the output from consecutive intervals. However, allocation can be performed over any timescale, including but not limited to, one interval in a day, an entire day, or many days, with all allocations per interval being calculated within the range.

[0132] Where a member of staff leaves a service without a handover or shift overlap, there will be a clear loss of information during the implementation of the service. This is a hard discontinuity, within the context of the present system. Where a member of staff arrives on shift mid-service implementation without a handover or shift overlap, the personnel will be operating underinformed for some amount of time, resulting in what is known as a soft discontinuity, within the context of the present system.

[0133] An evaluation criterion can therefore be implemented based on historical or future service implementation data to reduce service discontinuities, to provide further selection information for generating the rota from the metaset.

[0134] A further evaluation criterion might be fairness, wherein personnel themselves are distributed as equally as possible across the range of services appropriate for their characteristics, particularly seniority and specialism. One or more allocation preferences can be applied, which may be controlled by the system or by the personnel themselves via their own user interfaces, inasmuch as it is feasible for the personnel to have input into their own rostering preferences. Since fairness has the ability to have the least impact on service provision, it is the least prioritised evaluation criterion.

[0135] One method of calculating fairness is as follows. Each staff member may be able to set, or have assigned, a preference value for a given service or service category, which can then be tabulated or otherwise monitored across the services to be rostered. A specific relative frequency might be defined as follows:

[0136] This is the normalised relative frequency, where there are / staff members, and j services or service categories.

[0137] A service count (x) records the number of intervals that the staff member has worked during their time (f) days on the rotation. This allows an absolute frequency f to be produced for each staff member on each service:

[0138] A least-squares linear regression analysis can be applied, for example, for each service, producing a further coefficient:

[0139] „ > £ (fijrij) j K j2)

[0140] This allows an inferred relative frequency to be calculated for every staff-service pairing available: tj = Pjfii

[0141] Finally, a difference A between the target relative frequency and the inferred relative frequency is minimised algorithmically:

[0142] Fairness can thus be codified as being the mitigation of the largest A possible, where the A value can be interpreted as a metric of unfairness. Minimising the sum of A across an entire team might seem preferable, but could yield results where certain staff members are treated very unfairly whilst improving equal treatment of remaining staff.

[0143] The fairness evaluation should unambiguously yield a single preferred rota from the metaset, following application of the service quality evaluation criteria, thereby completing the process automatically generating an optimised third tier T3 rota data in a manner not performable by a human rota coordinator incapable of managing the data available.

[0144] As noted above, equipment can also be rostered within the present system 10, and said rostering can be modelled in the same manner as for personnel. However, there is no issue with service continuity or fairness, nor leave, but additional parameters, such as maintenance downtime may be required in addition. Shortage of equipment at present can lead to cancellation of services, and therefore simultaneous rota generation with equipment rostering can eliminate scenarios where well-staffed services are disrupted by lack of equipment.

[0145] Thus far, the rota generation process has been defined as being a one-off generation process, creating a single rota output. However, the personnel pool data input PPDI is a dynamic data set, allowing users the power to modify the rota without collapsing service provision, thanks to the processing capabilities of the present method and system.

[0146] It is possible to create a reallocation algorithm having additional inputs for determining what changes are feasible to the rota without negatively impacting the rota. This will be the implementation of the standard allocation algorithm, but applied to either provisional or published rota data.

[0147] It is noted that provisional data is here defined as a preliminary plan for a rota, and is therefore a starting point for the generation of a subsequent rota. This may be an artefact of the system 10, and may never be shared with a rota co-ordinator, but may be required for processing. However, the rota co-ordinator may be able to access and modify provisional data prior to more general publication. Published data is that which takes the form of a rota which has been shared with at least the rota coordinator, and may have been shared with end users 16 as well. Once a rota is published, further changes should be kept to a minimum to limit disruption.

[0148] Rota co-ordinators can run as many functions as desired for any period of data, to visualise the outcome. Once different scenarios have been tried, publication of a new rota can be committed. Changes made may not necessarily be the most optimal, so as to avoid disruption. There are competing factors to be considered. Simple rota changes, such as direct shift swaps, has the least impact on the ability for other staff members to plan their lives, whereas complex rota changes may affect more people, but may produce the most optimum rota from a service provision perspective.

[0149] Running of the reallocation algorithm on a published rota creates disruption, and this should be accounted for when triggering. The rota co-ordinator may therefore have override authorisation for activation of the reallocation algorithm. However, some changes may necessitate triggering of the reallocation algorithm, particularly changes in staff availability, and changes in the operation of services. This may be automatic, where there is unavoidable disruption.

[0150] The first category of reallocation is the accommodation of leave, such as annual leave, training leave, sickness leave, etc. via the platform. Leave will be readily visible to users via their user interfaces. As such, the least disruptive days to take leave for a specific user will be visible to them; the system can run the reallocation algorithm for each instance of leave considered being requested and display indicators of a desirability of leave being taken. The integration of leave requests into the present system can allow for pre-allocation of suitable training opportunities for staff.

[0151] Equally, there may be functionality present for determination of optimal leave, that is, looking at the time at which a staff member has left a rotation and finding the days with the least impact on the operational team. In this scenario, if a staff member has not identified when their preferred leave may be, the system 10 can automatically display to the end user 16 when the system-preferred leave for that individual would be.

[0152] In practice any of these functions, which can be considered higher order functions to rota operation, that is, anything modifying shift data, require recursive triggering of the allocation algorithm before finalising a rota.

[0153] Different types of leave may be handled in different manners. Annual leave is more than likely to need conditional approval in advance, allowing the system to pre-emptively resolve rota issues. Sickness leave on the other hand tends to be urgent, and thus if a staff member registers as sick on a given day, the system will be authorised to automatically perform a reallocation algorithm and pass to a rota co-ordinator for urgent review, or automatically publish an updated rota.

[0154] As such, automation of decision making can be handled in three potential ways: fully manual, in which all decisions are human-authorised; conditionally automatic, in which all decisions that pass predetermined relevant criteria are automatically granted, otherwise human intervention becomes necessary; and fully automatic, in which all decisions that fail to pass pre-determined relevant criteria are automatically rejected. In the latter scenario, no human rota co-ordinator is required. Decision making steps include: any allocation or reallocation algorithm run; a leave request; a swap request; a generation of a novel rota. Each of these can be previewed in advance, where the system is manual or conditionally automated, and the rota co-ordinator can make appropriate acceptances or rejections.

[0155] The automation of the decision-making process can be achieved, in full or in part, by the use of artificial intelligence or machine learning. For instance, training data can be provided in which a service score is applied to the finally-generated rota, with the service scores being used as input to the artificial intelligence or machine learning algorithms, so as to train the data and enable the generation of automated new rotas.

[0156] The system also has, for the same reasons, the capability to swap shifts between staff members on the rota. In otherwords, this is amendment of second tier rota data T2. In a medical context, this would ordinarily be a time-intensive process for doctors and rota co-ordinators, which is why current rostering systems are not flexible. The system will need to factor in worktime restrictions as required, and therefore may only display potential swaps between allowable staff members. Ordinarily, when a shift swap occurs, the doctors might be from different specialities, which may have a negative impact on potential coverage in other services within the specialties of the swapped doctors

[0157] In the present system, there will be a personnel choice data input for personnel to modify their rota- availability data, which occurs after the initial rota has been generated. This is discrete from the personnel pool input data PPDI, which comprises more static information. Potential rota amendments based on the modified rota-availability data can then be identified, ideally through a user interface of the user’s device. The reallocation algorithm can then be re-applied, thereby re-calculating the assignment of the personnel members based on the potential rota amendments. Once all staff members involved in the swap have approved it, the entire request can either be submitted for manual review by a rota co-ordinator to approve or reject it, or automatically approved by the system if its total effect on all teams involved is above a pre-set level of service provision.

[0158] It will be appreciated that there may be many different scenarios which might require a reallocation algorithm instance, such as: leave request; other absence request; an assessment of optimal leave, that is, identification of leave with the least disruptive reallocation; shift swap, or multi-person shift swap; novel rota generation; combinations thereof, as well as any other possible disruptive modifications to the published rota.

[0159] An example of a display 24 of the effects of a leave with swap function applied on an existing rota is shown in Figure 16 for two different specialities, Respiratory and Cardiology specialties respectively, with the coloured dots representing individual services and their service-provision-quality thresholds SQIO which have been met thus far. The first column for each speciality is the existing rota allocation fora given day. The second column is the post-swap rota allocation, with the coloured arrows between the columns representing the desirability of the swap as rota change indicators RCI. The third column is the post-swap rota allocation following a re-allocation algorithm having been performed to optimise the final rota.

[0160] The rota change indicators RCI provide the users and rota co-ordinators with a mechanism for assessing the desirability of a particular swap.

[0161] The process thus described is highly reactive, being responsive to change requests. However, the system is capable to pre-emptively identify potential swaps which are viable, by pre-calculating the relevant data upfront before presenting the availability of desirable swaps to staff members through their user devices 18. A user interface 26 showing the desirability of seven potential swaps available to a user, categorised by desirability, is illustrated in Figure 17. Here, there are three desirability levels: those having a beneficial effect to service provision; those having no discernible effect to service provision; and those having a disruptive effect to service provision. Severely disruptive swaps may be obscured, preventing staff members from utilising them. Further swaps 28 may be viable than may be otherwise trackable by users interacting directly with one another using the present system. For example, three- or four-way swaps may be feasible, as illustrated in Figure 18. Calculated swaps can thus be pre-emptively determined to be mutually beneficial across multiple specialties. This is then much less disruptive to the remaining teams, and takes far less staff or co-ordinator time to organise. Multi-way swaps are helpful for accommodating multiple staff members’ needs simultaneously, since direct swaps cannot accommodate all desires easily. The greater difficulty of calculation of swap effects is resolved within the present system, n- way swaps can be accessed by staff members if, for instance, the list of two-way swaps is unsatisfactory, at which point, additional staff members can be considered in the swap calculations displayed.

[0162] Additionally, since personnel can highlight their preferences for leave or specific scheduling, for instance, via modification of their fairness parameters, the rota can be generated with preferences inbuilt, and therefore the initial rota generated can be built from a fixed template which is already accommodating to the standard desires of staff members.

[0163] A mechanism for novel rota generation can also be created within the present system, in which second tier data T2 and third tier data T3 is generated purely from first tier data T1 . This concept is outlined in Figure 19. Once a staff member has been added into a rotation, that is a time-limited working period, for a specialty, novel rota generation will be able to fully create their shift pattern across the entire rotation. This can be achieved by a personnel pool data input PPDI which is a pure list of the staff members available at any given time. Rather than rigidly sticking to a template rota pattern, the novel rota generation can automatically calculate shifts, and place staff members onto services. All steps, including allocation, can therefore be automated, bypassing the need for a rota co-ordinator.

[0164] Notably, this is different to the above-described methodology, in that data in that second tier data T2 is generated in addition to third tier data T3.

[0165] Figure 19 shows how an exemplary eight-week rota template 30 might be expanded over sixteen weeks in a default rota schedule 32, on the left-hand side, which is merely a concatenated version of the rota template taken from the fourth week in the eight-week rota template 30. The individual colours represent different shift types, such as late or night shifts.

[0166] The right-hand column, on the other hand, shows the novel rota schedule 34. Individual shifts can be shifted around, in keeping with working practice directives, in order to create more consistent staffing levels within Specialties: avoiding the peaks and troughs that emerge from the default method.

[0167] The variability of this type of shift pattern system is advantageous since deleterious effects can be created by forcing staff members into rigid working patterns. For example, if there are multiple different grades of staff working over closely related specialties, different rota templates can align to form undesirable staffing levels; if too many doctors from one speciality are working on-call, on nights, or on post-night zero days, then a speciality can easily become understaffed and unsafe, whereas if too few are taking scheduled time away, then the service will easily become overstaffed.

[0168] To achieve the novel rota generation from a technical perspective, there are repeated iterations of the allocation algorithm and swap algorithm performed on a shift template, then sequentially targeting the most poorly-staffed days in the live rota with repeated optimal swapping, that is selecting the best swap possible for each day to be rectified, until a point is reached that most swaps are net-neutral rather than net-beneficial.

[0169] Machine learning techniques are ideally suited towards resolving this problem, by feeding multiple stochastic rotas into, for example, a neural network, using service-provision-quality thresholds SPQT and priority rulesets PRIR as ordinal fitness functions, from which subsequent output can be evaluated

[0170] It may be feasible to provide one or more global rota modifiers, which could be pre-set based on certain unplanned or emergency situations. Examples of such situations may be hospital winter pressures, critical lack of hospital beds, a major accident or emergency, ora pandemic. Each situation may have significant changes required to overall service provision. A global rota modifier, that triggers an automatic reallocation algorithm allows for optimization of the operational or available staff without needing to manually generate a special rota. In practice this automatic reallocation changes which services may be operational, and potentially changing the individual requirements for the service, via a modification of requirement statements REQS or priority rulesets PRIR. Having such a setting allows for facile redeployment of staff within such emergency conditions, given the time critical nature of the situation and the need for rapid, widespread and consistent communication, since the personnel requirement data input PRDI changes can be identified and modified ahead of schedule.

[0171] The connectivity of the present system allows for communication between the users thereof. One element which can be incorporated is a digital baton, which is passed digitally between users. This requires the users to perform a handover step at shift change, in which a digital baton or similar token is transferred between their user accounts. This could be performed manually by the users, but will more likely automatically transfer between users within the system to mitigate the possibility of users forgetting to handover. Notably, such an addition can only be included where the rota is a single source of truth, so that the digital baton is passed automatically to the correct individual. The digital baton acts as a tracker or identifier of the staff member responsible for a specific service, and therefore significantly reduces the complexity of identifying where the relevant person to contact in the case of an emergency is. This is a particularly challenging objective to achieve within a hospital setting. In an emergency context, this greatly simplifies the identification and contacting of the relevant physician. However, transfer of digital batons is useful in all specialties. It will be apparent that a rota must be generated first, in order for staff to make use of the digital baton provisions. However, external entities within the same organisation may be able to access the rota generation system as a communications mechanism, bleeping, texting, messaging, or otherwise contacting the relevant staff member.

[0172] The concept of digital batons may be extended so that each individual team may have a set of digital batons, with functionality differing between individual teams. It may then be possible to publish the digital batons to a live directory. For example, in a hospital context, the digital baton of a responsible doctor may be visible to external organisations, such as local general practices. The live directory effectively creates a universal live visible output of responsible persons to the wider world.

[0173] Indeed, the live directory process can be extended beyond the scope of an individual location. By way of example, tertiary centres can publish selected digital batons to the directories of hospitals it provides coverage for; similarly some hospital departments can publish their batons to the directories of local general practices. This enables a general practitioner to directly phone the registrar of a relevant specialty in the local hospital, without prior knowledge of their number of who they are. Instead, the system 10 looks up the relevant information, allowing the general practitioner to get specific advice. Similarly, a medical doctor in a typical hospital could directly phone the, for example, neurosurgical or liver ITU teams in different hospitals, massively bypassing the slow and often information-losing interhospital communication processes.

[0174] It is therefore possible to provide a method of automatically producing a rota for a service provider providing a plurality of services, each of the plurality of services having different personnel requirements. Identification of discrete service-provision-quality thresholds allows for the logistical data to be analysed and classified, such that an optimisation algorithm can be used to allocate staff effectively, without damaging service provision, and fairly.

[0175] The words ‘comprises / comprising’ and the words ‘having / including’ when used herein with reference to the present invention are used to specify the presence of stated features, integers, steps, or components, but do not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof.

[0176] It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.

[0177] The embodiments described above are provided by way of examples only, and various other modifications will be apparent to persons skilled in the field without departing from the scope of the invention as defined herein.

Claims

Claims1 . A method of automatically producing a rota for a service provider providing a plurality of services, each of the plurality of services having different personnel requirements, the method comprising the steps of: a] providing a personnel pool data input (PPDI), wherein the personnel pool data input (PPDI) comprises at least rota-availability data of personnel members of a personnel pool to be entered into the rota; b] providing a personnel requirement data input (PRDI), wherein the personnel requirement data input (PRDI) comprises service-provision-requirement data associated with each of the plurality of services, wherein the service-provision-requirement data for each of the plurality of services includes a plurality of service-provision-quality thresholds; c] providing a rota assignment-prioritisation data input (RAPDI) indicative of a prioritisation sequence for each of the plurality of service-provision-quality thresholds (SPOT) for each of the plurality of services; d] calculating an optimised assignment of the personnel members to the plurality of services based on a combination of the personnel pool data input (PPDI), the personnel requirement data input (PRDI), and the rota assignment-prioritisation data input (RAPDI); e] generating a rota based on an output of step d]; f] publishing the rota; g] providing a personnel choice data input for personnel to modify their rota-availability data; h] identifying potential rota amendments based on the modified rota-availability data, wherein there is provided a rota change indicator indicative of a net effect to the rota based on the potential rota amendments; i] re-calculating the assignment of the personnel members based on the potential rota amendments; j] generating a modified rota based on an output of step i]; and k] publishing the modified rota.

2. A method as claimed in claim 1 , wherein the personnel pool data input (PPDI) further comprises personnel specialism data.

3. A method as claimed in claim 1 or claim 2, wherein the service provider is a medical service provider.

4. A method as claimed in any one of the preceding claims, wherein there are at least three service-provision-quality thresholds (SPQT) for each of the plurality of services.

5. A method as claimed in claim 4, wherein there are five service-provision-quality thresholds (SPQT) for each of the plurality of services.

6. A method as claimed in any one of the preceding claims, wherein during step f], the rota is published to all of the personnel members.

7. A method as claimed in any one of the preceding claims, wherein the rota assignment prioritisation data input (RAPDI) further comprises a priority ruleset (PRIR) indicative of an overall prioritisation sequence for the plurality of services, based on the said prioritisation sequence for each of the plurality of service-provision-quality thresholds (SPQT).

8. A method as claimed in claim 7, wherein during step e], the generated rota is selected from a plurality of generated rotas, each of the plurality of generated rotas fulfilling the overall prioritisation sequence.

9. A method as claimed in claim 8, wherein during step e], at least one further evaluation criterion is applied to the plurality of generated rotas to select the generated rota.

10. A method as claimed in claim 9, wherein the at least one further evaluation criterion comprises historical or future service implementation data to reduce service discontinuities.11 . A method as claimed in claim 9 or claim 9, wherein the at least one further evaluation criterion comprises rostering fairness data.

12. A method as claimed in any one of the preceding claims, wherein the personnel pool data input (PPDI) comprises a placeholder or phantom entity indicative of locum or supply personnel.

13. A method as claimed in claim 12, wherein the phantom entity is characterized during step d] to improve compliance with at least one of the service-provision-quality thresholds (SPQT).

14. A method as claimed in any one of the preceding claims, further comprising a step of assigning a digital baton to a user account of the assigned personnel members for the plurality ofservices during a live period of the rota, the digital baton being transferrable between user accounts as responsibility for the plurality of services changes between personnel members.

15. A method as claimed in any one of the preceding claims, further comprising a step of applying a global rota modifier, based on a pre-determined operational condition.

16. A method as claimed in any one of the preceding claims, further comprising a step prior to step d] of providing an equipment data input, wherein the equipment data input (EDI) comprises at least rota-availability data of equipment to be entered into the rota, and wherein step d] further comprises calculating an optimised assignment of the personnel members and equipment to the plurality of services based on a combination of the personnel pool data input (PPDI), the personnel requirement data input (PRDI), the equipment data input (EDI), and the rota assignment-prioritisation data input (RAPDI).

17. A method as claimed in any one of the preceding claims, wherein during step e] the generation of the rota is based on a rota template.

18. A method as claimed in any one of claims 1 to 16, wherein during step e], the generation of the rota comprises altering shift patterns of the personnel members to generate a novel rota.

19. A method as claimed in any one of the preceding claims, wherein at least steps d] and e] are performed automatically.

20. A method as claimed in claim 19, wherein steps d] and e] are performed using artificial intelligence and / or a machine learning algorithm.

21. A computer program product configured for implementing the method of any one of the preceding claims.

22. A system (10) for automatically producing a rota for a service provider providing a plurality of services, each of the plurality of services having different personnel requirements, the system (10) comprising: a personnel pool data input (PPDI), wherein the personnel pool data input (PPDI) comprises at least rota-availability data of personnel members of a personnel pool to be entered into the rota; a personnel requirement data input (PRDI), wherein the personnel requirement data input (PRDI) comprises service-provision-requirement data associated with each of the plurality of services, wherein the service-provision-requirement data for each of the plurality of services includes a plurality of service-provision-quality thresholds (SPOT);a rota assignment-prioritisation data input (RAPDI) indicative of a prioritisation sequence for each of the plurality of service-provision-quality thresholds (SPQT) for each of the plurality of services; and a processor (12) configured to calculate an assignment of the personnel members to the plurality of services based on a combination of the personnel pool data input (PPDI), the personnel requirement data input (PRDI), and the rota assignment-prioritisation input (RAPDI), and subsequently generate and publish a rota based on the said calculation.

23. A system as claimed in claim 22, wherein the system is accessible via a user interface of a personal computing device (18) associated with each of the plurality of personnel.

24. A system as claimed in claim 22 or claim 23, wherein the processor is provided as part of a central server (14).

Images