Defining an “Artificial Pancreas”. Where are we with DIY systems? #WeAreNotWaiting

Back in 2013, in the US, Medtronic launched the 530G pump, and everyone and his dog called it an artificial pancreas. As Scott Hanselmann stated at the time, it was way too early to call it an artificial pancreas, and if we were going to call it such, according to the JDRF definition (which predates that launch by some time), it was a phase 1 device.

Commercial Systems

Well, we’re now coming towards the end of 2017, and commercially, we’re not that far forward, having moved from a phase 1 device in 2013, to a phase 2 device with the Medtronic 640G early in 2015, and in 2017, the Medtronic 670G has achieved somewhere between phases three and four.

As has been mentioned elsewhere, the tiny steps that have been taken forward by commercial entities have mainly been constrained by a conservative regulatory infrastructure that, reasonably, requires significant testing and demonstrable safety measures before anything is released to the general public, as it has to be usable by all, and not just the most driven to see change, although they may be early adopters.

Commercially, we know that others are working hard on Third Generation, phase 6 devices, with iLet probably being the most vocal about multi-hormone solutions. But that’s commercial systems.

“DIY” Systems

What of the “DIY” systems built by the WeAreNotWaiting community? Unconstrained by the same regulatory concerns that face commercial manufacturers, what has been achieved here?

As most people who follow this community will know by now, there are three systems that are in “mainstream” use. OpenAPS, Loop and AndroidAPS, so I don’t need to go into the detail of what they are and how they work.

What’s perhaps more interesting is to look at how they’ve developed over the past year, and where they fall on this scale.

Loop

Starting with Loop, from a personal interaction perspective, it is still the most beautiful interface and offers an incredibly simple interaction model. The Dynamic Carb Absorption model is very effective and has made living with it a lot easier, and the ability to run everything off your iPhone and Apple Watch is still a user experience that has only recently been matched. I think it’s fair to say it sets the bar in this respect though.

I think it’s fair to say, though, that the algorithm still requires user interaction around mealtime bolusing, even if that doesn’t require you to touch the pump, so while it does a fantastic job, based on the JDRF scale, I think we have to put it as a second generation, level 4 solution.

AndroidAPS

And what of AndroidAPS? At its core, it runs a version of the OpenAPS algorithm, with some other, additional features. Whilst it’s currently an implementation of oref0, oref1 is on the way. This will bring the “Super Micro-Bolus” (SMB) features on to a phone based system, which many of us have found to be incredibly beneficial. It also provides a similar interactivity model to that of Loop, in that there are both phone and watch functions that can both be used. In terms of level then, I think it can be classed similarly to Loop, and we can fairly put it at a level 4, Second Generation solution.

OpenAPS

Finally, we have OpenAPS. Earlier in the year, I wrote about the work to introduce the SMB features, and then how well this worked with Fiasp. In spite of the issues I’ve had with Fiasp, I’ve worked my way through them, and with the additional development work to enhance eSMB (which I wrote about here) even further, I think Scott, Dana and everyone who has been involved have achieved something quite special. How special? Well I’ll let the two pictures below speak for me.

In the first, I went out for a curry. The meal was a poppadom with chutneys, Chicken Achari Puri starter, then a main of King Prawn Balti and vegetable Ceylon with Pilau rice, followed by a couple of After Eight mints. We sat down, the food arrived and I estimated a 75g carb load. I IFTTTd that into the system, and left it to get on with it.

Due to the make up of curries, they generally have quite a difficult absorption profile, and when managed manually need multiple interventions. When the system takes over, this is the result:

Eaten late, and left overnight, what often happens is that you wake up in double figures. Not this time. You can see a lot of activity overnight as the enhanced SMB functions mop up the carbs, but the overall outcome, waking at around 7.5mmol/l (135mg/dl) is perfectly acceptable given the food.

So curry is a challenge. But then there’s Pizza. One of the trickiest meals to manage due to high carbs and high fat. This is setting a real challenge to the system, and at 100g carbs it’s not a small meal either:

The dog thought it smelled good. And this little lot is a recipe for glucose levels going up and staying up, requiring, typically, three or four interventions on MDI, or a very long combi-bolus on a pump.

With the latest round of oref1 though, we’re talking about simply telling it about 100g of carbs and leaving it be. Sounds too simple, doesn’t it? And yet, that’s exactly what I did. This was the result:

Now if we look at that, we can see that the time of pizza consumption had been preceded by some oddities. I’d inadvertently turned the rig off and not noticed, so the food announcement at around 18.30 wasn’t handled. I’d then rage bolused to stop the rise as I turned the rig on, then eaten chocolate covered popcorn to cover the drop (which is admittedly rather nice) before letting OpenAPS get back on with it’s stuff. So when I announced the pizza, I had IOB, historic COB and a whole host of other things going on.

After a couple of small microboluses, my glucose levels started to fall, not unexpectedly, before the pizza kicked in. Overnight, you see a pretty typical “Pizza Effect” being handled with additional SMBs. I haven’t totalled up the total units used. I’m not really concerned. What I like is that I woke up with a glucose level of 8 mmol/l (140mg/dl) and a peak overnight of just under 9 mmol/l (160 mg/dl) after eating pizza and doing absolutely nothing to manage it myself!!!! Not even a “Pushover” alert.

There’s the rub. I meal announced and left it. That’s it. I had to do none of the thinking about carb ratios, IOB, COB, what additional insulin I might need, whether I was going to bed, etc. I didn’t have to get up in the night to check glucose levels and see where they were at. I simply let it happen.

So, with Fiasp and this version of the algorithm, it appears that the requirement to bolus is eliminated, just as I predicted only a year ago.

To provide a little context, let’s take a look at the glucose distribution this has produced. Whilst two days isnt’ really a valid comparison, this is pretty impressive stuff:

On the clinical trial range, a tiny number of readings outside the thresholds, and the remainder of the indicators (aside from average glucose) showing non-diabetic numbers. Given the food choices, these are results that would blow most people away.

Whilst really fast onset carbs still need more up front insulin, even then, this version stops huge rises. This is a huge step forward in making life easier, and I think it qualifies the current iteration of this system as a level 5, second generation “Artificial Pancreas”.

In answer to the question posed at the start, “Defining an Artificial Pancreas. Where are we with “DIY” systems?”, I’d say we are a very long way along the JDRF’s scale. The latest features of OpenAPS, for me define it as a Level 5 system. This is a huge step forward.

Just think what we’ll be able to do with the possibility of real dual hormone solutions… Come on then iLet, let’s make access to your Dual Hormone device “open”, as the recent JDRF news suggested. It may get us to a Level 6 device much more quickly…