Recently, Dana announced oref1 to the world – a new algorithm in the OpenAPS family, and in her own words:
The notable difference between the oref0 and oref1 algorithms is that, when enabled, oref1 makes use of small “supermicroboluses” (SMB) of insulin at mealtimes to more quickly (but safely) administer the insulin required to respond to blood sugar rises due to carb absorption.
What this effectively means is that instead of setting a TBR that you receive for five minutes, you get the insulin of that TBR as a small bolus. If oref0 might think that you need 0.5u over the next five minutes, it would need to set a TBR of 6u/hr to run for 30 mins. oref1, instead delivers that increment directly, with some additional safety features in place.
Why am I writing about this now? Well I’ve been privileged to test this algorithm for a couple of months, and am pleased to say that the aims it sets out to address are very much fulfilled.
Essentially, you can consider oref1 to be an evolution of the oref0 alogrithm, and I won’t go into too much detail about it as the link to the diyps.org blog above tells you everything you might want to know, including that it is safe and works extremely effectively. To give you some idea, here’s breakfast this morning, running with oref1 and with a meal announcement and not a lot more. Just to be clear, this is a relatively low GI breakfast with a significant protein amount, but even low carb, I’d historically have to bolus for protein. With oref1 this is something that I no longer need to do.
As you can see, it has managed this extremely well. Throughout the testing, starting with using Novorapid, I’ve been able to run oref1 and get away with limited bolusing (on slow GI foods, basically none!) up to roughly 50g of carbs without experiencing huge spikes, using “Eating Soon” mode combined with an estimate of the amount of carbs I’ll be eating in the future.
So of its own, oref1 is a major step forward from AMA. But there’s more. Combining oref1 with Fiasp really brings forth the benefits and introduces more of what I’ve talked about in terms of improved management in the past. With the SMB model in place, I’ve been able to get away without bolusing for smaller and amounts of carbs, and not worry too much about when they are eaten. They have to be announced, but that’s it. With Fiasp it’s a whole different story. That early absorption really makes a difference to the effects when delivered in response to a glucose rise.
The best example of this was with a meal amounting to around 60g of carb equivalents (that’s carbs and protein, which I use to bolus), of which 24g was carbs, where oref1 was able to keep the rise down to 3 mmol/l post prandially, before bringing me back to where I started, without bolusing!
To provide an indication of how Fiasp works with oref1, for science, I consumed five of these (yes… I know…):
Which account for roughly 25g of pretty much neat sugar. This should raise my glucose level by something in the region of 7.5 mmol/l. Below you can see oref1 doing its work.
oref1 combined with the faster time to action of Fiasp has ameliorated the rise to a maximum level of 8.2mmol/l. To do so it used a combination of 1.8u of insulin delivered via SMB over an hour in combination with additional high temping. What’s impressive here is not what was delivered, but that 5 jelly bunnies were restricted to a rise of 3 mmol/l with the algorithm delivering insulin safely post eating, where I would have expected a great deal more. Obviously a bolus of the correct amount of insulin at eating would have had a lot lower rise.
If you were to attempt this with oref0, it would require that for each of those 0.2u SMBs, it would have set a TBR of 2.4u/hr to run for that period of time. More importantly, that 0.2u wouldn’t have been delivered in 5 seconds at the start of the five minute period, but would have been dripped over the entire 5 minute period, taking about 60 times as long, which obviously has an impact on rate of absorption and therefore rate of blood glucose rise.
But it really comes into its own when out and having a multi-course meal. You can tell the rig that you’re going to be eating soon, give it an estimate of carbs throughout the meal and then let it get on with managing. If you’re going to eat something high in fast acting carbs, then I’d recommend a bolus, but it makes this kind of meal much easier to deal with and results in very few major spikes as a result (by major spike, I mean that annoying feature of late timed boluses with meals out that result in numbers of more than 10 mmol/l), as can be seen by the graph below. Whilst these levels may be too high for some people (and I can understand that point of view), it’s quite refreshing for something to have your back.
This is oref1 working overtime, and me adding in when I was aware of foods that would really change it. A fantastically successful test of the algorithm for me.
As development continues, this is the type of technology that should get to a point where it will minimise high glucose levels without needing to be told about meals at all, although I suspect that remains a bit of a way off.
The key thing here is that with the introduction of oref1 alongside faster insulins, we are looking at something that takes more effort out of our of living with type 1 diabetes. I now have to do even less to keep in range, which is a huge advantage.
Whilst this is all open source DIY and still very new, I can see a time when this type of technology makes it into commercial offerings. We know, for example, that iLet and Bigfoot are looking at similar types of use case functionality. The question then comes back to accessibility. How do we get something with the power to make this much of a difference into the hands of those who need it? Who are those who need it? Both legitimate and difficult questions to answer.
But this is a start, and while cures and biological solutions remain a long way from the real world, it’s nice to have a technological alternative to make life easier.