1 Introduction

Bed allocation is a challenge faced by hospitals because hospital beds are scarce, and when poorly managed, it can lead to long queues or chaos in emergency rooms [9]. This is even more critical considering that developing countries face growing financial constraints making planning and efficient allocation of hospital beds increasingly difficult [11, 20]. Also, the area responsible for bed allocation needs to be concerned with several restrictions during bed allocation, such as the type of medical speciality, whether the patient is surgical or clinical, gender, and age of the patient [17]. This makes bed management an essential part of the planning and controlling of the operational capacity, and an activity that demands the efficient use of available resources [18].

Effective management of hospital beds has been the focus of much research such as the IMBEDS model that uses artificial neural networks and multi-attribute value theory for decision making [9]; statistical and data mining approaches [19]; an optimisation model based on evolutionary algorithms is used for bed allocation in [13]; and also literature reviews have been carried out [2, 11]. Although all that work seeks to improve bed management, they do not provide easy interaction nor decision support so that the professional in charge retains full control over allocations.

Keeping professionals in charge is important, given that this is a domain of sensitive decision-making, hence there is much resistance to replacing human operators with automated systems. In domains like healthcare, a mixed-initiative system, which supports human-computer interaction, becomes not just useful [10] but essential. In this domain, wrong decisions can lead to the loss of lives. That is why it is important that intelligent systems can support the decisions being made, but a human must make the final decisions.

We have developed an intelligent agent to validate bed allocation plans and to communicate with hospital professionals using natural language. Although humans still make the final decisions, an intelligent agent checks if all allocation rules are being complied with and warn the user if they are not. To make this possible, we use plan validation techniques and a chatbot that provides the agent with the ability to communicate with the human operator through natural language. Our approach performs the validation of the bed allocation plan using a planning domain built based on the allocation rules used in each of the local hospitals that cooperated with our work. To use different rules for other hospitals, it is only necessary to adapt the planning domain and the way the planning problem is generated. We developed our own PDDL plan validator in Java, so that it interacts better with the chatbot developed using the Jason platform [4]. We also created an automated generator of linear programming models for generating optimal bed allocations, which we can be used to provide suggestions of better alternative allocations when requested by the human operators, for example when the chatbot detected errors in the allocations they created themselves. We can generate optimal allocations much quicker with a solver such as GLPK than with a PDDL planner.

We have evaluated our approach with professionals responsible for bed allocation in two local hospitals. Also, the approach was evaluated by a doctor who provides consultancy to a local hospital. With their feedback, we were able to assess the efficacy and acceptance of our approach by those professionals; they considered our approach extremely useful and usable in the daily routine of the hospital. The version of the chatbot described in this paper in fact addresses all the suggestions made by those professionals to increase the usefulness of the chatbot for their work.

The remainder of this paper is structured as follows. Section 2 shows the bed allocation scenario and our approach. Section 3 presents the results obtained in the evaluation of our approach. Section 4 explains the improvements made. Section 6 provides some conclusions.

2 Materials and Methods

2.1 Eliciting Bed Allocation Rules

We interviewed a person responsible for bed allocation at Hospital Conceição in Porto Alegre - RS, Brazil. This professional (referred to as BA1) has more than seven years experience in this work. Our objective was to understand the real scenario of hospital bed allocation.

Fig. 1.
figure 1

Bed allocation rules.

Full size image

Hospital Conceição is the largest unit of the Conceição Hospital Group (GHC). It offers all the specialities of a general hospital in its outpatient clinic, as well as an emergency room and inpatients. It maintains a medical emergency service with doors open 24 h a day and has 784 beds [8].

For contextualisation, in Brazil there are three types of health systems: private, where the patient pays; private health insurance, where the patient pays monthly and this plan covers the costs of the hospital; and SUS is the national healthcare system that is funded by the federal government. 80% of the population uses SUS [17]. The Hospital Conceição only receives SUS patients.

BA1 is part of a department of the hospital called NIR (Portuguese acronym for Internal Regulation Centre). NIR is an administrative unit that monitors the patient from arrival at the hospital, during the hospitalisation process, and internal and external movement until discharge from the hospital. NIR has a manual created in cooperation with the Health Ministry to guide SUS managers and better conduct the process of creation and running of NIR units [12].

The NIR has full control over hospital beds. The function of the operational nurse (BA1) is the real-time management of free beds. BA1 is responsible for authorising new admissions from the requested reservations, the exchanges, and the blocking required according to the demand and availability.

BA1 currently uses a locally developed system that has a feature for bed management. This system only shows which patients need hospitalisation and which beds are currently available. The rules for bed allocation are in a document outside the system, so the person responsible for allocation needs to look at the document, or in case of BA1, memorised all those rules. Bed allocation errors often occur because some rule is overlooked. Some errors can cause delays in a patient’s accommodation since it is necessary to wait for a new allocation, besides all the unnecessary patient movement.

Based on the information obtained from BA1 and the NIR manual [12], we created a diagram with the main bed allocation rules (see Fig. 1). The diagram shows a large number of rules that need to be considered for an adequate allocation, prioritising good care, privacy, and the psychological state of patients. When there is overcrowding in the hospital, some rules may be ignored. In contrast, others can never be relaxed – for example, placing a patient who needs isolation in a non-isolation area.

Fig. 2.
figure 2

Bed allocation approach.

Full size image

2.2 Developing an Approach to Bed Allocation

We propose an approach for helping the professionals ensure that all bed allocation rules have been followed (see Fig. 2). In our approach, healthcare professionals inform which patient and which bed they want to allocate the patient for the system to validate the allocation in accordance to a particular set of rules. This is done as follows: our system, based on the allocation information (bed and patient), automatically generates a PDDL (Planning Domain Definition Language) [1] problem file and a PDDL plan file; the particular hospital rules in question are represented as a PDDL domain specification. The part of the system with patient and hospital information we call “web simulator”,Footnote 1 because it is implemented as a web system to simulate a hospital information system. Our web simulator was developed to facilitate interaction with the user when testing our approach. Figure 3 shows the simulator bed-allocation screen.

Fig. 3.
figure 3

Web simulator – bed allocation screen.

Full size image

Our approach also has an intelligent BDI agent constructed with Jason [4], which has access to the PDDL problem file and a PDDL plan file and uses them to validate the allocation, checking if any rules are being broken.Footnote 2

To do this validation, the Jason agent originally used the VAL validator [7, 10], which outputs a LaTeX report saved to a folder that will be analysed by the agent; we later mention how this has been reworked to improve performance. After the report is saved, the agent reads and processes that file. VAL is a plan validator that in our case checks if any bed allocation rule has been broken in the user allocation. VAL receives three files as input: 1) the plan file containing the information of the allocation made; 2) the problem file contains the current world state and the goals that should be achieved; 3) the domain fileFootnote 3 that describes the rules that must be followed to perform the allocation.

Fig. 4.
figure 4

Web simulator – bed allocation screen with chatbot.

Full size image

This domain file has predicates that describe the characteristics of beds and patients. The actions contained in the domain file are responsible for determining the behaviour according to the real hospital rules.

After analysing the validation report, our agent creates the response to the user, saying whether or not the plan is valid, and if it is not valid, it also tells the user which rule was being broken. One of the limitation of VAL, which led to the development we explain later, is that it stops the validation as soon as a broken rule is found, so if there are more broken rules, our agent would still report only the first one found. This response is sent to the user through a chatbot using the DialogFlow platform,Footnote 4 which in addition to responding, asks whether the user wants to confirm the allocation (see Fig. 4). If the answer is positive, the chatbot itself triggers the routine on the system responsible for completing the allocation. If the answer is no, the chatbot just cancels the allocation, leaving the system’s validation history saved.

When the user requests the chatbot to “check if my allocation is valid”, an intention is triggered on DialogFlow; we call it “Get Validation Result”. This intention calls through the webhook a function in Cloud Functions that searches in the database the last validation carried out by our Jason intelligent agent and returns to Dialogflow the answer elaborated by it. In addition to answering, the chatbot also asks if the user wants to “confirm the allocation”. For the chatbot to wait for the user’s response, we use Dialogflow contexts.

For the integration between the web simulator, Dialogflow, and Firestore, we use Cloud FunctionsFootnote 5 that runs on a NodeJs platform. Furthermore, to integrate the intelligent agent with Cloud Functions, we use an API developed in Asp.Net Core.Footnote 6 The information returned by the API, as well as the representation of the plan and problem, are saved in the database so that the chatbot can access it when prompted. Once this data is saved, the simulator issues a warning informing the user that it can already request the validation results to the chatbot.

3 Evaluation

We evaluated our approach in three phases. The first phase was carried out with two professionals responsible for bed allocation at Hospital Conceição; one is the same professional who previously informed us of the bed allocation rules. The second phase was with two professionals also responsible for bed allocation but at Hospital São Lucas da PUCRS (HSL). Finally, we evaluated our chatbot with the help of one of the doctors who assisted in the construction of the NIR manual [12].

For all evaluations, we fed the system with simulated data about beds, doctors, and patients. Based on the data in the system, we asked that professionals use the simulator to check out the simulated hospital situation and ask the chatbot to validate the bed allocation they created and then evaluate the feedback that the chatbot gave. Furthermore, we performed a semi-structured interview in order to collect the feedback of these professionals about the use of the system. All professionals signed a consent form for participation.

3.1 First Phase

We evaluated the approach with each professional individually. The first professional (BD1), who informed us about the allocation rules, has 7 years of experience in bed allocation. The second professional has more than 4 years experience in bed allocation. We highlight some points reported by those professionals:

  • Chatbot and allocation rules:

    • Interaction with chatbot is extremely easy.

    • The information about bed allocation problems that the chatbot points out are very useful and really what they use in practice.

    • They agree that it is not viable a system that allocates alone without a final decision made by a human operator.

    • They would be willing to use our system in their daily activities.

  • Suggestions:

    • Consider patients’ priorities.

    • The validation performed by the system is useful, but it would be even more valuable if it suggested how to correct the allocation if any rules were broken, providing allocation suggestions that do not break the rules.

3.2 Second Phase

We then evaluated our approach with two professionals at the same time. Both professionals have more than one year of experience in the bed allocation function. We also asked questions related to the allocation process to understand the differences between the reality of this hospital and Hospital Conceição. The main difference is that HSL serves the three types of health systems. We highlight some important considerations reported in this interview:

  • Chatbot and allocation rules:

    • They would not like a system that allocates beds autonomously, and prefer one that only make recommendations when requested.

    • They believe that the agent can help them in the daily routine.

    • They are willing to use our system in their daily activities if it remains not necessary to talk much to the robot or chatbot.

  • Suggestions:

    • Their current system does not distinguish between SUS beds, private health insurance, and private; it would be important that the chatbot had this knowledge.

    • Considering the rules of patient prioritisation is extremely important to them.

    • They suggested that the system should give priority to the relocation of a patient released from the ICU rather than other patients who need a bed of that type.

    • Interpret natural language written texts in the patient’s evolution to retrieve relevant information.

    • Generate warnings when a patient has been in the ICU more than 8 days or more than 30 days in the same bed.

    • Based on the patients’ discharge plan for the following day and the scheduling of procedures, the agent could advise if beds will be missing.

    • Tell when a patient was discharged for more than 30 min but the bed has not yet been vacated.

    • Tell when a bed is interdicted for more than 24 h.

    • The agent should also knows the business rules (regarding private health insurance) so that it can validate them too.

3.3 Third Phase

We performed an evaluation with the doctor who graduated over 10 years ago and has more than a year of experience as Consultant Medical Doctor. We highlight some important considerations reported in this interview:

  • Chatbot and allocation rules:

    • The rules are well in line with what are current practices.

    • It is feasible, and it is even necessary to reduce the variability in the conduction of bed allocation processes.

    • They informed us that they would use our system, because this type of software would make the process very fast, in addition to the accuracy and availability to work 24 h a day, seven days a week.

  • Suggestions:

    • Define the bed typology and not ask the doctor to define it, but validate the typology.

    • Suggest an allocation to the user. Not that the agent should make an allocation alone, but it would be good to give suggestions that someone would confirm.

    • Offer options of frequent-asked questions, instead of user typing or talking to the chatbot all the time.

    • When there is a list of patients in the emergency room waiting for a bed and a bed that is suitable for any of these emergency patients becomes vacant, the system should warn the operator.

    • Generate a bed availability forecast, for example, for the next six hours according to the discharge forecasts contained in the system.

4 Improvements Based on the Evaluation

Some suggestions made during the evaluation were considered of major importance and, in order to achieve them, we have carried out some improvements in our system. To facilitate communication between the Jason agent and Dialogflow, we started using Dial4JaCaFootnote 7 [5, 6], a general integration between JaCaMo and Dialogflow that has recently become available. To solve the limitation imposed by the VAL validator, which did not return a complete list with all the allocation problems that the plan has, we implemented a new PDDL validator that will be presented next. Moreover, to enable our agent to make optimised suggestions for bed allocations, we implemented an optimal bed allocation technique using linear programming, which will also be presented in more detail below.

4.1 Bed Allocation Optimisation

In order to allow our agent to make optimal suggestions, we developed an approach to bed allocation based on linear programming. After a linear programming problem is generated for a particular bed allocation instance, we use the GLPK solver to find an optimal solution.Footnote 8 The optimisation tries to allocate as many patients as possible while attempting to decrease as much as possible the distance of critical patients to the office where nurses are based.

The bed allocation optimisation program takes the database’s restrictions and converts them into three types of linear restrictions: equality, relative equality, and negation. Consider for example the following constraint.

$$\begin{aligned} \texttt {(2*Q112[p])+(abs(speciality[p]-2)/2) <= 2;} \end{aligned}$$

The equality constraint above requires that every patient allocated to the bedroom has a specific characteristic. In this case, we want the patient to have the speciality 2. Q112[p] is a Boolean value equal to 1 if patient p is in the bedroom; gender [p] is an integer value referring to the patient’s speciality, hospitals will usually have specific rooms for specific types of specialities. The left side of the sum results in 2 if the patient has been allocated to that bedroom; otherwise, it results in 0. The right-hand side results in 0 if the patient’s speciality is 2; otherwise, it results in some number greater than zero. The result of the sum must be less than or equal to 2, being the only case in which this does not happen when the patient is allocated to the bedroom, but the speciality is not 2.

$$\begin{aligned} \texttt {(Q112[p1]+Q112[p2])+(abs(gender[p1]-gender[p2])/2) <= 2;} \end{aligned}$$

Relative equality is used to require, for example, that if two patients are allocated to the same bedroom, they must have the same characteristic (in the case above, the same gender). The sum’s left-hand side has a maximum value of 2 when the two patients are in room 112. The right-hand side results in a value greater than 0 when the two patients’ genders are different. The restriction would only be violated when the two patients are in the same bedroom, but the genders are different, which must not be allowed.

$$\begin{aligned} \texttt {(Q112[p]) - abs(isolation[p]-1) <= 0;} \end{aligned}$$

Negation is used for example when we require that every patient allocated to the room does not have a specific characteristic. If the patient is in the room, but the isolation characteristic is 1, this will result in \(1-0 = 1\), which does not comply with the restriction. If the patient is not allocated to the room or the isolation value is not 1, the result is less than or equal to zero, according to the bed rules. If the room is not designed for isolation, it will not allow patients that must be isolated under the normal circumstances under which the optimiser normally operates.

In this work, we used the GLPSol solver of GLPKFootnote 9 (GNU Linear Programming Kit), which is a free open source software for solving linear programming problems. One of the implemented algorithms is the simplex method where, after assembling a geometrical figure, the program chooses a point and recursively chooses the relative maximum (or minimum) point, approaching the global optimal result at each iteration. GLPSol allows the user to set certain limits, such as a time limit. When the limit is reached, the process returns the best result found so far. This allows the program to generate some possibly useful allocation suggestions without having to arrive at the optimal result, which can be an extremely time-consuming process in some instances.

We have already integrated the optimiser with Jason Platform, allowing us to execute tests with our complete structure. Figure 5 presents the result of an allocation made using the optimiser.Footnote 10

Fig. 5.
figure 5

Optimiser output in web simulator

Full size image

4.2 Plan Validator

When real-world problems can be modelled in a planning language, it is possible to use a plan validator for example to tell the human operator whether a given plan is feasible or not [10]. Behnke et al. [3] define plan validation as “the task of determining whether a plan is a solution to a given planning problem”. A plan validator can be used in a wide range of applications. The application that interests us is the validation of bed allocation plans prepared by the user.

We developed a new plan validatorFootnote 11 using Java to facilitate the integration with Jason. Like VAL, our plan validator also receives three PDDL files as input: a file containing the domain, a file containing the problem, and a file containing the plan to be validated.

The domain file establishes some basic rules, such as the types of objects and possible actions. The actions are generally divided into three parts, the parameters, the preconditions, and the effects. In this case, the action of allocating a patient to a bed requires that the patient is not allocated to another bed and that the bed is empty. All other bed allocation constraints are also modelled as preconditions. The effects generated by applying this action are that the patient is now allocated, the room occupied, and the patient is allocated in that room. Problem files use domain rules to determine a particular problem, making all objects (e.g., patients and beds) and objectives explicit (e.g., all patients must be allocated).

For validators, a plan file is also necessary, which is simply a set of actions to be applied sequentially, which lead to the objective of the problem. Given these files, the validation process is straightforward, checking if each action is applicable and then apply its effects. An action is only applicable if the types of the parameters are correct (e.g., the action “aloc bed3” does not work if the action aloc requires a patient type) and if the preconditions have been met. If any action is not applicable, the plan is considered flawed. If all actions are applicable, but the problem’s objective is not satisfied, then the plan is also considered to be flawed. The plan only satisfies the problem if all actions are applicable and the objective is satisfied after applying the last action. A characteristic of the hospital domain is that the actions are not ordered. Given a suitable set of allocations, any order of execution will solve the problem, which, in general, would not be the case in other domains. This means that for us it is particularly useful to detect all errors in the plan and not just the first.

In our plan validator, the user has the possibility of printing the plan and the validation result in the terminal through the planTest function. The user still has the possibility, through the valOut(“filename”) function, to obtain a LaTeX file that generates a PDF with the validation report,Footnote 12 the result can also be analysed by our intelligent agent to give an answer to the user in natural language.

As the validator was designed so far thinking about a specific type of problem, we have made, for now, certain restrictions to facilitate the implementation of an initial version of the software. In our initial version, we have some limitations that do not negatively affect the results of the tasks for which we are using the validator, but that need to be resolved to make our validator available to the research community to use it. Although the PDDL language is modular, some specific options are practically universally accepted, however not all of them have been implemented yet. In total, our validator currently supports three options:

  • “STRIPS”, which allows for actions to add or remove effects, and is required in our validator;

  • “typing”, which allows the use of types and sub-types; and

  • “equality”, which allows the use of equality comparisons.

Another actual limitation is that the plan validator was made to be used in automatically generated problems. It considers that the PDDL files are semantically and syntactically correct. We have not yet implemented any pre-processing to look for errors automatically, but we developed a callable method to perform this check. The current version of our plan validator is available on GitHub.Footnote 13

5 Related Work

Oliveira et al. [13] developed an iterative Simulation-Optimisation approach using an evolutionary algorithm to optimise hospital-bed allocation. They applied their approach using datasets from DATASUS of Minas Gerais, Brazil, where the public health system assists nearly 80% of the patients.

Grübler et al. [9] proposed a model called IMBEDS to allocate patients to beds. IMBEDS is a hybrid model that aids in the bed selection process, using some techniques that work together to manage a waiting list of emergency patients and scheduled patients. The model uses an artificial neural network (ANN) and multiattribute value theory (MAVT), a technique used for decision making and conflict resolution in projects with multiple criteria, using contextual information about patients and beds. They evaluated the model in a Hospital in Porto Alegre, Brazil, that receives only patients from private insurance plans.

In Teow et al. [19], the authors extracted data from a hospital in Singapore and applied statistical and data mining approaches to identify the patterns behind bed overflow. Their main objective was to help the hospital devise strategies to reduce bed overflow and improve patient care.

Differently from the work described above, not only does our approach suggest and validate bed allocations through optimisation techniques but it also supports natural language communication using chatbots to interact with the users. We believe our application makes progress towards existing needs in the application of AI systems in domains like healthcare, in which agents provide natural language explanations, e.g., allocation failure in our scenario, supporting users’ decision making rather than being the decision makers.

6 Conclusions

This paper presented an approach to support hospital staff during the process of bed allocation. Although there is some work in the literature that intends to make completely automated allocations, this area of application has resistance to replacing human operators with automated systems. Therefore, in our approach, we only seek to support the decision-making of human professionals.

Our approach was built based on the expertise of professionals in the field, mainly based on an interview we conducted with a professional responsible for bed allocation in a local hospital. We evaluated our approach at Hospital Conceição and HSL, the latter having practices with significant differences since it serves not only SUS but also private patients. Also, we interviewed a doctor that provides consultancy to a local hospital in the area of bed allocation.

Among the points highlighted by the professionals about our approach, it has been mentioned that it is easy to interact with the chatbot and the information contained in the validation of allocation are very useful for their routine. Some good ideas have also been raised to improve our system so that it performs useful tasks in the bed-allocation routine. As our approach was developed based only on the existing practices at Hospital Conceição, the analysis made by the professionals of HSL yielded many ideas for our agent to be more useful in its planned use in those hospitals.

Through this research, we created a domain knowledge and developed a planning domain for PDDL and HTN planners that can also be useful for other projects that involve automated planning and plan validation.

As future work, we intend to investigate argumentation techniques [14,15,16] to implement more interactive agents and explain the allocation suggestions as requested by the interviewees. We believe that with the use of argumentation techniques, intelligent agents will be able to reason about beds and patients’ relations, thus providing useful explanations that will help the users by saying why a particular suggestion is being made. We intend to integrate our approach with the Hospitals’ information systems, which will allow us to make several queries as suggested by the experts during the evaluation phase. Moreover, we aim to use natural language models to allow the chatbot to answer questions about a patient’s evolution.