WO2023186571A1

WO2023186571A1 - Distributed health personnel allocation system for allocating personnel to medical events

Info

Publication number: WO2023186571A1
Application number: PCT/EP2023/056878
Authority: WO
Inventors: Alexander Sebastian FURNICA; Prescott Peter KLASSEN; Mark Thomas Johnson
Original assignee: Koninklijke Philips N.V.
Priority date: 2022-03-29
Filing date: 2023-03-17
Publication date: 2023-10-05

Abstract

Some embodiments are directed to a distributed health personnel allocation system for allocating personnel to medical events. The system may include a staff experience system, a plurality of mobile personnel devices, and an allocation system. The allocation system allocate a personnel with a high goodness score to a medical event and send a notification to the mobile personnel device associated with the allocated personnel.

Description

DISTRIBUTED HEALTH PERSONNEL ALLOCATION SYSTEM FOR ALLOCATING

PERSONNEL TO MEDICAL EVENTS

TECHNICAL FIELD

The presently disclosed subject matter relates to a distributed health personnel allocation system for allocating personnel to medical events, an allocation system, an allocation method, a computer readable medium.

BACKGROUND

Healthcare staff spends a considerable amount of time and effort looking for colleagues with the right availability and expertise to assist them with their current patient. More generally allocating personnel to medical events is a large issue in a hospital.

A known system is described in US20060074740A1, with title “Medical facility employee scheduling method using patient acuity information”, and included herein by reference. The known method describes a computerized method for scheduling employees at a medical facility that assigns acuity levels to patients at the medical facility. The number of employees to schedule is then determined based on the acuity level.

One drawback of the known system is the difficulty in estimating the resources required for a task. A staff member may for example be individually assigned to a task but as they go in to perform the task, he/she may realize that help is needed. Currently, personnel might go out searching for a staff member they believe could help, or in some cases use a communication tool such as WhatsApp.

Another such situation that may arise, is when a task would best be performed by someone else, either due to preference of the staff or an unforeseen event that requires them to be somewhere else. As with the previous example, there is currently no streamlined way to do this in existing systems, such as the known system.

The known system further suffers from inefficiency and unpredictability. A staff member may go search for someone, but given the dynamic environment in the hospital the outcome is both unpredictable and inconsistent.

SUMMARY

It would be advantageous to have an improved way to allocate personnel to medical events.

An embodiment of a distributed health personnel allocation system may comprise a staff experience system, an allocation system, and a plurality of mobile personnel devices. The staff experience system may be configured to store past experience of the personnel. Interestingly, the experience need not be restricted to experience from one particular site. For example, the staff experience system may receive experience information from multiple sources, including the allocation system.

The plurality of mobile personnel devices may be configured to provide location information and/or information on new experiences that are being acquired. Location information may, e.g., be used in allocation decisions. New experience data may be stored in the staff experience system. Interestingly, an embodiment of the allocation system combines past experience and geolocation, e.g., proximity, to select an advantageous allocation.

Experience may comprise past training or education. Experience may comprise past event that the personnel has worked on.

In an embodiment, the allocation system is configured to keep track of current activities that are being performed, e.g., in a hospital. Personnel may ask for help, in a help request, while other personnel may receive request to provide help, e.g., in a helper receiving alerts.

For example, an allocation request for a medical event, e.g., a request to schedule a person to a time and location to perform a medical task, may be fulfilled in various ways, some better than others. The allocation system may be configured to compute a goodness score for different possible allocations, and select an allocation that has a high goodness score, e.g., highest or higher than a threshold, etc.

The goodness score may be computed from the location information, e.g., from the distance between the current location of a personnel and the location of the medical event. The location information may be obtained from the mobile devices of the personnel. For example, in an embodiment, allocation of personnel is restricted to personnel for which associated location information indicates a nearness to the medical event below a location threshold.

The goodness score may be computed from a match between the desired personnel experience and the past personnel experience. In addition to location and experience, other factors could be included in the goodness score, e.g., availability, alarm fatigue, compatibility and so on.

Different factors may be traded-off against each other, and this can be reflected in how the goodness score is computed. For example, in a first goodness computing function a higher weight is giving to getting help in a short time, while in a second goodness computing function a higher weight is giving to getting help with the best expertise. Yet a further factor to optimize is getting help from the fewest people, so that small teams are used.

In this way, personnel may be selected that is both near the event and has the experience to deal with the medical event. Such allocations may be used for scheduled events, but is also especially advantageous for unscheduled events. For example, an allocation request may be received from a mobile device. The system can then quickly find someone is capable and near the event to provide quick assistance. Interestingly, in an embodiment, the system may further use patient health data, e.g., EMR data, in addition to staff experience data, providing a better, and faster user experience for the creation of teams. The staff experience system fulfills a need to provide objective career data of Health Care Professionals (HCPs). The staff experience system enables better matchmaking of patients to HCPs, as well as easier career management. In an embodiment, the staff experience system may store data, e.g., past personnel experiences, in a distributed ledger. Personnel experience may be stored in other types of storage. Experience may be stored in a distributed database, e.g., shared with other allocation systems, or in a local database, e.g., private to this allocation system. In an embodiment, the staff experience system is provided with an interface enabling HCP to manage stored experience data related to said HCP; e.g., to add, remove, or modify stored experience data.

Having data on staff experience allows to train a machine learning model to predict future allocation success. The staff experience data could be combined with patient health data to improve future allocation success prediction.

The allocation system and staff experience system are an electronic system, and could each be a single electronic device, e.g., a computer. The mobile devices are electronic devices, and could be a smartphone.

A further aspect is an allocation method. An embodiment of the method may be implemented on a computer as a computer implemented method, or in dedicated hardware, or in a combination of both. Executable code for an embodiment of the method may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product comprises non-transitory program code stored on a computer readable medium for performing an embodiment of the method when said program product is executed on a computer.

In an embodiment, the computer program comprises computer program code adapted to perform all or part of the steps of an embodiment of the method when the computer program is run on a computer. Preferably, the computer program is embodied on a computer readable medium.

BRIEF DESCRIPTION OF DRAWINGS

Further details, aspects, and embodiments will be described, by way of example, with reference to the drawings. Elements in the Figs are illustrated for simplicity and clarity and have not necessarily been drawn to scale. In the Figs, elements which correspond to elements already described may have the same reference numerals. In the drawings,

Fig. la schematically shows an example of an embodiment of an allocation system, Fig. lb schematically shows an example of an embodiment of an allocation system, Fig. 1c schematically shows an example of an embodiment of a staff experience system, Fig. 2a schematically shows an example of an embodiment of a distributed health personnel allocation system, Fig. 2b schematically shows an example of an embodiment of a distributed health personnel allocation system,

Fig. 2c schematically shows an example of an embodiment of a distributed ledger,

Fig. 3a schematically shows an example of an embodiment of an allocation data structure, Fig. 3b schematically shows an example of an embodiment of an allocation data structure, Fig. 4 schematically shows an example of an embodiment of an allocation method configured for allocating personnel to a health event,

Fig. 5 schematically shows an example of an embodiment of a distributed health personnel allocation system,

Fig. 6a schematically shows a computer readable medium having a writable part comprising a computer program according to an embodiment,

Fig. 6b schematically shows a representation of a processor system according to an embodiment.

Reference signs list

The following list of reference signs refers to Figs la-3b, 6a-6b, and is provided for facilitating the interpretation of the drawings and shall not be construed as limiting the claims.

100 a distributed health personnel allocation system

110 an allocation system

130 a processor

140 a storage

150 a communication interface

131 personnel tracker

132 allocation search

133 compatibility classifier

134 allocation prediction

135 medical event prediction

160 a staff experience system

162 a database

170 a processor

180 a storage

190 a communication interface

200 a distributed health personnel allocation system

210 an allocation system

211-214 a connection

225, 242 221-223 mobile personnel devices

230 a staff experience system

235 a computer network

241 a further experience provider

260 a request terminal

250 a patient health record system

231.233 a local database

232.234 a staff experience maintainer

271-273 a block

271.1-273.3 an information

1000 a computer readable medium

1010 a writable part

1020 a computer program

1110 integrated circuit(s)

1120 a processing unit

1122 a memory

1124 a dedicated integrated circuit

1126 a communication element

1130 an interconnect

1140 a processor system

DESCRIPTION OF EMBODIMENTS

While the presently disclosed subject matter is susceptible of embodiment in many different forms, there are shown in the drawings and will herein be described in detail one or more specific embodiments, with the understanding that the present disclosure is to be considered as exemplary of the principles of the presently disclosed subject matter and not intended to limit it to the specific embodiments shown and described. In the following, for the sake of understanding, elements of embodiments are described in operation. However, it will be apparent that the respective elements are arranged to perform the functions being described as performed by them. Further, the subject matter that is presently disclosed is not limited to the embodiments only, but also includes every other combination of features described herein or recited in mutually different dependent claims.

Fig. la schematically shows an example of an embodiment of an allocation system 110. Fig. 1c schematically shows an example of an embodiment of a staff experience system 160. Allocation system 110 and staff experience system 160 may be part of a distributed health personnel allocation system 100. The distributed health personnel allocation system 100 is configured for allocating personnel to medical events. The actual allocations are made by allocation system 110, which is configured for making said allocations. The staff experience system 160 is configured for storing past experience of the personnel. Allocation system 110 is configured to access staff experience system 160, and use the information to make allocations. For example, the distributed health personnel allocation system 100 may be used in a hospital or other medical setting for allocating health care personnel to medical events, e.g., situations that desire the intervention of health care personnel, preferably with experience that matches the event.

System 110 and system 160 may be distributed systems, e.g., comprising multiple devices. The devices may be at different geographical locations. This is not necessary though. Allocation system 110 may be an allocation device 110, e.g., implemented in a server. Staff experience system 160 may be a staff experience device 160 e.g., implemented in a server.

Allocation system 110 may comprise a processor system 130, a storage 140, and a communication interface 150. Staff experience system 160 may comprise a processor system 170, a storage 180, and a communication interface 190. Storage 140 and 180 may be, e.g., electronic storage, magnetic storage, etc. The storage may comprise local storage, e.g., a local hard drive or electronic memory. Storage 140 and 180 may comprise non-local storage, e.g., cloud storage. In the latter case, storage 140 and 180 may comprise a storage interface to the non-local storage. Storage may comprise multiple discrete sub-storages together making up storage 140, 180. Storage may comprise a volatile writable part, say a RAM, a non-volatile writable part, e.g., Flash, a non-volatile non-writable part, e.g., ROM. Storage 140 and 180 may be non-transitory storage. For example, storage 140 and 180 may store data in the presence of power such as a volatile memory device, e.g., a Random Access Memory (RAM). For example, storage 140 and 180 may store data in the presence of power as well as outside the presence of power such as a non-volatile memory device, e.g., Flash memory.

Staff experience system 160 may have access to a database 162. Database 162 may comprise records that indicate experience of a personnel, e.g., a past allocation of the personnel to a medical event. This may be an allocation made by allocation system 110, or by a further allocation system.

The systems 110 and 160 may communicate internally, with each other, with other devices, external storage, input devices, output devices, and/or one or more sensors over a computer network. The computer network may be an internet, an intranet, a LAN, a WLAN, etc. The computer network may be the Internet. The systems 110 and 160 comprise a connection interface which is arranged to communicate within distributed health personnel allocation system 100 or outside of distributed health personnel allocation system 100 as needed. For example, the connection interface may comprise a connector, e.g., a wired connector, e.g., an Ethernet connector, an optical connector, etc., or a wireless connector, e.g., an antenna, e.g., a Wi-Fi, 4G or 5G antenna. The communication interface 150 may be used to send or receive digital data, e.g., receiving a request to allocate medical personnel to a medical event, one or more records of personnel indicating past experience, location information of the personnel, availability information of the personnel, etc. The communication interface 190 may be used to send or receive digital data, e.g., experience for storing, a request to retrieve experience, a request to store or retrieve a care protocol, etc. The communication interface 190 may be used to communicate with other staff experience systems. For example, the latter may be used to implement a distributed ledger.

The execution of systems 110 and 160 may be implemented in a processor. The processor may be a system of multiple processor units. The systems 110 and 160 may comprise functional units to implement aspects of embodiments. The functional units may be part of the processor system. For example, functional units shown herein may be wholly or partially implemented in computer instructions that are stored in a storage of the system and executable by the processor system.

The processor system may comprise one or more processor circuits, e.g., microprocessors, CPUs, GPUs, etc. Systems 110 and 160 may comprise multiple processors. A processor circuit may be implemented in a distributed fashion, e.g., as multiple sub-processor circuits. For example, systems 110 and 160 may use cloud computing.

Typically, the allocation system 110 and staff experience system 160 each comprise a microprocessor which executes appropriate software stored at the system; for example, that software may have been downloaded and/or stored in a corresponding memory, e.g., a volatile memory such as RAM or a non-volatile memory such as Flash.

Instead of using software to implement a function, the systems 110 and/or 160 may, in whole or in part, be implemented in programmable logic, e.g., as field-programmable gate array (FPGA). The systems may be implemented, in whole or in part, as a so-called application-specific integrated circuit (ASIC), e.g., an integrated circuit (IC) customized fortheir particular use. For example, the circuits may be implemented in CMOS, e.g., using a hardware description language such as Verilog, VHDU, etc. In particular, allocation system 110 and staff experience system 160 may comprise circuits, e.g., for cryptographic processing, and/or arithmetic processing.

In hybrid embodiments, functional units are implemented partially in hardware, e.g., as coprocessors, e.g., cryptographic coprocessors, and partially in software stored and executed on the system.

Fig. lb schematically shows an example of an embodiment of the allocation system 110. For example, Fig. lb may be implemented as an embodiment of the system of Fig la. Fig. lb shows various examples of functional units that may be implemented in the allocation system. These functional units are optional, and may be used in any combination.

For example, allocation system 110 may comprise a personnel tracker 131. Personnel tracker 131 may be configured to obtain from a plurality of mobile personnel devices location information. The location information of the mobile personnel devices is indicative of the location of corresponding personnel. For example, personnel tracker 131 may store the last known location of a mobile personnel device. For example, personnel tracker 131 may store the time of the last known location of a mobile personnel device. For example, personnel tracker 131 may be configured to compute a list of personnel within an input distance from an input location, e.g., using the last known location, e.g., using the last known location if said location lies in a past time frame, e.g., the past 5 minutes. In an embodiment, the allocation system is configured to keep track of current activities that are being performed.

For example, allocation system 110 may comprise an allocation search 132. Allocation search 132 may be configured to compute a goodness score from the location information, and from a match between the desired personnel experience and the past personnel experience. Allocation search 132 may be configured to allocate a personnel with a high goodness score to the medical event and sending a notification to the mobile personnel device associated with the allocated personnel. For example, allocation search 132 may be configured with an optimization algorithm, e.g., a greedy search, simulated annealing, tabu search, and the like.

Sending a request may be to one or two or a few individual personnel. The request may also be broadcast to a larger group of people. The sending medium may be decided upon the number of people selected from the pool.

For example, allocation system 110 may comprise a compatibility classifier 133. The compatibility classifier 133 may be configured to compute personnel compatibility score between two personnel. For example, the compatibility classifier 133 may receive as input two or more personnel, retrieve information pertaining to the input personnel and determine therefrom a compatibility score, e.g., by applying a function.

For example, allocation system 110 may comprise an allocation prediction 134. The allocation prediction 134 may be configured to predict if future allocations can be fulfilled. For example, allocation system 110 may comprise a medical event prediction 135. Prediction unit 135 may be used by allocation prediction 134. Medical event prediction 135 may be configured to predict future allocation requests made for a medical event.

Fig. 2a schematically shows an example of an embodiment of a distributed health personnel allocation system 200.

Distributed health personnel allocation system 200 is configured for allocating personnel to medical events. For example, personnel may include doctors, nurses, and the like. For example, events may include scheduled events, e.g., surgery, wound care, and the like, and unscheduled events, e.g., emergency events, e.g., first aid, requests for assistance, etc.

Distributed health personnel allocation system 200 comprises an allocation system 210, a staff experience system, and multiple mobile personnel devices; shown in Fig. 2a are mobile personnel devices 221-223. There may be more than 3 mobile personnel devices, e.g., at least 3, at least 10, at least 100, etc. Typically, a mobile personnel device is associated with a particular personnel, e.g., a particular individual. A mobile personnel device could also, or instead, be associated with a particular role, e.g., the head nurse on duty.

Staff experience system 230 is configured for storing past experience of the personnel.

For example, the staff experience system may comprise a data interface for receiving personnel experiences and for receiving requests for retrieving personnel experience. Personnel experience may be received from a number of sources. For example, experience may be received from an optional further experience provider 241. The further experience provider 241 may, e.g., be a previous employer of the personnel, or an alternative employer, or an educational institute. For example, further experience provider 241 and staff experience system 230 may have a connection 242 for sending and receiving experience data. Experience providers may for example be cooperating hospitals and the like, that cooperate to better organize experience information.

For example, a source of experience data may be the allocation system 210. For example, the allocation system may be configured to send allocations of personnel to the staff experience system for storage. For example, in an embodiment, the past experience of a personnel stored in the staff experience system comprises previous allocations of the personnel by the allocation system.

For example, personnel, e.g., a staff member, may have a record, e.g., a profile, in staff experience system 230. For example, staff experience system 230 may store one or more information items form: role, education, certifications, contact information, etc.

For example, staff experience system 230 may be configured with a communication interface. The staff experience system 230 may receive over the interface a digital record indicating a particular personnel had a particular experience. The staff experience system 230 may receive over the interface a digital request for experience of a particular personnel, or for personnel having a particular experience. In response to such communication, system 230 stores or retrieves the data.

Personnel could be identified in staff experience system 230 in various ways. For example, a personnel may have an identifier, e.g., a number, or a unique name, e.g., a UID, or the like. A personnel identification may be free-form text, or structured data.

Shown in Fig. 2a is a connection 214 between the allocation system and the staff experience system 230 for sending and receiving experiences.

For example, the mobile devices may generate data for storage as well. Such data may include information about previous events, locations, times, patient conditions, and patient types for which a particular clinician has requested or searched for help. For example, data generated by the app may comprise historical app usage data. For example, data generated by the app may comprise user profile data. Location information gathered by the mobile devices are typically handled by the allocation system 210, but could be stored in staff experience system 230. For example, such historic location data is suitable for cross-checking experience data. For example, a mobile device may have a connection 225 to the staff experience system, e.g., for sending and/or receiving data. When an event is completed, its occurrence may also be registered in the staff experience system. For example, the allocation of personnel to an event may be recorded, and the later completion of the event by said personnel may also be recorded. Participants, patients, personnel, and the like may use their mobile device for storing information on the event. Such information may be sent to the staff experience system. For example, this information may indicate that the event took place, who was present, who played what role, ratings, feedback, and the like.

Data sent or received from the staff experience system 230 may be free-form data, structured data, or a combination thereof.

The staff experience system need not be unique to any particular allocation system. For example, multiple allocation systems 210 may use the same staff experience system, e.g., retrieve data therefrom and send experience data thereto.

In an embodiment, the staff experience system may have additional safeguards to ensure the validity of the data stored in the staff experience system. For example, in an embodiment, the staff experience system may comprise cross-check data that facilitates cross-checking of the staff experience data with respect to a data source controlled by the organization corresponding to the staff experience data. For example, an experience recorded in the staff experience data may be accompanied by data that corroborates the experience. The allocation system or the staff experience system may use such crosscheck data for cross-checking a staff experience entry with respect to the data source controlled by the organization, thereby establishing the validity of the staff experience entry. For example, a staff experience entry may be cross-checked by cross-checking one or more of a timestamp and a geolocation comprised in the staff experience data. For example, an organization may offer an interface to verify that a submitted time and location for a personnel is indeed correct. For example, a corroborating data may comprise a time and/or location, and, say, a further experience provider 241 may have an interface to verify that indeed a particular personnel was at the indicated time and place, thus corroborating the experience. For example, the allocation system processor may be configured to access the data source controlled by the organization via a gateway system of the organization. For example, the staff experience system and/or the allocation system may be configured to express the result of the cross-checking in an authenticity score.

The plurality of mobile personnel devices are typically associated with a personnel. A mobile personnel device comprises a data interface configured to send location information of the mobile personnel device. For example, the location information may be sent to the allocation system 210, e.g., over a connection 211.

For example, the mobile device may be smartphones that are configured as in an embodiment, by installing an app on them. The app may be installed either on the private phones of the staff or on hospital-owned devices that are given to staff members. This mobile application may connect to the staff experience system for storing data, e.g., over connection 225. For example, in the mobile device, e.g., an app, a staff member may register information pertaining to his/her experience in the staff experience system. For example, the information may comprise one or more of: a profile, a role, a training, a certification. Such information may be stored in the staff experience system in addition to experience collected by the allocation system or the experience source 241. The staff experience system typically holds experience related to multiple employers, training institutes, and the like.

The mobile device may be configured for further functions. For example, once multiple staff members are registered, the mobile device may be configured for contacting another staff member. A particular, useful option is to configure the mobile device for sending a help request. For example, if a medical event emerges or is in progress, or is more complex than foreseen, etc., the personnel involved may send a help request to the allocation system 230.

A help request may be for a secondary tasks. For instance, if nurse 1 has to stay longer at a bedside, e.g., due to patient deterioration, there may be help needed, say, for entering patient data, e.g., EMR data. Entering the patient data may normally have been a task that nurse 1 would do if he/she did not have to stay at the bedside.

For example, staff experience system may store data generated by usage of the mobile device, e.g., of an app installed thereon, staff profile data entered in the mobile device, e.g., during registration, optional location history.

The mobile device may be configured for showing notifications of allocation system 210. For example, an allocation of a personnel to an event may show up as a notification on the phone of the allocated personnel. Sending notifications is not necessary. For example, in an embodiment, the system may be configured to make the information on recommended staff member available to the requesting party, and possibly their location. The requesting party, e.g., a personnel member, can then request the personnel member him or herself. For example, the requesting party may be shown a webpage or the like with information of available and/or recommend staff members. For example, they can be shown on a map.

The mobile device are configured to determine a location. For example, location may be determined by a combination of GPS and Wi-Fi triangulation. GPS is used to determine the specific location, while Wi-Fi can be used as a reliable way to know on which floor the staff member is.

In an embodiment, allocation system 210 is configured to obtain location information from at least part of the plurality of mobile personnel devices. The location information is indicative of the present location of the mobile device. For example, location information may indicate a point or area in which the mobile device is located. The location information may indicate a building, a floor, or precinct. In an embodiment, allocation system 210 is configured to keep track of the location of personnel. For example, allocation system 210 may be configured to maintain a list of last known location(s) for registered personnel. For example, a mobile device may be configured to send a location information update in a schedule, e.g., after a fixed amount of time, e.g., every 5 minutes, or more or less. In an embodiment, the mobile devices are configured for geospacing. For example, some apps may be blocked in some areas. For example, whilst the staff may be allowed to use social media apps outside the hospital and in some non-clinical areas of the hospital, e.g., canteen, changing rooms, etc., within the specified geospaced areas any attempts to use a social media tool may be blocked. An attempt to use a social media tool may result in redirection the user to the installed app according to an embodiment. Furthermore, in the case of a specific event arising, such as an emergency situation, even use of the tool in the canteen/changing room areas may become compulsory.

Allocation system 210 comprises a data interface configured, e.g., to receive an allocation request for a medical event, send allocations, send and retrieve experience data.

For example, in an embodiment, a clinician may need help with an activity in a hospital. The clinician can enter the request for help in his/her mobile device. The allocation request is sent to the allocation system, who may be configured to allocate personnel as requested. For example, a nurse may realize that, due to other emergencies, he/she cannot complete a task in time and may want to ask one of him/her colleagues to do so in his/her place. This may be done by sending an allocation request from the mobile device to the allocation system 210. Yet, another possibility is asking for help from a specific role. For example, the allocation system may use the location of the registered personnel, and contact the nearest 2 people of the requested role; instead of 2 fewer or more may be contacted. In an embodiment, a mobile personnel device is configured for sending the allocation request for the medical event. In an embodiment, allocation requests may also or instead come from an optional request terminal 260. Request terminal 260 may be used to schedule multiple events. For example, request terminal 260 may be used to schedule a list of surgeries and the like with the allocation system. The allocation system can then allocate appropriate personnel for the planned events. Request terminal 260 may be connected to allocation system 210 through a connection 213.

Allocation system 210 is configured to obtain from the allocation request desired personnel experience. The desired personnel experience may be part of the request. In an embodiment, the request comprises an indication of the medical event for which personnel needs to be allocated. The desired personnel experience may be derived therefrom. For example, deriving experience from a request may comprise looking up the desired experience in the request, or may comprise applying a function to the request. An example is to apply a look-up table to the request, that maps elements in the requests, e.g., the event, to a desired experience. In an embodiment, a function is applied to the request configured for mapping the request to a desired experience. The function may be machine learned. For example, a training database may be created of sample requests and desired experiences. For example, the training method may be a decision tree, decision forest, gradient boosted forest, neural network, and so on. The desired experience may be free-form data, but may also be structured. For example, the desired experience may be a pointer or index into a list of standardized experiences.

For example, a desired experience may comprise one or more nominal variables that indicate the desired type of experience, and an ordinal variable that indicates the amount of desired experience. For example, the nominal variable may indicate a standardized type of experience, e.g., wound treatment, while the ordinal variable may indicate an intensity. Either variable may be implemented as a numeric type, e.g., integer. For example, in an embodiment, a desired experience is a list of tuples: [(al, bl), (a2, b2), ..., (an, bn)], wherein the first elements al . ..an indicate nominal variables indicating a type of experience, while the second elements b 1 ... bn indicate the ordinal variables. For example, if r is a request, and F is the mapping function, then allocation system 210 may be configured to compute: F(r)= [(al, bl), (a2, b2), ... , (an, bn)]. Many variants are possible. For example, it is not required that each experience has an intensity value.

Allocation system 210 may be configured to obtain from the staff experience system past personnel experiences. For example, the past experience data may be in the form of free-form data, or may be structured. In an embodiment, allocation system 210 may be configured to create summaries of the experience data. For example, the staff experience system may store records of the form (personnel xl, experience type x2, time from x3 to x4, location x5), for some values of xl-x5. This may be summarized into a record that summarizes, say, for personnel xl his total time with the various experiences. This may be alternatively or additionally summarized into a record that summarizes, say, for experience x2 the personnel having experience therewith. Such summaries are convenient since it avoids having to parse the database multiple times. Interestingly, it is not required that the records of the staff experience system are all of the same form, or even in a structured form. In that case it is especially convenient to make occasional summaries. The summaries may be made by the allocation system and stored either locally at the allocation system or in the staff experience system. The summaries may be made by the staff experience system and stored therein. Providing summaries instead of the raw data is advantageous as it reduces computing time, and reduces the amount of data shared in the system. On the other hand keeping the raw data allows cross-checking to be more efficient.

Allocation system 210 further obtains location information for personnel. Allocation system 210 may obtain yet other sources of information, e.g., availability information, compatibility information and so on.

Allocation system 210 computes a goodness score from, e.g., the location information, and from a match between the desired personnel experience and the past personnel experience. For example, experience with similar events, e.g., treating similar patients, may count positively towards the goodness score.

For example, if a desired experience contains a clause (al, bl), the allocation system may match it against an experience clause associated with a personnel (al, bl’). For example, the match may be considered good if b 1 ’ > b 1 , that is if the past experience of the personnel is larger than the desired experience then the personnel qualifies. Many other matching functions may be used, for example, the goodness score may contain a term -(bl - bl’)^A2, this allows a deviation from the desired experience but considers such a deviation to be a negative, e.g., to count against goodness. Yet another example is to include a term such as min (b 1 ’ - b 1 , 0) . The term b 1 ’ - b 1 is negative if the actual experience is too low, so that min (bl’ - bl, 0) is zero if experience is sufficient and negative otherwise. In this case, personnel with too little experience are not disqualified but this is counted against the goodness score, yet personnel with too high experience are not counted against the goodness score. In an embodiment, the goodness function has a term for location, so that personnel that is near the event have a higher score.

For example, the goodness score may be computed as a function of the data. In an embodiment, the goodness function comprises clauses that indicate goodness of experience, of location, and possibly of other data, e.g., availability, compatibility, and so on. For example, in an embodiment, the goodness function may be:

Goodness_score = F 1 ( experience data ) + F2 (location data) + F3 (compatibility data ) +

For some functions Fl, F2 and F3, etc.

For example, given an event the goodness score may be computed for multiple personnel, and one or more personnel with a high score, e.g., above a threshold, or the highest score(s), may be selected. If no personnel can provide a sufficiently high goodness, e.g., because no one has the right combination of experience, a team of personnel may be assembled that together have a sufficiently high score. The goodness scores may be used as a preselection, after which another selection mechanism selects the actual personnel for allocation. For example, goodness may be computed based on experience and location to create a short list. The actual selection is then made based on say availability or other considerations.

Allocation system 210 may be configured to restrict allocation of personnel to personnel for which associated location information indicates a nearness to the medical event below a location threshold. Restricting planning to personnel near the event reduces the computation resources for computing goodness scores. If the goodness scores are not sufficient when restricting to near personnel, the system may increase the location threshold, e.g., extending the area from which personnel may be allocated, if the goodness scores are below a goodness threshold and/or if an urgency value of the medical event is above an urgency threshold. For example, if a cardiac surgeon experience is needed, it may be needed to increase the threshold significantly, as near personnel even in a wide circle may not have the required experience.

The weight given to various clauses in the goodness function may vary depending on circumstance. For example, the weight given to location and/or availability may be lowered if need is high. Indeed, in the case of an emergency, such as a natural disaster or pandemic, the allocation system may even access staff who are not on site in order to assemble emergency teams. For example, if the staff is dealing with the emergency in an off-site location, the use of the localization data can advantageously be used to assemble teams within the limited time available. For example, in such a case the allocation system may be configured, to give a high weight to near personnel, e.g., who can arrive within 5 minutes, and a lower weight to experience. After allocating a personnel, e.g., with a high goodness score to the medical event, the system may send a notification to the mobile personnel device associated with the allocated personnel. Instead of sending a notification, the information may be made available in another way, e.g., only to the requesting party, and/or only to managing personnel, etc.

The location information may be used as a separate factor in the allocation, ensuring that only near personnel is considered in allocation decisions. This has the advantage that the location threshold can be dynamically increased or decreased to increase or decrease the number of personnel that are considered near, e.g., as the situation demands. For example, an interface configured in the system may allow the setting or changing of the location threshold. For example, the location threshold may depend on the type of event, its urgency, or the number of near personnel found so far. Another approach is to include location as a factor in the goodness score, and only consider location there. In this approach, if the number of personnel found for potential allocation is too small, the goodness threshold may be reduced, so that further away personnel is considered as well as less-experienced but near personnel. The weight given to location may be changed in an iteration as well. For example, initially location may be given a high weight in the goodness score, but if this does not produce the desired results, e.g., enough people, the weight of location can be decreased.

In an embodiment, more personnel is allocated than is needed. Once one of the contacted members responds positively to the request, the other personnel may be informed that there is no longer any help required. Should none of them respond, the allocation system may extend the range of possible contacts. For example, in an embodiment, the allocation system may be configured for allocating and notifying more personnel than requested, receive an availability message of allocated personnel, and deallocate personnel when sufficient personnel is available. Alternatively, personnel may be tried sequentially. For example, a first personnel is selected and allocated. After received a rejection of the first personnel, a second personnel is selected and allocated.

In an embodiment, to avoid alarm fatigue, a notification timer may track the last time a staff member interacted with the allocation system through the mobile device. An interaction in this case is defined as having accepted or declined a request, and/or having initiated a request themselves. The timer threshold through which the system will decide whether or not to consider the staff member for a notification will at first be static. However, after more data is gathered by the system from the mobile devices, more accurate assumptions can be made regarding the current context of the staff member. For instance, if we are relatively sure the staff member is currently busy with a task that takes around 5 minutes, the threshold will be set to 5 minutes. If, however, the task usually lasts 65 minutes, the threshold may be adjusted accordingly.

An advantage of the distributed system is that data concerning allocations and experience accumulates. For example, in an embodiment, the allocation system may be configured to send the allocation of the personnel to the staff experience system for storage. For example, if an event is completed, the allocation system of the personnel involved may be configured to send the completion to the staff experience system for storage.

The information provided by the staff experience system enables formation of teams that have the right sets of skills to work together and best help the patient. Using a patient health information, e.g., electronic medical record (EMR) and/or electronic health record (EHR) may be used to further improve the system. Using standardized treatment procedures, e.g., care protocols, the right set of skills for treating the patient may be determined within the system. This set of skills may be compared with the available skill set of the current personnel. Skill gaps identified during this step are then stored for this interaction. When the user of the mobile device requests for help from their colleagues, the mobile device may now not only use physical proximity and availability, but also required skill set for contacting colleagues.

The allocation system may be configured to take compatibilities between personnel into account. Due to different personalities and/or skillset combinations, certain staff members may not work very well together. Ideally, the allocation system would allocate colleagues that create the optimal team. There are various ways to achieve this given the data that is available. For example, patient health data may be analyzed to determine patient outcomes for similar patients but different teams. For example, by checking whether complications develop for a patient and comparing such a case to future patients of a similar condition. In this way, team combinations can be identified that are better avoided.

Another approach is through a microphone installed in the mobile device. Analyzing the sentiment and noise level of speech occurring in combination with certain staff members gives a good enough estimate for the compatibility between staff members. A higher than average noise level, perhaps from yelling or a raised voice level, and/or below average sentiment score of the words used in the conversation may suggest a poor chemistry between this combination of staff members. Such information may be stored, either locally in the allocation system, or in the staff experience system.

In an embodiment, a compatibility function is configured to compute a compatibility score for two or more personnel. If an allocation were to result in combining personnel with a low compatibility score, e.g., below a predetermined threshold, the goodness score may be decreased, to indicate that this allocation is less preferable to other allocations.

For example, in an embodiment, the goodness score may be derived further from a personnel compatibility score, the goodness score being lowered for allocating two or more personnel with a low personnel compatibility score. For example, the personnel compatibility score may be computed at least in part from an interaction classifier applied to personnel interactions obtained through the mobile personnel devices. The interaction content classifier may be executed on the mobile device itself, to avoid having to transfer audio recordings over a network.

The inventors found that the data collected by the system, optionally combined with other datasets, may be used for prediction. When staff members require help, this can be regarded as a case of misallocation of resources. It is desirable to predict such situations in order to allocate resources more efficiently. For example, in an embodiment, the allocation system is configured for predicting if a future allocation can be fulfilled. A prediction model may use historic allocation data, but may also use other data sources. For example, the prediction may use as input a patient record system configured for storing electronic patient information and/or personnel allocations in the staff experience system.

In an embodiment, the allocation system is configured to predict a future medical event — or more precisely a future allocation request for a medical event — and verifying that the future allocation can be fulfilled.

Also, from patient information, e.g., EMR, information about contribution of individual people, and their value may be taken into account. For example, after involvement of person 1, if an event was performed more successfully, or more efficiently, e.g., in less time, then this may be used as additional information, increasing the value for person 1 for this particular event.

For example, a future medical event may be predicted by training a machine learning model. For example, the input to the model may be obtained from the staff experience data, and possibly also patient health information. If a future medical event is predicted, it can then be verified if the event could be allocated for, or could likely be allocated for. Predicting future allocation success by an intermediate prediction of future medical events is an option, and not necessary.

A prediction model that uses patient health information, e.g., EMR data, to augment the model with patient-related data is more powerful. For example, it could be that patients over a certain weight always require help from an orderly for a specific procedure. In such a case, a system may verify in advance that such an allocation can be fulfilled. The allocation system may even suggest an additional allocation even if no such allocation is yet requested. For example, allocation system 210 may have access to a patient health record system 250 through a connection 212. For example, patient health record system 250 may be local to a particular hospital, while staff experience system 260 may be shared among multiple sites, e.g., multiple hospitals, or multiple allocation systems 210 or indeed be held completely separate of any sites and only provide access to sites when permitted.

Patients in a hospital are often attached to various sensors that collect data on their condition. Such data can be used as well to predict likely staff interventions. By combining this with the data generated by the mobile device, the model can also predict the likely number of staff members required to perform the task. This could be based on previous occurrences of the task where staff members have requested help via the tool, turning this into a classification problem.

For example, in an embodiment sensor data is used as input by a prediction function to predict patient conditions, such as hemodynamic instability, shock, etc. Such predictive information can be used together with the historical mobile device usage data, to estimate staff support characteristics (e.g., number, specializations, experience, timing) required, e.g., linked to the predicted patient condition or predicted medical event.

The estimation of potential help support can be done based on the previous allocation data, staff experience data, and patient health data. A machine learning algorithm trained on staff experience data, and patient health data may predict time of support, and type of support as output can be employed. By using such a machine learning algorithm, need for supporting/helping clinicians can be estimated at regular pre-set intervals. Based on these estimations, the allocation system can automatically preform search for matching clinicians, and store the results. Later, when the actual request from a user (e.g., clinician_l) comes, the latest pre-stored support information can be accessed and used for the final calculation. Such an approach can help in expediting finding the right support.

In addition to using EMR and patient monitoring data (sensors), information about the applied protocols can be used. Protocol information may or may not be stored in the EMRs. In case, EMRs do not include this information, another hospital database that contain protocol details, or tools such as protocol guidance solutions can be accessed. The protocols comprise standard operating procedures, possibly in structured form, which describe in clear details what needs to be done, when, and in which order, as well as the expected effects on the patient. Typically, protocols are defined by clinicians.

This means that, if the current applied protocol and protocol steps is known, the future protocols steps are well-defined. Hence, the information of these protocol steps can be used to calculate potential activities for which support may be needed in advance, as well as clinicians that may help. Later, when the user makes the real request, the pre-calculated information can be updated, and final result can be shown to the user. By anticipating and pre-calculating parts of the support-to-be requested, and support-to-be received, the time of receiving the support can be minimized. Machine learning may be used to estimate the need for help, and/or which help, needed for a given protocol step.

In an embodiment, a machine learning model predicts allocation success for a coming time period. For example, the machine learning model may predict a percentage of allocation requests that can be fulfilled in a next time frame, e.g., tomorrow, next week. An intervention may be based on such data, e.g., increase the availability of personnel. It is possible, but not required to predict medical events first, and predict allocation success based thereon. For example, the allocation system may predict that a certain number of heart attacks are likely, and use that as an input to compute allocation needs, and likely allocation success. Interestingly, the actual prediction of medical events is not needed as an intermediate step. For example, the machine learning model may directly learn that a particular set of experiences is likely to result in allocation problems, without predicting with what the event the allocation problem may occur.

In an embodiment, allocation request prediction uses a short term horizon. For example, an allocation prediction model may be configured to predict short term allocation request.

For example, the allocation prediction may predict future allocation success in general terms, e.g., as a percentage, but the allocation prediction may predict individual future allocation requests as well. The predictions of a future allocation request may be used to verify if the allocation could be fulfilled. This could be used to compute allocation success, but may also be used for other purposes. For example, having a predicted future allocation request, the allocation system may start doing the goodness score calculations, so that — should the request actually materialize — the allocation can be made quicker. The allocation may even be made in advance, e.g., if a likelihood of the allocation being needed is higher than a predetermined threshold.

The prediction model, especially a short term prediction model, works well on the historic allocation data. For example, in an embodiment, the allocation system may be configured to predict if a first allocation request for a medical event will be followed by a second allocation request. For example, the system may find that particular events are often underestimated, and as a result human request are often too conservative.

Predicting if a first allocation request for a medical event will be followed by a second allocation request may well be done on historic allocation data. A further helpful data source in this regard is the appropriate care protocol. For example, in an embodiment, a sequence of treatment procedures may be organized in defined protocols, the electronic patient information indicating a treatment procedure and/or the corresponding protocol, predicting a future medical event being derived from said treatment procedure and/or the corresponding protocol.

This has the effect that if a first allocation requests for a first medical event is made, but the prediction model foresees with high likelihood that the insufficient resources or experiences are requested, already an allocation for further personnel can be made.

Fig. 2b schematically shows an example of an embodiment of a distributed health personnel allocation system 201. Fig. 2c schematically shows an example of an embodiment of a distributed ledger. Embodiments of system 201 may be the same as embodiments according to system 200, except that system 201 uses a distributed ledger to store staff experience information. For example, shown in Fig. 2b are multiple staff experience maintainers; shown are staff experience maintainers 232 and 234. A staff experience maintainer maintains a distributed ledger. The distributed ledger comprises records that contain information for storage. A record, except a so-called genesis block, points to one or more earlier records — typically a single block, forming a graph structure, typically a linear graph structure. To create a new block some qualification must often be met, e.g., a proof of work, proof of stake, or the like. A staff experience maintainer has a local copy of the database, but keeps this synchronized with other maintainers. There is a rule to decide on conflicts, typically, the larger ledger, or longer chain, is authentic. A staff experience maintainer may comprise a so-called miner, especially if the distributed ledger is of proof-of-work type. However, in an embodiment, the staff experience maintainers comprise additional functionality, e.g., responding to data queries. In an embodiment, the allocation system 210 has a local copy of the database, which is periodically updated to the database of one of the maintainers.

A staff experience maintainer may be combined with an allocation system. The staff experience maintainer cooperates with other staff experience maintainers to keep the database up to date.

Fig. 2c shows three records, or blocks: block 271, block 272 and 273. The blocks contain information, e.g., information 271.1 - 273.3. Part of the information is related to the application, e.gs, contain personnel experience. Part of the information is related to the distributed ledger. For example, information 271.3 points to block 272. Information 272.3 points to a yet prior block, and so on.

Using a distributed ledger has various advantages. There is no need for a central party that controls which copy of the database is the authentic one. For example, a hospital may have a local allocation system but does not need to have its own maintainer, although it could have. Indeed every staff experience system could be maintained by different maintainers, none of which need to be associated with any hospital or site. Note that a so-called private distributed ledger may be used, without public access. Suitable distributed ledgers include blockchain, ether, directed acyclic graph based distributed ledgers, e.g., Tangle.

For example, Fig. 2b shows some of the possible parties that may be involved in a distributed health personnel allocation system. For example, an allocation system 210 may connect to a maintainer 232, a mobile device may connect to a maintainer 234 and so on. When a maintainer receives a request for information it may be serviced from its private copy of the database. For example, Fig. 2b shows a local copy 231 for maintainer 232 and a local copy 233 for maintainer 234. There may be more than two maintainers. When a maintainer receives a request for storing information the new information may be shared over a computer network 235 with the other maintainers. One of the maintainers generates a new block including the new information and sends it to the other maintainers. With respect to the latest blocks there may be some discrepancies between the maintainers, but as the blocks get older, these discrepancies disappear. For the type of data involved, e.g., experience data, this is not a problem.

In an embodiment the distributed health system is configured with cryptography to protect against undesired access. For example, data in the staff experience system may be encrypted. Data may be decrypted for the allocation system, after the allocation system authenticates to the staff experience system. For example, data may be made available to the allocation system but only in summarized form.

Fig. 3a schematically shows an example of an embodiment of an allocation data structure. Desired experience and/or personnel experience may be stored in a list format as indicated above. Fig. 3a shows a table format. Shown in Fig 3a are n experience types (EXP1 to EXPn) a location LC1 and an availability (AVL). This information is recorded for multiple personnel Pl, P2, etc. When a list of desired experiences is needed, a column may be found that matches the desired experience, e.g., is larger than the indicated experience. The location and/or availability fields may be used to filter personnel. Unavailable or not-near personnel may not be considered. In an embodiment, a combination of columns is found to fulfill a request. If an allocation does not completely satisfy a request, for example, if experience is lower than requested, the allocation may still be made, but a warning may be issued. For example, if the request asks, inter alia, for 4 months or more of experience in emergency room work, but the highest goodness is obtained for someone with 3 months of experience in emergency room work, the request may be fulfilled, but a warning may be issued. Fig. 3b schematically shows yet another example of an embodiment of an allocation data structure. In this case personnel information is recorded in nodes. Shown are nodes Pl to P5 which may store experience information for associated personnel. Edges in the graph indicate compatibility between personnel. For example, a clique finding algorithm may be used to find a set of personnel satisfying experience bounds while being interconnected, indicating a sufficiently high compatibility.

Below an example scenario for usage of the system is given. Nurse Alicia has the app of the system installed on her phone. The app continuously searches for patients linked to its registered user in the EMR. It finds a patient diagnosed with COVID-19 that is assigned to Nurse Alicia. This patient will require intubation. Via the connection to the staff experience system, the app knows that Alicia has little experience in this. When Alicia engages the app to request for help, the app begins searching in a 5 meter radius for available staff members that have experience in intubating patients of infectious diseases. No one matching these attributes is found within the radius, so the radius is expanded to 10 meters. Nurse Carla is now found to be available, and her app shows an alert that she is needed at Nurse Alicia’s location for help with intubation. During the procedure, the app analyzes the noise level in the room, as well as the average sentiment of the conversation and stores it in the history of interaction between these two staff members. After the procedure is completed, both Alicia and Carla’s experiences are updated in the staff experience system, with an extra occurrence of intubation to reflect their new experience.

In an embodiment of the distributed health personnel allocation system, a mobile personnel device being configured for sending an allocation request for allocation of a personnel with a medical experience to a medical event, the allocation system processor being configured to compute a goodness score for a personnel from the location information, and from a match between the requested experience and the past personnel experience of the personnel. This embodiment is preferably combined in a staff experience system that is configured to store past personnel experiences in a distributed ledger, a maintainer of the distributed ledger being included in the distributed health personnel allocation system, the maintainer being configured to maintain the ledger with maintainers of other distributed health personnel allocation systems.

Fig. 4 schematically shows an example of an embodiment of an allocation method 400 configured for allocating personnel to a health event. Method 400 may be computer implemented. Method 400 comprises: receiving (410) an allocation request for a medical event, and obtaining (420) from at least part of a plurality of mobile personnel devices location information, the plurality of mobile personnel devices being associated with personnel, a mobile personnel device comprising a data interface configured to send location information of the mobile personnel device, obtaining (430) from the allocation request desired personnel experience, obtaining (440) from a staff experience system past personnel experiences, the staff experience system configured for storing past experience of the personnel, the staff experience system comprises a data interface for receiving personnel experiences, computing (450) a goodness score from the location information, and from a match between the desired personnel experience and the past personnel experience, allocating (460) a personnel with a high goodness score to the medical event and sending a notification to the mobile personnel device associated with the allocated personnel.

Many different ways of executing the method are possible, as will be apparent to a person skilled in the art. For example, the order of the steps can be performed in the shown order, but the order of the steps can be varied or some steps may be executed in parallel. Moreover, in between steps other method steps may be inserted. The inserted steps may represent refinements of the method such as described herein, or may be unrelated to the method. For example, some steps may be executed, at least partially, in parallel. Moreover, a given step may not have finished completely before a next step is started.

Embodiments of the method may be executed using software, which comprises instructions for causing a processor system to perform method 400. Software may only include those steps taken by a particular sub-entity of the system. The software may be stored in a suitable storage medium, such as a hard disk, a floppy, a memory, an optical disc, etc. The software may be sent as a signal along a wire, or wireless, or using a data network, e.g., the Internet. The software may be made available for download and/or for remote usage on a server. Embodiments of the method may be executed using a bitstream arranged to configure programmable logic, e.g., a field-programmable gate array (FPGA), to perform the method.

It will be appreciated that the presently disclosed subject matter also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the presently disclosed subject matter into practice. The program may be in the form of source code, object code, a code intermediate source, and object code such as partially compiled form, or in any other form suitable for use in the implementation of an embodiment of the method. An embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the processing steps of at least one of the methods set forth. These instructions may be subdivided into subroutines and/or be stored in one or more files that may be linked statically or dynamically. Another embodiment relating to a computer program product comprises computer executable instructions corresponding to each of the devices, units and/or parts of at least one of the systems and/or products set forth.

Fig. 5 schematically shows a further non-limiting example of an embodiment of a distributed health personnel allocation system 500. Fig. 5 shows an allocation system 510. Allocation system 510 comprises staff selection logic 520. Optionally allocation system 510 comprises a natural language processing (NLP) engine 521 and/or an analytics engine 522. The NLP engine 521 may be configured to parse free-form data. Analytics engine 522 may be configured to mine data, generate report, train machine learning models and/or make predictions.

Allocation system 510 may be connected to a wireless computer network 530, e.g., a wifi system. Wireless network 530 may be used to communicate with a plurality of mobile device 540. Wireless network 530 may also be used to obtain location information from mobile device 540.

Allocation system 510 may be connected to a staff experience system 550. Staff experience system 550 may be configured to store experiences of personnel. Staff experience system 550 may obtain its information from multiple sources, e.g., multiple hospitals, personnel inputs, and the like.

Allocation system 510 may be connected to a patient health information system, e.g., electronic medical records, e.g., an EMR.

Allocation system 510 may receive user inputs from mobile device 540. Allocation system 510 may receive location information from mobile device 540. Allocation system 510 may receive data generated by the mobile device 570. The latter may include information indicating starting and/or completion of events, compatibility information, and the like.

Fig. 6a shows a computer readable medium 1000 having a writable part 1010, and a computer readable medium 1001 also having a writable part. Computer readable medium 1000 is shown in the form of an optically readable medium. Computer readable medium 1001 is shown in the form of an electronic memory, in this case a memory card. Computer readable medium 1000 and 1001 may store data 1020 wherein the data may indicate instructions, which when executed by a processor system, cause a processor system to perform an allocation method, according to an embodiment. The computer program 1020 may be embodied on the computer readable medium 1000 as physical marks or by magnetization of the computer readable medium 1000. However, any other suitable embodiment is conceivable as well. Furthermore, it will be appreciated that, although the computer readable medium 1000 is shown here as an optical disc, the computer readable medium 1000 may be any suitable computer readable medium, such as a hard disk, solid state memory, flash memory, etc., and may be non-recordable or recordable. The computer program 1020 comprises instructions for causing a processor system to perform said allocation method.

Fig. 6b shows in a schematic representation of a processor system 1140 according to an embodiment of an allocation system and/or allocation method. The processor system comprises one or more integrated circuits 1110. The architecture of the one or more integrated circuits 1110 is schematically shown in Fig. 6b. Circuit 1110 comprises a processing unit 1120, e.g., a CPU, for running computer program components to execute a method according to an embodiment and/or implement its modules or units. Circuit 1110 comprises a memory 1122 for storing programming code, data, etc. Part of memory 1122 may be read-only. Circuit 1110 may comprise a communication element 1126, e.g., an antenna, connectors or both, and the like. Circuit 1110 may comprise a dedicated integrated circuit 1124 for performing part or all of the processing defined in the method. Processor 1120, memory 1122, dedicated IC 1124 and communication element 1126 may be connected to each other via an interconnect 1130, say a bus. The processor system 1110 may be arranged for contact and/or contact-less communication, using an antenna and/or connectors, respectively.

For example, in an embodiment, processor system 1140, e.g., an allocation device or system may comprise a processor circuit and a memory circuit, the processor being arranged to execute software stored in the memory circuit. For example, the processor circuit may be an Intel Core i7 processor, ARM Cortex-R8, etc. In an embodiment, the processor circuit may be ARM Cortex MO. The memory circuit may be an ROM circuit, or a non-volatile memory, e.g., a flash memory. The memory circuit may be a volatile memory, e.g., an SRAM memory. In the latter case, the device may comprise a non-volatile software interface, e.g., a hard drive, a network interface, etc., arranged for providing the software.

While device 1110 is shown as including one of each described component, the various components may be duplicated in various embodiments. For example, the processor 1120 may include multiple microprocessors that are configured to independently execute the methods described herein or are configured to perform steps or subroutines of the methods described herein such that the multiple processors cooperate to achieve the functionality described herein. Further, where the device 1110 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, the processor 1120 may include a first processor in a first server and a second processor in a second server.

It should be noted that the above-mentioned embodiments illustrate rather than limit the presently disclosed subject matter, and that those skilled in the art will be able to design many alternative embodiments. Thresholds in embodiments may be set by the skilled person as the application demands.

In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. Use of the verb ‘comprise’ and its conjugations does not exclude the presence of elements or steps other than those stated in a claim. The article ‘a’ or ‘an’ preceding an element does not exclude the presence of a plurality of such elements. Expressions such as “at least one of’ when preceding a list of elements represent a selection of all or of any subset of elements from the list. For example, the expression, “at least one of A, B, and C” should be understood as including only A, only B, only C, both A and B, both A and C, both B and C, or all of A, B, and C. The presently disclosed subject matter may be implemented by hardware comprising several distinct elements, and by a suitably programmed computer. In the device claim enumerating several parts, several of these parts may be embodied by one and the same item of hardware. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

In the claims references in parentheses refer to reference signs in drawings of exemplifying embodiments or to formulas of embodiments, thus increasing the intelligibility of the claim. These references shall not be construed as limiting the claim.

Claims

CLAIMS:

Claim 1. A distributed health personnel allocation system for allocating personnel to medical events, the system comprising: a staff experience system configured for storing past experience of the personnel, the staff experience system comprises a data interface for receiving personnel experiences, a plurality of mobile personnel devices associated with the personnel, a mobile personnel device comprising a data interface configured to send location information of the mobile personnel device, an allocation system, the allocation system comprising a data interface configured to receive an allocation request for a medical event, and a processor configured for obtaining from at least part of the plurality of mobile personnel devices location information, obtaining from the allocation request desired personnel experience, obtaining from the staff experience system past personnel experiences, computing a goodness score from the location information, and from a match between the desired personnel experience and the past personnel experience, allocating a personnel with a high goodness score to the medical event.

Claim 2. A distributed health personnel allocation system as in Claim 1, comprising sending a notification to the mobile personnel device associated with the allocated personnel.

Claim 3. A distributed health personnel allocation system as in any one of the preceding claims, wherein the past personnel experiences are stored in a distributed ledger.

Claim 4. A distributed system as in any one of the preceding claims, wherein computing the goodness score is derived further from a personnel compatibility score, the goodness score being lowered for allocating two or more personnel with a low personnel compatibility score.

Claim 5. A distributed health personnel allocation system as in any one of the preceding claims, wherein the allocation system processor is configured for: restricting allocation of personnel to personnel for which associated location information indicates a nearness to the medical event below a location threshold.

Claim 6. A distributed health personnel allocation system as in Claim 5, wherein the allocation system is configured for increasing the location threshold if the goodness scores are below a goodness threshold and/or if an urgency value of the medical event is above an urgency threshold.

Claim 7. A distributed health personnel allocation system as in any one of the preceding claims, wherein a mobile personnel device is configured for sending the allocation request for the medical event.

Claim 8. A distributed health personnel allocation system as in any one of the preceding claims, wherein the allocation system processor is configured for predicting if a future allocation can be fulfilled, the prediction using as input a patient record system configured for storing electronic patient information and/or personnel allocations in the staff experience system.

Claim 9. A distributed health personnel allocation system as in any one of the preceding claims, wherein the allocation system processor is configured to predict if a first allocation request for a medical event will be followed by a second allocation request, and if so, to verify if the predicted second allocation request can be fulfilled.

Claim 10. A distributed health personnel allocation system as in any one of the preceding claims, wherein past experience of a personnel stored in the staff experience system comprises previous allocations of the personnel by the allocation system, the allocation system processor being configured to send the allocation of the personnel to the staff experience system for storage.

Claim 11. A distributed health personnel allocation system as in any one of the preceding claims, wherein the allocation system processor is configured for: allocating and notifying more personnel than requested receive an availability message of allocated personnel deallocate personnel when sufficient personnel is available.

Claim 12. A distributed health personnel allocation system as in any one of the preceding claims, wherein the staff experience system comprises cross-check data that facilitates cross-checking of the staff experience data with respect to a data source controlled by the organization corresponding to the staff experience data, the allocation system processor being configured for using the cross-check data of the staff experience entry, cross-checking the staff experience entry with respect to the data source controlled by the organization.

Claim 13. A distributed health personnel allocation system as in Claim 12, wherein the allocation system processor is configured to cross-check the staff experience entry by cross-checking one or more of a timestamp and a geolocation comprised in the staff experience data.

Claim 14. Allocation system configured for allocating personnel to a health event, comprising: a data interface configured to receive an allocation request for a medical event, and a processor configured for obtaining from at least part of a plurality of mobile personnel devices location information, the plurality of mobile personnel devices being associated with personnel, a mobile personnel device comprising a data interface configured to send location information of the mobile personnel device, obtaining from the allocation request desired personnel experience, obtaining from a staff experience system past personnel experiences, the staff experience system configured for storing past experience of the personnel, the staff experience system comprises a data interface for receiving personnel experiences, computing a goodness score from the location information, and from a match between the desired personnel experience and the past personnel experience, allocating a personnel with a high goodness score to the medical event.

Claim 15. An allocation method (400) configured for allocating personnel to a health event, comprising: receiving (410) an allocation request for a medical event, and obtaining (420) from at least part of a plurality of mobile personnel devices location information, the plurality of mobile personnel devices being associated with personnel, a mobile personnel device comprising a data interface configured to send location information of the mobile personnel device, obtaining (430) from the allocation request desired personnel experience, obtaining (440) from a staff experience system past personnel experiences, the staff experience system configured for storing past experience of the personnel, the staff experience system comprises a data interface for receiving personnel experiences, computing (450) a goodness score from the location information, and from a match between the desired personnel experience and the past personnel experience, allocating (460) a personnel with a high goodness score to the medical event.

Claim 16. A transitory or non-transitory computer readable medium (1000) comprising data (1020) representing instructions, which when executed by a processor system, cause the processor system to perform the method according to claim 15.