{'fraction_non_alphanumeric': 0.02446474531210227, 'fraction_numerical': 0.004299007268716237, 'mean_word_length': 5.036878948267031, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Development process of multiagent system for glycemic control of intensive care unit patients

This article presents the entire process of developing an agent-based system for the glycemic control of patients in the Intensive Care Unit (ICU). The agent’s goal is to monitor and recommend treatment to keep the patient’s blood glucose within the target range, avoiding complications in the health of patients and even decreasing rates of morbidity and mortality in the ICU. The process of developing the agent-based solution was presented, starting from the understanding of the problem, including a brief review of the literature, going through the pre-project and modelling through the Tropos methodology, until the implementation. The agent inference mechanism is based on production rules and intuitionistic fuzzy logic. An illustration of use, with the collaboration of a specialist intensive care physician, shows how agents behave in a real situation of monitoring and controlling the blood glucose of patients admitted to the ICU, interacting with all elements of the proposed architecture. Finally, feedback from health professionals indicate the system can assist in the glycemic control of patients in the ICU having advantages over traditional monitoring systems.


INTRODUCTION
The Intensive Care Unit (ICU) is considered a high-risk care setting, where carelessness or medical errors can cause deaths or complications to patients' health. According to the National Health Surveillance Agency, the ICU is a key area intended for the admission of critically ill patients, who require continuous specialized professional attention, specific materials, and technologies necessary for diagnosis, monitoring, and therapy. An ICU can be divided into areas according to the age group and even the specialty to be treated. In addition to being composed of several professionals forming a multidisciplinary team that must contain: specialist physicians, nurses, physiotherapists, among other health professionals. [1] Considering the hospital environment, the ICU is the most complex unit to be managed, as it is the place where patients with the most critical condition and who deserve greater care are concentrated. Therefore, improving productivity and cost, consequently, the care and treatment of patients are the main current challenges for care in the ICU, where personalization and automation of care offer opportunities to cause significant impacts. [2] The present work will initially take into account glycemic control, whose main function is to maintain the patient's blood sugar (glucose) level in a target range. [3] Both hyperglycemia and hypoglycemia, high or low amount of glucose in the blood, respectively, are frequent problems in ICU patients. Studies show that intensive glycemic control reduces multiple organ failure, systemic infections, the patient's length of stay in hospitals or ICUs, and even cases of mortality in critically ill patients, highlighting the need for strict control. [4] Although [5] recommend ideal blood glucose (target range) between 140 to 180 mg/dL, some authors including the specialist who contributes to this work say that this value may vary depending on the hospital in which it is applied. However, regardless of which is the ideal value the most important thing is to keep the monitoring. According to [6], the effective control of glycemia in the ICU environment has the potential to decrease the morbidity and mortality rates and the length of stay of the patient.
To improve the quality of patient care and even avoid medical error in the ICU, mechanisms such as protocols, checklists, and medical rounds at the bedside are indicated in the monitoring of patients and must be done by the intensive care physician and professionals working in this environment, such as nurses and physiotherapists. One of the ways to monitor patients in the ICU is through the application of the FAST HUG. This is a simple and significant mnemonic, which highlights seven of the main areas that must be followed by the health team for each patient in the ICU: Feeding, Analgesia, Sedation, Thromboembolic prevention, Head of the bed elevated, stress Ulcer prophylaxis, and Glucose control. Such verification must take place during medical rounds, at which time the multidisciplinary team monitors the patient at the bedside. It is recommended that it happen at least once a day and ideally, whenever any of the professionals attend to the patient. The fact that it is a mnemonic helps the professional to remember the seven essential items that must be checked. [3] Aiming to enhance the efficiency of FAST HUG, including glycemic control, the automation of processes combined with the use of Artificial Intelligence (AI) resources is very attractive. During the literature review, it was possible to find works that propose AI-based systems for glycemic control in the ICU, [7] as well as applying Multiagent System (MAS) for glycemic control, [8] and even focusing the ICU context. [9,10] However, none of the researched studies contemplates the use of MAS for glycemic control in the ICU.
Considering that MAS is an intelligent distributed approach, suitable for modular, changeable, and complex applications, with characteristics such as autonomy, integration, reactivity, and flexibility, it becomes an interesting solution for modelling large-scale health systems, since these can be considered as a collection of entities or autonomous agents that interact to achieve a common goal. [8] Regarding the knowledge of the agents, this can be built from the knowledge of a specialized intensive care physician. Concerning knowledge in the medical field, it can contain uncertainties, and the Intuitionist Fuzzy Logic (IFL) has great potential. According to [9], the health decision area is predominantly characterized by the prevalence of inaccurate information, since accessible information is generally vague, inadequate, or incorrect.
In this scenario, we propose a solution that is capable of monitoring and recommending treatment for glycemic control of critical patients in the ICU, through a MAS using IFL. The proposed system is called MAS4GC -Multiagent System for Glycemic Control. In this article, we present the entire development process of the MAS for glycemic control of patients in the ICU followed by an illustration of use. The rest of the manuscript is organized as follows. In Section 2 we present the methodology of the development process involving studies, design, modelling, and implementation; in Section 3 the results are presented through an illustration of the use of MAS4GC; in Section 4 a discussion contemplates the proposal in the research scenario, comparing it with other works currently available in the literature; finally, the final considerations are presented in Section 5.

METHODS
The MAS4GC development process is represented in Figure  1. This process was divided into four main steps, namely: problem definition, pre-project of agents, modelling, and implementation.

Problem definition
The problem was defined by contextualizing the current scenario in the form of in-depth research of the concepts related to the proposal and a literature review, which will be covered in the discussion section, confronting what was found about the proposal of this work.
Considering the medical field, concepts of ICU management were studied, more specifically through the mnemonic FASTHUG and glycemic control. Then the concepts referring to MAS, with a focus on modelling that took place by the Tropos methodology. The reasoning of agents was also studied, highlighting production rules and inference mechanisms. Since uncertain data is involved in the reasoning process, fuzzy logic and IFL were addressed. Finally, the technologies used for implementation were presented.

Glycemic control
During the studies about glycemic control, two important points were highlighted: monitoring (frequency of blood collection for blood glucose measurement), and treatment, allowing the glycemic level to be maintained in the target range (range of values minimum and maximum blood glucose levels, namely target range or normoglycemia). Such values vary in the literature according to the region and even between hospital institutions. Considering the lack of stan-dard among the values that regulate the glycemia of patients in the ICU, this work will use values based on the knowledge of Dr. Sérgio Eduardo Soares Fernandes, a specialist in intensive care of patients in the ICU. Thus, values were defined about glycemic rates, collection intervals, and dosage as shown in Tables 1 and 2.   As shown in Table 1, each patient's glycemic value range is represented by a code related to the episodes. Episode means the situation in which the blood glucose of the patient is. It refers to a value range that represents the amount of sugar the patient has in his blood system using the unit mg/dL (mass concentration). The codes (e.g. hypoS, hypoM) will be used to represent the knowledge of the agents and the system implementation variables.
Basically, for glycemic control, there are two procedures to be performed: collection and application. Collection refers to the number of times the patient's blood glucose should be collected on the day. Application refers to the drug to be applied (insulin or glucose) by which route (intravenous -IV or subcutaneous -SC), as well as the amount/dose should make up the patient's treatment. In Table 2, in addition to the code indicating the glycemic episodes, for each episode, the frequency of collection on the day and the indication of recommended treatment are shown.

Pre-project of agents
The model design started through the pre-project of agents, where the PEAS model (Performance, Environment, Actuators, and Sensors) was defined for each agent. As presented in [11], the PEAS consists of identifying the performance measure, the environment, the actuators and sensors of the agents. Besides, based on the objectives of each agent, it is also possible to describe the mechanisms by which they will perceive the information and how they will act in response to such stimuli. In this sense, a MAS project needs the modelling of the system to define the behaviour and reasoning of the agents, as well as which tools will be used in the implementation.
The proposed MAS is composed of three agents that interact with each other and also with a web system called Glycon (Patient Glycemic Management System), used as an interface for collecting blood glucose and patient data. The agents' objective is to collect, analyze data from the Glycon database, and provide important information to health professionals working in the ICU regarding the blood glucose levels of the patients. In the sequence, there is a description of the MAS4GC agents, followed by the PEAS model for each agent according to Tables 3-5. Check if the predictions are within a margin of error of 4mg/dL (+/-) per hour in advance with a percentage of correct answers of 80%. Environment Hospital ICU with characteristics: partially observable, stochastic, sequential, static, discrete, multiagent. Actuators collect and analyze data (patient and blood glucose), compare with previous data and predict next blood glucose levels, share the evaluation report with the other agents.

Sensors
Glycon database and/or Internet of Things (IoT) module.  • PAA (Patient Analyzer Agent): the patient's analytical agent has as main objective to collect the patient's data and their respective glycemia, whenever new data is inserted or updated in the Glycon Database. The agent must analyze such data and make a report assessing the patient's situation against existing previous data. This will allow the agent to calculate and make predictions of how the patient's next blood sugar will be. This report will be sent to PTA and AMA agents. • PTA (Propose Treatment Agent): this agent is responsible for analyzing the evaluation report generated by the PAA verifying whether the patient needs treatment (e.g., glucose or insulin application, dose, type of application, frequency of applications). Besides, it should try to find any irregularity pattern in blood glucose rates to identify any factor that may affect the patient, such as possible infection, for example. Finally, PTA issue alerts to the Glycon system to assist health professionals through this information. Health professionals may accept or not the suggestion of making glucose or insulin applications. • AMA (Adjust Monitoring Agent): this agent receives the patient's report sent by the PAA agent to analyze the current blood glucose collection plan referring to the frequency at which blood glucose collections took place. Based on this, check if it is in an acceptable range. If not, this agent will prepare a new collection plan with more spaced or closer frequencies. Like the PTA, it will issue alerts to the Glycon system to assist health professionals. It is worth mentioning that the professional will be responsible for accepting the suggestions for a new plan or maintaining the existing one in the system.

Modelling
After defining the pre-project of the agents with the PEAS, the MAS was modelled using the Tropos methodology for agent-oriented software development based on the i* framework (I STAR -Intentional STrategic Actor Relationships modelling). Tropos allows us to model the functionalities of an application based on objectives, through five diagrams: early requirements, late requirements, architectural design, detailed design, and implementation. [12] This design order was followed to contemplate the evolution of the MAS modelling process. To model the first three, the online tool piStar (online iStar modelling) was used. And to represent the detailed design and implementation, UML diagrams were used. The initial requirements diagram shown in Figure 2 identifies the stakeholders in the domain and defines them as actors: patient, health professionals, Glycon, and agents. The model addresses the dependencies and exchanges of resources between entities.
The process begins with the patient being admitted to the ICU receiving the care of health professionals, more specifically it involves blood glucose collection. Then the professional informs such data, in addition to the patient data to the Glycon system to store in the database. Once the patient's data and blood glucose are stored, the agents can collect, analyze, and consequently, if necessary, inform a new treatment proposal. This proposal is sent to the Glycon system, making it available to health professionals who can carry out the appropriate treatment on the patient.  About the late requirements diagram (see Figure 3), it is possible to see an expanded model from the early requirements that contains the decompositions of the actor health professionals in doctors, nurses, and others, because in an ICU environment these agents can accompany the patients including collecting the blood glucose levels and possible applications of glucose and insulin. Due to the detail that this diagram receives concerning the previous one, it is now possible to observe which agents will compose such a model. Besides, their dependencies to the objectives and the resources shared between them can be observed too. This diagram allows a general idea of the system that will be developed as well as to define the functional and non-functional requirements. The late requirements can be further explored in the architectural design diagram (see Figure 4), where a global view of the system is presented. In addition to all the actors involved in the environment, it is possible to observe the agents, their tasks (representing the functional requirements), as well as the dependencies and relationships with the other actors in-volved in the entire process. In this case, the agent system is represented by the MAS4GC actor that represents the agents who collect, analyze and provide information such as collection plans, propose treatments and send different alerts regarding the patient's health situation. Considering the detailed design, the MAS4GC architecture will be presented. In the interface module it is possible to observe that the data are retrieved by a health professional working in the ICU (e.g., doctor, nurse) and are inserted in the Glycon web system database. The agent module comprises a middleware that will have a MAS implementation framework using JADE (Java Agent DEvelopment framework). JADE uses the FIPA (Foundation for Intelligent Physical Agents) standard communication protocol to communicate with the agents. [13] The PAA agent will be responsible for retrieving the information from the web interface and sending it to other agents to perform their tasks. The agents' knowledge contains a knowledge base with inference rules, built with the aid of an intensive care physician, and an inference mechanism. The IoT module brings greater autonomy to the solution. In this way, monitoring and treatment can be performed using blood glucose monitors and infusion pumps, respectively.
At this stage, diagrams representing the line of reasoning of the specialist physician when providing care and consequently treating a patient were also drawn up. Such diagrams represent the flow of decisions that the doctor makes according to what is identified by the patient. These decisions represent the specialist's knowledge, which during the implementation phase are converted into inference rules to form the knowledge base to be used by the inference mechanism.
The inference rules follow the doctors' reasoning and the agents must conclude using them. This approach is defined by [14] as deductive reasoning based on symbolic AI. It is worth mentioning that deductive reasoning agents would correspond to an agent with a symbolic representation of a logical formula with syntactic manipulation corresponding to logical deduction or proof of theorems. Three diagrams were created that represent the knowledge that each of the agents should have. Figure 6 represents the knowledge of the PAA agent where its main function is to determine the patient's situation. First, it checks whether the blood glucose collected is the first, if it is, its range is checked, and the standard procedure based on the basic rule is carried out (presented in Tables 1 and 2). If there are already other blood glucose values collected, the agent will be responsible for making the comparison (i.e., initially employing a linear regression) to predict the next blood glucose to make adjustments for the best treatment and frequency of collections for that patient. Figure 7 illustrates the procedure that the AMA agent must perform based on the situation determined by the PAA to check in which range the patient's blood glucose is. It makes the calculation and suggests to the system that the frequency of the collections be increased or decreased, causing more or fewer collections over time.   Representing the implementation phase, the class diagram includes the classes that will be used by the Glycon web system for data capture and by the agents. Figure 9 presents the classes used to classify the objects involved in the model with their characteristics through attributes and methods. The relationship between these classes can be seen through associations. In the model, four classes were used, where the Paciente class receives information regarding the patient at the time of his hospitalization. Personal health data and other data that can interfere with the glycemic situation, in addition to an initial plan for blood glucose collections are part of the class diagram.
The Glicemia class gathers attributes related to blood glucose collections, including mainly the glycemic value. The Applicacao class includes data related to the glucose or insulin doses that the patient received during his hospitalization. The RelatorioAvaliacao class is responsible for modelling the data referring to the decisions that agents will take during the patient's hospitalization as a treatment suggestion, indication of possible complications, and even better blood glucose collection times for good patient monitoring. The names of the classes, attributes, and methods were kept in Portuguese to maintain the fidelity in the nomenclature about the implementation.

Implementation
In the implementation phase, the development of codes takes place. This stage was divided into three parts: interface implementation, agent implementation, and agent knowledge implementation.

Interface implementation
The Glycon web system (Glycemic control online) has the main objective to receive the patient's data and blood glucose for the health professionals to deal with it (insert, update, and list). However, the two most important tasks of the system are to record blood glucose levels and the possible applications of glucose or insulin that the patient may have received. Such information is listed and presented through graphics in a kind of patient's dashboard as shown in Figure 10.  Glycon is developed in Javascript through the React.js (frontend) and Node.js (back-end) frameworks. Its database uses the MongoDB Managed Database System (DBMS), a non-relational DBMS (NoSQL -Not Only SQL) available through the Atlas web tool. MongoDB is document-oriented, and the organizational structure of the data generates a JSON (JavaScript Object Notation) type document containing keys and values where the attributes and respective data are structured. Glycon is currently hosted on the Heroku Cloud Application Platform.

Agent implementation
The JADE framework will be used to implement the agents. JADE is a MAS development middleware written in the Java programming language. [15] It was defined following the specifications of the FIPA and through a set of tools that support the debugging and deployment phase. The JADE framework can be distributed between machines on multiple platforms and its configuration can be changed at runtime allowing the creation of new agents, including mobile agents from one machine to another, as long as these machines have installed JRE5 (Java Run Time).
One of the great advantages of JADE is the compliance with the FIPA specification, facilitating integration with other agent services. Native services of JADE are life cycle management, message transport, and yellow and white pages service, as well as some optional services such as agentsoftware integration, ontology service, and agent-man interaction. The Message Transport Service (MTS) is responsible for delivering messages exchanged between agents on the same platform or between platforms. All FIPA agents have access to at least one MTS and only messages addressed to the agents can be sent due to security mechanisms. According to the FIPA specification, the JADE framework includes two special features: AMS (Agent Management System) and DF (Directory Facilitator) which are automatically activated when JADE is started. AMS is an agent management system that controls access and use of the platform, dealing with the creation, completion, and other stages of the agents' life cycle. The DF offers the yellow pages service for agents, acting as a centralized database whose entries associate an agent with its services. [13]

Implementation of knowledge agents
To implement the inference rules, Drools, a Business Rule Management System (BRMS) tool is the option. [16] Drools provide a reasoning system with inference mechanisms including forward and backward-chaining allowing the evaluation of business rules and processing of complex events. The production rules are structured in conditions and actions (IF-THEN). The Drools engine stores, processes and evalu-ates data to execute business rules or user-defined decision models. The basic function of the Drools mechanism is to match received data or facts to the conditions of the rules and determine how to execute the rules. It will be through this tool that the rules illustrated by the diagrams in Figures 6, 7, and 8 will be executed. Drools and JADE are open-source and use Java language for implementation, an important characteristic that contributes to the development of applications that combine MAS with deductive reasoning agents.

RESULTS
In this section, MAS4GC is illustrated presenting how the agents behave in a real situation of monitoring and controlling the blood glucose of patients admitted to the ICU. Glycemic control is one of the processes performed during the application of the FAST HUG, where the health professional makes a bedside visit to the patient, collects his blood glucose and according to the value, makes the most appropriate decision based on his knowledge. In the case of MAS4GC, the professional inserts the data into the system, and knowledge-based agents using production rules suggest a treatment that health professionals can accept or not such recommendation. In the sequence, a usage scenario based on the model created will be presented.
The scenario starts when the health professional collects the patient's blood glucose, this can happen on two occasions: (i) as soon as the patient is admitted to the ICU, or (ii) during medical rounds. In the case of this experiment, patient data will be randomly generated using a biochemical patient simulator, with and without glycemic problems. It is also important to simulate patients with normal blood glucose to make sure that in these cases the agent will not recommend any treatment. After generating patient data, as well as the value of your blood glucose at the moment, this value is inserted into the Glycon database through its graphical interface (during the testing phase an API was in charge of generating data and inserting automatically into the database).
Assume that John S. was hospitalized at noon with blood glucose at 120 mg/dL. After identifying a new record in the database, the PAA agent collects his information and begins its analysis based on the rules presented in Figure 6, triggering Rule 1: Rule 1: IF collect = 1 AND glycemia = normalBG THEN alert: keep-watching This is the first blood glucose collected from the patient and it is in the target range (100-200 mg/dL). The recommendation, in this case, is to keep watching the patient, dispensing any type of treatment, and adjustments in the monitoring 52 of his blood glucose is recommended to be done every six hours. Thus, at 6 pm new blood glucose from the patient is collected and inserted into the Glycon and now the value is 190 mg/dL, triggering Rule 2: Rule 2: IF collect > 1 AND glycemia = normalBG THEN alert: keep-watching This time, more than one blood glucose is collected and the PAA agent can make a comparison between the values and generate the forecast of the next blood glucose. In this case, as much as the glycemia is still in the target range, it approached the limit of 200mg/dL and therefore the agent sends the patient's evaluation report to the AMA agent. AMA estimates how long blood glucose will still be found in target and indicates that the frequency of collections should be in-creased (more collections should be done in less time), and suggests that the next collection should be made in one hour. As suggested by the AMA agent, the professional makes a new collection at 7 pm and inserts its value in the Glycon. With this, the PAA agent identifies a hyperM (Mild Hyperglycemia), because its glycemia is at 240 mg/dL, triggering Rule 3: Rule 3: IF collect > 1 AND glycemia = hyperM THEN alert:2 units of regular SC insulin The PAA agent sends the report to the AMA agent so that it can adjust the frequency of blood glucose collections and also to the PTA agent since there is the need to carry out a treatment, which in this case is the application of two units of regular subcutaneous insulin (see Figure 11). Also, the PTA agent will do a calculation to identify possible trends in maintaining hyperglycemia, stability (target range), or even, due to an overload of the drug, causing hypoglycemia. In addition to calculating the ideal dose to re-establish the patient's target blood glucose range. As a recommendation, the AMA agent suggested that a new collection be made after one hour. Then, at 8pm a new collection was performed, and the blood glucose pointed to 150 mg/dL, returning to the target range. The PAA agent after elaborating his calculations identified a stabilization in the patient's blood glucose and recommended observation and a new collection in six hours, triggering Rule 4: Rule 4: IF collect > 1 AND glycemia = normalBG THEN alert: keep-watching Two new collections were performed at 2 am and 8 am (the following day) and showed blood glucose levels in the target range, 130 and 140 mg/dL respectively. Figure 12 presents the collections, applications, graph illustrating all the monitoring and treatment of the patient's blood glucose throughout the test period.
This process is repeated for all patients whenever new blood glucose is collected. A single patient case was presented, but the agents will not be limited to the decisions presented, they will be able to exchange information and cooperate to find patterns and detect possible problems in patients' health by crossing data from all patients in the ICU. The entire process of this simulation was followed up and validated by the specialist.

DISCUSSION
The decisions to be made by health professionals about treatment plans and blood glucose monitoring of patients in the ICU are complex involving uncertainty, mainly because it is a very dynamic environment relating not only glycemic problems in the treatment. Also, constant patient monitoring is needed. Thus, it is desirable to automate the process including other essential elements of the FAST HUG verification, creating decision support tools with adequate recommendations to assist health professionals.
Nevertheless, the purpose of this work is to present the entire process of developing a solution based on intelligent agents that does the glycemic control of critical patients hospitalized in an ICU through knowledge-based agents. In short, the work presents a solution that involves the development of MAS, IFL, and glycemic control in ICU. According to the research carried out in the current literature, no work found contemplates all these items, as can be seen in Table 6.  [8] x x [17] x x [6] x x [18] x x x [10] x x [9] x x x [7] x x MAS4GC x x x x In [8] three agents were defined to control and monitor the glycemic and diet of Type-2 diabetic patients. Using data from the patients' daily diet and blood glucose, the system makes recommendations for appropriate diets. Despite the work uses MAS and performs glycemic control, it was not applied in the ICU context. In the works of [6], [7], [17] the focus was to create an autonomous blood glucose controller (artificial pancreas) for ICU patients but does not apply MAS.
In [10] it was presented an agent-based architecture with real-time decision support for managing high-risk newborns admitted to the ICU-N. The agents have the objective of capturing data (physiological, measurements, and exams) of the neonate in the act of their hospitalization and provide the degree of risk to the health professional. The work presents a MAS applied to the ICU but does not include glycemic control.
Finally, the solution proposed by [9],[18] uses MAS and IFL. The authors propose to determine the degree of risk of patients in the ICU after entering their physiological data into the system. The evaluation of the prototype's effectiveness was tested in a real case study involving 16 patients from a Polyclinic in Tunisia. The prototype proved to be efficient. The solution is the most similar to this work, but it was not applied in the context of glycemic control. Also, only a risk estimate is offered and not continuous patient assessment.
Another fact that differentiates this work from the cited ones is that none presents a complete development method, a task not trivial involving several processes. To facilitate understanding, the method was divided into four stages as presented in Figure 1. In addition to the method used in the design development process, such research will also contribute to the system that can be applied in the ICU, helping health professionals in their diagnoses and treatments.
The MAS4GC system has three agents to perform data analysis, propose a treatment, and adjust the patient's blood glucose monitoring. The analysis agent also sends data to a system that intermediates the data with a human being, who in turn performs the necessary procedures on patients. Nevertheless, new agents may be added in the future to complement such tasks and even to cover other elements of FAST HUG, such as feeding, for example. The illustration of the approach presented shows that the use of MAS with production rules is an adequate solution to operate in complex environments such as the ICU.
Consulting the health professionals, they cite that the MAS4GC system can substitute the instructions in medical ICU in patients' prescription related to most of the usual cases with some advantages over traditional monitoring systems: it will be faster, adjustable, has breakpoint alerts, and presents the timeline in a visual chart. According to the specialist intensive care physician feedback, the system behaved as expected in the illustrated scenario indicating that it will be able to contribute to the health professionals since it emulates the specialist knowledge. Besides, the integration of new agents can result in discoveries making treatment faster and efficient.

CONCLUSION
This work presents the entire developing process of a MAS for glycemic control of patients in the ICU. The problem was taken into account through a literature review where possible methods and techniques of AI were raised through recent work. It became evident that the use of the combination of the MAS approach with IFL-based production rules is innovative and shows promise in medical environments, where agents can cooperate and act autonomously in a complex environment such as an ICU. Knowledge-based on inference rules replicates the knowledge of a specialist intensive care physician, and the use of IFL favours the variation and imprecision of the treated data.
The MAS4GC illustration of use showed how the agents behave in a real monitoring scenario controlling the blood glucose of patients admitted to the ICU. This process illustrates how all system architecture components interact to achieve the main objective of monitoring and treating patients with glycemic attention. After simulating treatments, the data were analyzed by the specialist intensive care physician who concluded that the recommendations were satisfactory. Also, it is intended to validate such data through statistical calculations, more specifically, calculating the relative risk of having blood glucose levels outside the target range.
As future work, we intend to implement the modelled MAS4GC, test it, and analyze the system in a real ICU environment, with the help and collaboration of a medical team to prove the efficiency of the proposed solution. Another ambition is to add the IoT module to the project so that it becomes fully autonomous.