Following the weekend at Glastonbury, where I was able to use SmartGuard to great effect, I thought it might be interesting to review the data that was collected and see if it gave an insight into SmartGuard’s activity. Firstly, I’ll review what we know of the SmartGuard algo, then I’ll go into the data that I recovered, to see what it shows of the SmartGuard data and whether there is anything different or odd happening and what it tells us about the best way to use the “suspend before low” functionality.
The SmartGuard Algorithm
According to page 159 of the 640G User Manual, the conditions at which Smartguard kicks in are:
Your Sensor Glucose (SG) value is at or within 3.9 mmol/L above your low limit.
Your SG is predicted to reach or fall below a level that is 1.1 mmol/L above your low limit within approximately 30 minutes.
After the minimum 30-minute suspend time, basal insulin delivery will automatically resume if the following conditions are met:
Your SG is at least 1.1 mmol/L above your low limit.
Your SG is estimated to be more than 2.2 mmol/L above your low limit within 30 minutes.
Your basal insulin delivery will be suspended for a maximum of two hours.
I’ve no idea about the models that Medtronic used to arrive at these numbers, but it’s clear that from this statement, insulin on board is not considered, however a risk factor is. What is the risk factor?
Reading between the lines of the above, if you are within 3.9 mmol/l of your low limit and your rate of change is predicted to bring your level to or below 1.1 mmol/l above your low level within 30 mins, then SmartGuard will activate.
This is, therefore, assuming that the worst case dangerous “SG drop” rate is 2.8 mmol/l in 30 mins or greater, or a rate of change of more than -0.093 mmol/l/min when you are below a certain level. I suppose that you could describe this as the “risk factor” as others have when looking at this.
I have assumed that the calculation uses the two previous Sensor Glucose readings (based on what we’ve been told of the 670G) to determine the future SG level.
It is clear from the data I pulled that the rate is not the driver in the calculation that the algorithm undertakes though. It is the end result of that rate and the current SG level.
Over the period I was at Glastonbury, there were a few auto-suspends thanks to SmartGuard, and the majority of them made complete sense. Ahead of the data, the key values to be aware of are my pre-programmed low level, which was 3.8 mmol/l, and the perimeter values this generated. The activation prediction threshold for SmartGuard is 4.9 mmol/l and the high point at which it will activate is 7.7 mmol/l.
Reviewing the data set is quite interesting. What I’ve shown in the table are the Suspends, with the rate of change between the preceding SG value on the one 5 mins before it, what that equates to over the next thirty minutes and where the SG level would be in 30 mins if that rate were to continue from now.
The majority of the suspends fulfilled these rules perfectly, resulting in acceptable suspends, however there are three that show up on the table where the assessment of what SmartGuard is doing don’t seem to hold true. In one of these cases, looking at the full data set, the change in ISIG (row 30) could have triggered the algorithm (questioning which values are used to calculate the difference) but the other two show no obvious signs as to why the Auto Suspend was triggered.
The data also seems to confirm that there is no recognition of the insulin on board, other than the result of the rate of change of blood glucose and where it might end up.
What’s notable for me is that my SG level variation is typically not that high (over this period it was 29%, or +/- 1.9 mmol/l, and I was rarely outside of the +3.9 mmol/l condition that allows SmartGuard to engage.
What does this mean for using SmartGuard?
Given an understanding of the rules of the game, you can tailor how you set up the 640G to maximise the benefit that SmartGuard gives you.
I mentioned the low limit that I had set up earlier. At that level, insulin cuts out if a 4.9 mmol/l level is predicted. This means that, typically, I don’t drop below about 4.2 mmol/l when it kicks in, however, on days where I’ve eaten more carbs and had a higher insulin usage, I have dropped lower and it is therefore not perfect.
You could, of course, ameliorate this by running slightly higher and setting a higher “low” level, which would result in being much less likely to go low and still allow for better average glucose control.
The other aspect of SmartGuard I found useful is that with this safety net in place, you can manage eating differently. Normally I’d bolus a good period of time before eating in order for food and insulin action to coincide. When in a position where this wasn’t possible, and I had to bolus immediately before eating, I took a larger bolus than normal (changing I:C Ratio from say, 1:10 to 1:8) such that the resultant peak wasn’t as high, with the knowledge that the following low from the tail would be held up by SmartGuard. It’s a bit like an automatically managed Superbolus.
The key to using this feature to your advantage is the level at which you set your low.
Applying this in an Artificial Pancreas, i.e. the 670G
Anyone who has used either an open or closed loop artificial pancreas will recognise the constraint/liberty here, and assuming the 670G works in a similar way, i.e. “correct before high”, with limits and predictions, the levels at which you set your high and low limits will dictate the efficiency of the system for you.
What does this mean in regards to using the system? I suspect that it means the learning curve for using the 670G is going to be noticeably different for those who are using a pump. I benefited from using HAPP ahead of touching SmartGuard. It told me when to suspend in an open loop form.
It was very insightful, and it leads me to the suggestion that using the alarm before low and alarm before high functionality to get people used to suspending and managing insulin delivery, before going out and out on the full blown 670G functionality will help to understand the experience of how an AP works and should require a reduced amount of face to face training in the process.