When we talk about AID systems, a range of options spring to mind. Of the 5 commercial systems that are either here or nearly here, 3 of them run the control algorithm on the pump device and 2, like the DIY systems, run on either a phone or an additional device.
This might not seem like a very important thing to raise, and when there are people struggling to obtain or afford insulin, it’s probably not something most people are going to spend too much time worrying about. And yet. It can play a big part in how you get the best out of one of these devices.
For those who are active, and used to a pump, there is already the concern about what do you do with the pump when exercising. Obviously, if you use Omnipod, this is less of an issue.
But alongside that, using an AID system where the algorithm is separate from the pump puts you in an awkward position. If you don’t have the control device, you don’t have a hybrid closed loop.
Does this matter?
I think it’s something that people should perhaps consider when looking at the options for AID systems that they are presented with. For example, many DIY users that use AndroidAPS have two phones. One to run AAPS and their regular phone (especially if you’re generally an iPhone user). Do you want the overhead of that second device?
What about when you’re exercising? If you go for a run, where do you keep the device? Do you take your regular phone with you on your run? What if it’s a large (6″ screen) android device? Are you comfortable running with that?
I, for example, have stopped taking my Android phone with me when I run because it’s too large. That means my control algorithm sits at home and does nothing. It also means that I don’t have CGM. I could run it on a second phone, but that would mean carrying 3 phones around with me. It’s a first world, privileged problem to have, but then I could argue that of having an AID system and CGM available as well.
Or how about if you work in a place where phones aren’t able to be taken, whether that’s down to not allowing the people you work with access to them, or because of the risk that you might take and share photos?
Are you making a lot of fuss over nothing?
That’s also a good question. Once again, I think we’re into user preferences here. Having the option of using a separate control algorithm hopefully gives a user the option of multiple different available pumps, any one of which may suit them better than the one with the embedded algorithm.
I do, however, believe that the physical implementation of AID systems is likely to play as big a part in choice as anything else. And with this in mind, it’s understandable that there’s a significant amount of excitement about the Omnipod 5 system. It seems to offer the best of both worlds. Control Algorithm on the pump and bolus management from your phone. Even if Gary Scheiner has raised a few concerns over how the Omnipod 5 works.
However, you can’t bolus from a pod. While HCLs operate as they do, a bolusing phone app alongside a pump in your pocket with full control functions seems like the best way forward.
So what are you really saying?
This is yet another aspect of the differences between AID systems and what that means for the user. It highlights the issue that all the commercial systems have.
There is no way to try them and see which one works best for you.
Sure, if you have compatible kit, you might already know that a system with a phone controller is or isn’t for you from using a DIY system, but for the many that don’t, choosing which is best for you is going to come down to a paper comparison, and potentially expert guidance from healthcare professionals.
So it will remain an educated guess, and where control algorithms and physical systems come into play, that could prove to be an expensive mistake.
Tim, you highlight one of the very difficult issues … the opportunity to “try on” a device. An AID is a very intimate item of daily/24/7/minute-to-minute wear. Why wouldn’t a device manufacturer want to let you try it? I know, the cost of training plus all the options for infusion sets, etc. BUT, the problem remains, even if the solution is hard to find.
The second issue baffles me. Why shouldn’t manufacturers send out a 2nd back up pump with any system (as was done by Diesetronic). Just always seems that the manufacturers are not particularly interested in the customer satisfaction. They offer what they offer … take it or leave it.
Interesting article. I started AID using DIY Loop. I used it for about 1 1/2 years and loved it, but the phone dependence was less than ideal. As soon as I was eligible and CIQ was available on Tandem, I switched to Tandem + G6. I like being phone independent, but miss pump control from watch and phone. Also, I compete in a dog sport that does not allow self-timing, so now I can participate in that sport with losing AID for extended periods. A Tandem/Dexcom system with optional phone control would be my perfect solution.
so a wearable device would be the best choice ,like a watch which runs the controller……
Possibly, but I think there are two parts to this.
Wearables and phones are generally multipurpose. You need to be able to retain the health tracking/notification capabilities on the watch whilst having it communicate 288 times per day with CGM and then an additional 288 connections to the pump.
That’s why I think some sort of hybrid probably makes sense, linked to a regulatory approved interoperability layer that allows different algorithms to sit on different pumps.
Even the longest lasting watches (generally health devices like Garmin) are going to struggle with this level of radio Comms happening as frequently as they do. Experimentation with full Android watches hasn’t yielded great battery life.
Essentially, I think you need a way to embed the algorithm in a programmable firmware layer to minimise watch CPU use and find a way to optimise communications such that battery life is not affected as heavily. Neither of these is going to be that easy.
I think your comment about “longest lasting watches” is really on point. The precise reason _why_ Garmin watches last so much longer than a ‘real’ smart watch like an Apple Watch is that they have pared down radio comms and general onboard CPU power to the bare minimum, and the functions they do have rely on single-purpose silicon. The moment you tried to run something like the Loop watch interface on a Garmin, it would suck battery just like an Apple Watch.