GB2560506A

GB2560506A - Scheduling

Info

Publication number: GB2560506A
Application number: GB1703721.9A
Authority: GB
Inventors: Geir Solvoll Terje
Original assignee: Callmesmart As
Current assignee: Callmesmart As
Priority date: 2017-03-08
Filing date: 2017-03-08
Publication date: 2018-09-19
Also published as: GB201703721D0

Abstract

A resource allocation system comprises a resource information store 14, configured to store a plurality of resource records including information identifying a resource and information describing a live status and a capability of that resource; a resource pre-allocation processor 16 configured to create a resource availability profile by determining for each of a plurality of event types an allocation score identifying a suitability of each resource for each event type, and to update the resource availability profile based upon a change to the resource record; an event manager 18 configured to, responsive to reception of communication describing an event, match the event to the resource availability profile to select a resource; and a notification engine 22, configured to transmit an event notification to a communication device associated with the selected resource. Live status can include log-in status, presence, manual status override, busy status due to event or a schedule. Event type can include telephone call, text message, sms, multimedia message, video call, email, alarms, forward messages, and requests for equipment.

Description

(54) Title of the Invention: Scheduling

Abstract Title: Resource allocation system (57) A resource allocation system comprises a resource information store 14, configured to store a plurality of resource records including information identifying a resource and information describing a live status and a capability of that resource; a resource pre-allocation processor 16 configured to create a resource availability profile by determining for each of a plurality of event types an allocation score identifying a suitability of each resource for each event type, and to update the resource availability profile based upon a change to the resource record; an event manager 18 configured to, responsive to reception of communication describing an event, match the event to the resource availability profile to select a resource; and a notification engine 22, configured to transmit an event notification to a communication device associated with the selected resource. Live status can include log-in status, presence, manual status override, busy status due to event or a schedule. Event type can include telephone call, text message, sms, multimedia message, video call, email, alarms, forward messages, and requests for equipment.

FIG. 1B

Notification engine

notification engine

Notification engine

_f communication

mouse

6/14

avaiiablity profile
event type	suitability
t t t 1 c i i i t t e t t ί »	a a a a a a a B B B a

FIG. 5

start

end

start

end start

next updated resource record

S10 update availability profile fc updated resource record

S10-

end start

S10-15

start

end

Intellectual

Property

Office

Application No. GB1703721.9

RTM

Date :28 July 2017

The following terms are registered trade marks and should be read as such wherever they occur in this document:

Bluetooth (Page 11)

Galileo (Page 33)

Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo

SCHEDULING

FIELD AND BACKGROUND [0001] The present disclosure relates to scheduling and in particular but not exclusively to scheduling or allocating of resources by a computer-implemented resource allocation system. [0002] In demanding work environments such as healthcare facilities, it is believed that poor communication practices lead to interruptions to and multitasking by medical practitioners such as to increase the likelihood of clinical and medical errors. Conventional approaches to allocation of practitioners to activities based upon manual calendaring of activity with the addition of a communication system such as the use of pagers are thus believed to be ineffective in providing for efficient and reliable deployment of practitioners in a manner that enables the practitioner to work in a streamlined and effective way. Similar considerations are believed to apply to other work environments.

[0003] A number of authors have addressed issues of communication and resource management. These include EP2,241,093 which discusses blocking or distinctively alerting incoming communications as a function of an emergency indication, KR101094607 which discusses a method for allocating resource in multi tenancy system, US 7,171,667 which discusses a system and method for allocating resources based on locally and globally determined priorities, WO2011/116340 which discusses a context-management framework for telemedicine, US2015/0213223 which discusses a holistic hospital patient care and management system and method for situation analysis simulation, US2012/0290311 which discusses a method and apparatus for physician location tracking, US2009/0125332 which discusses automated execution of health care protocols in an integrated communications infrastructure, and US 8,923,822 which discusses a method and apparatus for managing interruptions from different modes of communication.

SUMMARY [0004] Particular aspects and embodiments are set out in the claims.

[0005] Viewed from a first perspective, the present teachings deploy a computer-implemented resource allocation system which iteratively reviews the capability and status of resources such as to provide for rapid and appropriate allocation of resources to new events.

[0006] One aspect of the present teachings can provide a computer-implemented resource allocation system comprising: a resource information store configured to store a plurality of resource records, each resource record comprising information identifying a resource and information describing a live status and a capability of that resource; a resource pre-allocation processor configured to create a resource availability profile by, for each resource record in the resource information store, determining for each of a plurality of event types an allocation score identifying a suitability of each resource for each event type, and to update the resource availability profile based upon a change to the resource record; an event manager configured to, responsive to reception of communication describing an event, match the event to the resource availability profile to select a resource to be allocated to the event; and a notification engine configured to transmit an event notification to a communication device associated with the selected resource. Thereby resources can be pre-allocated based upon a maintained description of the resource status and/or capabilities to be allocated to a variety of possible events such that when an actual event occurs one or more resources can be allocated to that event with a minimum of processing at that time.

[0007] in some examples each resource record further comprises information describing a location, such that the relative positions of a resource and an event can be taken into account. [0008] in some examples, the event communication can be an event attendance instruction. Thus a resource may be allocated to attend an event with a minimum of decision-making delay between the event being notified and the allocation being made. This may provide for rapid attendance of resources at an urgent or emergency event and/or may provide for a resource to attend a visitor in good time to avoid or reduce a queuing delay for the visitor.

[0009] in some examples, the resource pre-allocation processor can be configured to detect a change to a resource record and to update the resource availability profile for the changed resource record. Such change detection may for example operate by receipt of a notification that a resource record has changed, and/or by periodically checking for resource record updates. In some examples, the resource pre-allocation processor can be configured to update the resource availability profile for the changed resource record in real-time or near-real-time. Thus the information describing the resource upon which the pre-allocation is performed may be kept as up-to date as possible and thereby the pre-allocation decisions can be made as accurate as possible so as to minimise the likelihood of a resource being miss-allocated to an event.

[0010] The resources may be human resource and/or an equipment resources. In some examples, the resource can be an equipment resource and the notification engine can be configured to send an event notification to a communication terminal of a human resource also selected by the event manger and/or of an equipment handier for the equipment resource. Thus the approach provides for management of resources irrespective of whether the resource is self-acting or an inanimate object, [0011] in some examples the live status can comprise one or more selected from the group comprising: log in status, presence, manual status override, busy status due to ongoing event, and schedule. Thus the system can be implemented to provide for a variety of real-world factors that affect the availability of resources for allocation to events.

[0012] in some examples, the location comprises a measured location or a proximity to a location beacon. Thus the system can be implemented to deal with resource location according to any location-determining system and thereby provide for appropriate and accurate preallocation decisions.

[0013] In some examples, the event type comprises one or more selected from the group comprising: telephone calls, text messages, sms, multimedia messages, video calls, emails, pages, alarms, forwarded messages and calls, and requests for equipment. In some examples the event type can define a location, a capability requirement and an urgency. Thus the system can be implemented to cope with a wide variety of events applicable to a variety of operational contexts, thereby to provide useful and appropriate pre-allocation decisions.

[0014] In some examples, the event notification can comprise one or more selected from the group comprising: type; content; time; originator ID, such as location, calling party id, called party id, message sender id, and message receiver id; and indicative selection criteria, such as group id, role, capability and responsibility. Thus an event can be notified in such manner as to enable the pre-allocation results to be utilised efficiently to provide an effective and appropriate resource allocation response to an event.

[0015] in some examples, the allocation score can be based on a closeness of match of resource capability and/or responsibility defined by the resource record to an event type capability requirement, in some examples the allocation score can be based on an availability profile such as available, busy and pager mode, and wherein a different availability profile is applicable to different event types. In some examples, the allocation score can be based on a closeness of match of resource location to event location. Thus the system can be implemented to take into account a variety of factors in making pre-allocation decisions, and/or can take into account the relative importance of those factors to the implementation context and to different event types, so as to provide appropriate and effective pre-allocation decisions. [0016] in some examples the notification engine can be configured to transmit the event notification to the selected resource via a communications channel selected from the group comprising: PA, phone call, sms, pager, email, text message, conference call, and video call. In some examples the event notification can indicate the event urgency. Thereby, the system can be implemented to communicate with resources and/or resource handlers in such a manner as to provide effective notifications that are appropriate to the resource, the event and/or the implementation context.

[0017] in some examples the resource pre-allocation processor can be configured to create and update the resource availability profiles based upon one or more rules defining matching criteria and importance for different ones of the data within the resource record for each event type. Thus the system can be implemented to maintain the pre-allocation decisions up-to-date in a manner tailored to the priorities and demands of the particular implementation context.

[0018] in some examples, the resource information store can be configured to store and process resource records and corresponding availability profiles for a complexity space defined by the number of resource records, the number of fields per resource record, the number of event types, and the number of fields per event type, for example where the complexity space comprises at least 1000, at least 10,000, at least 100, 000 or more than 100,000 permutations. Thus the system can be implemented to handle extremely large numbers of resources and event types while maintaining the rapidity of resource allocation when a real event occurs and is notified to the system.

[0019] in some examples, the resource information store can be for storing resource records corresponding to human resources and the system can further comprise a second resource information store for storing resource records corresponding to equipment resources. Thus resources having different natures can be identified and managed separately within the system. This permits the use of cross-checks such as ensuring that any for given event type that specifies a human as well as an equipment resource an appropriate set of resource types as well as resource capabilities is allocated.

[0020] In some examples the resource records relate to resources of one or more selected from a hospital or other healthcare facilities or organisations; an emergency response service; an armed forces training or deployment operation; armed forces materiel; project management; an oil and gas exploration and extraction operation, and transport & logistics operation. Thus the system can be implemented into a wide variety of implementation contexts.

[0021] Another aspect of the present teachings can provide a computer-implemented method of allocating resources to events, the method comprising: determining, for each of a plurality of resources having a resource record defining a live status and a capability of that resource, a suitability score relating to each of a plurality of event types; responsive to determining that a resource record of a resource has changed, determining an updated suitability score for that resource for each of the plurality of event types; responsive to receiving an event notification corresponding to one of the event types, matching the event to the suitability scores of the resources to identify a resource to allocate to the event; and transmitting an event communication to a communication terminal corresponding to the allocated resource. Thereby resources can be pre-allocated based upon a maintained description of the resource status and/or capabilities to be allocated to a variety of possible events such that when an actual event occurs one or more resources can be allocated to that event with a minimum of processing at that time.

[0022] A further aspect of the present teachings can provide a computer program product comprising computer-implementable instructions for causing one or more programmable computers to become configured as the apparatus or method described above.

BRIEF DESCRIPTION OF THE FIGURES [0023] Examples in accordance with the present teachings will now be set forth by reference to the accompanying drawings, in which:

[0024] Figures 1A, 1B and 1C show schematically a number of logical arrangements of process elements for a resource allocation system.

[0025] Figures 2A and 2B show schematically a number of hardware arrangements for a resource allocation system [0026] Figure 3 shows schematically a logical structure of a resource information store.

[0027] Figure 4 shows schematically a logical structure of an availability profile.

[0028] Figure 5 shows schematically a logical structure of a live status.

[0029] Figure 6 shows schematically a logical structure of an event type.

[0030] Figure 7 shows schematically a method for resource management, [0031] Figures 8A and 8B show schematically methods for updating a resource record.

[0032] Figure 9 shows schematically a method for generating an availability profile.

[0033] Figures 10A and 10B show schematically methods for updating an availability profile. [0034] Figure 11 shows schematically a method for determining a resource for a received event.

[0035] While the presently described approach is susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are herein described in detail. It should be understood, however, that drawings and detailed description thereto are not intended to limit the scope to the particular form disclosed, but on the contrary, the scope is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims

DETAILED DESCRIPTION [0038] The present disclosure relates to a resource allocation system that uses information about each resource to pre-allocate each resource to each of a plurality of event types, updating the pre-allocation over time so as to reflect changes to the information about the resources, such that when an event does occur, the system can select one or more most appropriate resources allocate to the event and also notify those resources that they have been allocated to the event, in some examples, a notified resource (or an individual or system with responsibility for managing the resource) may have a facility to accept or reject being allocated to the event. [0037] A first example of a resource allocation system 10 is schematically illustrated in Figure 1A. The illustration in this figure is indicative of logical elements within the system to carry out the processes according to the present teachings. As shown in Figure 1A, a resource allocation system 10 includes a resource update interface 12 via which new resource information can be received. As will be discussed further below, a resource record for any given resource may include at least information identifying the resource and information describing a live status and a capability of that resource. Optionally, information describing a location may also be included. The resource update interface may receive complete resource records and/or updates to existing resource records.

[0038] As seen in Figure 1A, the resource update interface 12 is connected to a resource information store 14. The resource information store provides a repository for the resource records, storing for each resource the resource information for that resource. As mentioned above, the resource information for each resource record includes at least information identifying the resource and information describing a live status and a capability of that resource.

[0039] The resource information store 14 is connected to a resource pre-allocation unit 16. The resource pre-allocation unit 16 creates a resource availability profile for each resource. The resource availability profile identifies the suitability of the resource to each of a plurality of event types. As will be discussed in more detail below, the resource availability profile is determined by matching the current resource information in the resource record for that resource to a requirements schedule of each of the plurality of event types. The resource availability profile as created by the resource pre-allocation until 16 is then stored with the respective resource record in the resource information store 14. The resource pre-allocation unit is configured to continuously update the resource availability profiles responsive to updates to the resource information of the resource records. This continuous updating process may work on one or more of a timer basis where the pre-allocation unit looks for resource record updates after a given time interval, or an interrupt/notification basis where the pre-allocation unit is notified from the resource information store and/or resource update interface of new resource information being available.

[0040] The resource information store 14 is also connected to an event manger 18. The event manager 18 is configured to access the resource availability profiles of the resource records in response to the occurrence of an event. An event is notified to the event manger by an event input interface 20 which received notification of an event from an event source. Upon receipt of an event notification from the event input interface 20, the event manager 18 compares the notified event to the resource availability profiles from the resource information store and uses this comparison to select one or more best match resources for the event of the event notification. The event manger is connected to a notification engine 22 via which a notification can be sent to the selected resource(s) to inform that resource(s) that the resource has been assigned the event to handle.

[0041] This notification may be sent to the resource and/or to an individual or system with responsibility for managing the resource. For example, notifications for a resource in the form of a human may be sent to a device of that human and/or to a device of a secretary or personal assistant with responsibility for managing the diary of that human. The notification engine can also be configured to receive an accept/reject response from or on behalf of a resource assigned to the event. Such an accept/reject response can be notified by the resource engine 22 back to the event manager 18 so as to provide that the event manager 18 can determine a new or further resource to be allocated to the event if needed.

[0042] Thus it will be appreciated that the system of the present approaches can utilise an iterative, ongoing update process to continuously provide an up-to-date pre-allocation of resources to event types, so as to maximise the responsiveness of a final allocation decision making process when an event is notified. Such an approach allows all relevant data for resource allocation to be taken into account by the resource allocation decision process in a manner which minimises the time taken to allocation a resource to an event after the event is notified.

[0043] A second example of a resource allocation system 10 is schematically illustrated in Figure 1B. The illustration in this figure is indicative of logical elements within the system to carry out the processes according to the present teachings. As shown in Figure 1A, the logical elements of the system are similar to those illustrated in Figure 1A discussed above, but he connectivities differ.

[0044] Thus, as shown in Figure 1B, the resource update interface 12 is connected to provide new resource information to the resource pre-allocation unit 16. The resource pre-allocation unit 16 is connected to the resource information store 14 and can identify in the resource information store 14 any existing resource record corresponding to the new resource information. The resource pre-allocation unit 16 can process the new resource information to update the resource availability profile for that resource record and store the updated resource record including the resource availability record to the resource information store 14. In situations where the new resource information form the resource update interface 12 corresponds to a previously unknown resource, the resource pre-allocation unit 16 can process the new resource information to generate a resource record and a corresponding resource availability profile and pass both to the resource information store 14 for storage as a new resource record. It will be appreciated that this connectivity provides that the resource preallocation unit may be responsive to new resource information arriving from the resource update interface to trigger a next iteration of the pre-allocation determination for any given resource record. Alternatively the resource pre-allocation until may cache new resource information until a predetermined time period has elapsed and then trigger the processing of new resource information when the time period completes.

[0045] As is further shown in Figure 1B, the resource information store is connected to an event manger 18, which in turn is connected to an event input interface 20 and a notification engine 22 as already described above with reference to Figure 1A.

[0046] Thus it wiil be appreciated that the system of the present approaches can utilise an iterative, ongoing update process to continuously provide an up-to-date pre-allocation of resources to event types, so as to maximise the responsiveness of a final allocation decision making process when an event is notified. Such an approach allows ail relevant data for resource allocation to be taken into account by the resource allocation decision process in a manner which minimises the time taken to allocation a resource to an event after the event is notified.

[0047] A third example of a resource allocation system 10 is schematically illustrated in Figure 1C. The illustration in this figure is indicative of logical elements within the system to carry out the processes according to the present teachings. As shown in Figure 1C, the logical elements of the system are similar to those illustrated in Figures 1A and 1B discussed above, but the connectivities differ.

[0048] Thus, as shown in Figure 1B, the resource update interface 12 is connected to provide new resource information to the resource information store 14. The resource information store 14 is in turn connected to the resource pre-allocation unit 16 such that the resource preallocation unit 16 can access updated resource records in the resource allocation store 14. As discussed above with respect to Figure 1A, the resource pre-allocation unit 16 may trigger a pre-allocation update cycle based upon one or more of a timeout basis and a notification/interrupt basis.

[0049] in the present example, the resource pre-allocation unit 16 outputs the determined resource availability profiles not to the resource information store 14, but to a resource allocation store 17.

[0050] The resource allocation store 17 is connected to the event manger 18 such that the event manger 18 can access the resource availability profiles stored therein. The Event manager 18 is in turn is connected to an event input interface 20 and a notification engine 22 as already described above with reference to Figure 1A.

[0051] Thus it wiil be appreciated that the system of the present approaches can utilise an iterative, ongoing update process to continuously provide an up-to-date pre-allocation of resources to event types, so as to maximise the responsiveness of a final allocation decision making process when an event is notified. Such an approach allows ail relevant data for resource allocation to be taken into account by the resource allocation decision process in a manner which minimises the time taken to allocation a resource to an event after the event is notified, it will also be appreciated that a variety of logical structures can be implemented to achieve the ongoing update process that provides the efficiency of decision making after an event notification is received.

[0052] As the skilled reader will appreciate, a computer implemented approach may be considered in terms of both logical elements and hardware elements. Although a variety of logical elements and structures have been described above, it may also be appropriate to consider the underlying hardware that provides the computational, storage and communication resource for the logical elements.

[0053] Figure 2A illustrates schematically a first hardware implementation 30 within which the logical elements of the resource allocation system may be implemented. In this example, a processor 32 is connected via one or more communications busses 34 to a volatile storage 36 such as RAM in which active program and computation data may be held while in use. The processor 32 is also connected to non-volatile storage 38 in which operating instructions and/or function data may be stored, in the present context, processor may carry out under program control the logical operations of the resource pre-allocation unit and event manager. The volatile storage may be used during the operation of these logical operations to store data upon which those logical modules are operating. The volatile storage may additionally be used to store a copy of the resource information store and/or resource allocation store so as to provide for rapid access thereto. The non-volatile storage may store program instructions for the processor and may also store the resource information store and/or resource allocation store, either as the only copy in situations where the non-volatile storage provides sufficiently fast access to the data therein to not require a cached copy in volatile storage, or as a record copy of data cached to the volatile storage so as to provide persistence of data if the computer system loses power or otherwise suffers interrupted operation.

[0054] Also shown as being part of the computer system 30 in Figure 2A are a display 40, communications interface 42, keyboard 44 and mouse 46. Ail of these elements can be used for one form of I/O or another and thus are of relevance to the resource allocation system as providing hardware basis for the resource update interface, event input interface and notification engine. For example, either or both of the resource update interface and event input interface may provide for manual data entry by an operator using a mouse and/or keyboard, with the operator being able to track their input activity using the display. Also, the communications interface may provide for the resource update interface and/or event input interface to receive data via a communications link such as a wired or wireless network link. The notification engine may be provided in part by the processor to generate a notification message or alert and then also by the communications interface to carry the notification message or alert to a notification system or device associated with the resource.

[0055] Figure 2B illustrates a first hardware implementation 50 within which the logical elements of the resource allocation system may be implemented, in this example, a distributed arrangement is illustrated. This may be a local scale distribution, such as where a processing server is coupled to a storage area network and I/O modules, or may be a more wide scale distribution where different parts of the system are in different locations and linked via a LAN, WAN or the Internet.

[0056] Thus, as shown in Figure 2B, a processing server 52 may provide a processor 32 and associated volatile storage 34. One or more such processing servers 52 may be provided to implement the resource pre-allocation unit and event manager. Also, one or more storage servers 56, connected to the processing server 52 via a network 54 may provide non-volatile storage 58 to provision or either or both of program instruction for the processing server 52 and a storage facility for the resource information store and/or resource allocation store. The resource information store and/or resource allocation store may additionally or alternatively be cached to the volatile storage 36 of the processing server 52. Additionally, also connected via the network 54, one or more I/O units 60 may provide interface capability to support the resource update interface, event input interface, and/or notification engine.

[0057] Further, as will be appreciated, a distributed computing arrangement such as that illustrated in Figure 2B may be provided by way of a virtualisation regime, under which a hypervisor or other control system provides a virtual hardware layer such that the resource allocation engine may be implemented onto a virtual hardware platform resembling that shown in Figure 2A, which virtual hardware platform is a virtualised onto a distributed hardware implementation such as that shown in figure 2B.

[0058] As will be appreciated, operating instructions for causing a programmable computing system such as that illustrated in figures 2A and 2B can be provided to the computer system as a computer program product. Such a computer program product may be conveyed using a suitable carrier medium. Carrier media may include carrier signals such as may be transmitted over a network such as the internet. Carrier media may also include physical media such as optical media, magnetic media or electronic media such as portable discs, memory sticks and installable storage such as hard disk drives or flash drives for computers, all of which physical media may also collectively be termed non-transitory media, [0059] Thus it will be seen that the logical arrangement of resource allocation elements can be provided in accordance with any of a number of hardware implementations.

[0060] As mentioned above, the resource information store 14 stores resource records containing information describing the resource. Figure 3 illustrates the resource records in the resource information store 14. Each resource record 70a, 70b ... 70n includes a number of data fields relating to the resource.

[0061] These data fields include a resource ID 71 that identifies the resource in question. The resource ID 71 typically includes one or more of identification items such as a name, nickname or employee number etc. In the case where a resource may be an physical item as well as or instead of a human, the ID 71 may include an item identified such as type, serial number or stock number etc. The resource ID 71 may also include contact information for the resource, although this is not always necessary as resource contact information may be otherwise made available within the event engine or notification engine.

[0062] Although an optional element which can be included according to the needs of a given implementation, in the present example, resource record 70 also includes a location 72. This is a current location for the resource and thus may vary depending upon the implementation. The location may include multiple levels of granularity. For example in a healthcare context, the location may include one or more of: a healthcare facility identification such as a particular hospital or doctor surgery or a private location associated with an on call ready location or a patient home visit; a location within a healthcare facility such as a ward, department or building identifier; and a specific room identifier such as a particular treatment room, operating theatre or office. For example in an emergency reaction service context, a location may include an attendance location such as a police, fire, coastguard or ambulance ready room at a station, or an on-call location attending to an existing or previous emergency call.

[0063] A variety of approaches for determining location may be performed. Typically a location determination system is used which enables a resource location to be related to a known location at or in which an event may take place. For internal installation locations such as rooms in a hospital a number of beacons (such as Bluetooth beacons) can be used where each beacon corresponds to a known location and a device for a given resource can determine its location from beacon reception or proximity. The system can be programmed with the position of each beacon. Thus the system can determine a resource location based upon one or more beacon signals received by a device of that resource. For external locations radio positioning system such as GPS can be used by the device of a resource to determine the resource’s location determine thereby permit calculation by the system of a location of a resource relative to known fixed locations such as hospitals, care homes, clinics, deployment depots etc.

[0064] The resource record also includes a live status 73, discussed in more detail with reference to Figure 5 below. The resource record also includes a capability 74. The capability 74 includes data relating to the skills and abilities of the resource. This may include a role identifier and specific skill identifiers within the role. For example in a healthcare context, the capability may indicate a role in the form of doctor, nurse, nursing assistant, administrator or the like, and/or may also indicate a more specialist role such as paediatric doctor, paediatric nurse, physiotherapy nurse, cardiology doctor, surgery support nurse, anaesthetist or the like. Additionally, it could indicate a further specialist skill or restriction, such as an administrator who has received defibrillator training or a person with known back trouble who cannot perform lifting activity. In an example emergency services response context, the capability may include an identification of a particular emergency service, such as fire service or police service and/or may also include an indication of a specific role such as paramedic, diver, pursuit driver, or firearms officer.

[0065] Additionally, the resource record includes an availability profile 75. As will be appreciated, this will be the case if the system is configured such that the pre-allocation unit stores the availability profile to the resource information store (such as in the examples shown in Figures 1A and 1B). In implementations where the pre-allocation unit does not store the availability profile into the resource information store (such as the example shown in Figure 1C), the availability profile will be stored in an alternative location such as a resource allocation store, either with or without the resource record.

[0066] The availability profile 75 as created by the pre-allocation unit is further illustrated with reference to Figure 4. As shown in Figure 4, the availability profile includes a number of entries for each of a number of event types 76. The availability profile 75 also includes a corresponding suitability result 77 for each event type. The suitability is obtained by matching the current resource information in the resource record for that resource to a requirements schedule of each of the plurality of event types. The nature of an event type is discussed below with reference to Figure 6. in the availability profile 75, the event type entries may include the whole event type profile or may include a subset of the full event type, such as an identifier field of the event type.

[0067] Although not shown in Figure 4, the resource record may also include other information relating to the resource. This information can include a username and password for the resource to use when logging in to the resource allocation system. The information can include an extension number on which the user can be telephoned, messaged or paged when loggedin. If as discussed below, a system-specific device is issued to the resource, this extension number may be a number linked to that device. Personalisation settings, such as ringtones, cooldown period after event allocation, and default contact lists for the resource may also be included in this information. The Information may also include logs of previous activity, including histories such as a history of allocated events, a history of allocated but not attended events, a history of sent and/or received messages and/or pages for the resource. Such information may be stored in an alternative logging or history store in some examples, so as to minimise the size of the resource record to be considered by the pre-allocation while still retaining the history or logging information within the system.

[0068] Figure 5 illustrates a live status 73 of a resource record 70. The live status 73 includes one or more fields relating to the current status of the resource to which the particular resource record 70 relates. The fields of the live status 73 may include any information pertinent to establishing the status of the resource which and may affect the allocatability of that resource to an event type and thus influence the suitability score generated by the pre-allocation unit for the availability profile of that resource. This information may take the form of some, all or none of the example fields illustrated in Figure 5.

[0069] In the present example, the live status 73 includes a log-in status 81, which is representative of whether the resource is logged in to some form of system that represents and at-work or on-duty status, such as a work time logging system, messaging system, or physical presence monitoring system. The live status 73 of the present example aiso includes a manual status override 82, which is indicative of a status update being manually applied to the resource record, either by the resource or by an authorised administrator on behalf of the resource. The manual status override 82 may therefore be indicative of a human resource being recorded as on sickness absence, in a non-interruptibie meeting or consultation, being noted as on-call despite not being on-premises, an over-ride to a planned schedule or the like.

[0070] The live status 73 of the present example also includes a task active status 83, which is indicative of being unavailable for events requiring immediate response due to having been already allocated another event. In implementations where the resource allocation system monitors ongoing events until those events complete, this task active status 83 may be updated by the resource allocation system once that earlier event has been logged as completed. Another approach provides for the task active status 83 to be updated based upon a report from a resource that the event has completed. These two approaches may both be implemented in the same system. For example where the event is an incoming telephone call to be answered by the resource, the resource management system may note when the telephone call ends, and where the event involves a physical spillage that requires cleaning the resource may log with the system once the cleaning has been completed.

[0071] The live status 73 of the present example also includes a schedule status 84, which provides for a recorded schedule or calendar of activity of the resource to be used to establish times at which the resource has relatively higher or lower availability to deal with an event. For example, a resource scheduled to a staff meeting may be excluded from allocation to handle an incoming telephone call event, but may remain available to be allocated to an emergency cardiac arrest event or firearms office requirement event. In contrast a resource scheduled to a high priority activity such as performing surgery or attending a court hearing may be removed from allocation to all or almost all events. For resources that are objects or equipment rather than humans, the schedule status may include information describing when that resource is in regular use for scheduled activities or information describing when that resource is out of use of repair or maintenance.

[0072] The live status 73 of the present example also includes a responsibility allocation 85, which serves to record a current responsibility or set of responsibilities for the resource. For example, where a resource is allocated to a duty roster of emergency attendance resources this can be recorded in the responsibility allocation 85 such that the resource allocation system would be more likely to allocate a resource on this roster to an emergency event than to a resource not on this roster.

[0073] Thus it will be seen that a variety of resource status factors can be taken into account using the live status field(s) of the resource record. Thus a wide variety of factors that may affect the suitability of a resource for any particular event type may be recorded in the resource record so as to be available to be taken into account for the pre-allocation of resources to event types by the system. As will be appreciated from the discussion above, the various resource status factors may be considered as being context data associated with the resource and similarly the definitions of the event types may be considered as relating to context data of the event type.

[0074] As will be appreciated from the discussion above and below, many of the data fields utilised in the resource record are very much dynamic as a resource location will change as the resource moves across a site or from one site to another or out on to a remote visit or call. Likewise the resource log-in status will change as resources log in and log out for example in associate with shift changes. Also the resource schedule will update over time as the resource moves between appointments and as different appointments are added or removed. In addition, a resource override and a resource active event status will change over time as resources move onto unscheduled activities and/or attend to previous events. Thus it will be seen that the volume of updates received to the resource records via the resource update interface 12 would be expected to be significant and therefore knowing which resource is available to be allocated any given event that may occur is a non-trivial task. Accordingly, the pre-allocation to defined event types approach of the present examples provides for any actual event to be rapidly allocated a suitable resource without a need to consider after the event occurs any particular data describing individual facets if a resource’s current availability and suitability for the event.

[0075] As will also be appreciated, the present examples are applicable to handling resource management for very large numbers of resources and very large numbers of possible tasks. Taking the example of a healthcare facility such as a hospital, there may be thousands of staff to coordinate and hundreds or thousands of different event types to process. The present approach provides for this volume of resources and event types to be handled efficiently and effectively through the process of iterative pre-allocation such as to enable a received event to be allocated to one or more resources very rapidly after receipt of the event.

[0078] it will also be appreciated that the volumes of information create a large number of complex permutations in terms of the interactions between the different properties and statuses of the resources and how these are allocated to actual occurring events. Thus to efficiently and effectively manage ail of these permutations in such manner to enable events to be processed and allocated in a rapid and accurate manner is a non-trivial activity. As just one example, system to manage a staff of 50 persons (resources) covering 8 locations with each person having a status of 5 status fields (each of which can adopt one of two states) and a capability field which can adopt one of 5 states, and the system capable of allocating those persons to any one of 20 event types ends, up with 400,000 permutations. This complexity scales up rapidly as the amount of information on each resource, number of locations, number of resources and/or number of event types increases. For example, just adding to the resource record one additional live status field with a binary state will double the number of permutations to be considered.

[0077] The present approaches handle the complexity and extent of permutation through the provision of a two-stage system which processes and pre-allocates all resources to a set of known event types and then uses the pre-allocation to rapidly and efficiently select a particular resource or resources to handle a particular actual event when such an event occurs.

[0078] Figure 6 illustrates an event type 76 which can be used for the pre-allocation unit generating the availability profile. This event type 76 is used by the pre-allocation unit for matching against the respective resource records in the resource information store to produce the availability profile 76.

[0079] in the present example, the event type definition 76 includes an identifier 90 for the event type. This event type identifier is also used in an event notification so as to permit the event manager to identify the correct event type entry in the availability profiles so as to facilitate the determination of one or more resources to allocate to the event of the event notification. As discussed above, the availability profile 75 may include the whole event type definition 76 or may include a subset of the event type information. Typically this subset will include the event type identifier 90.

[0080] The event type definition 76 of the present example also includes an urgency indication 91, a location 92 and a capability requirement 93. In the present example, as the resource record includes the optional location field, the event type definition 76 is also defined to include a location field. A number of example event types are discussed below to illustrate these fields. The urgency indication 91 is representative of a required reaction time to an event conforming to the event type. This urgency may be based upon a number of factors such as acuteness of the event (such as an event notifying of a fire or a cardiac arrest), immediacy of the event (such as an incoming telephone call of low acuteness but which cannot be delayed as the call is in progress already), and blocking or inconvenience caused by the event (such as a consequential inability to use or access one or more locations until the event has been resolved, such as might be expected from a cleaning event or a damage removal event).

[0081] The location 92 is representative of a location at which any event confirming to that event type will take place. The location 92 is chosen in a given implementation to have a granularity that facilitates efficient resource handling for that environment and different event types may be allocated locations at different levels of granularity. For example in a healthcare context, the location may include one or more of: a healthcare facility identification such as a particular hospital or doctor surgery or a private location associated with an on call ready location or a patient home visit; a location within a healthcare facility such as a ward, department or building identifier; and a specific room identifier such as a particular treatment room, operating theatre or office. For high acuteness event types such as a cardiac arrest or other time-critical medical emergency the location granularity may be selected to be a relatively small area such as to provide that any summoned resource has only a small distance to cover, whereas a cleaning event may have coarser location granularity so as to enable one cleaning team to be called to events across a larger area.

[0082] The capability requirement 93 provides details of the capabilities required of any resource allocated to an event conforming to the event type. Thus, a cardiac arrest event type may call for a resource with specialist skills or training in appropriate techniques such as defibrillator use, a cleaning event type may call for skills and equipment in cleaning, an incoming telephone call event type may call for access to a telephone on which to receive the call, and a road traffic accident event type may call for skills and training in emergency rescue and traffic control.

[0083] Thus it will be seen that by implementing the event type according to the needs of the implementation context, the pre-allocation approach of the present teachings can be used to pre-allocate resources to a wide variety of event types for use in determining with minimal delay an actual resource allocation solution to any given actual event notification.

[0084] A number of example event types and corresponding considerations are now described to illustrate how these can be implemented for a number of events that may be expected to occur in a healthcare facility such as a hospital. These example event types are then usable by the pre-allocation unit to create the availability profile for each resource record as against each event type. The rules for deciding the context relevancy and prioritization are configurable for each type of event.

[0085] Cardiac arrest alarm

Event ID	Cardiac arrest 1
Location	Location 1 or escalate
Urgency	Critical (1)
Capability requirement	Logged in to resource system Doctor No conflicting higher urgency event allocation No conflicting higher urgency schedule No conflicting higher urgency override
Attendance selection	All matching resources within location

[0086] Nurse alarm

Event ID	Nurse attendance 1
Location	Location 1 or next nearest location
Urgency	Important (2)

Capability requirement

Logged in to resource system Nurse No conflicting event allocation No conflicting schedule No conflicting override

Ό087] Patient alarm

Event ID	Patient attendance 1
Location	Location 1 or next nearest location
Urgency	Normal (3)
Capability requirement	Logged in to resource system Any medical staff No conflicting event allocation No conflicting schedule No conflicting override

Ό088] Pager call

Event ID	Pager call
Location	Any
Urgency	N/A
Capability requirement	Logged in to resource system Any staff Any status Available to receive pager events

[0089] incoming call

Event ID	Incoming telephone call
Location	Any
Urgency	N/A
Capability requirement	Logged in to resource system Any staff No conflicting event allocation No conflicting schedule No conflicting override

Ό090] Incoming messages

Event ID

Incoming message

Location	Any
Urgency	N/A
Capability requirement	Logged in to resource system Any staff Any conflicting event allocation Any conflicting schedule Any conflicting override

[0091] The pager call, incoming call and incoming messages types may be used, dupiicated or modified to allocate any form of incoming communication. These may include telephone calls, text messages, sms, multimedia messages, video calls, emails, pages, alarms, forwarded messages and calls, and requests for equipment/resource, other electronic notifications and other electronic forms of communication.

[0092] Thus it can be seen that a variety of event types can be defined having a variety of urgencies, location requirements and capability specifications.

[0093] Further approaches may be implemented to deal with other situations. Other medical event types may be defined depending on the nature of the event in question. Other communication event types may be defined based on the nature of the communication, or may be defined to fit within one of the communication types above. For example, although the communication types refer to “incoming” communication, this can be treated as incoming in the sense of incoming to the resource in question, such that internal calls, messages and pages can be handled in the same way as calls, messages and pages arriving from outside.

[0094] In some examples, an alternative call handling process may be implemented to deal with calls that cannot be answered by the intended recipient resource. Options under such a process may include force the call to go through anyway, forwarding the call to another resource, sending a message describing the call, or hanging up. Different ones of these options may be used for different call sources. The call forwarding option may select a different resource or group of resources to receive the call instead of the intended recipient resource and having a suitable capability relationship to the intended recipient resource.

[0095] Turning now to an overview of how the resource allocation system described above operates to allocate resources to particular event, reference is made to Figure 7. This figure illustrates a set of high level steps for operating the resource allocation system using preallocation of resources described by resource records to possible events and then using the pre-allocation to decide an actual resource allocation responsive to an event.

[0096] Starting with step S7-1, a resource record is determined from resource information describing that resource. The resource record is stored in the resource information store 14. Then, at step S7-3, the pre-allocation unit 16 determines a suitability score for that resource record as against each event type and creates the availability profile. As discussed above, the availability profile may be written to the resource information store 14 or the resource allocation store 17. Thereafter, in response to a determination or notification that one or more resource records are changed at step S7-5, the suitability scores for the changed resource records are updated by the resource pre-allocation unit 16 at step S7-7.

[0097] Continuing the process, responsive to receiving at step S7-9 an event notification via the by event input interface 20, the event manager 18 identifies at step S7-11 a resource for the event by comparing the notified event to the availability profiles. The identified resource is then notified of the event via the notification engine 22 at step S7-13. Depending on the nature of the event, the notification may be a text-based or audio message, a phone call, a haptic alert such as a device vibration and/or a non-verbal visual or audio alert such as a flashing light or notification sound.

[0098] The process can then continue at step S7-15 with an optional step of receiving an accept/reject response to the notification sent to the resource. This step may be implemented in systems where an accept/reject facility is provided to the resource. As indicated by the dashed line, in the event of an event allocation rejection from the resource, it may be necessary to determine another resource for the event and therefore the process may return to step S7-11 for identification of another resource. In situations where multiple resources are allocated to an event, such re-identification of a resource for the event may not be required, or may only be required where all or more than a certain number or percentage of the multiple resources reject the allocated event.

[0099] An event accept/reject response can be generated by an allocated resource in response to receiving an event allocation communication at a suitable device associated with the resource. Such a response can aiso or alternatively be generated on behalf of an allocated resource in response to receiving an event allocation notification by a person or system responsible for managing the time/schedule of the resource. Further, such a response can additionally or alternatively be generated as a fault handling response in the event that a communication engine is unable to deliver the event allocation notification for the attention of the resource and/or as a fault handling event in the case that the allocation decision was made on resource record data that was not fully up to date.

[0100] The resource allocation system of this example continuously checks for updates to the resource records and re-calculates the suitability scores for changed records so as to keep the pre-allocations of the resources to the event types up-to date. Depending on the exact triggering method used to cause the next update cycle, this update may be considered as operating on a real-time or near-real-time basis. In some examples, the system may be configured to process resource record updates in response to new resource information being received by the resource update interface 12. In other examples, the system may be configured to process resource updates on a time cycle basis where a check for new updates is made every time a wait interval expires. In addition, a combination of notification and timeout may be used.

[0101] In the present example, a timestamp system is used to manage the relationship between handling updates and taking event allocation decisions. At regular intervals, a timestamp is issued by the event manager (in alternative examples this could be issued by, for example, the resource pre-allocation unit or a control entity). The timestamp indicates a current time point at which updates to resource records and consequent updates to availability profiles are fixed. Thus each successive timestamp represents a respective point in time from which the availability profiles are frozen. This freeze only lasts until the next timestamp, and by arranging each timestamp to be separated from the previous timestamp by a small interval, the system achieves performance that in real-world terms appears to be real-time or near-real-time in responsiveness. In the present examples, each inter-timestamp interval is of the order of a few seconds, typically between 1 and 25 seconds. This interval can be set for each implementation of the system according to factors such as the volume and/or rate of resource updates and the volume and/or rate of events occurring. Thus, in approaches that implement this approach, updates to availability profiles based upon resource updated are effectively queued or paused until the next timestamp is issued. Typically, by having a short inter-timestamp interval, the number of updates to be made is small compared to the total volume of resource records and availability profiles within the system.

[0102] In recognition that even with a very short inter-timestamp interval it is possible that an event may be allocated to a resource that is no longer available to receive that event, the present teachings also provide that an fault handling arrangement may be implemented to deal with situations where an allocation decision was made on resource record and availability profile data that was not fully up to date. An example approach for such fault handling is described below.

[0103] With reference to Figures 8A and 8B, there will now be described approaches for updating a resource record based upon incoming resource information. The approaches illustrated provide for updates to be processed on a simple queue or notification system (Figure 8A), or to be processed on a timeout system (Figure 8B). Such updates to resource information may be used to input into the system changes to a resource’s schedule, skills, availability, log-in status or any other information stored in one or more resource records.

[0104] Accordingly, a first example approach for updating resource records in the resource information store 14 is illustrated in Figure 8A. In this example, the process starts based upon a trigger or notification that new resource information has been received and/or is waiting in a queue or buffer. Accordingly, at step S8-1 the method starts by assessing the next resource update awaiting attention. At step S8-3, the corresponding resource record is identified. In some examples, this identification may be performed by matching a resource identifier of the new resource information to a resource identifier of a resource record. In the event that the new resource information does not correspond to an existing resource record, the new resource information may either be used to generate a new resource record or be notified to an administrator user of administrator function for further handling. Such an administrator can then take action relating to administrative steps such as creation of a new resource record or rejection of the new resource information.

[0105] Having identified a matching resource record for the new resource information, the process continues at step S8-5 where the resource record is updated according to the new resource information. Thus the updates based on the current new resource information are complete. Accordingly, the process continues at step S8-7 where a check is made to determine whether any further new resource information has been received and/or is waiting in a queue or buffer for handling. If the answer is yes, then processing returns to step S8-1 where the next resource update has been. If on the other hand the answer at step S8-7 Is no, the process ends. The process can then be restarted in response to a future trigger or notification that new resource information has been received and/or is waiting in a queue or buffer, [0106] Turning now to Figure 8B, a second example approach for updating resource records in the resource information store 14 is illustrated. In this example, the process is a continuous process that loops on a timeout basis to repeatedly re-check for new resource information that has been received. Accordingly, at step S8-11 the process checks for the presence of new resource information awaiting attention. If it is determined at step S8-13 that no new resource information is awaiting attention, then the process continues to step S8-15 where a delay occurs or a wait until the end of a next timeout period is performed. Following step S8-15, the process returns to step S8-11 where a new check is made for the presence of new resource information awaiting attention.

[0107] If it is determined at step S8-13 that new resource information is awaiting attention, then the process continues to step S8-17 where by the next new resource information awaiting attention is selected. At step S8-19, the corresponding resource record is identified, in some examples, this identification may be performed by matching a resource identifier of the new resource information to a resource identifier of a resource record. In the event that the new resource information does not correspond to an existing resource record, the new resource information may either be used to generate a new resource record or be notified to an administrator user of administrator function for further handling. Such an administrator can then take action relating to administrative steps such as creation of a new resource record or rejection of the new resource information.

[0108] Having identified a matching resource record for the new resource information, the process continues at step S8-21 where the resource record is updated according to the new resource information. Thus the updates based on the current new resource information are complete. Accordingly, the process returns to step S8-13 to check whether any more updates of new resource information are waiting attention.

[0109] Thus it will be seen that updates of new resource information can be handled in a number of ways to process updates to resource records in the resource information store 14. Thus the resource information store can be kept up-to date on an ongoing basis with new resource information.

[0110] With reference to Figure 9, there will now be described an example approach for creating availability profiles for resource records in the resource information store 14. This example method is described in the context of the structures illustrated in Figures 1A and 1B above in that the availability profile is written to the resource record in the resource information store. A similar approach can however be adopted with the result that an availability profile is written to a resource allocation store such as that illustrated in Figure 1C described above. [0111] The approach of Figure 9 commences at step S9-1 with a next resource record being selected for processing. Then, at step S9-3 a next event type is selected for consideration. Having selected a particular event type for a particular resource record, a comparison is performed between the data in the fields of the resource record and the fields of the event type. The result of this comparison provides that at step S9-7 an availability score is determined for the suitability of the resource described in the resource record for the event type being considered. The process then checks at step S9-9 whether any further event types need to be evaluated for the currently selected resource record. If the answer is yes the method returns to step S9-3 for the next event type to be selected. If the answer Is no, then the processing for the currently selected resource record is complete such that the availability profile for that resource record can be applied to the resource record at step S9-11.

[0112] With the availability profile for the selected resource record now complete, a check is performed at step S9-13 to determine whether any further resource records need to be processed, if the answer is yes, then the process returns to step S9-1 for the next resource record to be selected, if the answer is no, then the process is complete. Thus it will be seen that the pre-allocation unit 16 can process a resource record to determine an availability profile therefor. The availability profile can then be written to an appropriate store, such as resource information store 14 or resource allocation store 17.

[0113] Although it is described with reference to Figure 9 above that the process performs a check on ail event types for a given resource record, the process could be configured to process all resource records for a given event type before moving to a next event type. Alternatively, a batch-handling approach could be performed where all resource records in a group or batch are processed according to event type before the method moves on to the next group of resource records.

[0114] With reference to Figures 10A and 10B, there will now be described approaches for updating an availability profile based upon an updated resource record. The approaches illustrated provide for updates to be processed on a simple queue or notification system (Figure 10A), or to be processed on a timeout system (Figure 10B). Such updates to resource information may be used to input into the system changes to a resource’s schedule, skills, availability, log-in status or any other information stored in one or more resource records.

[0115] Accordingly, a first example approach for updating availability profiles by the resource pre-allocation unit 16 is illustrated in Figure 10A. In this example, the process starts based upon a trigger or notification that a resource record has been updated. Such trigger or notification may be performed based upon completion of a resource record update such as described above with reference to Figures 8A and 8B. Accordingly, at step S10-1 the method starts by selecting the next updated resource record awaiting attention. At step S10-3, the corresponding availability profile is updated based upon the revised resource record field data. This update may be performed in much the same manner as generating a new availability profile, such as described above with respect to steps S9-3 to S9-11 of Figure 9. in the case where the updated resource record does not have an availability profile, a new availability profile may be created in the same way.

[0118] Thus the updates based on the current updated resource record are complete. Accordingly, the process continues at step S10-5 where a check is made to determine whether any further updated resource records are awaiting attention. If the answer is yes, then processing returns to step S10-1 where the next updated resource record is selected. If on the other hand the answer at step S10-5 is no, the process ends. The process can then be restarted in response to a future trigger or notification of updated resource records.

[0117] Turning now to Figure 10B, a second example approach for updating an availability profile based on updated resource records in the resource information store 14 is illustrated, in this example, the process is a continuous process that loops on a timeout basis to repeatedly re-check for new resource information that has been received. Accordingly, at step S10-11 the process checks for the presence of updated resource records awaiting generation of an undated availability profile. If If is determined at step S10-13 that no updated resource records are awaiting attention, then the process continues to step S10-15 where a delay occurs or a wait until the end of a next timeout period is performed. Following step S10-15, the process returns to step S10-11 where a new check is made for the presence of updated resource records awaiting attention.

[0118] if it is determined at step S10-13 that new resource information is awaiting attention, then the process continues to step S10-17 where the next updated resource record awaiting attention is selected. At step S10-19, the corresponding availability profile is updated based upon the revised resource record field data. This update may be performed in much the same manner as generating a new availability profile, such as described above with respect to steps S9-3 to S9-11 of Figure 9. In the case where the updated resource record does not have an availability profile, a new availability profile may be created In the same way.

[0119] Thus the updates based on the current updated resource record are complete. Accordingly, the process returns to step S10-13 to check whether any more updated resource records are waiting attention.

[0120] Thus it will be seen that that resource pre-allocation unit 16 can process updated resource records in a number of ways. Thus the availability profiles can be kept up-to date on an ongoing basis as resource records are updated.

[0121] In some examples resources may be grouped. Thus it may be provided that all resources of a particular group are notified of events together. Additionally or alternatively, it may be provided that colleagues of a given role or grade may be grouped together such as to provide for group-level availability management. Where groups are used, a group head may also be allocated to provide for group-level oversight of resources at a human level as well as through the resource allocation system. Thus a group head may be enabled to update a schedule or status of another resource within the group or, for example set a rule that no more than a certain number of percentage of resources within the group can be allocated to events at any given time.

[0122] The timescale for updating the availability profiles may be set in dependence upon the expected rate of resource information changes, in the present example, the updates to availability profiles are performed In real-time or near-real-time. In this context, real-time means that the updates to the resource information are processed sufficiently quickly that after any given resource update is received, the corresponding availability profile is updated fast enough that an event received after the resource update will be processed based upon an availability profile from pre-allocation that takes the resource update into account. With reference to the timestamp approach discussed above, this would mean that the timestamp interval is so short that in the normal course of events there are no updates queued for processing when the timestamp is applied and that any updates that arrive before the next timestamp are processed as part of creating that next timestamp. Further, the concept of near-real-time means that resource information updates are processed to create updated availability profile information as soon as the resource information updates are received, such that an event received after the resource update should normally take the resource information update Into account but may not include a small number of most recent resource information updates if there has not been time to perform the pre-allocation between receipt of the resource information update and the receipt of the event. In the context of the timestamp approach discussed above, this corresponds to the situation where the timestamp interval is sufficiently short that only a small number of updates need to be queued or paused pending the next timestamp being processed.

[0123] Returning to the healthcare environment example introduced above, there are now presented some examples of how a resource record may be matched to an event type to create an availability profile.

[0124] Starting with the example of the cardiac arrest alarm, this is now illustrated in parallel 5 with example resource record entries that enable the comparison to be made and a suitability score to be reached.

[0125] Cardiac arrest alarm

Event type fields	Event type definition	Resource Doctorl	Resource Doctor2	Resource Doctors	Resource Doctor4	Resource Nursel	Resource Nurse2
Event ID	Cardiac arrest 1
Location	Location 1 or escalate	Location 1	Location 1	Locationl	Locationl	Locationl	Locationl
Urgency	Critical (1)
Capability requirement	Logged in to resource system	Logged-in	Logged-in	Logged-in	Not iogged in	Logged in	Logged in
Doctor	Doctor	Doctor	Doctor	Doctor	Nurse	Nurse
No conflicting higher urgency event allocation	No active events	On internal telephone call	No active events	No active events	No active events	On nurse alarm
No conflicting higher urgency schedule	in surgery	Scheduled to paperwork time	Scheduled to patient consultations	Scheduled off-shift	Scheduled to patient consultations	Scheduled to ward care shift
No conflicting higher urgency override	No override	No override	No override	No override	No override	No override
Suitability score		0	3	2	0	1	1

Ό126] In this example, if can be see that Docforl is rated as suitability zero because he or she is in surgery and thus cannot abandon a patient on the operating table to deal with another patient. Doctor2 however is rated with suitability three because he or she is on an internal telephone call (which in this example is assumed not to involve direct input to a patient) and scheduled to paperwork time with no over-rides applied. Doctor3 is rated with suitability two as he or she is scheduled to patient consultations and thus gets a iower rating than Doctor2 who is not seeing patients. Doctor4 is rated with availability zero as he or she is not logged In and by way of confirmation of this is scheduled off shift. Both nurses are rated to suitability one as neither is a doctor (the prerequisite for this event type) but both are available with no higher priority events or schedule and thus could be allocated to such an event type in a situation where no doctor were available.

[0127] A further example now illustrates the same set of resource records tested against the nurse alarm event as illustrated above.

Ό128] Nurse alarm

Event type fields	Event type definition	Resource Doctor!	Resource Doctor2	Resource Doctor3	Resource Doctor4	Resource Nurset	Resource Nurse2
Event ID	Cardiac arrest 1
Location	Location 1 or escalate	Location 1	Location 1	Locatiorri	Location 1	Location!	Location 1
Urgency	Critical (1)
Capability requirement	Logged in to resource system	Logged-in	Logged-in	Logged-in	Not logged in	Logged in	Logged in
Doctor	Doctor	Doctor	Doctor	Doctor	Nurse	Nurse
No conflicting higher urgency event allocation	No active events	On internal telephone call	No active events	No active events	No active events	On nurse alarm
No conflicting higher urgency schedule	in surgery	Scheduled to paperwork time	Scheduled to patient consultations	Scheduled off-shift	Scheduled to patient consultations	Scheduled to ward care shift
No conflicting higher urgency override	No override	No override	No override	No override	No override	No override
Suitability score		0	0	0	0	2	1

Ό129] In this example, can be see that all doctors are rated as suitability zero because they are not nurses. Nursel is rated with suitability three because he or she is capable of attending but is scheduled to patient consultations and thus should be given a suitability high enough to indicate that he or she could be selected to receive the nurse alarm event, but low enough that another nurse resource currently not scheduled to specific patient activity will be allocated to the alarm if available. Nurse2 is rated with suitability 1 as although he or she a nurse and has not specific schedule or over-ride collision, he or she is already allocated to another nurse alarm event and thus should only receive another nurse alarm event if no other nurse resources are available.

[0130] Thus Is can be seen that the wide variety of factors set out in the event type fields can be used as a point of comparison to various resource records so as to arrive at a suitability score for each resource record to that event type. It will be appreciated that greater or lower resource specificity may be used in the definition of event types depending on factors such as the nature of the event, the size and skill spread of the resource pool upon which the system can call, it will also be appreciated that a wide range of possible suitability scores may be awarded to different resources so as to provide a suitable level of granularity to cope with the different combinations of matching and non-matching fields as between the event type and the resource record.

[0131] Turning now to Figure 11, this illustrates a process of handling an event notification received via the event input interface 20 and allocating that event notification by the event manager 18 to a particular one or more resources based upon the availability profiles. This process therefore enables the event manager to rapidly and efficiently chose one or more resources to be allocated to a given event based upon the pre-allocations stored in the availability profiles corresponding to the various resource records.

[0132] Thus, the process of Figure 11 commences at step S11-1 with an event notification being received via the event input interface 20. As discussed above, this event notification may therefore arrive via a manual input such as a keyboard or buttonpad of the system, or from a connected input device such as remote terminal or emergency button via a network or other remote data connection.

[0133] Upon receipt of the event notification, the event manager 18 identifies the event type at step S11-3 and compares the received event to the availability profiles of the various resources known to the system at step S11-5. Therefore, at step S11-7, the event manager can determine the one or more resources with a best suitability to be allocated the received event. Thus a suitable event handling output can be sent to the determined resource(s) via the notification engine 22. The event handling output may be a notification directed solely to the selected resource or may be sent to one or more other resources instead of or in addition to the selected resource. The event notification as sent to the resource may include details of the event such as location, urgency and capability requirement. The event notification may be transmitted to the selected resource by a suitable communications mechanism, such as by PA, phone call, sms, pager, email, text message, conference call, or video call, or by any other form of electronic communication or notification. In the event that the selected resource as allocated to the event for handling of the event is unable to attend to the event, the resource may be provided with an option to reject the event such as to cause the event manger to select a different resource for handling fhe event [0134] The accessing of the availability profiles at step S11-5 includes accessing the availability profiles stored in the resource information store 14 or resource allocation store 17. To facilitate rapid and efficient access to the availability profiles, the availability profile data may be stored as a multi-dimensional array, it is noted above with respect to Figure 3 that the availability profile may be stored on a conceptual level within in the resource record, however as a matter of logical arrangement of data for access by the event manager, a number of different data structures may be utilised to provide for efficient access and searching. Thus in one example, an availability resource array may be constructed with the availability score for each event type for each resource record in an individual node in the array, such that for any event type, an availability score for each resource records can be accessed and sorted to facilitate a best match approach for identifying one or more resources to allocate for any given received event. [0135] As will be appreciated, where the resource is a human resource, the notification will be sent to a communication device associated with that human resource, in the present example, the notification device is a dedicated communication device allocated to the resource as part of the operation of the resource allocation system. This communication device can make and receive telephone calls, text messages, and emails, and can receive pages. Thus the human resource may be provided with a single device that provides for all in-ro!e communications requirements. Such devices may be maintained by the system and allocated in combination with a system login activity, such that the resource is allocated a communications device and changes login status to logged in at substantially the same time, such as when starting a working shift. In examples which use resource or event location, such devices may also provide for automatic location updates to be provided for the resource record of the resource allocated to the device. By using an appropriate location finding technology (which may include GPS, proximity beacons such as Bluetooth beacons or other location-finding technologies) the device may keep track of its current location and send updates whenever the device changes to a different location. Additionally, such a device may permit a user to view and/or update at least some of their own or other users’ resource status information. For example, a user may be able to use an allocated device to manually update fields such as a manual status override, or a schedule change. Also, a user may be able to see the availability of colleagues (such as other members of a resource group) in terms of login status, current availability status, current event allocation status or the like. Where group heads are allocated, fhe group head may be enabled to use the device to monitor the group information and/or update group member information as discussed above..

[0136] Other approaches for communications devices associated with human resources can be used in other examples, in some examples the resource may be associated with one or more communication devices not specifically associated with the resource allocation system, but which are available for the resource allocation system to communicate with. Thus a resource may have one or more of a mobile (cellular or DECT) telephone, pager, messaging tablet, desk telephone, desk or mobile computer or the like to which certain notifications may be provided. The resource allocation system may for example be configured to send telephone call events to a telephone device and text message or page events to a pager device.

[0137] In some examples, the resource allocation system may allow for a blend of systemspecific communication devices and other communication devices. For example, where a resource is on-shift at a work location, the resource may be provided with a resource allocation system communication device with the communications facilities and link to login status as outlined above. In addition, a resource that is working in a different location or off-shift (such as if working from home or another office) may be able to log in to the system for receiving telephone calls or text-based messages relating to activities that can be performed remotely, but not for receiving notifications of urgent in-premises or on-shift activities. Returning to the healthcare example discussed above, a resource may receive a resource allocation system communication device when on-shift in a healthcare facility and thus be available for ali suitable events. That same resource may be able to log in remotely when performing paperwork tasks from an office building or from home and in that remote log-in status may be able to take telephone calls from colleagues or from patients, but will not be available to attend locationspecific medical emergency events.

[0138] In the context of the fault-handling approach mentioned above in which an unprocessed update may cause allocation of a resource to an event, which allocation would not have occurred if that unprocessed update had been processed, a device associated with the resource can provide the fault handling processing. This can be applied whether the device is a system-specific communication device or another communication device operating systemspecific software or apps to provide interactions with the system. Such a device may keep track of all resource status updates that it sends to the resource update interface and in particular a time property of when such updates were created and sent to the resource update interface. [0139] Accordingly, when such a device then receives a notification that the associated resource has been allocated to a given event, the system timestamp according to which the allocation decision was made by the event manager can be provided in that event allocation notification. Thus the device can compare the timestamp for the event allocation decision as included in the event allocation notification to the submission times of the most recently submitted resource status updates for the associated resource. If this comparison indicates that one or more resource status updates have been submitted since the event allocation decision timestamp, the fault processing can be invoked.

[0140] in the present examples, such fault processing may take one of two forms. The first is that any such time conflict causes a fault-handling response to be passed back to the event manager indicating that the event allocation decision was made on out of date data such that the event manger can decide whether a new event allocation decision needs to be made, either excluding that resource or forcing a next timestamp to be made (if it hasn’t already) before the redetermination.

[0141] The second form is that the device can itself perform processing to determine whether the submitted resource status update makes any difference to the allocated event as notified in the resource allocation notification. For example, if a resource status update has been provided that the resource is unavailable for any events within the next hour (e.g. due to being a surgeon who has commenced a surgery in an operating theatre) then the device may send a fault reply of the received event is an incoming telephone call, but not if the incoming event is a meeting notification for two days’ time. In this approach, a smaller number of fault handling replies may be possible, at the expense of requiring greater intelligence in the device for the resource. In this approach, if the device determines that the resource status update does make a difference to the ability of the resource to accept the event allocation (or if the device cannot determine an answer to this determination) a fault-handling response is passed passed back to the event manager indicating that the event allocation decision was made on out of date data such that the event manger can decide whether a new event allocation decision needs to be made, either excluding that resource or forcing a next timestamp to be made (if it hasn’t already) before the redetermination.

[0142] As is discussed below, not all event allocation rejections from the fault handling system will result in a new allocation determination by the event manager. This applies to both of the described approaches for communication device implemented fault handling.

[0143] in examples where the resource can be an article or item of equipment, the notification engine 22 may provide a notification of the event being allocated to that resource directly in situations where the equipment is capable of autonomous operation. The notification engine 22 may also or instead provide a notification of the event being allocated to one or more predefined handlers of the equipment. This approach may include notifying a human resource both of their own personal allocation to the event and of an equipment item that they will need to obtain or collect in order to handle the event.

[0144] As discussed above, the system may be implemented with the possibility or requirement for a resource allocated to a task In this way to positively accept or reject an allocated event. Such an acceptance or rejection may be provided by or on behalf of a resource using a suitable device as also discussed above. Similarly, a fault handling approach may provide for automatic rejection of an allocated event in a situation when a submitted but not-yet processed update to the resource status has caused an event allocation decision by the event manager that would not have been made bad that update already been processed.

[0145] Where an event is allocated to a single resource, a rejection response may trigger a further iteration of determining an allocated resource according to the approach shown in Figure

11. In such a further iteration, the resource that rejected the task may be excluded from consideration. Where an event is allocated to multiple resources, a further iteration of the steps in Figure 11 may be repeated in some circumstances but not in others. For example if only one or a small proportion of resources allocated to the event reject the event, this may not require a further iteration to identify alternative resources to allocate to that task. On the other had if a large proportion or ail of the resources allocated to the task reject that task then a further iteration may be required. The exact determination of whether or not to re-perform an identification of resources to allocate to the task will likely depend upon the nature of the task and other factors in the system implementation. In a further alternative approach, the initial determination of resource(s) to allocate to an event may return more resources than are initially allocated and notified. In this approach, a rejection from one or more resources that have been initially allocated and notified could be followed by an allocation and notification to additional tasks returned by the initial process but not initially allocated and notified.

[0146] Thus it will be appreciated that a variety of approaches may be implemented for allocating an event to a resource and communicating the event to the resource.

[0147] Accordingly, the reader will appreciate that the approaches disclosed herein may be deployed to provide efficient and rapid resource allocation decisions in response receipt of an event. This rapid response is facilitated by the pre-allocation of a large number of resources to each of a large number of event types so as to provide that the allocation decision is largely premade. Furthermore, by constantly updating the pre-allocations based upon status changes to the resources, the allocation decisions are based upon up-to-date resource status conditions. [0148] As will be appreciated from the discussion above and the various examples mentioned, the resource record may be populated with a wide variety of context data (resource information) relating to the resource. This context data may be varied depending upon factors relating to the particular resource environment to be managed by any given implementation. However, it will also be appreciated that many environments requiring management of resources to provide event allocation, particularly environments with large numbers of resources and event types, are likely to have a number of common themes as regards the types of context data that may be used. Examples of such context data fields that may be applicable to a variety of implementational environments include the following.

[0149] Group is defined in the present examples as being substantially static data relating to a resource’s employment or team membership. Group membership can change over time, but would ordinarily be expected to be stable for at least a number of hours and more likely a number of days, weeks, months or even years. A resource may be able to belong to more than one group. A group allocation can be used to provide a closed loop of resources to receive events. This closed loop of resources for receiving events may be used in a number of ways, such as: that ail members of the group always receive all events: that at least one member of the group always receives an event of a given type; or that a minimum number of group members are always kept free of current event allocation. Such a group may be based upon list of colleagues in a working team and thus may also provide for a telephone dialling group or similar in an internal resource directory. Group properties may define that all group members are connected to an identical set of rules for event allocation and may also define a set of possible events that can be allocated to one or more group members. Group existence, membership and properties may be configured by an administrator role as required by the particular implementation. Viewing group membership and properties may be available to group members and/or a group lead role.

[0150] Role is defined in the present examples as being substantially static data relating to the employment position, capability or area of expertise of the resource. Role information may change over time due to a resource receiving additional skills training and/or role changes such as promotions, but would ordinarily be expected to be stable for a number of weeks, months or years. A role allocation can be used as a factor in deciding the relevance of specific event types when considered by the pre-allocation approach. Role information may be visible in an internal resource directory and may be connected to a set of default rules associated with the particular role. The role information may define a set of possible event allocations, in that some event types may be assignable only to certain roles or vice versa. Such role Information may therefore override or supplement rules defined by group membership. Role existence, membership and properties may be configured by an administrator role as required by the particular implementation.

[0151] Assignment is defined in the present examples as being flexible data linked to responsibility, such as responsibilities of a work-shift team or responsibilities within a work-shift team. The assignment can be used as a factor in deciding the relevance of specific event types when considered by the pre-allocation approach. Assignment information may be visible in an internal resource directory and may be connected to a set of default rules associated with the particular assignment. The assignment information may define a set of possible event allocations, in that some event types may be assignable only to certain assignments or vice versa. Such assignment information may therefore override or supplement rules defined by group membership. Assignment existence, membership and properties may be configured by an administrator role as required by the particular implementation.

[0152] Presence is defined in the present examples as dynamic data linked to the login-status of the resource in the resource allocation system. Presence information may be visible in an internal resource directory. In general, resources with no presence are ignored as allocatable resources for a given event. However, where an event is notified as an advance notice event and the resource is expected according to shift or schedule data to have active presence by the time the event occurs, then the resource may be allocated to the event despite having no presence at the time that the event was notified.

[0153] Status is defined in the present examples as personal data linked to the business in which the resource allocation system is deployed. The status is used to avoid interruptions in busy situations such as a time-interval after allocation of a resource to a previous active event and for example when changing or entering locations. Depending on the status, some further event notifications via some event notification channels (such as a page notification of a critical emergency) may be permitted during a busy status whereas other event notifications or event notification channels (such as a telephone call) may be blocked. Status information may be visible in an internal resource directory. The status time-settings and locations can be connected to default rules, but the time-setting rules can be personalized and status can manually be set to appropriate modes by the resource, [0154] Location is defined in the present examples as static data linked to known locations in the geography to which the resource allocation system is deployed. In geographies such as buildings, campuses and other defined areas or volumes, location may be provided by localised beacons such as Bluetooth beacons. In large geographies that include off-site deployments, location may be provided by a positioning system such as a satellite navigation receiver compatible with GPS, GLONASS or Galileo or the like. Mixed location setting systems may also be implemented using localised beacons and positioning system receivers. When a resource is at a given location, the resource record may be updated to reflect the currently detected location. The location information can be used to set a status of resources entering that location, either for a defined time period or for the duration of the stay in that location. The location information can also be used to track distance of a resource from any other location, which may be used in determining a suitability score for a resource to an event type that requires proximity to a particular location in the event type definition. A location may also have associated default rules. Location may in some implementations allow a manual override either to the location itself or to a default status associated with the location.

[0155] Therefore, it will be understood that the present approaches can provide for resource allocation to be performed based upon intelligent pre-allocation of a large number of resources to each of a large number of predefined event types so as to enable a rapid yet correct allocation of a resource to an event when the event is notified to the system.

[0156] Although specific examples have been provided of deployment of the presently disclosed resource allocation system in a healthcare environment and an emergency services response environment, the present approaches can be deployed in a variety of environments.

Typically such environments involve the management of very large numbers of resources and very large numbers of possible tasks. Example environments in which the present approaches may be usefully deployed include hospitals and other healthcare facilities and organisations, emergency response services, armed forces training and deployment, armed forces materiel management, project management, oil and gas exploration and extraction operations, and transport 8s logistics operations.

[0157] By providing a resource allocation system that uses communication devices specific to the system according to at least some examples discussed herein, resource allocation may be performed while achieving consistent use of resource notification devices appropriate to the deployment environment. This may facilitate ease of movement and operation for the resource by minimising equipment to be carried by the resource while facilitating continuity of working in the event of device failure as the failed device can simply be ignored and a replacement device obtained and logged-in to maintain presence and status within the system. Such devices may also provide for data security by ensuring that personal devices of the resources in the system are not usable for confidential work-related communication. Also, such devices may provide for appropriate devices to be selected for the deployment environment, such that for example ruggedized devices may be issued in a construction work environment and easily sterilisable devices may be issued in a healthcare environment.

[0158] By providing a resource allocation system that uses selected rules to define which resource(s) should be allocated to a given event according to at least some examples discussed herein, resource allocation may be performed while achieving minimal unnecessary disturbance to resources caused by unnecessary notification of alarms or alerts relating to events that the resource is not suited or able to attend or deal with. Thus notifications of events may be provided either silently or not at all to resources with a present location, status or presence that prevents or renders unsuitable that resource for handling the event. Such reduction of “noise” may provide for resources to work with fewer disturbances and therefore to apply concentration to the task in hand for optimised accuracy and efficiency.

[0159] Therefore, there has now been described an approach for efficiently and effectively allocating resources to events based upon computational pre-allocation of matches between resource records and event types such that upon receipt of an event a suitable resource can be selected from the pre-allocation results and notified via a controlled communication channel that the event has occurred and that it is now the allocated resource for that event. The preallocation can be updated on an ongoing basis to provide that actual event allocation is based upon up-to-date pre-allocations based upon up-to-date resource records. Thus the speed of response provided by the pre-allocation is provided in cooperative synergy with the accuracy of determining resource allocation in real time to provide that the allocation is appropriate to the current status of resources in the system.

Claims

1. A computer-implemented resource allocation system comprising:

a resource information store configured to store a plurality of resource records, each resource record comprising information identifying a resource and information describing a live status and a capability of that resource;

a resource pre-allocation processor configured to create a resource availability profile by, for each resource record in the resource information store, determining for each of a plurality of event types an allocation score identifying a suitability of each resource for each event type, and to update the resource availability profile based upon a change to the resource record;

an event manager configured to, responsive to reception of communication describing an event, match the event to the resource availability profile to select a resource to be allocated to the event; and a notification engine configured to transmit an event notification to a communication device associated with the selected resource.

2. The computer-implemented resource allocation system of claim 1, wherein each resource record further comprises information describing a location.

3. The computer-implemented resource allocation system of claim 1 or 2, wherein the event communication is an event attendance instruction.

4. The computer-implemented resource allocation system of claim 1, 2 or 3, wherein the resource pre-allocation processor is configured to detect a change to a resource record and to update the resource availability profile for the changed resource record.

5. The computer-implemented resource allocation system of claim 4, wherein the resource pre-allocation processor is configured to detect a change to a resource record by receipt of a notification that a resource record has changed, and/or by periodically checking for resource record update.

6. The computer-implemented resource allocation system of claim 4 or 5, wherein the resource pre-allocation processor is configured to update the resource availability profile for the changed resource record in real-time or near-real-time.

7. The computer-implemented resource allocation system of any preceding claim, wherein each resource is a human resource or an equipment resource.

8. The computer-implemented resource allocation system of any preceding claim, wherein the live status comprises one or more selected from the group comprising: log in status, presence, manual status override, busy status due to ongoing event, and schedule,

9. The computer-implemented resource allocation system of claim 2 or any claim dependent thereon, wherein the location comprises a measured location or a proximity to a location beacon.

10. The computer-implemented resource allocation system of any preceding claim, wherein the event type comprises one or more selected from the group comprising: telephone calls, text messages, sms, multimedia messages, video calls, emails, pages, alarms, forwarded messages and calls, and requests for equipment.

11. The computer-implemented resource allocation system of any preceding claim, wherein the event type defines a capability requirement and an urgency.

12. The computer-implemented resource allocation system of claim 11, wherein the event type further defines a location.

13. The computer-implemented resource allocation system of any preceding claim, wherein the event notification comprises one or more selected from the group comprising: type; content; time; originator ID, such as location, calling party id, called party id, message sender id, and message receiver id; and indicative selection criteria, such as group id, role, capability and responsibility.

14. The computer-implemented resource allocation system of any preceding claim, wherein the allocation score is based on a closeness of match of resource capability and/or responsibility defined by the resource record to an event type capability requirement.

15. The computer-implemented resource allocation system of any preceding claim, wherein the allocation score is based on an availability profile such as available, busy and pager mode, and wherein a different availability profile is applicable to different event types.

16. The computer-implemented resource allocation system of claim 12 as dependent from at least claim 2, and any claim dependent thereon, wherein the allocation score is based on a closeness of match of resource location to event location.

17. The computer-implemented resource allocation system of any preceding claim, wherein the notification engine is configured to transmit the event notification to the selected resource via a communications channel selected from the group comprising: PA, phone call, sms, pager, email, text message, conference call, and video call.

18. The computer-implemented resource allocation system of any preceding claim, wherein the event notification indicates the event urgency.

19. The computer-implemented resource allocation system of any preceding claim, wherein the resource is an equipment resource and wherein the notification engine is configured to send an event notification to a communication terminal of a human resource also selected by the event manger and/or of an equipment handler for the equipment resource,

20. The computer-implemented resource allocation system of any preceding claim, wherein the resource pre-allocation processor is configured to create and update the resource availability profiles based upon one or more rules defining matching criteria and importance for different one of the data within the resource record for each event type.

21. The computer-implemented resource allocation system of any preceding claim, wherein the resource information store is configured to store and process resource records and corresponding availability profiles for a complexity space defined by the number of resource records, the number of fields per resource record, the number of event types, and the number of fields per event type, for example where the complexity space comprises at least 1000, at least 10,000, at least 100, 000 or more than 100,000 permutations.

22. The computer-implemented resource allocation system of any preceding claim, wherein the resource information store is for storing resource records corresponding to human resources and further comprising a second resource information store for storing resource records corresponding to equipment resources.

23. The computer-implemented resource allocation system of any preceding claim, wherein the resource records relate to resources of one or more selected from a hospital or other healthcare facilities or organisations; an emergency response service; an armed forces training or deployment operation; armed forces materiel; project management; an oil and gas exploration and extraction operation, and transport & logistics operation.

24. A computer-implemented method of allocating resources to events, the method comprising:

determining, for each of a plurality of resources having a resource record defining a live status and a capability of that resource, a suitability score relating to each of a plurality of event

5 types;

responsive to determining that a resource record of a resource has changed, determining an updated suitability score for that resource for each of the plurality of event types;

responsive to receiving an event notification corresponding to one of the event types, matching the event to the suitability scores of the resources to identify a resource to allocate to

10 the event; and transmitting an event communication to a communication terminal corresponding to the allocated resource.

25. The method of claim 24, further comprising steps of operating the system of any of 15 claims 1 to 23.

26. A computer program product comprising computer-implementable instructions for causing one or more programmable computers to become configured as the apparatus of any of claims 1 to 23 or to carry out the method of any of claims 24-25.