Use of Case-Based Reasoning to Enhance Intensive Management of Patients on Insulin Pump Therapy

Abstract

Background

This study was conducted to develop case-based decision support software to improve glucose control in patients with type 1 diabetes mellitus (T1DM) on insulin pump therapy. While the benefits of good glucose control are well known, achieving and maintaining good glucose control remains a difficult task. Case-based decision support software may assist by recalling past problems in glucose control and their associated therapeutic adjustments.

Methods

Twenty patients with T1DM on insulin pumps were enrolled in a 6-week study. Subjects performed self-glucose monitoring and provided daily logs via the Internet, tracking insulin dosages, work, sleep, exercise, meals, stress, illness, menstrual cycles, infusion set changes, pump problems, hypoglycemic episodes, and other events. Subjects wore a continuous glucose monitoring system at weeks 1, 3, and 6. Clinical data were interpreted by physicians, who explained the relationship between life events and observed glucose patterns as well as treatment rationales to knowledge engineers. Knowledge engineers built a prototypical system that contained cases of problems in glucose control together with their associated solutions.

Results

Twelve patients completed the study. Fifty cases of clinical problems and solutions were developed and stored in a case base. The prototypical system detected 12 distinct types of clinical problems. It displayed the stored problems that are most similar to the problems detected, and offered learned solutions as decision support to the physician.

Conclusions

This software can screen large volumes of clinical data and glucose levels from patients with T1DM, identify clinical problems, and offer solutions. It has potential application in managing all forms of diabetes.

Introduction

Intensive glucose control in persons with type 1 diabetes mellitus (T1DM) has been shown to lower glycosylated hemoglobin (A1C) levels and reduce the risk of long-term complications.^1–3 To achieve intensive glucose control, multiple daily insulin injections (MDI) or insulin pump therapy, frequent self-monitoring of blood glucose (SMBG), and adjustment of insulin dosages based on this monitoring are required.^4–6 Continuous glucose monitoring systems (CGMS) have demonstrated improvements in glucose control, A1C levels, and the detection of hypoglycemic events in persons with T1DM on pump therapy.^7–9

Current glucose monitors and data management systems produce tremendous volumes of glucose data automatically. However, data must still be reviewed by health care providers so that appropriate adjustments in insulin therapy can be recommended. Figure 1 shows a typical display of SMBG data for a patient over 12 weeks as presented for review. Most glucose data management systems do not provide adequate information concerning life events, which are major factors contributing to abnormal glucose excursions and are needed to make appropriate therapeutic decisions. The fact that frequent SMBG (4-6 fingersticks per day) can achieve comparable glucose control or A1C levels to CGMS^7–11 indicates that there needs to be improvement in the ability to interpret the data in relation to life events. At the present time, there is a paradoxical situation of simultaneously having too much data and not enough data. For the diabetologist managing hundreds of patients with diabetes, this places a tremendous burden to review patient glucose records and make appropriate adjustments in therapy to correct the problems.⁵ This in turn, contributes to the “clinical inertia” in diabetes management^12–13 even for the most conscientious physicians.

Figure 1.

Data overload generated from frequent glucose monitoring.

This study was conducted to develop case-based decision support software to enhance glucose control in persons with diabetes. Case-based reasoning (CBR) is an artificial intelligence (AI) approach that capitalizes on experience with past problems and solutions to determine solutions for current problems.¹⁴ In brief, a CBR system stores knowledge structures, called cases, into a case base. Each case is composed of three parts: the description of an actual problem, the solution that was applied to that problem, and the outcome of applying that solution to the problem. When a new problem is encountered, the system searches its case base for the most similar past case or cases. The solution to a similar past problem forms the basis for developing a solution to the current problem¹⁴. A CBR system derives its knowledge, and thereby its power, from its cases. Therefore, the quantity and quality of cases is paramount for successful system operation.

Case-based reasoning seems promising for diabetes management because: formal models or algorithms cannot yet adequately assist patients with T1DM in the outpatient setting; there is a large experience base of assisting patients with problems in blood glucose control; and CBR can integrate numeric data, such as blood glucose readings, with descriptive and personal preference data, such as work schedules and lifestyle choices.^15,16 The potential of CBR for diabetes management was first recognized by Bellazzi et al.¹⁷ While sharing common goals, our approach differs in that it considers life-event data, includes patients on insulin pump therapy, and uses CBR as the primary automated reasoning method.

Software currently available to T1DM patients in the outpatient setting is exemplified by that marketed by Medtronic MiniMed. Patients can download their pump and meter data to a central site, where they and their physicians can review it in log form or in various graphic representations. This software makes no attempt to interpret the data automatically or to provide therapeutic advice. Pumps include a “bolus wizard” that uses a numeric formula to recommend individual bolus doses for meals and corrections. In this study, software was developed to extend current capabilities by (a) incorporating additional lifestyle data and plotting this data graphically to facilitate interpretation by health care providers, (b) automatically analyzing the data and detecting abnormal excursions in glucose patterns, (c) learning the solutions that successfully correct the clinical problems detected, and (d) remembering which solutions work for a particular problem case. A preliminary report of this work has been presented in abstract form.¹⁸

Patients and Methods

This study was approved by Ohio University's Institutional Review Board and conducted to assess the feasibility of building an intelligent decision support system for patients with T1DM currently on insulin pump therapy. Twenty moderately well-controlled patients (average A1C level: 7.45%) were chosen for this initial 6-week study. We attempted to enroll 10 patients with excellent glucose control (A1C < 7.0%) and 10 patients with less than optimal glucose control (A1C between 7–9.5%). One to three patients participated at a time because of the tremendous volume of data that was being collected from each patient. The study differed from typical clinical research in that data were collected from patients solely to build cases, or knowledge structures, for a case-based reasoning software system.

Background data were collected from each patient and entered into an Oracle database. This included personal data, a diabetes history, occupational information, pump information, insulin sensitivity, carbohydrate ratios, A1Cs, presence or absence of diabetic complications, other chronic diseases, medications, family history of diabetes, and typical daily schedules for work, exercise, meals, and sleep. During the study, patients performed SMBG 6–15 times per day, and wore the Medtronic MiniMed CGMS for 72 hours or more on three separate occasions, at weeks 1, 3, and 6 of the study. The CGMS data was downloaded directly into the database.

Each day, patients manually entered their daily data into the database. These included daily SMBGs, meal and correction bolus dosages and waveforms, temporary basal rates, work schedules, sleep schedules, exercise, meals, infusion set changes, hypoglycemic episodes, menstrual cycles, stress, and illness. Patients were encouraged to enter additional narrative information about any miscellaneous events that they felt could be impacting their blood glucose levels. The data entry system developed for the study was Web-based, allowing anytime, anywhere access with any Web browser.

Two software tools were built to help physicians interpret the large volume of patient clinical data. The first was a simple written report displaying all clinical data during the period of time studied, along with each patient's basal/bolus insulin doses, carbohydrate ratios, and sensitivity index. The second was a graphic representation of the patient's blood glucose and life-event data in single-day snapshots that contained much more clinical information than any analytical software tool available to date. Figure 2 shows a typical daily screen shot from this graphic tool.

Figure 2.

Graphic representation of life-event data, glucose levels, and insulin therapy. The horizontal axis indicates time of day, and the primary vertical axis indicates blood glucose level. A secondary vertical axis marks the units of basal insulin infused per hour during the 24-hour period. Basal rates are indicated by the line at the bottom of the display. Temporary basal rates and suspension of basal infusions can also be depicted. Red markers indicate individual blood glucose measurements obtained from finger stick determinations at various times during the day. The CGMS glucose data, when available, was depicted in the center of the screen as a line superimposed on the SMBG data points. At the top of the graph are event markers for other types of clinical data collected, including time of awakening, timing of meals, snacks, exercise, work, and bedtime. Specific events such as hypoglycemic events, infusion set problems, date and time of infusion set changes, pump/infusion set failure, intercurrent illness, stress, or onset of menses can be documented graphically in relation to other life events and glucose levels. By clicking on any event marker, the health care provider could see additional narrative information displayed as it relates to a particular event. For example, clicking on the hypo event marker displays the time of a hypoglycemic episode, the blood glucose level, and the symptoms being experienced by the patient. Clicking on the hypo action marker displays what the patient did to correct the hypoglycemia.

Once a week, knowledge engineers met with participating physicians to review the patient data. Physicians would identify new problems, recommend therapy adjustments, and explain the findings to knowledge engineers, who would then structure these findings into cases. Following the meetings, physicians would contact patients concerning the observed events, ask for additional information concerning their cases, and then make recommendations for changes in therapy. At subsequent sessions, the effectiveness of solutions suggested would be assessed. The cases for the software system would then be updated accordingly.

At the completion of the study, the software was tested by rescanning all data collected to assess its ability to detect specific problems. Tests were conducted by removing some cases from the knowledge base and then using them as test cases. This is a standard approach used to test CBR systems, especially when it is labor intensive and time consuming to acquire cases. We are presently acquiring data from 60 additional patients on insulin pump therapy to test the system further. In this paper, we report on success at case building and problem detection.

Results

Twelve of the 20 patients who enrolled in the study completed the 6-week protocol. The eight patients who did not complete the entire study cited personal problems or lack of time to enter data as the major deterrents to their completion. Fifty cases of individual patient problems with their solutions and outcomes were identified. Twelve different types of clinical problems were identified from these patient cases. Software was developed to detect the 12 types of problems automatically and to offer intelligent decision support based on past experience.

Graphic Presentation of Clinical Data

The graphic presentation of clinical data in relation to glucose levels throughout the day was designed to facilitate rapid identification by physicians of clinical problems and to help physicians develop patient-specific solutions for each problem identified. Figure 2 illustrates the graphic presentation of clinical data. The narrative information was presented in specific event markers that could be clicked and viewed in relationship to the graphic data. The graphic presentation of patient information enabled physicians to visualize glucose values, timing, and dosages of basal/bolus insulin, and life events occurring prior to, during, and following a specific event. This enhanced the physician's ability to detect a problem, determine the potential causes and effects of life events on glucose levels, and see how the patient responded to the problem. This allowed development of case-based solutions intended to prevent or correct problems if they were seen again. Viewing data sequentially over longer periods also helped to identify recurring problems and verify if solutions previously suggested had prevented or reduced the probability of their recurrence. We were able to discover unique, recurrent problems that were previously unrecognized by either the patient or the physician.

To demonstrate the utility of this graphic presentation, we present three cases of problems detected and their corresponding solutions. Although we describe only one problem per screen to illustrate the process, we often noted multiple problems with the same patient on the same day, as seen in the illustrations.

Detection of Abnormal Glucose Patterns

Case 1: Nocturnal Hypoglycemia

The first example is for a 56-year-old female with T1DM since the age of 24, on an insulin pump for 8 years, and very well controlled. She has no long-term complications, and her A1Cs typically ranged between 6.5-6.7%. Following her first week of participation in the study, the knowledge engineers showed a graphic presentation of her CGMS records, SMBG records, and life-event data to the physicians for evaluation. The initial 72 h CGMS data (Figure 3) indicated that she was hypoglycemic all night long without sensing it. She noted that in the morning when she awoke she felt terrible and was “totally out of it” (hypo event marker). From her life-event data, it was noted that she was not eating a bedtime snack (meal and wake/sleep event markers).

Figure 3.

Case 1, nocturnal hypoglycemia.

Case 2: Overcorrection of Hypoglycemia Followed by Rebound Hyperglycemia

This is a case of a 56-year-old male who has had T1DM since the age of 17, on an insulin pump for over 10 years. He has mild microvascular complications, A1Cs < 7.0%, and his physician suspected frequent hypoglycemia. Indeed, he was noted to have frequent episodes of hypoglycemia followed by rebound hyperglycemia (Figure 4). During the episode depicted, the patient's blood glucose reading was 55 mg/dl, and he described symptoms of confusion, dizziness, weakness, and feeling sleepy (hypo event marker). The hypo action marker showed that he had treated his hypoglycemia by consuming 6 oz orange juice, a cup of yogurt, and some whole wheat sesame snacks. As a consequence, his glucose level surged to over 250 mg/dl.

Figure 4.

Case 2, overcorrection of hypoglycemia with rebound hyperglycemia.

Case 3: Overcorrection of Hyperglycemia

The third patient is a 36-year-old male with T1DM since the age of 15, on an insulin pump for 2 years, with A1Cs ranging between 5.9–6.7%. During his participation in the study, it was noticed that he frequently developed hypoglycemia following correction of hyperglycemia (Figure 5). Although no CGMS data is depicted, it was noted from his glucose and life-event data that he was treating the hyperglycemia by taking a correction bolus of insulin (bolus marker) and exercising vigorously (exercise event marker), resulting in hypoglycemia (hypo event marker).

Figure 5.

Case 3, overcorrection for hyperglycemia.

Case-Based Reasoning to Suggest Solutions for Abnormal Glucose Patterns

As the software was being developed, the clinical problems identified were stored along with their clinical solutions. Note that these solutions were individualized to the needs of each patient by the participating physicians. The clinical success or failure of each solution, once identified, was also stored as part of each case.

Solution for Case 1: Nocturnal Hypoglycemia

For Case 1, to prevent nocturnal hypoglycemia, the patient was instructed to lower her midnight to 7 a.m. basal rate by 0.1 unit/hr. (basal insulin display) and always eat a bedtime snack (meal and wake/sleep event markers). The outcome was successful, as both suggestions were taken by the patient and the problem did not recur in subsequent weeks (Figure 6).

Figure 6.

Solution for case 1.

Solution for Case 2: Overcorrection of Hypoglycemia Followed by Rebound Hyperglycemia

In Case 2, the solution suggested was to suspend the pump for 15 minutes, reduce the amount of carbohydrates consumed to 30 g, recheck the glucose in 15 min, and then restart the pump. A followup the week after showed that the patient had reduced carbohydrate intake and suspended the pump. However, he forgot to restart his pump for over one hour, which resulted in rebound hyperglycemia (Figure 7). Thus, the initial solution failed to prevent rebound hyperglycemia. An additional recommendation was made to set an alarm on his watch to remind him to restart his pump in 15 min. However, he did not suspend the pump with hypoglycemia again, fearing that he would forget to restart the pump due to cognitive symptoms of confusion, dizziness, weakness (Figure 4) associated with his hypoglycemia. He did reduce the amount of carbohydrates consumed to correct the hypoglycemia to 30 g, which in followup datasets was shown to be successful.

Figure 7.

Solution for case 2.

Solution for Case 3: Overcorrection of Hyperglycemia

In Case 3, the patient was overcorrecting for hyperglycemia by using both a bolus of insulin and then exercising vigorously. As a solution, he was told to skip the correction bolus of insulin if he intended to exercise. When he followed these directions, his blood glucose came down into the normal range (Figure 8). For most patients with T1DM, we would have recommended correcting the hyperglycemia with a correction bolus before exercising. However, visualizing the glucose, insulin bolus, and exercise data together enabled us to individualize the advice for this particular patient, who historically had responded well to exercise as a method to correct his hyperglycemia.

Figure 8.

Solution for case 3.

Software Capabilities

Figure 9 presents an overview of how the prototypical system operates. The system can now scan clinical data collected from a specific patient and automatically detect 12 different types of abnormal glucose excursions (Table 1). Problem detection routines were developed to find the types of problems most frequently encountered by physicians during the study. The system produces a list of problems detected for a particular patient and the frequency of each problem type (Table 2). The provider can then view identified problems on the graphic display with all life-event data available to facilitate interpretation. Specific event markers can be activated and narrative data analyzed to confirm that the problems detected are correct and clinically important and to look for potential other causes. On average, the software detected 29 occurrences of the 12 different clinical problems per patient in 6 weeks of data.

Figure 9.

Overview of system operation.

Table 1.

Abnormal Glucose Patterns Automatically Detected by Software

Hypoglycemia	Hyperglycemia
Awakening Pre-meal Post-meal Over-correction for low glucose Over-bolus with meal Pre-waking Exercise-induced	Awakening Pre-meal Post-meal Over-correction for high glucose Possible pump or infusion set malfunction

Table 2.

Problems and Frequency Detected for a Typical Patient During a Six-Week Period

Over-correction for hyperglycemia	21
Exercise-induced hypoglycemia	10
Pre-meal hypoglycemia	9
Post-meal hypoglycemia	7
Over-correction for hypoglycemia	2
Awakening hypoglycemia	2
Pre-waking hypoglycemia	1
Over-bolus with meal	1

Next, the provider may select any of the detected problems for further automated analysis. Once a problem is selected, the system searches the case base of learned clinical problems to find the most similar past problem or problems. The most similar problems are displayed and their solutions are offered as decision support to the physician. Providing successful therapeutic adjustments that were made for similar problems in the past may aid the physician in determining an appropriate recommendation for the current patient. The physician is left to decide whether or not, and in what form, the advice is given to the patient.

Patient Satisfaction

An exit survey was completed by the patients who finished the study. Patients spent between 15 and 60 min per day on data entry. Most characterized the online system as easy to use, but said they would prefer to have decision support available on their own medical devices, rather than via computer. Ten of 12 patients felt that increased contact with health care professionals during the study was beneficial in managing their glucose levels. All patients felt that immediate feedback by an automated system with advice concerning blood glucose levels would be beneficial. The majority would also adopt a therapy adjustment recommendation from a computerized system. This patient acceptance of automated intelligent decision support suggests that additional research in this area could lead to a practical tool for patients.

Discussion

Intensive glucose control in persons with T1DM places a tremendous burden on patients to document glucose levels, insulin adjustments, and life-event data contributing to recorded glucose levels, and on physicians to review these records and make appropriate therapeutic adjustments. As a consequence, many patients, even in intensive diabetes management programs, are not adequately controlled. Computerization of glucose data management has actually created the paradox of having too much data and not enough data at the same time. Surveys have shown that many physicians are overwhelmed by the volume of data and the time required to analyze it, and often do not attempt to adjust medications either during office visits or afterward.^12,13 Studies utilizing computer-driven insulin dosing algorithms have demonstrated improvements in glucose control in the hospital setting.^19–22 However, to date, algorithms available for patients or practicing physicians cannot predict the individual response to specific clinical situations nor remember the previous responses of a particular individual to similar situations.

This paper describes a prototypical case-based system that screens large volumes of glucose and life-event data obtained from persons with T1DM on insulin pumps in the outpatient setting. The system remembers recurring clinical problems that a patient has experienced and offers decision support to the clinician. The integration of life-event data, glucose levels, and basal/bolus insulin doses in a graphic presentation helps physicians identify glucose trends more readily and adjust therapy more effectively. As more patients are studied, additional cases will be stored in the case base and additional problem detection routines will be developed.

One of the weaknesses of the current prototype is the Internet-based data entry system. Patients with T1DM already spend inordinate amounts of time on diabetes self-care, averaging 2 hours per day.²³ Our patients felt that the time required to document the life events in this study was burdensome. A future goal is to integrate this data collection process directly into insulin pumps or glucose monitoring devices, and download data to the server daily or continuously, which would improve data entry accuracy and reduce time demands on the patient.

The long-range goal of this research is to design and implement software to analyze large volumes of patient blood glucose and life-event data automatically in order to detect abnormalities in glucose control more readily (especially recurrent problems) in persons with diabetes, as well as provide suggestions for therapeutic intervention comparable to those of a diabetologist. This would allow continuous detection and correction of problems in blood glucose control while decreasing physician workload. Initially, the software will help the health care provider manage multiple complex patients with diabetes. Eventually, the system could be loaded onto a patient device for continuous data analysis and real-time low-risk patient advice.

In the future, the technology could be applied to all forms of diabetes and potentially used in “regional diabetes data download centers.” These centers would receive data from large numbers of patients with all forms of diabetes, analyze the data, and make therapeutic suggestions to the primary care physicians. This could help overcome the clinical inertia for intensive diabetes management in general practice.^12,13

Conclusions

This paper presents the potential use of case-based reasoning to monitor large volumes of glucose and life-event data and enhance the management of patients with T1DM on insulin pump therapy. A case base of 50 problems in blood glucose control with their associated solutions was constructed. Prototypical software was built to detect 12 common problems in blood glucose control, help identify their causes, and offer solutions that have proven successful in the past to the physician as decision support in making therapy adjustments. In the future, once proven safe and effective, the software could be incorporated in patient devices to provide daily decision-making support in non-critical situations and to immediately alert physicians in critical situations.

Abbreviations

AI

artificial intelligence

CBR

case-based reasoning

CGMS

continuous glucose monitoring system

T1DM

type 1 diabetes mellitus

A1C

glycosylated hemoglobin; (MDI) multiple daily insulin injections

SMBG

self-monitoring of blood glucose

Funding

We thank Medtronic MiniMed, the Ohio University Russ College Biomedical Engineering Fund, and the Ohio University College of Osteopathic Medicine Research and Scholarly Affairs Committee for their support.