Human-in-the-Loop Insulin Dosing

Abstract

The last ten years of efforts in developing automated insulin dosing systems have led to one hybrid closed-loop device in the US market with more in the late stages of development. Much of the focus has been on algorithms, including closed-loop, detection of sensor and pump faults, and safety. There has been less discussion in the open literature about user interface design and related options. This article provides perspectives on automated insulin delivery (AID) system design by analyzing commonly used devices, such as bicycles and car entertainment systems. The recent Boeing 737 Max 8 disasters are used to highlight related challenges with AID systems. The role that system engineers can play in the do it yourself artificial pancreas system movement is also discussed. The human-in-the-loop remains by far the most important “component” of any AID system.

Background

This commentary is based on a presentation that I made during a panel discussion on “Real-World Outcomes with Diabetes Devices: How Can We Improve?” at a meeting hosted by the JDRF, Helmsley Trust and NIH at the June 2019 ADA meeting. As the engineering representative on the panel, I decided to use some typical devices that everyone is familiar with to illustrate some of my points. Redundancy and user interface design are illustrated through bicycle and automobile radios, respectively. This commentary is not meant to be comprehensive review of the current automated insulin delivery (AID) devices, but rather to provide “food for thought” about device design.

Introductory Example of Redundancy: A Bicycle

As an engineer and avid bicyclist, I am a strong believer in redundancy. While I enjoy road riding for speed, I also use my bicycle to commute to and from campus. Particularly since my commuting sometimes occurs at night, it is important to always have charged headlights and taillights available, thus I use two headlights (Figure 1(a)) and two taillights (Figure 1(b)). Also, since I may wish to wear regular shoes or hiking boots, rather than bicycle shoes with cleats for “clipless pedals,” I have two-sided pedals, one with a platform useful for any shoe and the other side with an attachment for the shoe cleats for additional power on the upstroke (and thus additional speed) (Figure 1(c)).

Figure 1.

Illustration of redundancy on a bicycle: (a) two headlights, (b) two tailights, and (c) two-sided pedals (one platform, the other “clipless”).

Clearly, there are tradeoffs made in selecting components for a bicycle. The additional components mean extra cost and weight, so the bicycle will not be as fast as possible. Tires useful for gravel, and potholes, will not be as fast as road tires on smooth pavement. Having two headlights is only beneficial if you are assured that when the battery in one headlight dies the other one has enough charge to operate. So, the flexibility and the redundancy come at a cost (financial or personal time). The same is likely to be true of AID systems—additional sensors add redundancy, yet possibly require additional calibration and tracking of the sensor state of health. Similarly, the addition of glucagon may improve glucose control performance, but incurs additional capital and operating costs and another component that could fail.

Human-Machine Interfaces

While much of my travel is by bicycle and mass transit, sometimes I must drive an unfamiliar automobile. Usually, my goal is to go safely from point A to point B, but I would also like to listen to music on the radio. In the 1960s and 1970s, this was quite easy—all radios had the same design with a tuning knob on one side, a volume knob on the other, and pushbuttons tuned for specific stations (see Figure 2). No matter what car you drove, you would immediately know how to make the radio work and could make changes in the volume or station without taking your eyes off the road. Imagine my frustration when driving a car with the interface shown in Figure 3. I must take my eyes off of the road to find the “audio” button, which when selected (using a touchscreen) will lead to other touchscreens before I can select a radio station. If I have already started driving before turning on the radio, in the interest of safety, I usually complete the drive without the radio. My annoyance with these interfaces is shared by others that have similar safety concerns,^1,2 not only with entertainment systems but the design of transmission shifters as well.

Figure 2.

Typical radio from the 1960s and 1970s.

Figure 3.

Interface for a new Toyota Prius Prime.

The message related to AID is that more information and options are not necessarily better. Some people may prefer minimal information and interaction with their devices; this may also be situation dependent. If different interfaces (and system performance criteria) are used by various individuals, this puts additional pressure on physicians and their staff to keep up to date with many systems and options. Irl Hirsch noted in his presentation and panel discussion that many health care systems reimburse physicians and nurse practitioners based on relative value units, and that they might be able to spend only 20 to 30 minutes with each patient; how can they possibly provide advice on the use of AID along with all of the other health-related matters that need attention?

Safety

I have previously discussed safety in AID by comparing methodologies used in aircraft and chemical process systems.³ During the past year, there were two crashes of Boeing 737 Max 8 aircraft within a five-month period (Lion Air Flight 610, October 29, 2018 and Ethiopian Airways Flight 302, March 11, 2019) killing 346 people.⁴ A major contributor to the crashes was the Maneuvering Characteristics Augmentation System (MCAS), which was designed to reduce the risk of a stall condition^5,6; see the appendix for more details. While the aircraft might actually be horizontal, if an angle of attack (AoA) sensor has a false high reading, the MCAS can activate and force the nose down; naturally, the pilot would react by bringing the nose back up. Such an occurrence is clearly seen in data from the first crash (Lion Air), where the oscillatory behavior is induced by the pilot “fighting” the control system⁷ (see Figure 4), culminating in a nose drive. Unfortunately, this could have been avoided had the pilot realized that he could switch off the MCAS.

Figure 4.

Trajectories during the crash of Lion Air, October 29, 2018. Plots from Satcom Guru,⁷ annotated.

The MCAS antistall algorithm was only active if the pilot selected manual control; this is counterintuitive since the pilot has every reason to believe that they have full control of the actuators while in manual mode. While the aircraft had two AoA sensors, only one was active at a time, depending on which of the redundant flight computers was in control. It is also hard to understand why Boeing did not include the two sensors in a fault detection system that would provide a warning and deactivate the MCAS. It is possible that the relationship between Boeing and the FAA was too “cozy” resulting in a less than critical analysis of the algorithmic changes. It is easy for this situation to arise because, after all, who understands the aircraft better than personnel associated with the aircraft?

The relation to AID is several-fold. If redundant, but conflicting, CGMs are used, one reading high and the other reading low, what is the safest control action? Should more insulin be given in response to the high reading, should insulin be shut-off in response to the low reading, or should the system default to a preprogrammed basal level? Because the greatest short-term risk is hypoglycemia, most people would select to either shut-off the insulin delivery or allow it to default to basal mode. Also, if the system is in manual mode, should a low glucose suspend algorithm be active? In the process industries, safety instrumented systems always have the priority to “take over” no matter what is active at the higher levels. As another example, even home furnaces have a flame detector that shuts off gas to the furnace if a loss of flame is detected. My experience is that the flame detector itself can fail, but the fail-safe mode shuts off gas to the furnace even if there actually is a flame—thus a certain false positive rate must be tolerated to assure a high true positive rate.

On May 17, 2019, the FDA issued a warning about the use of unauthorized devices for diabetes management.⁸ Apparently, this was based on the use of an FDA approved sensor that had been combined with an unapproved transmitter (and algorithm) to communicate the sensor signal, which was used by an unapproved (do it yourself [DIY]) AID algorithm. It appears that the transmitted glucose value was falsely high for an extended period of time, and the AID algorithm continued to dose insulin based on the high reading, leading to a severe hypoglycemic event. A clear explanation of this event is given by Katie Disimone⁹ who also cites a similar event posted on the OpenAPS Github Repository. She rightly notes that a continuous glucose monitor (CGM) is more than a raw sensor signal and includes checks to confirm the validity of a glucose estimate.

Indeed, any control system is composed of many layers, with the most important one being a safety layer that confirms that sensor signals are valid, communication with sensors and actuators are valid, etc. Fault detection techniques can be used to open the loop and provide a warning. For example, a signal (particularly one as variable as glucose) should be checked for being “too consistent.” Analytical redundancy uses a model to detect inconsistency between the GGM and insulin infusion rates; our experience is that these algorithms work even better under closed-loop control.¹⁰

Do It Yourself Open Artificial Pancreas System (OpenAPS) Movement

The DIY open artificial pancreas system (OpenAPS) movement has yielded some impressive results, in sheer person-hours of feedback control,^11-15 through OpenAPS, AdroidAPS, and Loop¹⁶ platforms. My feeling is that the movement can benefit from contributions by systems and control engineers in several areas. To begin with, the “Loop” algorithm is a form of model predictive control (MPC), which has been extensively studied and analyzed for the past 40 years. The Loop algorithm is essentially solving a “coincidence point” MPC problem, that is, the insulin control moves will achieve a desired (model predicted) glucose value at a specific point in the future (prediction horizon or the end of the insulin time-action profile).¹⁷ The way the Loop problem is formulated means that an optimization problem does not need to be solved, in contrast to classic MPC problems. The Loop algorithm also realizes that models are not perfect, so there are several terms to compensate for what control engineers call “plant-model mismatch” (the difference between actual CGM measurements and the model predictions); this is one area where the Loop algorithm could take advantage of developments in the MPC field. Also, all closed-loop systems have multiple safety layers and often include “data reconciliation” or “fault detection” algorithms; again, these are areas well-studied in the systems and control community.

There are a number of clear benefits to the open source approach taken by the DIY community. The objectives, approach, models, and algorithms are clearly stated and easy to understand, which also makes it easier for people with a particular expertise to contribute code for particular components (control algorithms, fault detection, user interface, etc.). The downside is that someone without as much experience may modify the code for their personal device, yielding results that may not be intended.

Human-in-the-Loop

My introduction to type 1 diabetes was in 1977 when my sister was diagnosed at the age of 11. In our small town, there were not many physicians who understood the disease and my mother quickly became the decision support system for my sister. Offhand, there were some good aspects to being diagnosed during that era—I do not recall many questions about whether that was the “good” or “bad” diabetes, and there were not suggestions that it could be cured by including cinnamon in her diet.

Certainly, the state of art in diabetes technology has changed during the intervening 42 years. Remember that self-monitoring blood glucose meters were not yet available, syringe technology was relatively crude and rapid-acting insulins did not exist. My sister has had an insulin pump for over ten years and started closed-loop control using a commercial device about two years ago. I asked her to make some comments about her experiences and they were

• Oh it’s definitely improved life for me!

• The only problem I have with the AP is that it is very slow to correct unexpected highs—so much so that it’s usually best in those situations to switch back to manual for a while. I know—it’s a safeguard, but still annoying!

• I’m thrilled with every (seemingly) small advance—even the small change in shape of the tape was a great improvement!

• My only suggestion probably wouldn’t be desired by everyone, but wearing my pump via clip on waistband or pocket, I find myself constantly reading it & dosing, etc. upside down rather than unclipping.

One key point is the frustration with conservative feedback control algorithms that have a very slow return from high blood glucose values, causing her to “open the loop” and provide extra insulin manually. We found similar frustrations during our clinical trials—individuals who are diligent about estimating carbs, providing meal boluses and compensating for exercise could become frustrated when in closed-loop mode (without meal announcement), because of slow performance compared with feedforward control (meal announcement). I note that there is potential to use adaptive learning and other techniques that observe the actions taken (insulin infusion rates delivered) while in manual mode to improve closed-loop performance. We also know, anecdotally, that patients using a commercial closed-loop system will sometimes enter “phantom carbs” to provide extra insulin while remaining under closed-loop control.

I should note that frustrations with automatic control can be observed by operators in chemical process manufacturing plants—when transitioning to different operating conditions (different temperatures), they often switch to manual control and make more vigorous adjustments to the actuator.

Her other points concern nonalgorithm-related usability of the devices, including how the pump clips on the waistband. Clearly, the interface was not designed to be used in this “upside down” mode. Perhaps, future generations of interfaces could include accelerometer sensors to detect orientation, much like tablet computers.

Incorporating Additional Sensors

The necessary components of an AID system are a CGM, an insulin pump, and a control algorithm (and related safety components), which can reside on a separate device (such as a smartphone) or on the pump. Multiple CGMs, of different types (optical and electrochemical), are under development and add redundancy.^18,19 Improved closed-loop performance is possible if other sensors are used, particularly accelerometers for exercise (and sleep) detection.^20-22 Further, accelerometers (and gyroscopes) in a wristwatch worn on the dominant hand can be used to detect meal motions to provide an advisory “meal announcement.” Exercise and meals can also be anticipated based on history, GPS, and calendar information and using artificial intelligence and deep learning techniques.²³ Clearly, all of this comes at a cost in battery life and system complexity, and many individuals may not desire this (particularly those that prefer minimalistic radios from the 1960s).

The focus of this article has been on single hormone (insulin) delivery. It should be clear that including glucagon can result in improved glucose control with increased capital and operating costs.

Other Considerations

I have worn CGMs and one of my main frustrations was with the tape that would quickly unravel; I finally started wearing the CGM on my arm and wrapping it with beige flexible tape! Thus, while there have been tremendous advancements in electronic device performance, there remain challenges in producing tape with the right “stickiness” characteristics when applied to skin. Thus, not all AID challenges are due to the use of “modern” technologies.

Summary

As more people with type 1 diabetes begin to adopt automated insulin dosing systems, there will be a need for these devices to be more flexible, that is, have interfaces and performances that are personalized. The current generation of systems has largely been tested on people that were highly motivated to participate in clinical trials, for example, and are likely to enjoy/tolerate frequent interaction with their devices. The AID research focus has largely been on the control algorithms to regulate blood glucose, first overnight (to prevent nocturnal hypoglycemia), then 24/7 to handle meals and exercise. Devices receiving FDA approval have received scrutiny on safety and performance that is as good or better than standard therapy, without as much focus on the device interactions.

It is quite a challenge to commercialize devices that have the flexibility for different interfaces and closed-loop performance requirements for different individuals. By nature, an individual preferring a minimalistic approach will need for that to be the default setup, rather than requiring multiple screens.

The control systems need to evolve to more explicitly include the “human-in-the loop” and tolerate (even take advantage of) their actions to achieve tighter blood glucose control. Improved safety layers deserve further consideration, particularly in DIY systems. The recently announced relationships among Tidepool, device manufacturers, and the DIY community can lead to rapid progress on this challenge. The involvement of systems and control specialists in this open source movement may also lead to increased safety and performance.

Appendix

Concise History of Boeing 737 Decisions

The Boeing 737 was designed in the 1960s, with a first commercial flight in 1968; over time, new models increased in size to accommodate more passengers. While the most successful commercial jet aircraft of all-time, Boeing recognized that they needed a new more efficient midrange aircraft to be competitive in the marketplace. Rather than designing a new aircraft from the ground up, which would take substantial time, in 2011, they decided to modify the design of the 737.⁵ The more fuel-efficient engines to be used were larger than the original design, requiring a different placement on the wing. The new engine placement led to increased risk of the aircraft nose lifting up, possibly leading to a stall condition. To avoid this, the Boeing engineers created a MCAS that relied on an “AoA” sensor to indicate the angle of attitude.⁶ If the sensor indicated that the plane was at too high of an angle for its speed, then the MCAS adjusted the horizontal stabilizer to force the nose of the plane downward. The algorithm was based on a timer that activated the stabilizers for a ten-second period, followed by no action for five seconds.

The original algorithm included both AoA and accelerometer sensors, but a last minute change eliminated the accelerometer and made the algorithm more aggressive by allowing more movement of the stabilizers. And, while there were two AoA sensors, apparently Boeing charged extra for AoA discrepancy lights, although some people in Boeing thought that there would be no charge for that minimal information. Further, Boeing was able to convince the FAA that there was no need to retrain pilots for the 737 Max 8, since changes were minor and the MCAS would be rarely activated.