It’s the numbers, silly…
The first thing that anyone dabbling in looping needs to consider is that you need to know your numbers. That means plenty of testing. And when I say testing, that’s basal testing, I:C ratio testing and ISF testing. That means doing I:C and ISF at different times of day to confirm that you don’t get changes and therefore need to have them added differently.
Why’s this important? Well both Loop and OpenAPS work out your insulin adjustments using this data, and if it’s wrong, then both struggle to keep you in target and deliver a good result. Fortunately, Autotune from the OpenAPS stable make this much easier to handle, and is also integrated within OpenAPS.
So before you start looping, spend a couple of weeks capturing all your data (as best as possible) in NightScout, and then run Autotune on it. It will give you a very good estimate of the pump basal settings, ISF and Carb ratio that you should start with. But also remember that it’s only as good as the data it gets.
The second similarity is setting maximum TBRs. In both cases, it’s crucial to remember that setting max TBRs that are too high could be lethal. Only set them to something that you could recover from. Again, this is true whether you are looking at a commercial or open source system.
Using the Loops… OpenAPS or Loop?
Both Loop and OpenAPS have developed a long way in the past 12 months. To such an extent that there are now clear differences between the two, but both can achieve good results in different ways.
Much of the detail of the Loop algorithm is discussed in the Loop guide, available from the Loop Github, while Dana Lewis, Scott Leibrand have written up most of the detail regarding how OpenAPS and specifically oref0 works at OpenAPS.org and on the DIPYS blog.
From an end user perspective, there are a few key differences between the two that I notice in everyday life with the systems. They can be condensed down to three headlines, which is a significant change from a year ago. “Form“, “Function” and then “Interaction“.
Form
We all know by now, I hope, that the Loop algorithm runs in Loopkit, which is a fantastic piece of work from Nate Racklyeft and others to build an artificial pancreas framework that runs on the iPhone.
The form of Loop is excellent. It runs on an iPhone, uses the Dexcom G5 app (or G4 share) on the phone and handles everything in one easy package. It can be installed by anyone with access to a Mac and has a great GUI showing all the information you might need plus a bolus wizard that incorporates Insulin on Board (IOB) into the calculation, giving you the ability to manage your condition from the phone interface.
OpenAPS is designed to work with the pump and a range of different input methods. Most users use NightScout as the system for interaction with a rig (via a multitude of additional interfaces, such as pebble apps, IFTTT and others), however it’s also possible with an Android phone to have a set up where temp targets and glucose data (via xDrip+) can be provided without having any internet connection. Carb amounts currently have to be entered into the bolus wizard on the pump when offline, so although it doesn’t look as pretty as Loop, it can work effectively. Alternatively, when used online, Nightscout provides the ability to do all of these things.
Both systems are also capable of using the Medtronic Enlite glucose monitoring system, which takes away the reliance on Dexcom locally.
From a hardware standpoint, early in the cycle, the decision was taken to put the OpenAPS system on a separate bit of hardware, whereas Loop was built with the phone as the brain. The reason for this is that more flexibility can be exerted over how the operating system responds on a separate rig , whereas, on a phone, you are more at the whim of the phone/OS manufacturer.
Whilst Loop has always been portable as you only need a RileyLink, which has a long lasting battery, Explorer Board based OpenAPS rigs are also small. Side by side, with both using Dexcom G5, you can see that overall bulk is really pretty similar, and the only real difference is battery life in this scale set-up.
Function
Function is where the big differences between the two systems can be found and why Interaction is now an additional component.
The Basics
Both the Loop algorithm and oref0 (the original OpenAPS algorithm) have basic functionality that is straightforward and consistent across both. They observe the sensor glucose levels and based on a calculation looking out, predict future blood glucose based on insulin on board and then adjust current glucose levels to try and get future, predicted levels within the target range. Loop’s algo is detailed in the earlier linked guide, whilst the basic oref0 functionality can be found here, about halfway down the page. Both systems now have similar exponential insulin absorption curves following recent work, which is described well by Katie DiSimone in her blog.
Essentially, both use the bolus and temporary basal history, combined with DIA and published IOB curves, to calculate current net IOB and use this to determine a future glucose level. Whilst the algorithms both attempt to attain similar outcomes, they are different.
Both have a “deviation function” to determine whether glucose change is in accordance with the earlier algorithm and then modify insulin delivery if it is not.
In Loop this is called “Retrospective Correction” and works by checking back every time it makes a prediction. It logs the prediction it makes, and every time (every five mins) it makes a projection, it pulls the previous value from 30 mins ago, and includes the variation of that value from where the current status is to work out how far out it is and adjust insulin and future glucose level accordingly, decaying the variation over 60 mins.
In oref0, a term called “BG Impact” or BGI, which is simply the current insulin activity (first derivative of IOB) * insulin sensitivity, is first calculated. This represents the degree to which BG “should” be rising or falling, and can be directly compared to the delta between the current and last CGM reading, or an average delta over the last 15m or so. To calculate the deviation, oref0 does this comparison, between the 15m average delta in CGM readings and the predicted BGI. It then applies that deviation as an adjustment to the eventual BG prediction. This is based on the simple assumption that if BG is rising or falling more than expected over the last 15 minutes, that trend is likely to continue over the next 15-30 minutes, and the magnitude of the projected deviation is approximately equal to what was seen over the last 15 minutes.
As can be seen here, both are very similar. In its most basic implementation, oref0 also includes a function called Bolus Snooze, which stops the basic algorithm from issuing a low temp basal immediately after a meal bolus if glucose values don’t necessarily correspond to the input meal data.
Both also have the ability to set a temporary target glucose level to deal with either workouts (higher) or ahead of food (lower, which drives increased insulin to get the GLUT4 receptors ‘unlocked’).
In its predicted glucose model, Loop also includes a feature called “Glucose Momentum”, which takes the last 15 mins of readings and linearly projects them out for a further 30 mins with a decay to zero.
Both systems also have a dynamic carbohydrate absorption model which observes actual carb absorption versus a model that the algorithm holds and adjust insulin after eating accordingly. The initial models for carb absorption are slightly different across the two algorithms, with OpenAPS using a linear model and Loop using Gary Walsh’s carb absorption curves. We’ll talk a little more about dynamic carb absorption in the next section. In Loop this is known as Dynamic Carb Absorption and in OpenAPS it’s part of the Automated Meal Assist functionality.
That’s where the basics (and commonalities) end. The next steps for each are different and serve different purposes.
The more advanced functionality
The key differences between advanced functionalities lie in the core of the system and how they have developed over the past 12 months.
Loop
Loop’s advanced functionality is a bolus capability that allows a bolus to be provisioned based on net IOB and future predicted glucose levels. You can configure a threshold to not issue a bolus if the future predicted levels drop below a minimum level in the settings. The carb data that the code uses defaults to three hours, and uses Dynamic Carbohydrate Absorption to manage variation from this (it does so very well). Alternatively you can tell it a different value, with initial values set as 120, 180 and 240 mins and dynamic absorption will then manage based on this.
It’s worth bearing in mind that the initial bolus recommendation that Loop makes is based on the carb absorption data that is entered, so if you choose to allow the default setting (3 hours) on a longer absorbing meal, there is a risk of hypo if you follow the bolus advice, especially with Fiasp, and even with Dynamic Carb Absorption, it may not be able to handle the effects.
It’s great to be able to bolus from the phone, but this carb absorption guess can make initial use of Loop more difficult to come to terms with. If you get the carb absorption wrong, you can find yourself with either too much or too little insulin on board early on. This ends up in either highs or lows that shouldn’t really be occurring.
Dynamic carb absorption does mean that you no longer need to be wholly accurate in your carb estimates as Loop is able to pick up the slack when there is more or less carbohydrate on board.
Glucose Momentum is no longer considered in the bolus estimate.
Loop also uses Healthkit extensively, which means that you can use it with a food recording app to add carb content for meals by using those apps instead of Loop, which can be hugely helpful.
OpenAPS
OpenAPS’s key advanced features have changed in the past year and are now known as oref1 (as opposed to oref0, which only adjusts basal insulin). The key pieces of functionality are Unannounced Meals (UAM) and Super-Micro Bolus (SMB).
Simply put, UAM allows you to enter a bolus (usually via the easy bolus buttons on the pump), and OpenAPS will estimate your carb absorption based on the bolus size, then administer insulin according to how much insulin you gave yourself and what it sees in the glucose variation. To administer the insulin, dependent on what you have configured in preferences, it can use TBRs or SMBs.
SMBs are based on the concept of “Super Bolusing“, giving “micro” boluses in line with calculated insulin requirements and setting basal to zero. SMBs deliver the same quantity of insulin more quickly than TBRs, e.g., after eating, if OpenAPS calculates that you need further insulin, in the old model it would set a TBR for a 30 minute duration and then adjust that with every new blood glucose reading. In the new model, it evaluates the insulin requirement versus the constraints and then delivers a micro bolus. This means that you get more of the required insulin into the body earlier, and it therefore takes effect more quickly.
In the 0.6.0 version, which is the current master, this functionality has been enhanced (eSMB) such that the user can control the aggressiveness of the bolusing and it is possible, when using Fiasp, to not need to bolus, even for meals of 100g carbs.
Use of both these functions is controllable via the preferences file.
Offline
It’s worth noting that the above picture describes both my rigs. When I use Loop or OpenAPS, I am able to loop offline as well as online. I simply carry the rig/Rileylink and the phone.
All of my CGM is run from a Dexcom G5, and on OpenAPS I run it with xDripAPS as my glucose data source. This means that the Android phone is all I need to see the system. I have a small http server running on the rig that broadcasts to my cellphone over bluetooth and hot buttons that allow temporary targets to be set from the phone. I can enter any carb data from the pump. Whilst this isn’t as straightforward as it is with Loop, it does mean that I am unencumbered by needing a cellular or internet signal in order to loop.
Interaction
I’ve added this as a new section with this update to the page for good reason. The way you interact with the two systems, assuming you are using the advanced functionality is now rather different. I’m splitting this into two as there are two components of interacting with both systems. Set-up and Daily Use.
Set-Up
Set-up is different for both systems.
Firstly the build.
I’m assuming that NightScout has been set-up in both cases, as it’s incredibly useful in the reports it generates for reviewing how your loop is working, however, it is a required set-up item for OpenAPS.
Loop uses the iPhone, so you need to set up using a Mac. If you don’t have a Mac with a specific version of MacOS Sierra, you need to either buy one or to set up a virtual Mac (currently the Loopdocs assume you have a Mac, so you may need to look online for advice to create a virtual Mac). You’ll also need xCode 9 and to download Homebrew and Carthage from the command line and set up an Apple Developer account. If you don’t want to rebuild Loop every seven days, you’ll also need to purchase the $99 paid account. Then you can follow the instructions in the docs to do the setup, which is a straightforward GUI interaction in xCode.
It’s worth bearing in mind that nearly every Apple update of iOS requires a new build of Loop, and may also introduce additional work on your Mac in terms of configuring the required components through Homebrew. These aren’t insurmountable difficulties, but they do exist.
OpenAPS built on the current recommended hardware (Edison and Explorer Board) can be done a couple of ways. The recommended approach is to purchase a pre-flashed Edison which has the operating system onboard already. Building can then be done from any of a Mac, Windows or Linux PC and is not particularly picky about what operating system you are currently using. Again, there are step by step instructions, and the biggest difference is whether you prefer a GUI or a command line for interaction, now that there is an automated script to manage set-up of the Edison and OpenAPS. Admittedly, adding a bluetooth tether requires more command line use and isn’t automated by a script, but as long as you are prepared to follow the instructions, it’s not an overly difficult process.
If you are planning on flashing an Edison yourself, the process is a little more involved and therefore I would consider it more difficult.
All in all, Loop may be slightly easier to set up, but given the amount of automation that is now in OpenAPS, it should no longer present the challenges that have put people off in the past.
Secondly, the system set-up.
We’ve already stated that prior to looping, it’s worth running Autotune to ensure that the correct basal rates are configured. If you’ve done this and put this data in your pump, then that’s just about it for OpenAPS. It then pulls your Carb Ratio (CR), Insulin Sensitivity (ISF), basals, etc, off the pump and uses them. You’ll need to log on to the rig to set up any customisations to the preferences file that you choose to use.
In Loop, you copy all your settings off the pump manually, including basals, ISFs and CRs. Whilst it’s not the end of the world, it does give you a bit more to do on the phone interface and leaves a little more room for error.
Day to Day interaction
This is where the biggest divergence now comes into play. From a day to day basis, the two have become very different, and even more so with the current Dev version. My personal view on the user experience is that just because Loop has a more complete, single interaction model, that doesn’t make it the better user experience.
Going on its own description:
Loop is an automated insulin delivery system designed to reduce the time and cognitive load spent on diabetes, and Loop seeks to deliver it with a glanceable interface, seamless connectivity, and the compact package of the RileyLink.
Loop does this with aplomb, and offers a watch app to assist. On the other hand, OpenAPS is:
The Open Source Artificial Pancreas System (OpenAPS) is a safe but powerful, advanced but easily understandable, Artificial Pancreas System (APS) designed to automatically adjust an insulin pump’s insulin delivery to keep blood glucose (BG) in a safe range at all times.
The briefs are subtly different and this is evident in how they can be used day to day.
It’s worth mentioning that in both cases, for best results, decent carb counts should be entered, but if you don’t have those then the outcomes tend to be slightly less effective.
Meals
At a mealtime, with Loop, you will either go into the watch app or the phone app, choose the meal option, enter the carb amount, and if you want a reasonable bolus estimate, enter the anticipated meal absorption as best as you think it will be. Loop will then offer a meal bolus amount that you can either administer or change (or ignore – more on that later). It will then administer the bolus and start to monitor carb absorption, alongside adjusting TBR accordingly.
Using regular fast insulin, you may also kick Eating Soon off and enter the details of carbs in order to have Loop offer a prebolus amount based on carb and insulin absorption. If using Fiasp, this latter step is much less necessary.
At a similar mealtime with OpenAPS running oref1, you have a choice. You can either use the easy bolus buttons on the pump to administer a bolus, and leave it at that, or you can enter carbs, either by Nightscout, the pump bolus wizard, IFTTT buttons on the phone or smartwatch or using Hot Buttons on a phone (if offline). OpenAPS will then continually evaluate your carb absorption and SMB accordingly. Thanks to the IFTTT interaction you can also schedule Eating Soon or Exercise modes via that mechanism, or using a script via Cron on the rig, so if you have a regular routine, these can easily be achieved.
If using regular fast acting and not Fiasp, you would also enable eating soon, and potentially bolus ahead of the meal.
The other aspect of this SMB approach is that it’s possible to enter a minimal bolus and allow the system to decide what to do (and with the eSMB version in Dev, using Fiasp, not enter a bolus at all). This makes it significantly easier to live with the system as there is less interaction and observation required, and you can let it get on with it. There’s no need to double check that your carb absorption period was okay, for example.
What this means in practice is that in using OpenAPS day to day, I hardly interact with the phone. I’ll either hit a couple of IFTTT buttons on my watch or I’ll easy bolus for a rough estimate of 50%-60% the insulin I need, and let the system get on with the rest of it, whereas if I use Loop, to be confident in the offered bolus, I must enter the anticipated carb absorption.
You can also not enter a bolus with Loop, but then the carb absorption entry becomes critical, and if you allow it to use dynamic carb absorption to provide the mealtime insulin, you typically need to set a maximum TBR that is a multiple of what you need when you don’t have carbs on board. This isn’t something I’m all that comfortable doing as it leaves you with no safety valve should the unthinkable happen when there are no carbs on board, however low the risk of issues (i.e. accidental carb entry or bad glucose data).
From a meal entry perspective, I now find that OpenAPS is easier to use as I don’t have to worry too much about how much bolus to give, exact carb amounts nor think about carb absorption. The advanced features have removed much of the need for this interaction and with Fiasp in the armoury, it is possible to achieve excellent results using these techniques. Essentially it has removed a lot of the thinking about interaction.
Other times
Whilst it’s recommended to use Autotune before setting up either loop, OpenAPS has the added benefit of being able to run Autotune on a nightly basis. This means that it can adjust basal rates and ratios according to changes that it has seen during the previous day. I’ve found this to be tremendously useful when dealing with Fiasp as it has made living with the changes I’ve observed from it much less manual (even though it has had its fair share of issues).
What this means in practice is that your overall system parameters should remain reasonably within bounds using OpenAPS, whereas you may need to do a periodic manual re-run of Autotune with Loop. It’s not a big thing, but it’s something worth bearing in mind.
The ability to manage OpenAPS via a remote GUI with NightScout is something that parents have mentioned is useful in situations where their kids are remote from them, e.g. at nursery.
In addition, having an OpenAPS rig in the middle of the house at home makes it easy to wander around the house and it doesn’t matter if I put my day to day rig down somewhere where it can’t speak to my pump. This isn’t a big issue, but highlights a difference between OpenAPS and Loop, where I’d need the RileyLink in close proximity at all times.
When things go wrong…
For the most part, dealing with both OpenAPS and Loop for me have meant rebooting the rig/phone/Rileylink when running on the master branch. On the Dev branch I tend to dig into things more. As I run my OpenAPS rig either using the home WiFi or via the phone BT Tethering exclusively, and let the phone take care of Wifi interoperability, I haven’t seen the issues that others have reported with using wifi in various places.
If you require more technical digging into the logs, then Loop presents an easier interface to cut, paste and send from, as opposed to having to add an SSH terminal to your phone for OpenAPS.
Having said that, the actual amount of time I use the SSH interface in day to day running is very limited, so making assessments on stability of either system over the other is pretty difficult and suggests to me that they are both very stable.
Conclusions
There are now some major differences between OpenAPS and Loop and users who are jumping into this world for the first time need to be aware of them.
A lot of people started with Loop because it appears easier to set up, however I’d argue that OpenAPS is now a lot closer in terms of ease of setting up.
Once in operation, whilst Loop is portable it’s no longer more portable than OpenAPS. In addition, while, with Loop tuned properly you will get great results, the Loop algorithm is not as advanced as that available from OpenAPS. It requires more interaction and thinking in order to get good results. It is however, a better looking and more complete graphical user experience than OpenAPS, and that is important to some people.
From my perspective, it’s much easier to manage glucose levels with OpenAPS than with Loop, and I have multiple rigs located around the house and at work. I rarely use Loop day to day as I value the lack of interaction that I am able to achieve with OpenAPS.
So what do I recommend? Well, as with all these things, I’d say it’s up to you. But for me, I use OpenAPS because the functionality serves me better. I like that I don’t have to do very much, simply pressing a couple of watch buttons. I like that the eSMB functions with Fiasp mean that it achieves an 88% time in range for me, without me having to think about carb absorption. I’m also not so bothered about the GUI.
As with all of these things, it’s worth considering what the options mean before making a decision. For me the lack of mealtime bolusing and the ability of the system to just get on and work without much input from me is why I elected OpenAPS over Loop, and going back and re-reviewing both systems for this article hasn’t changed my mind.