In Silico Testing of the Semi-Closed Loop Infusion System with a New Simulator

1Abstract—Goal directed fluid therapy (GDFT) implies the flow-related parameters guided infusion of fluids. It requires adherence to complex clinical algorithms and fluid protocols, as well as simultaneous monitoring of several parameters and evaluation of their fluid responsiveness or actual response to fluid challenges. Automated clinical decision support systems (ACDSS) are used to ease the task. However, they are based on the flow-related (hemodynamic) parameters – arterial blood pressure, cardiac output, etc. Meanwhile, infusions guided by hemodynamic endpoints may lead to edema. A mini Volume Loading Test (mVLT) may be helpful in detection of imminent edema from changes in hemodilution during stepwise infusion which is conventionally used for hemodynamic optimization. We developed an ACDSS which is based on evaluation of both hemodynamic and hemodilution parameters. It operates on the basis of our unique algorithm which implies interchangeable application of fluid loading, vasopressor injection and red cell transfusion. This ACDSS is used in our PC-based command centre of a prototype semi-closed loop (SCL) infusion system. We developed a simulator – ‘Virtual Patient’ – on the basis of our previous clinical records aiming to test a new controller, as well as train the research team before starting a clinical trial. In silico testing continued for 12 hours on five occasions. Primary endpoint was the compliance of a controller with our clinical algorithm and the stability of operation in a spectrum of arterial hypotension and bleeding scenarios. The prototype SCL infusion system was found ready for clinical validation.


I. INTRODUCTION
Hemodynamic optimization using intravenous fluid administration may have a positive influence on outcomes of treatment in terms of lower occurrence of complications and reduced length of stay in hospital, as well as improved long-term effects in moderate and high risk patients [1].
Goal directed fluid therapy (GDFT) implies stepwise fluid administration (fluid challenges) guided by the flow-related parameters ranging from arterial blood pressure (ABP) to cardiac stroke volume.Poor adoption of hemodynamic optimization during major surgery is both surprising and concerning [2].The complexity of the procedure is one of the reasons why only 16 % of anaesthesiologists use GDFT for high risk patients [3].Thus, automated clinical decision support systems (ACDSS) are entering the market [4], e.g.clinical platform EV1000 TM from Edwards Lifesciences Corp. (USA) [5] and LiDCOrapid v2 from LiDCO Ltd. (UK).They are based on sophisticated simultaneous evaluation of several invasive and non-invasive flow-related parameters.However, there is evidence that hemodynamic optimization may not be sufficient for achieving the better results of treatment.Although benefits of GDFT were prevailing in early reports [1], the more recent data showed no benefit [6] or even worse outcomes [7].
These controversial findings may find explanation in the following.An ultimate goal of optimized circulation is maintaining or improving organ perfusion and oxygen delivery to tissues.Thus, swelling of tissues (edema) is a concern.Volume kinetics indicated that 65 %-70 % of crystalloid solution usually remains in blood vessels at the end of infusion, whereas only 20 %-25 % remains therein 20 min later [8].Most of the volume which leaves circulation soon after infusion is translocated into tissues.However, conventional clinical methods are not sufficiently sensitive and specific for the detection of when the necessary fluid accumulation in tissues turns into edema during hemodynamic optimization by fluids.Thus, a mini Volume Loading Test (mVLT) for detection of imminent edema during stepwise infusion was proposed [9]- [11].It requires measurement of haemoglobin concentration (Hb) before and after each fluid challenge.The method defines hemodilution non-responsiveness as a sign of imminent edema.It may or may not coincide with non-responsiveness Previous concerns regarding the reliability of continuous non-invasive techniques for measuring hemodynamic parameters and Hb are increasingly replaced by the evidence of clinically acceptable accuracy [12].Thus, closed-loop infusion systems may soon become a reality in everyday clinical settings.The conventionally available hemodynamic parameter is ABP and intravenous fluid loading as the firstline treatment of arterial hypotension was used for decades.Thus, no surprise that the first closed loop infusion system for the perioperative maintenance and restoration of target ABP by injecting vasopressors was put into clinical trial immediately after the introduction of continuous noninvasive arterial pressure (CNAP TM ) technique [13].The ACDSS of probably the most investigated closed loop infusion system is based on the sole evaluation of the noninvasively measured static and dynamic flow-related parameters -stroke volume and its variation [14]- [15].
We developed an upgradable ACDSS for a novel semiclosed loop (SCL) infusion system on the background concepts of GDFT and mVLT, and the basis of our clinical algorithm which implies interchangeable application of fluid loading, vasopressor injection and red cell transfusion.The blueprints of the system are described elsewhere [16].
Development of simulators and performing simulation studies are standard steps in the testing of new controllers before starting clinical trials.We developed a simulator -'Virtual Patient' -on the basis of our previous clinical records aiming to test a new controller, as well as train our research team before using it in a clinical trial.

II. THE SCL INFUSION SYSTEM
The SCL infusion system includes command centre with user interface and four remote devices (Fig. 1).Critical values of target parameters are set by physician.System generates visual and audible alarms when the pre-set critical values of target parameters are reached.This ACDSS system is designed to give pop-up advises for algorithmic decision-making and interventions (Fig. 2), but they must be approved by the attending physician.

Decision Support System
Advices direct the physician's actions towards three therapeutic interventions:  Fluid infusion by a high-volume infusion pump;  Titrated vasopressor infusion by a syringe pump; or Transfusion of packed red blood cells (PRBC).

III. VIRTUALISING THE SYSTEM
For the novel ACDSS and SCL infusion system to be properly tested, the target parameters exceeding preestablished critical values must be obtained, what is virtually impossible in vitro.Therefore, a system emulating target parameters' responses to various stimuli has been designed.Features of this system are detailed in Fig 3. Normally medical equipment is connected directly to patient to either monitor vital signs or introduce property changing agents such as haemoglobin diluting isotonic solution or blood pressure change inducing vasopressor solution.All hardware is connected to ACDSS using physical lines that might fail in numerous ways:  Lines can get disconnected (tripping),  Lines can be occluded or damaged,  Signal can be distorted duo to EMI, supply voltage fluctuations, etc.Since patient in vitro acts as a black box between controlling and monitoring hardware we can only virtualize the data input and output protocols, transfer data directly to and from patient in silico as inputs and outputs.Use of physical lines to connect ACDSS to patient in silico allows us to simulate unreliable connections and creates an opportunity to use the system in an exam where examiner can introduce certain events (for example sudden loss of blood) without the knowledge of examinee.The equipment in question is connected to DSS via serial and Ethernet interfaces, however it is not mandatory to use the same interfaces as long as we provide appropriate encapsulation.
Figure 4 depicts possible advantages and disadvantages of selected transport layers.
The ACDSS is connected to monitoring hardware via serial interfaces.Therefore, several technical challenges are imposed.Since serial interfaces on modern systems are provided using serial to USB converters there is no guarantee that enumeration order will not change due to replaced converter.Furthermore, there is no guarantee that no other systems utilizing serial interface are not connected to ACDSS.This requires elaborate querying scheme in order to reliably detect required devices and ignore any others.Monitoring hardware in question provides two different data acquisition interfaces: polling and streaming.Detection of streaming devices can be accomplished by opening all serial ports with required parameters, including reasonable timeout, and listening for incoming data.Required data streams can be detected by applying required deserialization routines on data and checking results.Ports not containing streaming devices can be further opened and polled.Even though specific request is sent, in order to reduce the risk of false positive detection precautionary response deserialization should be performed.Since commercially available USB to RS485 converters [17] usually utilize only one data channel (half duplex mode) care must be taken to perform these steps in order described, otherwise a risk of damaging the converter or losing communication arises.Taking above into account, in order not to confuse DSS, virtualized hardware should not only provide correct implementation of data serialization protocols, but also simulate appropriate lag between request and response or chunks of streamed data.

IV. VIRTUAL PATIENT
The virtualised system should respond to stimuli automatically according to predefined formulae.Therefore, a patient response model was created according to aggregated statistical data [18].These are the invasively measured mean arterial pressure (MAP, Fig. 5(a)) and noninvasively measured SpHb (Radical-7 from Masimo Corp., Irvine, USA) which, referring to its measuring site is labelled as capillary haemoglobin (Fig. 5(b)).For the purpose of this model the blood loss over time is constant, if no adverse or other events take place.On average, in our model, the change in blood pressure due to blood loss was described as where t-time in minutes.When the blood pressure reaches the lower margin, determined by the physician, fluids are infused at a predetermined constant rate, and their influence to blood pressure in the model were described as 2 ( ) 0.34 0.02 .
As the Hb changes much less during the operation, it might be described as constant and differ from patient to patient.Haemoglobin values are obtained using two distinct methods: invasive arterial (aHb) and non-invasive capillary (SpHb).The change in Hb due to fluid infusion over time are described respectively: The next task is to determine the effect of red cell transfusion.It is assumed that the ABP change is negligible, and therefore not included in the model.The changes in Hb were described as 10 g/L increase per unit.
The ABP increase was defined as 150 mmHg increase for each 1 mg/kg/min, when administered according to the algorithm described in Fig. 6.Fig. 6.The vasopressor infusion algorithm.
The parameter responses described above were used in the software (Fig. 7) to determine the state of patient parameters in accordance to the physician's actions at any given time (Fig. 8).As real life testing and training using real patients is impossible, this model was extremely valuable.All patient reactions were determined using data from real clinical settings.
To simulate different patient reactions and various operation scenarios, including the improbable and adverse ones, different starting conditions were chosen.To simulate the operating environment, the measurements were given in 5 minute cycles, because that is the rate in which blood pressure measurements are taken in real operations.Additional delays were added to account for the data loss due to sensors, which are disconnected, moved and etc.These conditions helped refine the SCL system software to better match the needs of the physicians.
The goal of the virtualisation was to refine the responses of the system actions (fluid or drug administration) rather than mimic the pattern of the blood pressure and haemoglobin count during the operation, so other factors, such as anaesthesia drugs, where not represented in this model.For the Virtual Patient to be suitable, for example, for SCL system validation, these factors would have to be taken in to account.
In silico testing continued for 12 hours on five occasions.Primary endpoint was the compliance of a controller with our clinical algorithm and the stability of operation in a spectrum of arterial hypotension and bleeding scenarios.Further testing of the system was done during surgeries of hip replacement to improve the performance during clinical trials (Fig. 9).This SCL infusion system was successfully tested with the simulator and our research team was trained to operate the system.The prototype SCL infusion system was found ready for clinical validation.

Fig. 5 .
Parameters recorded during stepwise infusion in pre-and postoperative mVLT fluid protocols in our previous observations[18].Data point referred to as baseline is the value before the first crystalloid bolus.Data points referred to as mini fluid challenges are the values determined after the 5 min period without fluids which followed each of the three crystalloid boluses.Data are presented as means ± SEM.Aiming to adapt 'Virtual patient' for training purposes, the patient's parameters and their reactions to the treatment have been taken into account.The pattern of Virtual patient's responses:  Changes in blood pressure (for any reason);  Changes in blood pressure during the stepwise fluid infusion (mVLT fluid protocol);  Change of Hb due to fluid administration;  Change of Hb due to blood transfusion;  Changes in blood pressure during vasopressor.