Bmc Medical Informatics and Decision Making Design and Implementation of Grip: a Computerized Glucose Control System at a Surgical Intensive Care Unit

Background: Tight glucose control by intensive insulin therapy has become a key part of critical care and is an important field of study in acute coronary care. A balance has to be found between frequency of measurements and the risk of hypoglycemia. Current nurse-driven protocols are paper-based and, therefore, rely on simple rules. For safety and efficiency a computer decision support system that employs complex logic may be superior to paper protocols.


Background
Critically ill patients often suffer from 'stress hyperglycemia', a condition in which insulin resistance due to increased catecholamine levels causes high blood glucose values [1]. The association between stress hyperglycemia and adverse outcome has been observed in numerous patient categories, ranging from patients admitted to the general ward [2] to myocardial infarction [3] and stroke patients [4]. For decades, stress hyperglycemia was thought to be merely a marker of disease, and was tolerated as long as glucose levels were not excessively high (e.g., over 11.0 mmol/L). The publication of the Leuven intensive insulin therapy study in September 2001 caused a paradigm shift in critical care medicine [5]. This study showed that rapid lowering of blood glucose levels below 6.1 mmol/L and subsequent maintaining of normoglycemia reduce mortality and morbidity markedly. These results were confirmed by a before-after study performed by Krinsley, in which also a decrease in mortality was achieved with tight glucose control [6]. Especially for septic patients, guidelines now recommend using insulin to reduce high glucose levels [7]. However, infusing insulin in order to lower glucose levels bears the risk of inducing life-threatening hypoglycemia, especially in sedated patients admitted to an intensive care unit (ICU). In order to cut back this risk, glucose levels must be frequently measured. Each measurement calls for a decision on what action to take to keep glucose levels in the normal range. With recommended sampling frequencies ranging from every 1 -2 hours to every 6 hours, implementation of tighter glucose control poses an important logistic challenge. Many investigators have proposed nurse-driven protocols for glucose control. After each glucose measurement, simple if-then rules or lookup tables yield an advice on how much insulin needs to be administered [8][9][10]. Even though glucose sampling frequency is high, reduc-tion of hyperglycemia is often not satisfactory, and, more important, hypoglycemia is relatively common [9]. Glucose metabolism is also an important topic in acute coronary care. Several studies have evaluated glucose-related therapies as strategies to improve outcome in acute coronary syndromes, such as high dose glucose-insulin-potassium (GIK) infusion [11,12], or combined glucoseinsulin infusion to reduce glucose levels [13,14]. Although clinical results have been mixed, with most recent results being negative, the efficacy of glucose-lowering interventions in acute coronary care is still unknown since none of the published trials achieved tight glycemic control [11,14]. Because coronary care units (CCU) are a less controlled environment with a lower personnel-topatient ratio than ICUs, intensive insulin therapy is hard to achieve with paper protocols [14]. An optimized decision making algorithm might be able to make tighter control possible.
We hypothesized that a computer program can employ the necessary complex logic to achieve the desired level of both safety and efficiency of glucose control without excessive glucose sampling frequencies. In the beginning of 2003 we initiated development of a computer controlled decision support system.

Design rationale
We conceived the computer decision support system (CDSS) to be used primarily by nurses. Our first implementation site was our 12-bed surgical ICU at a tertiary teaching hospital, and we planned for future implementation at other ICUs and at the CCU. A thorough analysis of factors which lead to successful CDSS deployment and usage has previously shown integration of the system into routine clinical workflow to be of paramount importance [15]. Automatic provision of a concrete recommendation instead of merely an assessment of the situation, and provision of decision support at the time and place of decision making were other elements that were highly predictive of successful implementation. Figure 1 shows the different steps a nurse takes when performing glucose control. Repetitive glucose measurements are followed by appropriate action to maintain normoglycemia. At our surgical ICU, as well as at the CCU, blood glucose values were determined by a point-of-care blood gas analyzer, giving a very short delay between blood sampling and availability of the glucose value (~2 minutes). As most nurses wait at the point-of-care analyzer until the result of the analysis is known, a computer situated next to the analyzer was the ideal spot for the system to interact with the nurses and to give its recommendations. This ensured an easy integration in standard clinical workflow, and made sure that the recommendations were provided to the responsible nurse at the place and time when needed. Figure 1 Glucose control cycle. Nurse-driven glucose control consists of the repetitive execution of the cycle depicted in this figure. First, the nurse acquires blood from the patients and gets the glucose level. A protocol or doctor then decides what action should be taken (in most cases a change of the rate of the insulin pump), and subsequently this action is performed at the bedside by the nurse.

Glucose control cycle
The project was named GRIP (Glucose Regulation for Intensive care Patients). One of the key design principles was that the output should be regarded as recommendations, not as orders. The recommendations that GRIP gives could be overruled at any time. If overruled, GRIP continues to give meaningful advice the next time (as long as it knows that its recommendation was not followed, and what action was taken instead). In this way, GRIP remains usable in various unforeseen situations.

Technical design
A high-level overview of GRIP's design is shown in figure  2. To enhance safety and facilitate user acceptance, all information that was available in the central hospital database was queried from there and not from the nurse. To ensure correct glucose values, each glucose value that was retrieved from the laboratory system required a validation from the responsible nurse. In this way, measurement errors, patient swaps, and other mistakes were prevented from disturbing the decision making of GRIP. After each glucose measurement, a number of clinical variables were queried from the nurse (table 1). The commu-nication with the hospital database was designed using standard communication protocols such as Health Level 7 (HL7). Data collected and computed by GRIP, as well as error messages, were stored in a relational database using standard query language (SQL) queries. Being in a database system, the data was easily accessible for special-purpose applications, such as a report generator for periodic auditing of quality of glucose control or other aspects of GRIP, or for a data extraction program for purposes of research. Most data in the database was stored as pieces of eXtensible Markup Language (XML), which facilitates extension of data storage in the future.

Recommendation generation algorithm
Recommendations generated by GRIP mainly consist of two parameters: the recommended insulin pump rate and the time at which the next blood sample should be taken. Also, in special cases (currently on occurrence of glucose values > 15 or < 4 mmol/L) the recommendation is accompanied by a request to consult the attending physician. On low glucose levels (< 3 mmol/L) the 'hypoglycemia advice' is given, which consists of an intravenous glucose dose, an insulin pump rate of zero, and prompt notification of the attending physician. Our current implementation of GRIP is based on the use of continuous insulin infusion and does not recommend boluses of insulin. It has been observed that due to a saturation effect, continuously infused insulin is more effective than boluses of insulin [16].
We will briefly describe the algorithm for pump rate. We hypothesized that by using solely the most recent glucose value, efficient glucose control is hard, if not impossible, to achieve, and chose to include rate of change of glucose as secondary parameter. The basis for our pump rate algorithm is the following formula: In this formula, ∆I is the proposed change in pump rate, is the mean pump rate over the 4 hours preceding the last glucose measurement, G 0 is the most recent glucose value, G target is the target glucose value, and ∆ -4h G is the change in glucose level between the last glucose value and the value 4 hours earlier (this value is linearly interpolated). The first term of the formula ensures that when a patient receives a high insulin dose, the change the algorithm suggests will be larger than when the current dose is low. The formula exhibits two interesting properties. First, the algorithm needs an explicit target blood glucose level to aim for. As the optimal blood glucose target is still subject to discussion, we have set this value to 6.5 mmol/L High-level overview of GRIP Figure 2 High-level overview of GRIP. Grip contains four major components: a component to interface with the hospital information system, a component to interface with the nurse, a component that calculates the advice that GRIP gives, and a component that logs errors and stores all data GRIP generates. HL7 : Health Level 7. SQL : Standard Query Language. [17,18]. Changing the target to a different value would be easy to accomplish. Second, the algorithm only uses data from the most recent four hours. As a consequence, potentially valuable preceding data are ignored and oscillation of glucose levels may be induced by the short time interval. However, we decided in favor of this short interval because of its robustness to sudden changes. In case of a sudden increase or decrease in insulin sensitivity due to some clinical event unknown to GRIP, the preceding glucose and insulin values become less relevant, or in the worst case even misleading to the recommendation algorithm. Therefore, provided glucose is sampled sufficiently often, the short lookback time makes quick adaptation to new situations possible. In our implementation, the result of the aforementioned formula is only an intermediate result. Decreases in enteral or intravenous glucose administration as filled out by the user automatically lead to a proportional reduction of the dose recommendation, e.g., if the patient received 64 ml/hour of enteral feeding and this is lowered to 16 ml/hour, the advised pump rate will, depending on other factors, be decreased by approximately three quarters. To improve user acceptance, recommendations lower than 0.3 units/hour are converted to 'no pump'. The final recommendation is generated after applying a number of safety measures, the most important being the limitation that GRIP never recommends a pump increase of more than 1.5 units/hour and never recommends pump rates over 10 units/hour. Saturation of the effect of insulin provides another argument for limiting the pump rate [16,19].
The algorithm that calculates the desired time of the next glucose measurement is considerably more complex. Its main feature is a calculated measure conceived to quantify the risk of hypoglycemia. The following measures lead to a higher predicted risk of hypoglycemia, and consequently to a shorter interval to the next advised glucose sample: high insulin pump rate, high recommended pump increase, fast glucose decrease (as measured by the extrapolated glucose in 4 hours, derived from the current glucose value and the current ), low or decreasing glucose intake, and occurrence of recent low glucose values. The maximum advised glucose sampling interval is 12 hours, and the minimum interval is 30 minutes.

User interface
A graphical user interface was designed to both acquire clinical information from the nurse and communicate advice to the nurse. To make user input as simple as possible, all filled out information is automatically filled in with the previous values so that only changes require user action. Figure 3 shows the main screen of GRIP. This screen provides a quick overview of all patients. Figure 4 shows the screen providing details for one patient. The required action which a nurse should take was divided in three steps: 1. Take a blood sample and analyze it. Clicking the button in GRIP makes GRIP query the hospital information system to see if it can retrieve the new value.
2. Review the current information of a patient and update this information if changes have occurred. This step also includes validating each newly acquired glucose measurement.
3. Review the insulin pump advice given by GRIP and tell GRIP whether it was accepted and executed or, if not, what the new insulin pump rate is.
∆ ∆ glucose t These three steps normally follow each other in order, but each step is also immediately accessible without following the previous steps (e.g., a physician who changes an insulin pump could immediately tell this to GRIP by taking step 3, without the need to first take blood, etc.)

Hardware and availability
The program was designed to run on a standard commodity personal computer, situated directly next to the pointof-care glucose analyzer for optimal integration in the clinical workflow. The program was developed in Java, a freely available multi-platform language. Because MySQL ® (a freely available open-source database server) was chosen as the database system, the entire system can be run using only free software. Upon completion of a new feature-complete version scheduled for the beginning of 2006, GRIP will be released under the open source Gnu Public License [20], and will be downloadable from http:/ /grip-glucose.sourceforge.net. This means GRIP can be used by anyone free of charge.

Evaluation of the system
Glucose control before implementation of GRIP was performed by a sliding-scale paper protocol. This protocol advised an insulin pump rate which was based on the last measured glucose level. Measurements were taken 4 times a day at a fixed schedule. When needed, the scheme was adjusted for individual patients on a daily basis. The medical staff of the ICU was informed and unanimously agreed to gradually implement GRIP. Since the move from conventional practice to GRIP constituted an organizational and logistic change that aimed to improve existing and accepted medical practice, approval by the medical ethical committee or patient consent was deemed unnecessary. To get a basic idea of control achieved by the system, we recorded all glucose measurements of all patients during the first 4 month period in which GRIP was in effect. We also retrieved age, reason of admission, history of diabetes, APACHE II score, and both ICU and hospital mortality for these patients. Safety of control was assessed by checking all patients for occurrences of severe hypoglycemia (< 2.2 mmol/L) or mild hypoglycemia (< 3.5 mmol/L). To assess the ability to reduce hyperglycemia, all patients staying longer than 24 hours were analyzed. As the target level was 6.5 mmol/L, we defined a target glucose range of 4-7.5 mmol/L. For each patient, we determined how much time the glucose levels were within this target range and we represented this value as the fraction of the entire length of stay. We determined the time from admission to the first glucose under 7.5 mmol/ L, and calculated median and interquartile range for glucose levels at 6-hour intervals for the first two days. Finally the hyperglycemic index, a measure indicative of overall hyperglycemia that is not lowered by hypoglycemic episodes, was calculated for each patient [21].
Patients at the ICU were enterally fed as soon as possible. When enteral feeding was not possible for prolonged periods, total parenteral nutrition or concentrated glucose infusions were started at moderate doses (100-200 grams per day).
User acceptance was assessed by a questionnaire. Nurses were asked to fill out the questionnaire 1 month before and 6 months after implementation of GRIP. The questionnaire held 6 months after implementation of GRIP contained a number of questions asking for a direct comparison between working with GRIP and working with the paper protocol.

Statistical analysis
For the nurse questionnaires, a 7 point scale of agreement was used. Differences before and after usage of GRIP were tested with the Mann-Whitney U test. All data are presented as median (interquartile range). Statistical analysis Figure 3 Main screen of GRIP. The main screen of GRIP. An overview of the ICU is shown replicating the arrangements of beds on the floor. Beds have colors according to pending action: green -no action has to be taken, orange -action has to be taken and a small icon indicates what action, in this case a new glucose value was detected in the hospital data system, which needs a validation from the nurse, and red -urgent action required, for example occurrence of hypoglycemia, or an advised measurement that is more than 30 minutes late. Each bed shows the current insulin pump rate, the most recent glucose value and the time it was taken, and the time the next glucose value needs to be taken. Empty beds are shown in grey. Each bed is clickable to yield a more detailed information panel shown in figure 4.

Implementation details
Implementation of GRIP began in the beginning of 2003. In the fall of 2003 an initial version of GRIP was tested for three weeks at the surgical ICU without nurses or doctors following its recommendations. Nurse feedback indicated that this test version's user interface was insufficiently intuitive. In November 2004 the final version of GRIP, including the improved user interface as described in the methods, was deployed. First it was monitored for 6 weeks, while the regular paper protocol was still followed. In the next two weeks we started following GRIP's recommendations, gradually increasing its usage bed-by-bed. From January 2005 on, insulin therapy of patients on all beds was determined by GRIP. During the first weeks of deployment a number of small changes to solve trivial problems were needed. Thereafter, two major problems have occurred. First, the computer running GRIP experienced a sudden complete hard-disk crash in April 2005, losing all data. Using our automatic daily backup, the system was up and running again within 6 hours, with less than 24 hours data loss, which was easily reentered into GRIP from the charts. The second problem was the transition to daylight savings time. This was handled correctly by GRIP, but unfortunately the central hospital system only picked up the correct time later during the next day. Before the central system was adjusted to the proper time, all measurements appeared to GRIP one hour later than they actually were. Apart from inconvenience to the nurses, these problems caused no misleading recommendations or dangerous situations. Currently, the system has been running without interruption for over 3 months without any change, maintenance, crash or other problem. A number of other problems have occurred, all external to GRIP, which would have affected a paper protocol equally as much as it affected GRIP. These included measurements that failed to be included in the central hospital database and malfunction of the point-of-care analyzer. After these problems were resolved and GRIP started receiving correct data again, its recommendations could immediately be followed, because GRIP ignored the erroneous data.

Training of nurses
Basic data entry in GRIP proved to be very straightforward. Only data entry of events that happened in the past was not completely obvious. During the first 2 month observation period, residents were asked to perform data entry and as no recommendations were used, they could experiment and save any questions until the lead programmer (MV) was present at the ICU. When real use of GRIP by nurses was initiated, almost all residents knew how to work with GRIP and could provide explanation to nurses. The staff intensivist (MN) involved in the design of GRIP also provided explanation when asked. No special meetings for training had to be scheduled.

Safety and efficiency
During the 4-month period from January 1st to May 1st, 2005, 179 patients were treated at our ICU, for a total of 957 patient-days. Patient characteristics are shown in table 2. Severe hypoglycemia (< 2.2 mmol/L) occurred once in one patient (0.6 %). Analysis revealed that this was caused by a human error involving accidentally increasing the rate of the insulin pump. Mild hypoglycemia (< 3.5 mmol/L) occurred in 20 patients (11.2 %). 109 out of 179 patients stayed longer than one day at the   Figure 5 shows median and interquartile range of glucose levels during the first 48 hours of ICU stay.

User acceptance
Questionnaires were filled out by 32 nurses before implementation of GRIP and by 22 nurses after implementation. After deployment of GRIP, nurses judged glucose control to be running more smoothly than before deployment of GRIP (p < 0.001, figure 6). There was a trend towards nurses finding that glucose values are less often too high or too low. GRIP was judged as being simple to work with, and chosen almost unanimously as an improvement over the old paper protocol. Estimated time spent on glucose control per working shift was 10 (6 to 12) minutes before GRIP and 10 (10 to 15) minutes after GRIP (p = 0.13). Analysis of paired observations before and after implementation of GRIP revealed similar results. From the free text section of the questionnaire it was clear that the nurses found that GRIP was able to adequately manage glucose control in more patients than the paper protocol. Nurses therefore did not need to call the attending physician as often as before and thus were able to devote more time to other tasks.

Discussion
In this report we present GRIP, a computer decision support system for glucose control by intensive insulin therapy. This system was successfully implemented at a surgical ICU, and was found to provide safe and efficient glycemic control. User acceptance, an important hurdle for successful implementation of a clinical decision support system, was excellent with minimal training. Nurses clearly rated GRIP as an improvement over the conventional sliding scale protocol. GRIP will be released under an open source license and will thus be free to use and improve by anyone in the future. We think especially GRIP's independence of a patient data management system (PDMS) is a strong point that makes it widely usable. At ICUs where a PDMS is already operational, GRIP might introduce double data entry. However, this can be easily resolved by either letting GRIP query the PDMS for information or by converting GRIP's advice module into a plug-in of the PDMS.
The efficiency and safety of control achieved by GRIP's current relatively simple algorithm was satisfactory. In the Leuven study, a mean glucose level of 5.7 mmol/L was achieved in a cohort of patients with a median APACHE II score of 9 [5]. Krinsley  During the design of the current recommendation algorithm a number of arbitrary decisions were taken. Based on experience, we chose to include glucose value and glucose difference as the two most important determinants of advised pump rate, and we chose to limit pump rate to 10 units per hour. Although evidence for the rationality of the latter decision exists [16,19], most decisions were taken purely based on prior experience in controlling glucose levels. Our results show that this algorithm gives satisfactory results, but we are aware that GRIP has the potential for substantial improvements in the future, as our choices are unlikely to be the most optimal. For example, the current algorithm is very cautious and only takes small steps when increasing the insulin pump rate, sacrificing rapid control in favor of safety. Analysis of the data that have been collected thus far may reveal situations in which the algorithm can safely take larger steps to achieve more timely glucose control. It will be interesting to analyze differences between groups of patients with respect to factors such as reason of admission, presence of diabetes, and concomitant drug use. This will allow glucose control to transition from the current general "one size fits all" approach, which uses the same advice for every patient, to a more tailor-made approach, which makes use of as much information as possible to make its advice fit an individual patient's needs. As the advice generation module can be changed without affecting the user interface, algorithm improvements can be implemented without additional training of the nurses.
Prior studies have evaluated different types of computer systems for glucose control in critically ill patients. A number of studies have evaluated feasibility of continuous glucose sensors, which in theory provide ultimate efficiency and safety of control. However, apart from the obvious extra costs, continuous sensors have been found to lack reliability, requiring frequent replacements of the sensor, and report inaccurate data in the hypoglycemic range [22,23]. We believe that for the foreseeable future, the vast majority of glucose control schemes will still employ sequential discontinuous measurements. Chase et al. have worked on developing models for accurate insulin dose prediction in critically ill patients, but with 2 measurements per hour, measurement frequency was much higher than GRIP's [19,24]. Rood and colleagues have previously investigated computerizing guidelines for glucose control and found that glucose measurements were taken at the prescribed time more often, and glucose control improved in comparison with the preceding paper protocol [25]. Unfortunately, a PDMS plug-in with an undisclosed 4-page flowchart was used, limiting widespread usability, and in our opinion a formula-based approach as taken by GRIP will be easier to optimize and customize to different patient groups than a flowchartbased set of rules. Naturally, in case the latter approach may prove to yield better control, GRIP's advice generation module can be easily altered to follow that approach. We are currently in the process of starting implementation of GRIP at other ICUs. Furthermore, we are implementing GRIP in the coronary care unit. We consider a personalized algorithm to be the key to more efficient and safe glucose control in acute coronary care.

Conclusion
GRIP, a computer decision support system for glucose control by intensive insulin therapy, exhibited efficient glucose control without inducing severe hypoglycemia during a 4 month period. Acceptance by nurses was excellent, with minimal training needed. GRIP will be released as free/open source software.