2016. One hell of a year, and not always in the right way. But looking at it from my own personal transition on the Diabetes Technology front, it’s been eventful. And what I look for now is not what I expected when I started this journey!
A year in review…
At the start of the year, I was using the Freestyle Libre, as I had been for more than a year previously, and discussing, over pub drinks, writing artificial pancreas software based on the algorithms we use at work, as I could see similarities in the behaviours and circumstances under which they operate.
Fast forward to the end of the year, and I’m running a pancreas farm…. But there’s quite a journey between the start and end of the year, so let’s rewind a bit to January!
At the start of January, I had Libre data, was aware of Dexcom, and the #wearenottwaiting crowd and had also decided that I wanted a pump, so I’d badgered a Specialist Registrar into getting me put forward to the clinic director to get me on to one. I had been pumping, surreptitiously under the radar for three months at this point, but fortunately, in a time hop, it was approved. Then came the PWD conference in Nottingham in February.
That was probably the watershed moment for me, when I decided that I’d pick up the baton and run with building stuff. I’d seen Tim Omer’s blog but when he was showing off HAPP, his open loop artificial pancreas platform, I realised that I needed something like this in my life. After a few fits and starts, I built my first xDrip Wireless Bridge in March, and started running HAPP. It was a good entry point into how OpenAPS works and showed me what I thought were some amazing results. I was also able to use it with the 640G I would receive in May. But at that point, I also encountered my first issues with Open Source Diabetes Tech. Too much stuff to carry around. And that’s a point I’ll come back to.
It was also around this time that I met Dana Lewis, as she was en route to Scandinavia and stopped off in London. A group of people using the OpenAPS platform met up for dinner in Islington one evening, which was an interesting experience, and also made me consider how we might use my 640G in the context of OpenAPS.
Whilst HAPP was producing amazing numbers, I needed to have my xDrip Wireless Bridge, an extra Android phone (I use an iPhone for work) and the Smartwatch that talked to the phone. Plus my normal paraphernalia. HAPP made it to Download and successfully survived a very wet and muddy environment, but also changed my mind about what I wanted to carry and charge.
So I elected to take up the 640Gs promise of “Predictive Low Glucose Suspend” and SmartGuard, and invested in the Medtronic system. What this basically entailed was a “Sugar Surfing Plus” approach, where I knew that I’d be unlikely to go low, but equally, would have to manage upward pressure. It was surprisingly, and enlighteningly effective. It made Glastonbury easy. I could superbolus and not worry about what happened next. A massive breakthrough in my view. It did become clear that the SmartGuard “recovery” algo didn’t quite act as aggressively as I’d have liked, with Insulin being resumed rather later than might be helpful. During this period, pazaan also completed the 640G uploader, which I was able to use with Nightscout.
Having used all this tech, what I really wanted was to not have to think, and that’s where the Artificial Pancreas building started. If I look at why I wanted to build myself a Hybrid Closed Loop, it’s not for the reasons that many have had.
My overnight glucose levels were being managed very effectively – I’d managed to tune basal rates as a result of having the Libre before going on to the pump, and the SmartGuard capabilities meant that I didn’t really have to worry about overnight lows – even after Gym sessions, as it was doing a great job of cutting off basal in a timely fashion, even if the resumption was a little slow.
What I wanted a Hybrid Closed Loop for was to limit the amount of time I was spending Sugar Surfing. Whilst it’s an incredibly powerful mechanism for managing diabetes, it’s also time consuming, involving and a lot of work. However you look at it, you have to be fairly dedicated to keep it up, and for the previous two years I’d been doing a lot of that. Having something that automatically is watching your back and defending the highs was really appealing.
So off I went on holiday and, as I wrote here, took the 640G uploader python code and deployed it onto the Raspberry Pi, alongside OpenAPS.
Throughout the Autumn, and well into the winter months, I’ve grown my pancreas farm, dumping the carelink stick and taking advantage of the stuff that Scott and Dana have built to distribute pancreases around my house and work. As part of that, I’ve also jumped onto Loop, which for what I currently have, wins the portability race. It only really became available during the summer.
I’ve already spoken about my preferences and the reasons for using the various platforms, so I won’t go into it again here. Suffice to say, as I have before, that I prefer OpenAPS from a functional standpoint.
However, that’s not going to be the case for much longer. I’ve explorer boards on the way, and plan to use the Enlites with the 722. Why, well, it comes back to portability and “off line” use. That’s probably the biggest concern with all of this stuff, and may be my biggest learning point of using Hybrid Closed Loops this year.
For me, the biggest point of this technology may be different to that for others. For me it’s a labour saving device. If I can not have to think, then it’s doing its job. An automated system should limit the amount of time I have to interact with it, ultimately getting to the point where I don’t have to interact at all. Whilst both revert back to my target, OpenAPS does a better job, for me, of keeping me there, which is why I want it in as portable a form as possible.
What Next?
At the start of the process I was striving for functionality. That was what was driving me. As I near the end of the year, my priorities have changed. I have functionality by the bucket load, and now I want it constantly available. Reliability and portability with offline use has become most important. This is where, with the best will in the world, the tools we have available are often let down by the fact that we have had to glue them together.
Once you become accustomed to using a Hybrid Closed Loop, you want it to be constantly available. There are a few points as to why this isn’t the case right now. What are the weakest spots for me?
- iPhone process management and bluetooth can be pernickity and when you are reliant on it for your CGM data to drive your pancreas, it becomes problematic. I’ve found that the number of times I’ve lost connectivity between my iPhone and Dexcom G5 sensor, or that the app has inexplicably hung, or that Loop has inexplicably stopped has been too high, and it has nearly always happened overnight, when you most want the protection against lows.
- We can’t process prioritise on this platform, and as a result, the basis on which it works can hugely interfere with an operable pancreas. This is one very good reason why the phone itself should never be the core brain of the system. It can be advisory, sure, but you need resilience for when it fails. Until we can guarantee the uptime of a process on the supercomputer in our pockets, they are not good enough to be in charge of a “Life” process.
- If you lose this functionality, having a failover “Low Glucose Alert” mode that is independent of the brain or an inactive app also becomes important. My experience of the Medtronic connectivity on their CGM devices (based on the 640G) is that it is better than the Dexcom G5 to iPhone, which is a good reason for starting to use it on the 722.
How would we fix this? I think the starting point would be to port xDrip with G5 support to Linux and the Explorer board. I’m not convinced that bluetooth is the whole issue, and I think that the iPhone is a much larger part of the problem.
Then there’s portability and offline use. The explorer board and Edison go a very long way to fixing this for OpenAPS. Some of the earlier discussion about how to take glucose monitoring offline also becomes really important. I mentioned early on that the need to carry a multitude of stuff really got on my nerves. That’s also driven people to use Loop over OpenAPS, regardless of their preference for the algo.
I’ve not mentioned the commercial offerings that are on the way, but given the feedback that Advanced Meal Assist has received, I’d doubt that any of them, at first, will provide the capabilities that OpenAPS can. The work that’s been done over the past couple of years in this arena is truly outstanding.
The real question remains “What next?”. How far can we push the boundaries with what we have? Still… #wearenotwaiting
Leave a Reply