WO2015117200A1

WO2015117200A1 - Scheduling bookings

Info

Publication number: WO2015117200A1
Application number: PCT/AU2015/050038
Authority: WO
Inventors: Steven DAHL; Staffan FLODIN
Original assignee: Smart Clinics Pty Ltd
Priority date: 2014-02-05
Filing date: 2015-02-05
Publication date: 2015-08-13
Also published as: AU2015213482A1

Abstract

This disclosure relates to scheduling bookings. A processor first receives a request for the booking. The request comprises request data indicative of a starting time of the booking and of a booking type. The processor then determines based on the starting time of the booking and based on durations of a selection of most recent historical bookings of the booking type, a value indicative of a probability for the booking finishing before a time limit. Finally, the processor determines whether the value satisfies a predetermined condition based on the time limit and if it does, the processor stores the starting time associated with the request data to schedule the booking for the starting time. This way, bookings can be scheduled even in cases where a booking with a deterministic normal duration for this appointment type would not fit into the available time slot.

Description

"Scheduling Bookings"

Cross -Reference to Related Applications

The present application claims priority from Australian Provisional Patent Application No 2014900340 filed on 5 February 2014, the content of which is incorporated herein by reference.

Technical Field

This disclosure relates to scheduling bookings. In particular, but not limited to, this disclosures relates to a method, software and computer system for scheduling a booking.

Background Art

Many medical practices rely on booking systems to schedule bookings, such as doctor's appointments for patients. Typically, patients call the medical practice with particular dates and times in mind when a booking would suit. A receptionist of the medical practice can then query the roster and existing schedule and organise a starting time for an appointment with the patient over the phone. However, it is difficult for these practices to schedule bookings such that the individual doctors are booked with minimal gaps in their working day while, at the same time, avoiding long waiting times for the patients.

Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each claim of this application. Throughout this specification the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps. Disclosure of Invention

A computer implemented method for scheduling a booking comprises: receiving a request for the booking, the request comprising request data indicative of a starting time of the booking and of a booking type;

determining based on the starting time of the booking and based on durations of a selection of most recent historical bookings of the booking type, a value indicative of a probability for the booking finishing before a time limit;

determining whether the value satisfies a predetermined condition based on the time limit and if it is determined that the value indicative of the probability satisfies the predetermined condition storing the starting time associated with the request data to schedule the booking for the starting time.

The method schedules the booking if the value indicative of the probability for the booking finishing before the time limit satisfies a predetermined condition. For example, it is sufficiently likely that the booking will finish before the end of the day. As a result, bookings can be scheduled even in cases where a booking with a deterministic normal duration for this appointment type would not fit into the available time slot. Therefore, available time in a scheduler can be used more efficiently, which is an advantage over other methods which assume a fixed duration of each booking. Using the above method, bookings can be allowed to run over time as long as the probability for doing so still satisfies the condition.

Further, the value indicative of the probability is based on durations of a selection of most recent historical bookings. This allows the value to adapt over time to changing durations, such as by service providers becoming more experienced. This is an advantage over considering the entire historical population because considering the entire historical population would lead to a very slow adaption rate.

Even further, the selected historical bookings are of the particular booking type. As a result, the population for the determination of the value indicative of the probability is even smaller and even more specific to the booking type. Therefore the value is more accurate, which is an advantage over methods which do not distinguish between different booking types.

Storing the starting time may comprise storing an association between the starting time and a service provider identifier. The method may further comprise receiving the service provider identifier, wherein the selection of most recent historical bookings is a selection of most recent historical bookings of a service provider that is identified by the service provider identifier. The service provider identifier may be associated with a health care professional.

The booking type may be one of multiple medical issues of a patient.

The time limit may be a starting time of a subsequent scheduled booking.

The time limit may be an end time of a work period.

The method may further comprise:

determining based on the durations of the selection of most recent historical bookings a predicted duration of the booking such that a further value indicative of a further probability that the booking finishes within the predicted duration of the booking satisfies a further predetermined condition,

wherein storing the starting time comprises storing the starting time associated with the predicted duration.

The predetermined condition may be based on multiple values each indicative of a probability for a previously scheduled booking finishing before a respective time limit.

Determining the value indicative of the probability based on the durations may comprise determining the value indicative of the probability based on a probability function approximating a distribution of the durations.

The probability function may be based on one or more distribution parameters and determining the value indicative of the probability based on the durations comprises selecting the one or more distribution parameters based on the booking type.

The probability function may be a normal distribution function and the distribution parameters are mean and standard deviation. Determining the value indicative of the probability may be based on a logarithm of the durations. The selection of most recent historical bookings of the booking type may comprise a selection of historical bookings of the booking type that are younger than a predetermined age threshold.

The selection of most recent historical bookings of the booking type may comprise a selection of a predetermined number of most recent historical bookings of the booking type. The method may further comprise generating a user interface comprising a first selection to allow a user to provide the starting time and a second selection to allow the user to provide a booking type.

The method may further comprise upon detecting that the user has selected a booking type generating a user interface comprising a third selection comprising options for a booking sub-type based on the selected booking type, wherein determining the value indicative of a probability is based on durations of a selection of most recent historical bookings of the booking sub-type. Software installed on a computer causes the computer to perform the above method.

A computer system for scheduling a booking comprises:

a data port to receive a request for the booking, the request comprising request data indicative of a starting time of the booking and of a booking type;

a processor

to determine based on the starting time of the booking and based on durations of a selection of most recent historical bookings of the booking type, a value indicative of a probability for the booking finishing before a time limit,

to determine whether the value satisfies a predetermined condition based on the time limit and if it is determined that the value indicative of the probability satisfies the predetermined condition to store the starting time associated with the request data to schedule the booking for the starting time; and

a data store to store the starting time associated with the request data. Optional features described of any aspect of method, computer readable medium or computer system, where appropriate, similarly apply to the other aspects also described here. Brief Description of Drawings

An example will be described with reference to

Fig. 1 illustrates a computer system for scheduling a booking.

Fig. 2 illustrates a method for scheduling a booking.

Fig. 3 illustrates a user interface for entering identification details.

Fig. 4 illustrates a user interface for selecting a booking type.

Fig. 5 illustrates a user interface for selecting a booking sub-type.

Fig. 6 illustrates a user interface for selecting a proposed starting time.

Fig. 7 illustrates a database that stores historical bookings.

Fig. 8 is a scatter plot of historical bookings.

Fig. 9 illustrates an example schedule.

Fig. 10 illustrates a cumulative probability function.

Best Mode for Carrying Out the Invention

Fig. 1 illustrates a computer system 100 for scheduling a booking. The computer system comprises a processor 102 connected to a program memory 104, a data memory 106, a communication port 108 and a user port 110. The program memory 104 is a non-transitory computer readable medium, such as a hard drive, a solid state disk or CD-ROM. Software, that is an executable program, stored on program memory 104 causes the processor 102 to perform the method in Fig. 2, that is, processor 102 receives a request for a booking, determines a value indicative of a probability for the booking finishing before a time limit, determines whether that value satisfies a predetermined condition and if it does so, the processor 102 stores a starting time associated with the request on data memory 106 to schedule the booking. The processor 102 may receive data, such as request data, from data memory 106 as well as from the communications port 108 and the user port 110, which is connected to a display 112 that may show a visual representation 114 of a current booking schedule to a user 116, such as the receptionist or the doctor. In one example, the processor 102 receives request data from another computing device, such as a smart phone 118 operated by a patient 120, via communications port 108, such as by using a 3G, LTE, Wi-Fi network according to IEEE 802.11, the Internet or any combination of these or other technologies. Of course, the smart phone 118 may be replaced by other devices, such as a Personal Computer or tablet computer.

In one example, the processor 102 receives and processes the request data in real time. This means that the processor 102 schedules a new booking every time request data is received and completes this calculation before another patient device sends the next booking request.

Although communications port 108 and user port 110 are shown as distinct entities, it is to be understood that any kind of data port may be used to receive data, such as a network connection, a memory interface, a pin of the chip package of processor 102, or logical ports, such as IP sockets or parameters of functions stored on program memory 104 and executed by processor 106. These parameters may be stored on data memory 106 and may be handled by- value or by-reference, that is, as a pointer, in the source code.

The processor 102 may receive data through all these interfaces, which includes memory access of volatile memory, such as cache or RAM, or non-volatile memory, such as an optical disk drive, hard disk drive, storage server or cloud storage. The computer system 100 may further be implemented within a cloud computing environment, such as a managed group of interconnected servers hosting a dynamic number of virtual machines.

It is to be understood that any receiving step may be preceded by the processor 102 determining or computing the data that is later received. For example, the processor 102 may generate a request for a booking including request data and stores the request data in data memory 106, such as RAM or a processor register. The processor 102 then reads the data from the data memory 106, such as by providing a read signal together with a memory address. The data memory 106 provides the data as a voltage signal on a physical bit line and the processor 102 receives the request data via a memory interface.

Fig. 2 illustrates a method 200 as performed by processor 102 for scheduling a booking. The method 200 may be implemented in software, such as .Net or Java, and computer system 100 may be a web-server with processor 102 executing method 200. In one example, processor 102 generates HTML user interfaces according to Figs. 3 to 6 and sends the HTML code to smart phone 118. Smart phone 118 displays the user interfaces and allows patient 120 to prepare a request for a booking.

Fig. 3 illustrates a user interface 300 displayed on smart phone 118 for entering identification details. Although the following examples implement the user interface 300 as a website, it is also possible to implement the user interface 300 as a smart phone app installed via Apple's App Store or Google Play, for example.

User interface 300 comprises a first name field 302, last name field 304, phone number field 306 and email address field 308. Patient 120 provides all the required data and smart phone 118 sends the data to computer system 100. It is noted that the user interface 300 may alternatively be presented to the patient 120 at the end of the booking process. Further, features in user interfaces described in this description may be displayed all at the same time or separately in a sequence depending on screen size and preferences.

Fig. 4 illustrates a user interface 400 for selecting a booking type, such as possible medical issues of a patient. User interface 400 comprises three categories: preventative care 402, routine treatment 404 and health management 406. Each of the categories 402, 404 and 406 comprises multiple different booking types. In this example, patient 120 selects booking type "minor illness" 408.

Fig. 5 illustrates a user interface 500 for selecting a booking sub-type after the patient 120 has selected the booking type 'Minor Illness' 408 in Fig. 4. In this example, user interface 500 is essentially the same interface as user interface 400 in Fig. 4 with the difference that the 'Minor Illness' 408 option is now expanded to show a list 502 of sub-types that are defined for that type. For the method 200 performed by processor 102 it is of little relevance whether a booking type or a booking sub-type is specified by patient 120 and therefore, throughout this specification, the term 'booking type' also includes 'booking sub-type'.

Fig. 6 illustrates a user interface 600 for selecting a proposed starting time. User interface 600 presents the patient 120 with multiple options for the starting time of a new booking. For example, a first starting time 602 is 10: 10 am. The patient 120 selects starting time 602, such as by tapping the touch screen of the smart phone 118 or by using a computer mouse. Of course, if none of the proposed starting times suit the patient 120, the patient can select a different time of day or a different day altogether, such as by selecting a button labelled "calendar" (not shown).

It is noted that the list of starting times in user interface 600 may be created based on existing bookings as will be explained below. Processor 102 may also create the list of starting times by creating a starting time every 30 minutes or every 20 minutes.

Referring back to Fig. 2, the processor 102 receives 202 a request for a booking, such as by the patient 120 selecting a "request booking" button after providing the relevant values. The request for the booking comprises request data, such as HTML POST or GET data. Further, AJAX may be used to transmit the data to the processor 102. The request data is indicative of the starting time selected by patient 120 and of the booking type selected by the patient 120. It is noted here that the booking request does not necessarily have to be received in one single communication step.

For example, the patient 102 selects the booking type in Figs. 4 and 5 and the processor 102 receives this booking type. The processor 102 then creates a list of starting times, such as a list of times every 30 minutes over a time slot between existing bookings that has no bookings so far. The patient 120 selects starting time 602 and the processor 102 receives the starting time as part of the booking request. It should be understood that in some examples, the processor 102 receives the actual booking type, such as "minor illness", and the exact starting time, such as "10: 10AM", while in other examples, the processor receives an index or parameter that is indicative of to the actual values, such as "Ti" for the above booking type or "24" for the actual starting time, assuming the time slots are indexed.

Further, it is to be understood that the starting time may or may not be provided by the patient 120. For example, the patient 120 may provide a suitable time and processor 120 queries a list of existing scheduled bookings. The processor 120 identifies a gap between two existing scheduled bookings and determines the starting time of the requested booking as the finishing time of the previous booking.

The processor 102 then determines 204 a value indicative of a probability for the booking finishing before a time limit, such as a subsequent scheduled booking or the end of the working day of a particular doctor. Determining that indicative value in step 204 is based on a selection of most recent historical bookings of the booking type. During the operation of the medical practice, multiple patients consult with the individual doctors. Each doctor has a running sheet of which patients have bookings for that particular day. In one example, the doctor operates a computer system that hosts a consulting work flow which guides the doctor through appointments with multiple different patients. The doctor interacts with that consulting work flow and from that interaction, the start time, end time and duration can be automatically determined and sent to the processor 102, where the duration is stored on data store 106. It is noted here that instead of the duration, the data store 106 may store the start time and end time and determine the duration on demand.

The booking type of that historical booking is available to the processor 102 and therefore, the processor 102 records the duration of that historical booking associated with the booking type. In one example, processor 102 stores historical bookings in an SQL database.

Fig. 7 illustrates a database 700 that stores historical bookings 702, 704, 706 and 708. Database 700 may be hosted on datastore 106 or on a separate data server. Each historical booking is associated with a doctor identifier 710, a duration 712, a booking type 714 and a starting time 716. An SQL SELECT query can be executed on database 700 to generate a selection of bookings having desired values in columns 710, 712, 714 and 716.

When processor 102 receives the booking type, processor 102 executes such a query to generate a selection of bookings that have the same booking type as the requested booking, such as 'Τ .

This query can be modified such that only the most recent bookings are retrieved, such as by selecting bookings that are younger than a predetermined threshold, such as one month. Alternatively, the selection may be a selection of a predetermined number of most recent historical bookings, such as the most recent 100 bookings for that booking type.

Fig. 8 is a scatter plot 800 of historical bookings. Each historical booking is represented as a dot located in relation to a time axis 802 and a duration axis 804. Historical bookings are recorded up to the current time 806 at which processor 102 receives a request for a booking. The processor 102 selects most recent historical bookings, such as by applying a time window 808 to the predetermined threshold 810 or by starting at the current time 806 and collecting bookings from right to left until the predetermined number of bookings are selected. In the example of Fig. 8, this predetermined number is ten and therefore, processor 102 selects ten most recent historical bookings 812.

As can be seen in Fig. 8, the durations 800 show a downwards trend which is natural as doctors get more experienced with a particular booking type. In other examples, there may be an upward trend, for example if there is a seasonal condition, such as flu, that is encompassed in a reason and that condition requires more time, which causes the trend to go up. In yet another example, if a doctor is allocated more complex cases the trend will also go up. Since the value indicative of the probability for a booking finishing before a time limit is based on most recent historical bookings, that value will adapt over time and the downwards trend observed in Fig. 8 will be reflected in that value.

It is to be understood that 'most recent' does not mean that necessarily all bookings are included. For example, some historical bookings may be outliers and therefore disregarded.

Further, in examples where the distribution characteristics, such as mean and standard deviation, are pre-computed and stored on data store 106, additional bookings may be collected but the distribution characteristics are updated at a later stage. For example, distribution characteristics are updated once a day at 2am but the bookings are collected and buffered during the day. The bookings become 'historical' once they are incorporated into the distribution characteristics. As a result, a booking request made in the afternoon is not based on the buffered bookings but is still considered to be based on the most recent historical bookings, which are the historical bookings that were used to determine the distribution characteristics.

In one example, the query is further modified to select historical bookings with a particular doctor ID 710 in Fig. 7. It can be seen in Fig. 8 that the duration of the historical bookings 800 shows a downwards trend, which indicates that the doctor is getting more experienced with this booking type and future bookings may be scheduled assuming a shorter duration.

Based on the starting time of the booking and based on the selection of most recent historical bookings of the booking type, the processor 102 determines a value indicative of the probability for the booking finishing before a time limit. The time limit may be, for example, the starting time of a subsequent booking or the end of the working day of the doctor. In one example, processor 102 determines the mean duration and the standard deviation of the duration for the selection of historical bookings. Collected clinical data has shown that the duration can be approximated by a log-normal distribution, which means that the processor 102 determines the mean and standard deviation of the natural logarithm of the durations, uses the normal distribution to calculate probabilities or logarithms of durations and converts the result back to durations by applying the invers logarithm. j (ά -μ)²

A normal distribution is defined by f (d ) = ^2σ' f°^r duration d. The

advantage of a normal distribution is that it is defined by only two variables, the mean μ and standard deviation σ. These values may be pre-computed by processor 102 and stored on datastore 106 for each booking type and doctor.

It is to be understood that instead of computing the probability that the booking will finish in time, the processor 102 may equally compute the probability that the booking will not finish in time. In that case the probability would not need to be above a minimum value to satisfy the condition but would need to be below a maximum value.

Fig. 9 illustrates an example schedule 900 of a particular doctor with a first existing scheduled booking 902 for Bob with booking type ' skin and mole check' and a subsequent scheduled booking 904 for Alice with booking type 'pregnancy' . Carol has the role of patient 120 in Fig. 1 and requests a new booking 906 for booking type 'minor illness' . Carol provides 9am as a suitable time and processor 102 determines the starting time of 10am as the earliest possible starting time because 9am is already booked by Bob' s booking 902. There is a gap of one hour and thirty minutes between Bob's booking 902 and Alice's booking 904. Assuming 10am as the starting time for Carol's booking, Fig. 9 also shows the mean value 908 and the spread 910 of the finishing time of the booking given the durations of the selection of the historical bookings as described above. It can be seen that the spread 910 overlaps the starting time of Alice's booking 904 which means that there is a chance that Carol's booking, when scheduled to start at 10am, will run into Alice's booking. In other words, if the duration for Carol's booking 906 is determined from the inverse probability function such that the probability for finishing within that duration is relatively high, such as 70%, Carol's booking 906 would overlap with the start time of Alice's booking 904.

The operator of the practice can make a business decision what threshold to set for the probability of bookings for finishing on time. A low threshold means that it will be more likely that Alice has to wait but there may be higher profits since it is less likely that the doctor has a gap that could not be used to make revenue. Vice versa, a high threshold means that Alice is less likely to wait with less profit for the operator. In one example, a probability of 30% is a good trade-off.

In one example, the value indicative of the probability is the probability itself. In this example, the processor 102 retrieves the time limit, such as the starting time of Alice's booking 904 and determines the duration by subtracting the starting time of the booking request from the starting time of the subsequent scheduled booking, which is 1.5 hours in the example of Fig. 9. Processor 102 then computes the probability that the duration is less than or equal to two hours.

Referring back to Fig. 2, processor 102 determines 206 whether that probability satisfies the predetermined condition of being above the threshold of 30%, for example.

Fig. 10 illustrates a cumulative probability function (cdf) 1000 of the durations of the selection of historical bookings. For a duration of two hours 1002 it can be seen that the probability for finishing on time is 50% (indicated at 1004), which is above the threshold of 30% (indicated at 1006). Therefore, the probability satisfies the predetermined condition and the processor 102 can schedule Carol's booking between Bob's booking 902 and Alice's bookings 904. In another example, the value indicative of the probability for the booking finishing before a time limit is an estimated duration, that is, an inverse probability for a given threshold of 30%, for example. It is noted that in cases where the logarithm of the duration is used to model the distribution as a normal distribution, the inverse logarithm needs to be applied at this point.

Referring to Fig. 10, the processor 102 calculates for threshold 1006 a duration 1008 that results in exactly the threshold probability 1006. In the example distribution of Fig. 10 the duration is lhl5m.

The predetermined condition in this example is defined in terms of a maximum duration based on the available time, which is, in turn, based on the starting time of the booking. Processor 102 determines whether the computed duration is less than the available time between Bob's booking 902 and Alice's booking 904. In this example, the determined duration is lhl5m while two hours are available. Therefore, the determined duration, that is, the value indicative of a probability for the booking finishing before the time limit satisfies the predetermined condition (step 206 in Fig. 2), that is, the value is less than the gap of two hours, and the processor 102 can schedule the booking in that time gap.

In one example, processor 102 receives the booking request and selects from data store 106 the mean value and standard deviation for the duration of historical bookings for that booking type. Processor 102 then calculates the probabilities or inverse probabilities by executing source code that implements probability functions, such as the open source project meta-numerics, installed on program memory 104 as:

var cip = new NormalDistribution (2.670968 ,

0.60169) .InverseLeftProbability(0.3) ;

var duration = Math. Exp (cip) ;

where 2.670968 and 0.60169 are mean and standard deviation, respectively, of the logarithm of the duration. This corresponds to a mean of 14.58 minutes and standard deviation of 16.98 minutes of the duration.

Example results are:

Probability Duration

0.5 14.45

0.4 12.41 0.3 10.54

0.2 8.71

0.1 6.69

0.05 5.37

If it is determined that the value satisfies the condition, the processor 102 stores 208 the starting time associated with the request data to schedule the booking for the starting time. For example, the processor stores the starting time in a calendar application, such as Microsoft Outlook, as the starting time of a new meeting item with that starting time and stores the request data, such as the booking type, patient name, etc., in the details field of the calendar item.

In one example, processor 102 stores the determined duration 1008 in Fig. 10 as a predicted duration of the new booking. As a result, the same threshold applies to determining whether a booking can be scheduled in this time slot and to determining the predicted duration of the booking. In the example of Fig. 9, the duration according to a 30% probability for finishing in time is lhl5m which results in a predicted ending time of 10:45am for Carol's booking. In another example, the processor 102 determines a predicted duration after determining that the booking can be scheduled in this time slot. In that case, a different threshold may be applied and the processor 102 determines the predicted duration for Carol's booking 906 based on the durations of the selected historical bookings. The threshold for determining the predicted duration may be higher, such as 50%, than the threshold for deciding whether to schedule the booking in a particular slot, such as

25%.

In a further example 102, the user interfaces shown in Figs. 3 to 5 may allow entries for multiple booking types in one booking. For example, a patient 120 may suffer from abnormal skin conditions and feeling depressed. Treating this patient may require less time than treating two separate patients with one of these booking types. Therefore, processor 102 applies a scaling factor to the determined duration.

Processor 102 first determines the duration for each booking type individually as if the booking was for two separate patients based on the given probability as discussed above. Then, processor 102 multiplies each individual duration by a scaling factor and adds the scaled individual durations to determine a final overall duration. This allows excluding certain booking types from being scaled and it allows applying different scaling factors to different booking types. In one example, processor 102 applies the following scaling factors to account for multiple booking types:

one booking type - scaling factor k₁ = 1;

two booking types - scaling factor k₂ where k₂<l;

n booking types - scaling factor k_n where k_n<l and k_n < k_n+1;

Including the equality for n booking types allows the scaling to flatten, such that for a large number of booking types the scaling factor does not reduce further.

Possible numbers for scaling factors ki ...k_n are { 1, 0.95, 0.9,... } where n<6, which is an upper boundary on the number of booking types per patient and could be a different number in different examples.

In a similar way, the user interfaces show in Figs. 3 to 5 may allow entries for multiple patients in a single booking, such as a family appointment. Since greeting the patients, setting up the room and cleaning the room takes less time than individual bookings, processor 102 may apply scaling factors to account for that. Again, processor 102 first determines the durations for the individual patients separately, adds the durations and multiplies the result by a scaling factor. In one example, processor 102 applies the following scaling factors to account for multiple patients in the same booknig:

one patient - scaling factor pi where pi=l

two patients - scaling factor p₂ where p₂<l;

n patients - scaling factor p_n where p_n<l and p_n< p_n+i

Including the equality for n patients allows the scaling to flatten, such that for a large number of patients the scaling factor does not reduce further.

Possible numbers for scaling factors pi ... p_n are { 1, 0.9, 0.8 ... } where n<4, which is an upper boundary on the number of patients in a single booking and could be a different number in different examples. Combinations of multiple booking types and multiple patients may also be possible. In that case, processor 102 multiplies the result of adding the individual durations with both factors k and p.

The duration for a particular probability may not depend on existing scheduled bookings and therefore, it is possible to pre-compute the duration for each booking type and store the pre-computed values on data memory 106. Processor 102 then determines the value indicative of the probability for the booking finishing before the time limit by retrieving the duration from the data memory 106. The processor 102 then determines whether the value satisfies a predetermined condition by checking whether the retrieved duration is less than the available duration in the particular time slot. The stored durations may be pre-computed every 24 hours to incorporate additional historical durations collected during that time period.

Processor 102 may have a further database stored on data memory 106 which stores associations between booking types and service provider identifiers and in particular, identifiers associated with health care professionals, such as names of doctors. Based on this further database, processor 102 can select a particular doctor for a particular booking type and when storing the booking data to schedule the booking, processor 102 also stores an association between the starting time and the identifier of the selected doctor.

In that case, the processor 102 receives the doctor identifier from the database and the SQL query that selects historical bookings as described earlier may be further limited to historical bookings of that particular doctor, such as historical bookings 702 and 704 in Fig. 7. It is noted that historical booking 708 is not selected because it has a different booking type 714. The processor 102 finally sends a confirmation message to the patient's device 118 to inform the patient 120 that the booking is scheduled for that starting time.

If the value indicative of the probability does not satisfy the predetermined condition, the processor 102 repeats steps 202 and 204 of method 200 for a different starting time. The different starting time may be determined based on a search strategy Processor 102 searches in both directions from the proposed start time. I.e. search both backwards and forwards and select the slot based on the following rules:

1 . If the slot is in the past ignore it.

2 . If the slot is outside of the roster ignore it.

3 . If the probability for finishing is less than the minimum allowable probability ignore the slot as described above with reference to Fig. 2.

4 . Select the slot closest to the proposed appointment start time.

5 . If both the backward search and forward search are of equal distance to the proposed appointment start time, use the one with the highest probability for finishing in time.

When operating the above booking system 100 over multiple days, it may occur that on Monday, for example, most scheduled bookings have a probability for finishing in time of 30% while on Tuesday, for example, most scheduled bookings have a probability of 40% for finishing on time. While on both days the scheduling is valid, it is more likely on Monday that patients have to wait. In particular, towards the end of the day there may be a delay from any previous booking that affects the later patients.

For that reason, when a new booking is scheduled the condition on the value indicative of the probability may be based on existing scheduled bookings and the respective multiple values indicative of probabilities for these bookings finishing on time. For example, processor 102 multiplies the probabilities for each of the existing bookings finishing in time individually to determine an overall probability for finishing in time. If that overall probability is below a certain threshold, processor 102 adjusts the predetermined condition such that new bookings have a higher probability for finishing in time.

In another example, after processor 102 receives a booking request in step 202 in Fig. 2, in step 204 processor 102 determines the probability for the current booking request and for all previous bookings on the same day finishing before the time limit. In the example of Fig. 9, the processor 102 determines a probability that the sum of durations of Bob's booking and Carol's booking is less than 2h30m. When using normal distributions, the processor 102 calculates the sum of the mean values and variances of the respective distributions to determine the mean value and variance of the combined normal distribution. The processor 102 then determines the probability for the combined bookings for finishing on time using these combined mean and variance values. In yet a further example, the value indicative of a probability for the booking finishing before a time limit may be determined with no reference to a distribution function. Instead, processor 102 determines the available duration in a particular time slot and iterates over the selected historical bookings. The processor 102 counts the selected bookings with a shorter duration than the available duration. In step 204 of method 200 in Fig. 2 processor 102 then divides that counted number by the total number of selected historical bookings to determine the estimated probability. Processor 102 proceeds with steps 206 and 208 as above.

In one scenario, the duration of a procedure has little variance around a mean value of 10 minutes due to the nature of the procedure. For example, a patient requests a test of a biological sample and the test has a constant duration of 10 minutes due to a chemical reaction. This booking would be around 13 minutes comprising 3 minutes for setting up the test for the patient and for finalising the test. If an 11 minutes time slot is available, the probability of finishing in 11 minutes would be close to zero and processor 102 would not schedule this booking in that time slot.

There may be other factors that influence the duration of the booking and are therefore used to select the historical bookings to get a more accurate estimate. These other factors may be characteristics of the patient such as age, gender, other conditions and whether the patient is a first time visitor or return visitor.

One important application of the above method is in cases where there is a short gap before the end of the day or before a break. If there is a 5 minute gap just before end of day that gap can be used to schedule a 13 minute consult and hence utilise that time. Similarly, if there is a gap just before a scheduled break that gap could be filled with an appointment that will eat in to the break. Both these rules are managed by business rules to ensure the intent of end of day or breaks is not lost. In one example, the probabilistic scheduling is of higher priority and has failed to fill the gap, which means that the probability of finishing on time is less than the probability threshold, e.g. 30%. The following example rules address this scenario: • An appointment is allowed to overlap a break as long as it consumes no more than x% of the break where x is configurable per practitioner. For example x can be set to 20% which means that for a 30 minute break a 6 minute overlap is allowed.

• For overlaps into breaks the standard duration, such as a duration associated with a 50% probability, is used. E.g. the duration for a 30% probability for finishing is not used to calculate the overlap.

• Appointments are allowed to run over end of day with up to y minutes where y is configurable per practitioner. For example y can be set to 10 minutes.

• For overlaps over end of day the standard duration, such as a duration associated with a 50% probability, is used. E.g. the duration for a 30% probability for finishing is not used to calculate the overlap.

In another example, appointments are stacked as far as possible, which means appointments are scheduled with no gap between them.

If an appointment is proposed to start at 12:30 and there is an existing appointment scheduled that ends 12:25 there is a situation where the fragmentation needs to be managed and processor 102 determines whether the 5 minute slot can be used. That depends on the nature of the clinician and appointment type. One effective rule is to calculate the probability of the appointment type about to be booked finishing within the gap and allow the gap if the probability is greater than or equal to the lowest acceptable probability.

In other words, let g be the gap between an existing appointment a_n and the appointment to be scheduled, a_n+1. The new appointment, a_n+1, is for reason r and practitioner p. Only allow the appointment to be scheduled at the proposed time if probabilityOfFinish(g,r,p)>=P_mi_n. If the probability is lower than the minimum acceptable probability, P_mi_n, move it to be adjacent to an existing appointment. Example rules

• Appointments are stacked so that a gap is not left between the new appointment and an existing appointment where that gap cannot accommodate an appointment of the same type as the new type.

• In instances where there are appointments both before and after and neither gap can be used for scheduling the appointment is stacked against the one before. This may cause an unusable gap after but that is better than two unusable gaps. It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the specific embodiments without departing from the scope as defined in the claims.

It should be understood that the techniques of the present disclosure might be implemented using a variety of technologies. For example, the methods described herein may be implemented by a series of computer executable instructions residing on a suitable computer readable medium. Suitable computer readable media may include volatile (e.g. RAM) and/or non-volatile (e.g. ROM, disk) memory, carrier waves and transmission media. Exemplary carrier waves may take the form of electrical, electromagnetic or optical signals conveying digital data steams along a local network or a publically accessible network such as the internet. It should also be understood that, unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as "estimating" or "processing" or "computing" or "calculating", "optimizing" or "determining" or "displaying" or "maximising" or "selecting" or the like, refer to the action and processes of a computer system, or similar electronic computing device, that processes and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

Claims

CLAIMS:

1. A computer implemented method for scheduling a booking, the method comprising:

receiving a request for the booking, the request comprising request data indicative of a starting time of the booking and of a booking type;

2. The method of claim 1, wherein storing the starting time comprises storing an association between the starting time and a service provider identifier.

3. The method of claim 2, further comprising receiving the service provider identifier, wherein the selection of most recent historical bookings is a selection of most recent historical bookings of a service provider that is identified by the service provider identifier.

4. The method of claim 2 or 3, wherein the service provider identifier is associated with a health care professional.

5. The method of any one of the preceding claims, wherein the booking type is one of multiple medical issues of a patient.

6. The method of any one of the preceding claims, wherein the time limit is a starting time of a subsequent scheduled booking.

7. The method of any one of the preceding claims, wherein the time limit is an end time of a work period.

8. The method of any one of the preceding claims, further comprising:

9. The method of claim 8, wherein the request for the booking is a request for a number of persons and determining the predicted duration comprises:

determining the predicted duration for each person;

combining the predicted durations; and

reducing the combined predicted durations based on the number of persons.

10. The method of claim 8 or 9, wherein the request for the booking is a request for a number of booking types and determining the predicted duration comprises:

determining the predicted duration for each booking type;

combining the predicted durations; and

reducing the combined predicted durations based on the number of booking types.

11. The method of any one of the preceding claims, wherein the predetermined condition is based on multiple values each indicative of a probability for a previously scheduled booking finishing before a respective time limit.

12. The method of any one of the preceding claims, wherein determining the value indicative of the probability based on the durations comprises determining the value indicative of the probability based on a probability function approximating a distribution of the durations.

13. The method of claim 12, wherein the probability function is based on one or more distribution parameters and determining the value indicative of the probability based on the durations comprises selecting the one or more distribution parameters based on the booking type.

14. The method of claim 13, wherein the probability function is a normal distribution function and the distribution parameters are mean and standard deviation.

15. The method of claim 12, 13 or 14, wherein determining the value indicative of the probability is based on a logarithm of the durations.

16. The method of any one of the preceding claims, wherein the selection of most recent historical bookings of the booking type comprises a selection of historical bookings of the booking type that are younger than a predetermined age threshold.

17. The method of any one of the preceding claims, wherein the selection of most recent historical bookings of the booking type comprises a selection of a predetermined number of most recent historical bookings of the booking type.

18. The method of any one of the preceding claims, further comprising generating a user interface comprising a first selection to allow a user to provide the starting time and a second selection to allow the user to provide a booking type.

19. The method of claim 18, further comprising upon detecting that the user has selected a booking type generating a user interface comprising a third selection comprising options for a booking sub-type based on the selected booking type, wherein determining the value indicative of a probability is based on durations of a selection of most recent historical bookings of the booking sub-type.

20. Software, that when installed on a computer causes the computer to perform the method of any one or more of the preceding claims.

21. A computer system for scheduling a booking, the computer system comprising: a data port to receive a request for the booking, the request comprising request data indicative of a starting time of the booking and of a booking type;

a processor

a data store to store the starting time associated with the request data.