Port and Portability – form and physicality of the closed loop

Port and Portability – form and physicality of the closed loop
Port and Portability – form and physicality of the closed loop

With a nod to the nineties, thank you Mr Curtis and Mr Elton, and some sweet alliteration, my tramping around with a veritable “pancreas farm” in my backpack and some of the other integration that the Nightscout team has achieved has led me to spend some time thinking about the form factor and physicality of the closed loop device. Having glued together the fairly simple task of the Alexa Skill as described in the Nightscout documentation, Alexa started to tell me things last night. Namely, what my future blood glucose would be:

It’s not an enormous step for Alexa to be giving boluses from here. Whether it’s a sensible one is a different question, and not one I’m going in to right now, but in terms of form factor and interaction, that Nightscout is now a voice begs the question of where we go with the closed loop systems.

As most will know by now, I’ve been running both Loop and OpenAPS more or less side-by-side because both have different capabilities, and therefore pros and cons.

The Pros of OpenAPS for me are AMA and Autosens, while on Loop it is the portability. I thought I could sacrifice the advanced functionality for portability, but the more time I’ve spent with it, the more frustrating I’ve found the Loop carb absorption model, which I’ve found brings the whole “Hybrid Closed Loop” model far more into the “Hybrid” function as I find myself having to check that I’ve got the absorption model correct.

But the portability. It’s great. Everything working on one device with a radio link up module. I guess the step that I’d like is oref0 to be ported to Loop, and I’d probably be happy as Larry, as that’s what it was developed for. My coding skills are rather a way from that though. In the meantime, the mini-OpenAPS will also be available soon.

The design philosophy of each of the two platforms is notably different. Loop is the ability to run your diabetes from your phone, as, admittedly, many of us do with life now. OpenAPS is a reference design allowing you to run your diabetes from a separate brain.

Both have limitations, dependent on how you implement them, but those limitations should also guide what we ask for from device manufacturers for future commercial systems.

Firstly, off-line looping.

The importance of this should not be underestimated. If you live in London and use the tube, the offline loop is critical. Commercial systems wouldn’t pass FDA approval without this being possible. You can’t be reliant upon a network connection to be doing this in a commercial world. Medtronic are using a new generation of their Guardian/Enlite technology and running it all from the pump. Others are using Dexcom. But it all runs locally. If you look at the OpenAPS community, aside from using the Receiver, there are a number of interesting alternatives being tested by various users to try and make this work. It is, of course, built in to Loop.

Secondly, the Pancreas Farm (or the box of bits)

Okay, so maybe I’m overstating the point, and a part of this is my carrying around too much stuff. But it raises an interesting question . How much is too much, and where should the intelligence reside? In many ways this is the same question in regard to a pump.

To use Loop, I need to carry a RileyLink and an iPhone, and my “brain’s” connectivity to my “pancreas” is handled by a BLE to 900mHz converter. If I forget it, get too far away from it, or get in an environment where there is too much BLE, my connectivity drops.

To use OpenAPS, I need to carry a “brain”, which talks to my “pancreas” via 900mHz comms. But my brain also needs data, and it gets this either from a USB connected receiver or by talking via my phone to the cloud, or if I’m using one of the smart offline solutions, by talking to some local device.

As you can see from both of these, I need some form of extra “thing” in order to make the #wearenotwaiting systems work. Those of us who use these systems understand that and do it anyway. It’s worth it. But would your average Type 1 in the street?

There is a reason that Medtronic have built the 670G within the 6xx series pump case. You only need the one device that manages everything. It keeps your carriables down, removes the risk of loss of the “brain” if you misplace your mobile phone, or other device, but it does mean you have to manage it all from the pump. And it also means that it’s not extensible, at least by anyone other than Medtronic. But that’s a fact of life with medical devices and the FDA.

The interface – my everyday interactions…

Loop is built with IOs at its core and has a User Interface to suit. OpenAPS integrates nicely with Nightscout, not quite so plush, but still totally useable. What do the commercial systems do? Run on the commercial device using a bespoke, closed interface. Whilst this may be required from an FDA perspective, it makes using the device less straightforward, requiring more localized training and spend. Bigfoot had originally run with a phone app, but seem to have been pushed into a specific device due to FDA demand. But isn’t this the key area of any closed loop? How you interact with it, as you will have to do from time to time?

Wearenotwaiting exists because the technology companies haven’t been able to keep up with the needs of their consumers in relation to T1D, whether as a response to not investing in tech enough, or due to restrictions that have been put in place by regulation. What do we want?

My artificial pancreas wish list, if it’s not too much to ask…

What does my wish list look like? Well… It takes items from each of these areas and glues them together. While I realise that it’s not going to be hugely engaged with open source projects, there are one or two things that all closed loop platforms should be doing….

  • I’d like a delivery device and remote control so that I know that if the remote control is dropped, loses contact, gets stolen or lost, the system will still work and I can still do everything I need to. That means bolus/enter food/do eating soon/yes…. Anything. All glucose data will feed the delivery device.
  • I’d like the remote control to be an app on a phone. There, I’ve said it. It’s an app as device. It will use bluetooth to talk to the delivery device and it will have its own encryption within that application comms stack.
  • I’d like to interact with the system from my phone, and not need to use the delivery device except in extreme circumstances.
  • I’d like to be able to upload the data real time to my choice of service provider. It’s my data so I get to choose where it goes. NightScout, Diasend, Carelink. I want to elect my own choice of analytics provider. It should be my choice, not the choice of the manufacturer who is trying to capture the data to use with IBM Watson to their own end, and to feed things like Alexa.
  • I’d like an APS Algo App Store, where I can select the algorithm I’d like to use and deploy it to my phone or the cloud, where it can use my historic data to back-test against what I’m currently using and show me which algo would give me better results. I might use that, but so would healthcare professionals.

With the past few months of using both Loop and OpenAPS, I’ve found that both are massive steps forward. They allow us to do things we’ve only ever dreamt of as Type 1s, and it’s right that we are not waiting. But if the diabetes tech manufacturers and regulators really want something to be built that’s what patients want, they need to talk to patients, far more effectively than they seem to be doing. And they need to open up data and interactivity between systems. Both Loop and OpenAPS are built on extensible frameworks. Why is there nothing commercial that fits this?

There’s a reason why #wearenotwaiting…

 

 

8 Comments

  1. I like the idea of running each algorithm on historical data. But would this work and how useable would it be?
    The source data would of been affected by the current algorithm and the historical data would not show the correct adjustments by the APS system.
    It’s a nice idea, but possible\useable?

    • That’s a good point. Technically, it should be possible to build some form of framework that takes this into account, but as you say, it’s unlikely to be all that easy.

      I’ve effectively done something similar running Loop and OpenAPS side by side speaking to different pumps. It’s interesting to see the different decisions they both make.

      • I really like the idea of comparing the outcome over time of different APS algorithms. HAPP I plan to do this per APS suggestion, as its easy to pass the same data to each algorithm, I would love to work out a way to do this for 24 hours of data

        • Having run Loop and OpenAPS literally alongside each other at the same time, you see that the treatment approaches sometime vary quite a lot.
          The issue you always have when you take looped data and apply the algo is that where the data is already affected by an algo, you’ve kind of modified the results.

          I think what might be interesting is to do 24 hours of traditional pumping then overlay the different algos retrospectively (as the data is all stored in the mlab database). You’d need some form of simulator though, as you’d need to determine how the changes done by the loop then react. I guess you could use the Glucodyn models to enable the prediction process.

  2. This is an awesome article. I’m using loop too and finding it much tougher to get right than the OpenAPS rig I started with.

    • I think most people starting with Loop find something similar. There’s a fair amount of faffing involved in trying to estimate carb absorption and getting ISF and DIA right, and I’ve had to come up with a strategy to handle the foods I eat that isn’t something that’s immediately obvious. OpenAPS is easier, once you’ve got it set up, to just get on and use.

Leave a Reply

Your email address will not be published.


*