Indeed. The lower power consumption would make the DIYPS more efficient. Congrats to Dana and Scott! :)

Happy and Healthy New Year!

I don’t think so…notice that there are *3* USB devices connected. A Pi Zero would require adding a hub, and that would make the whole thing more complex. Better a B+ or Pi2B to begin with.

It probably comes under “practicing medicine without a license”, or just a medical device that hasn’t gone through FDA regulated tests and trials (which take years and cost millions of dollars).

If it were published, it would probably have be in some 3rd world country with lax or non-existent medical device regulation.

You don’t want people who don’t know what they’re doing just going out and buying the pieces, not following the instructions correctly, and then someone winds up in a diabetic coma, or worse. Even a typical doctor may not feel qualified to determine whether what they’ve done is appropriate, not because of the medical aspects, but due to the medical/technical boundary being crossed. There are very few people with enough expertise in both fields to evaluate this for use by people who aren’t as sophisticated as Dana and Scott, and they’re going to tend to work for device manufacturers and/or medical research organizations.

The good news is that by collecting sufficient data and demonstrating a very high level of benefit, folks like Dana and Scott are helping to accelerate the likely FDA approval of this technology. However, first, a lot of very important questions need to be answered, most of which have to do with “corner cases” in testing, especially in the reliability realm. A Pi and the software available is not something you’d want operating the autopilot on a commercial airliner because it was never designed for that level of reliability, and if I were a patient, I’d want something that has at least been banged on by someone without a horse in the race (a neutral observer) with a lot of experience in what can go wrong with such devices.

This is especially true in that there are a _lot_ of moving parts in this system that may not yet have undergone the total-system scrutiny you’d really want to do to not only verify proper operation, but identify precautions that must be followed. I’d guess that power reliability would be very high on the list, e.g., is backup battery power good enough for hands-off continued operation, or should an alarm sound/flash when primary power is interrupted? Should there be an independent monitoring system that ensures that none of the various components have locked up (e.g., a system “heartbeat” monitor that doesn’t rely on any of the operational system’s components)?

You don’t want the insulin pump to be told to not deliver any more insulin ever, or to pump the maximum amount for an unlimited period of time, and there are a lot of cases where that might be possible that have to be eliminated, or an alarm might need to be tripped if a monitoring system detects this seems to be happening. Murphy just loves this sort of problem domain … in spades.

Still, it is very exciting to see this and I hope that evaluation can be performed expeditiously and thoroughly to benefit many people. A friend my age passed away after struggling with managing wildly-varying blood sugar levels her entire adult life, despite careful monitoring and dietary precautions. While due to Type 2 (adult-onset) diabetes associated with child-bearing, it eventually caused wounds in extremities that couldn’t heal, deteriorating retinae, and eventually a brain hemorrhage that was the last straw.

You can find tools to interface with your Carelink here: https://github.com/bewest/decoding-carelink (Big kudos to Ben West for his work for many years on understanding communication with Medtronic pumps, which enabled us to close the loop!)

You should come join our mailing list and/or Gitter chat room. There are a ton of tools our community has built that you’d find useful (many at https://github.com/openaps).

Rupert, good questions!

1. Would it work well for other people?
A: With #OpenAPS, there are now 22 other people (as of 1/4/16) who have built a system for themselves and are seeing similar results.

2. Sleeping with gear strapped on?
A: You don’t wear anything strapped on your body; you’re already wearing the pump and CGM, but the rest of the system can be under the mattress or on a bedside table. The range of the Carelink stick isn’t terribly far, but the average ~3 feet is good enough to work from sitting beside you on a desk or in a backpack or on a bedside table.

3. With regards to the accuracy of the CGM, it seems to vary by CGM. The Dexcom G4 with the 505 algorithm on the receiver is good enough for many people to choose to use in an AP setting. But even with that, the system has to be designed to take into account occasional fluky data, such as “compression lows”, missing data, etc. If you’re interested, you can read more in our reference design to see how we’re addressing that & other safety considerations: https://github.com/openaps/docs/blob/master/reference-design.md

Rupert, I too am a type one diabetic for 45 years. I also work in software development which must comply with certain safety standards, so you’re right in that there is real risk for anyone to implement. It’s great that Dana has achieved such good results, however for those of us living in the UK, CGMs are just not available except in extreme cases. That said, the DAFNE process is in use in many European countries (Dose Adjustment for Normal Eating) which is a very simple closed loop system where you measure your blood glucose level before each meal and simply dose according to the carbohydrates about to be taken together with +/- adjustment based on the result. What would be interesting is to know Dana’s HBA1C results before and after to demonstrate the improvement. Also with respect to other diabetics (22) taking this up Dana, how did they tune/calibrate their systems? A great effort though, many congratulations. This has to be the future of diabetic control. One final point regarding SD card corruption, have you thought about formatting into a number of blocks. Writing to each in turn, use a checksum to confirm successful write and then mark as current. If not retry a number of times and in event of failure either mark block as faulty and try another. Last case is overwrite the current block but this risks losing your data. (I could probably have worded that better).

Having the data unecrypted, while beneficial to you to get this to work, should be viewed as a bug, not a feature.

Awesome, Steve! Please make sure to include Ben West in your story – he spent MANY years working to understand the communication between the Carelink stick & the pump, enabling us & so many others to do everything from better understand our existing devices to closing the loop as described above. Without his work, and without the contributions of many others to this project, we wouldn’t have this today. It’s truly a community project and a community effort.

Gordon, good question. If the battery for the Pi dies, or you go out of range of the system, or the SD card in the Pi gets corrupted, or (insert any number of failures), your pump simply resumes ‘normal’ operations. This means reverting to the pre-programmed insulin rate, which is standard of care/normal insulin pump operation.

We designed the system knowing that the battery might die unexpectedly, etc., and so instead of doing “boluses” (short bursts of insulin at one time, which can’t be counteracted easily without having to intervene and eat something), we issue temporary basal rates in increments of 30 minutes to alter the pre-programmed rate. If the BG rises, the rate is incrementally higher. If BG is dropping, the rate is lower as needed. *And*, the rate issued is the absolute safest thing to do based on past data and projections well into the future, assuming it could be the last command that the system receives. Thus, the system is often conservative, but if it is in range, will re-issue a command the next time it reads (~3-5 minutes) and continue the cycle.

You can see more about how this design is implemented by taking a look at our reference design here: https://github.com/openaps/docs/blob/master/reference-design.md

The Medtronic pumps only use serial number as security for their wireless connectivity.

It has already been proven by a security researcher that the medtronic devices can be controlled fairly easily, including giving dosages from a computer with the relevant hardware.

My one query is, with the CGM and the bolus wizard, there already is a loop of sorts here. Ok this takes the manual element out of it, so is extremely useful.

Elijah: would love to have you join us and build your own OpenAPS system. You don’t need to already know how to code, though you’re correct that an eagerness to learn new skills is essential. There have been several people with no coding experience who learned how to use the Pi and implement their own system with little or no help.