CamAPS: A month in review

*** To test out CamAPS, I was loaned a DanaRS pump by Advanced Therapeutics and provided with free access to CamAPS by CamDIAB. My thanks to both***

After over a month with CamAPS, I feel comfortable that it and I have had a chance to get to know each other pretty well, and that we’ve been able to make progress on what it does and how it works. 

But of course, what people really want to know is how did it perform? The stats as gathered in Diasend (more of that later) show:

What these stats show is 87% Time in Range (3.9mmol/l-10mmol/l). with 7% below 3.9 and 6% above 10mmol/l.

Overall, that’s a decent time in range, with a little too much time below 3.9mmol/l. Having said that, I am unable to exclude things like Dexcom sensor starts that resulted in 8 hours of “Low” with bloods showing normal, so I’m of the opinion that we’re probably looking at a “real” value of 6% below 3.9mmol/l.

In terms of what that looks like compared to DIY? The data for the last 6 months of 2019 shows:

In other words, for the month of April, CamAPS has a time in range that was marginally better than OpenAPS over the last 6 months of 2019, with recorded lows slightly worse than OpenAPS. 

With both having a target of 6 mmol/l for the most part, OpenAPS achieved an average glucose level of 6.8 mmol/l while CamAPS achieved 6.3mmol/l. Standard deviation for OpenAPS was 2.4 while CamAPS was 2.1.

So in reality, CamAPS was comparable to the DIY system that I was previously using, although over the month of April.

And that’s the summary on a purely stats based review, but the other factor that comes in to play is its use. And that’s where we go into…

Likes, dislikes and things that make you go “Hmmm”

As with any system, there are things that as you use it you will like, and things you won’t. This is my summary of those for me, and let’s be honest here, .

Likes

Obviously, the stats themselves show that the algorithm works, and that it produces outcomes that are what I as a user want to see. Discussing this with Professor Roman Horvorka, since the launch, the mean TIR across all users is a heady 83%. That’s pretty impressive.

What’s also good (perhaps even great) is that once you’ve entered your 5 day average TDD and weight, you never look at basal rates. It just works. And for those people on AndroidAPS or on Loop, this means no more tuning basal rates, or ISF, when things appear to be going awry. If you have small children, this is obviously very useful as this is one of the bugbears of using DIY systems with kids (and in many cases, adults). Adjusting settings. For many DIY system users, this would be a very useful win.

Another key “Good” is the ability to run the app on your phone. Basically, no more using a pump to interact, which will appeal to many people. 

Finally, the way it adapts to how you treat meals is also good. If you are habitually an over- or under-boluser, it adapts to how you bolus and should make post-prandial highs less of an issue. 

Dislikes

There are one or two things that I found frustrating with interacting with the system. The first of these is that every time you go to the bolus calculator, you have to wait for the system to connect to the pump, as it pulls the bolus calculator settings off the pump. This takes between five and twenty seconds each time, and is quite annoying. Here is an example:

I’d prefer it to store the bolus calculator “rules” internally, and then allow you to enter your meal data prior to the pump communication, then send the bolus after you’ve gone through it. It would make the process flow more easily.

A second is that if you want to enter a bolus without choosing a carbohydrate amount, you have to enter the dose using a wheel, as below:

I’d prefer a number pad to key in the dose, but I can understand why this is there, as it reduces the risk of a high number being entered and resulting in an overdose.

As a result of this, I have found that I tended to enter pre-boluses with a carb amount using the meal preset buttons due to it saving a lot of time.

By doing this, it also eliminates the likelihood of entering a pre-bolus, then returning to enter carbs plus some more insulin, and accidentally giving yourself the full bolus for the carb entry due to previous boluses being ignored in the bolus calculator, which is unlike the behaviour I’ve seen in any other bolus calculator that I’ve observed, which I find not quite intuitive. Having said all of this, I may reconsider how I bolus on DIY systems. It remains to be seen what happens when I go back to OpenAPS.

I’m told that the bolus calculator uses the same logic as that on the DanaRS pump, but there is one major difference, and that is that the pump DOES include the earlier bolus as part of its mealtime IOB calculation.

While all of these were annoyances for me, many people will probably not be too bothered about this, and anecdotally, I hear that many people trialling the app like it because it is very simple to use and interact with.

The other interaction item that I disliked was the lack of access to the CGM data other than through the app. I’m told that Dexcom Share will be coming during 2020, but that watch access to the app itself is more challenging, given the state of current regulatory oversight being heavily focused on CoVID-19 related items. Still, if it was available on Share, you could get it on to a watch via standard #WeAreNotWaiting methods. 

Things that made me go “Hmmm”

There are a couple of things that come up in this section. Before we get going here, it’s worth taking a minute to try and understand some of how the algorithm learns. It uses a Bayesian learning framework. This means that the way that it figures out what it wants to do is based off Bayes’ Theroem, which allows us to use some knowledge or belief that we already have (commonly known as the prior) to help us calculate the probability of a related event.

At one level, CamAPS splits the day up into the multi-hour periods, and then uses a combination of inputs from Carbohydrate, Insulin and CGM data, as well some of the adjustments from the use of Ease-Off and Boost to modify the prediction of what will happen, and then adjust what it does. It has multiple levels of period that it uses for learning, which in some cases is 2-3 days and others is longer. The CamAPS team have also built “Forgetting” into the model, although I haven’t asked whether this is Bayesian inference based, stabilised forgetting or something like a Kalman filter. I assume it is mainly used in the context of one off events or very old events that are perhaps no longer valid in the future probability prediction (which looks out for about 3.5-4 hours into the future).  The algorithm also learns specifically from hypos in preceding periods and actively aims to avoid them in the future. 

So why that particular statement? To put in context what sometimes can happen. 

What the algorithm learns

During a working week, I get up, shower and remove and suspend the pump while in the shower. This then results in a rise in glucose levels following this removal.

Over the course of a few days, the algorithm learned this behaviour, and started to increase insulin a little before I showered, as you can see in the below images. 

In all three of these images look at the time period between 3am and 7am. In picture one, we see a low level of insulin between 4 and 6 and then an increase as the rise starts after the suspended period. 

In picture 2, slightly more insulin in this period, and in picture 3, what appears to be quite a bit more. In picture 3 we see this results in a hypo. The following day it also did. Now this could simply be down to being slightly more insulin sensitive on the third day, but highlights what can sometimes happen with a system learning what’s happening when circumstances may change.

To resolve this, there are two options. Either setting a higher target for the time period affected, or pre-planning to add an Ease-Off at that time, to avoid the algorithm dosing. It will then learn about this and stop doing so. Or you can rely on the hypo learning, and it will stop automatically, which is what I saw after that.

Now to be very clear here, this wasn’t a common occurrence, and lows caused by the algorithm are something that can happen with DIY systems as well, so I’m not going to pretend that DIY systems always work perfectly, but it is something to be aware of. 

Insulin on Board

Another feature that I found awkward, probably due to DIY use rather than anything else, was the way that Insulin on Board is reported.  Even though it is following the standard bolus calculator model of only telling you about additional IOB in relation to bolused insulin, there are times, like before exercise, that it would be helpful to know whether the IOB is higher or lower than “nomal”, so you can do something to deal with it.

I find this particularly an issue when spontaneous exercise occurs. Under normal circumstances, if you have time to set an Ease Off or plan to do exercise at a specific time and can run Ease Off for an hour previous to the exercise, it does a pretty good job of avoiding lows happening with shortish (30-60 mins) aerobic exercise. I found it to be much more difficult when I didn’t have that ability to arrange what I would do, and inevitably ended up eating food and telling the system it was for treating hypoglycaemia so that it wouldn’t give insulin. With that information, or some kind of prediction information, I may have been better informed.

Pump Basal Rate adjustment

If you recall from previous posts on CamAPS, you enter your previous basal rates into the pump to give you something to fall back to in the event of the communications failing, the  phone being lost, etc. If you’ve been using CamAPS for a long time, and it has adjusted you to a different background insulin setting, there’s no feedback as to how that has happened and what your basal rates should be now. There’s probably a good personal pump hygiene activity to check your average total daily dose over the last week (TDD), as reported by CamAPS, at least monthly, if not more frequently, and see whether it has changed from the values you used at the start. If it has, then I’d adjust the hourly segments on your pump by the percentage difference between the two totals. 

Changing phones

The system works through parameterisation, and this includes pretty much everything you enter manually, as well as the learned factors that it uses. While things that you’ve entered manually are stored on the CamAPS cloud (e.g. personal targets, Dexcom serial numbers, etc) and updated when they change or weekly if they don’t, pump serial number, weight and Total Daily dose aren’t, for security reasons. Additionally, the learned factors are also not uploaded to the cloud, for similar cybersecurity reasons. Essentially, if someone got to the settings in the cloud, the risk is that they could make changes that, when next downloaded to the system, could result in an adverse situation. From what I understand, the team at CamAPS are considering whether this is the correct way to continue. 

Diasend

All your data can be uploaded to Diasend to give you something to review. While Diasend is the go to service for most clinics in England, I’m not a huge fan of how it displays data, and it would be great if other options were available. Sadly, they aren’t so that’s what we’re stuck with for now. I’d hope that once Tidepool have a European license, they would also be an option. 

Overall, what did I think?

I think the stats at the start speak for themselves. With me, it achieved 87% time in range over the month of April and with the current user base, it’s achieved 83%. That’s pretty impressive, and considerably better TIR than either the 670G or Control-IQ achieved in their clinical trials. Having said that, this wasn’t unexpected from some of us, given the outcomes of the CamAPS trials… So we know the algorithm works.

How about as a user? Well, I’ve detailed the things that went well and not so well in this article and also this post. It’s very clear that when you move to a new piece of software you have to adapt what you used to do to how the new software works, and it’s important that anyone moving from standalone pumping or DIYAPS to another Automated Insulin Delivery (AID) system is aware that they will have to make changes and what those may entail. As someone who was used to using OpenAPS in a way that had limited meal entry and carb counting, that was quite a significant change for me. If you were coming from one of the systems with a bolus calculator that you used religiously, then this probably wouldn’t be too different. 

While I really disliked not being able to see my glucose levels on a watch while using it, and I’m sure some parents would hate not having Dexcom share available, that functionality is at least in the plan for the system.

One of the things that you find as a user is that it is very simple to use, and if you come from a background where you haven’t been used to using DIY, i.e. most people with Diabetes, then I think you’d find this very easy to use. The question often comes up about what it costs. At the moment it is £70 on top of whatever your costs currently are.

Is it worth it? According to consultants that I know who are trialling it in their hospitals, plenty of people seem to think so. If you don’t want to DIY (and despite what many in the DIY community believe, a huge number of people don’t want to), then this is as good a way of getting going on AID systems as any out there. 

For me personally, now my month with the system is up, and I’m out of supplies for the pump, I’m going back to OpenAPS. I’ve been impressed with CamAPS. It’s a good solution that runs on a phone and is quickly updated when they need to or want to make changes to it. For anyone who hasn’t been able to build a DIY system and wants an AID it’s a good option to take. I only wish it worked with alternative pump choices. 

---

Footnote:

Who are CamDIAB, and what does your £70/month go on?

The company’s objective is to be sustainable over the longer term continuing development and investment in improvements of the CamAPS FX app to remain competitive. They want the app to be made widely available and currently have six ongoing clinical studies to support reimbursement, from the youngest age range at 2-6 years old, to the oldest at 60+. There is also an ongoing pregnancy study.