I am dependent on insulin to survive, and like everyone else in that category I need to get the dosing right in order to survive and to stay healthy.. This dosing is affected by diet, exercise, and a myriad of other factors. But unlike many people I have a guardian angel that manages most of those dosing decisions for me.

It’s amusing to think that the last time I administered a bolus (either by injection, manually on a pump, or via direct command on a looping system) was in December.
December 8th, 2020 to be precise: fourteen months ago. And it’s been over 12 months since I last declared any food intake to my loop. Australia Day 2021 happened to be that day.

Last April I wrote “No-bolus for 4 months”, and the adventure has just continued!

Clinical data

There’s more to explore in upcoming articles, but for now here’s a summary of some of the latest data (over 75 days ending in early February 2022):

HbA1c (lab)	5.4%, 36 mmol/mol
Time In Range (3.9-10 mmol/L) (70-180 mg/dL)	95%
Time In Range (3.9-7.8 mmol/L) (70-140 mg/dL)	89%
Coefficient of Variation (relative SD)	23%

This is not the lowest HbA1c result I have ever had. I did have 5.0% several times in 2020. That was while I was still carb-counting and bolusing, but at least it’s staying within the reference range. More on that in tomorrow’s article.

Remember, this is for a fully-automated system. The only real input I’ve been giving it is pre-declaring periods of significant exercise. I do not give boluses or even declare food. I am not a “low-carber” although I do try to eat sensible volumes.

Now, these are just the stats from 75 days at the end of the year. It turns out that across the entire 12 months (including all my experiments along the way) my Time In Range for 3.9-10 mmol/L (70-180 mg/dL) wasn’t actually 95%.
It was “only” 93.9% averaged across the 365 days.

What I’m using

The technology

I use an AID (Automated Insulin Delivery) or “looping” system where my insulin pump is automatically adjusted based on the data from my CGM.

No commercial company has built the system I use to manage my blood glucose: I’ve had to assemble it myself. The system is comprised of some commercial components though. The CGM and pump are both commercial medical devices, but are coordinated by software running on a computer I carry with me. This is actually a tiny Android phone, although it’s separate from the iPhone I use as my phone.

The software has been AndroidAPS, and some related software. But in terms of basic functionality everything I’ve been using can be done within AndroidAPS.

I have continued to tweak and tune the loop over time of course.

Core algorithm

The algorithm that’s been driving my loop is essentially the oref1 reference design (found in OpenAPS, AndroidAPS, FreeAPS X and some others).

The only significant tweak to its implementation has been changing a function which essentially disabled the loop if the blood glucose had not changed in a while (an old “safety override” which was intended to catch problems with a faulty CGM system). I kept hitting situations where this was because the loop had been doing its job well, and not because the CGM was faulty (which there are now other checks for anyway). Temporarily disabling the loop had some unfortunate side-effects such as interfering with starting exercise/activity mode.

Beyond that, this is standard oref1!
I have not had to experiment with fancy experimental designs with dynamic ISF.

I use one ISF (insulin sensitivity factor) across the entire day.
My default basal profile does vary across the day in what is essentially a circadian rhythm: my background needs are lower when asleep than awake for example. I have a few times run without the loop active (and thus the pump falls back to the default basal profile) and it has kept me fairly stable, so I have some trust in that profile.
But the algorithm is flexible enough that I can for example vary my sleep timing a lot without having to make manual adjustments.

Tweaks/tuning

My goal range is 3.9-7.8 mmol/L, and my default target BG level has been 5.1 mmol/L (although I’ve recently raised this to 5.3).

I have been experimenting with two “automation” optimisations enabled which adjust the target BG level.
If my BG is falling below 4.0 mmol/L it raises the target to 6.0 (disabling “micro-bolus” dosing) for 20 minutes, and if it’s rising above 7.8 it lowers the target to 4.2 for 15 minutes. But overall the glucose control is being managed by the oref1 algorithm.

I have not been using automations to scale my profile up/down in response to BG levels: only the target has been tweaked.

In the lead-up to (and during) exercise I set an “activity” target level of 7.0 mmol/L. While that’s in effect the above automations are automatically disabled, as well as micro-bolus adjustments (the system will still vary the basal insulin flow). After unusually-extended exercise I will sometimes use a scaled “profile switch” to tell the system I need less insulin for a while, but usually I let the system’s “autosens” take care of that.

CGM

I have mainly been using a Dexcom G6 CGM, although I have at times this year experimented with systems using Libre1, Dexcom G5, and PocTech sensors. The G6 has been nice and reliable (and a lot more convenient without so much need for calibrations) but it could always be cheaper. It is the most expensive component of my AID system.

Pumps

I have mainly been using a YpsoPump OPN pump, although I have at times switched to my Accu-Chek Combo and Omnipod DASH pumps (only changing the pump: the rest of the system is the same) without noticeably affecting the overall results. The differences in the pumps are mainly in terms of “user experience”: factors like the size and convenience of the pump (including silence and promptness of communications). Overall they all deliver insulin at the command of the loop software (and a variety of other pumps are also supported).

The YpsoPump OPN is a version of the YpsoPump which has been used in some clinical trials I’ve been involved in. I’m hopeful its communication functions will become available in a future standard version of the YpsoPump.

Insulins

A year ago I was using Fiasp, and initially felt that the faster action of it (compared to Humalog/etc) was the key that had helped me achieve a fully-closed loop. However since then I have spent time experimenting with Humalog and NovoRapid again, and still managed to maintain no-announce and no-bolus operations.

I was conscious that my levels were varying a lot more than when using Fiasp, but by then I had enough patience and trust in the system that I was prepared to let it bring my levels down by itself after a meal. I’m sure years prior I would have been worrying about it and wanting to give manual override corrections, but with a little patience the right things happened.

I’m sure it helped that I have a much better understanding now of the different insulin behaviours and faith in my loop configuration. I have written multiple times about the importance of modelling the insulin activity as accurately as possible, and I believe this is fundamental to the algorithm being able to achieve somewhat predictable outcomes.

Of course, things improved again when I returned to Fiasp. And have improved further in the months I’ve been using Lyumjev.
I think it’s sometimes easier to learn about the impact of various algorithm/usage decisions when using faster insulins (where the insulin activity and IOB drops away faster) but the lessons learnt with those have been relevant across the board.

What now?

There is new technology coming down the line which will help me and thousands of other people living with T1D. Developments in insulins, CGMs, looping software, and the platforms it runs on. But certainly the tech I’ve been able to use for the last year seems to still be at the leading edge of AID systems (commercial or otherwise).

I’m fully expecting my stats to keep improving over time. Even over the next few months. But we’ll see.

It’s a big adventure, and I’m glad I didn’t wait when I set up my loop in 2017. Every year, every month, every day is precious.