Some are retrospective studies based on real-world data; some are prospective or observational studies; and now, as of today, there is a published RCT (randomized control trial)  assessing safety and efficacy of the OpenAPS algorithm. This article was published in the New England Journal of Medicine (NEJM) in the September 8, 2022 issue.

You can find the article on NEJM here.

Key results:

• The mean time in range was significantly greater with the open source AID system used in the study (a modified version of the AndroidAPS app which uses the OpenAPS algorithm) — participants spent 3 hours 21 minutes more time in range each day than those with sensor-augmented insulin pump therapy (SAPT, meaning a pump and a CGM but no automated insulin delivery). Benefits with AID were seen among both children and adults. No episodes of severe hypoglycemia or DKA occurred in either group.
• The conclusion from the study is that among children and adults with type 1 diabetes, use of an open-source automated insulin delivery system (using the OpenAPS algorithm in a modified version of AndroidAPS) resulted in a significantly higher percentage of time in the target glucose range than use of a sensor-augmented insulin pump, without an increase in adverse events.

Dana Lewis has also written a plain language summary of the key takeaways from the study and provided some commentary on the impact of having an open source, patient-developed/community-developed system studied in an RCT and published in NEJM.

BACKGROUND:

A method to calculate changes in insulin needs was developed in the OpenAPS (Open Source Artificial Pancreas System) community. Individuals have natural fluctuations in insulin needs, but excessive periods of sensitivity or resistance may indicate ongoing physiological trends and therefore impact T1D management. It can be challenging for individuals with T1D to identify in real-time (or near real-time) factors that influence sensitivity/resistance, and adjust insulin dosing in response to the changing trends.

Autosensitivity (referred to as “autosens”) was developed as part of the open source, do-it-yourself hybrid closed loop (OpenAPS) to reduce the burden in responding to these changes in real life. It is designed to adjust proportionally to the changes in insulin sensitivity. It therefore differs from “Autotune”, which recommends adjustments to underlying ISF, carb ratio, and basal rates for insulin pump settings.

METHODS:

• Autosens analyzes each CGM data point for 24 hours, comparing observed change to expected impact from insulin.
• Autosens calculates the deviation for the median of the last 8 and 24 hours of CGM data points and determines the sensitivity ratio (SR) required to neutralize the median deviation.
• Autosens was run retrospectively to obtain an hourly SR value (first calculated SR every hour) for (N=1)*16 individuals using OpenAPS. There were 13 adults, and 3 kids (<18) in this data set.
• M = 5393 data points, range = 922 to 20,473.
• (Note: while ISF could be obtained for any time frame greater than 5 minutes, it was determined that one ISF calculation per hour was a useful sample rate to assess changes through the day.)
• A SR of >1.0 indicates resistance; <1.0 indicates sensitivity. Histograms were created to visualize SR for each participant.
• Mean SR ± SD was calculated and those falling beyond ± 10% of 1.0 were classified as being resistant and sensitive respectively.

RESULTS:

• Person 3 trended toward sensitivity [0.79 ± 16]; indicating underlying basal rates and other settings may need to be adjusted
• Persons 4, 9, and 16 trended toward resistance [1.2 ± 0.28; 1.33 ± 0.30; 1.41 ± 0.37]; indicating that an increase in basal rates and other settings may be of benefit.

CONCLUSION:

• Idiographic visualization of SR can be useful for detecting overall patterns of sensitivity/resistance potentially unaccounted for by the user’s pump settings.
• This approach can be useful for understanding real-time changes to adjust insulin dosing, as well as retrospective analyses to understand patterns of changes.
• Many dozens of individuals are using autosensitivity in real-time to automatically adjust insulin dosing as part of DIY-closed loop systems (OpenAPS and AndroidAPS).
• Future studies using the retrospective autosensitivity method to detect insulin sensitivity changes could be used on the following topics:
  • Understanding growth/hormone-related sensitivity changes, including better knowledge about the impact of the menstrual cycle
  • Better understanding circadian profiles and monthly variation of insulin sensitivity needs
  • Illustrating correlation with insulin pump site change patterns

—

You can find out more about OpenAPS here on OpenAPS.org, from the reference design to frequently asked questions (such as what hardware is needed and where the code and documentation can be found) and links to news articles on OpenAPS community. Documentation for individuals seeking to set up DIY closed loops themselves following the OpenAPS reference design is available here.

(If you’re at Scientific Sessions, please do stop by and ask questions during the poster session on Sunday from 12-1pm!)

—

BACKGROUND:

The #OpenAPS community is an active patient community that is developing DIY tools and resources for people with diabetes. There are over (n=1)*310+ people worldwide self-building various types of DIY hybrid closed loop artificial pancreas systems. As a result of observing hundreds of people in the OpenAPS community, we recognized that most people were relying on poorly tuned underlying insulin pump settings before starting a closed loop system.

Autotune, a tool for automatically tuning insulin pump basal rates, ISF, and carb ratios, was created in January 2017. Autotune was initially intended for primary use in pumpers who are using a DIY closed loop system, but was iterated upon to support non-looping pump users, and is also being used by people on MDI to help tune their basal insulin dosing. (Autotune can be used by anyone with a CGM who manually or automatically uploads insulin dosing and treatment (i.e. carb) data to Nightscout.)

How Autotune Works (Summary, see full details here)

• Insulin dosing and carb data, glucose data from CGM, and pump profile settings are used to calculate expected blood glucose impact (BGI) for each glucose value.
• Each glucose value is then categorized as being most attributable to basal, ISF, or carb sensitivity factor (CSF = ISF / carb ratio), and used to calculate adjustments to basals, ISF, and CSF.
• For each hour, total BGI deviations, and necessary adjustment in basal to bring deviations to 0, are calculated; 20% is applied to the previous 3 hours’ basals.
• Median deviation for entire day’s ISF-attributed data and necessary adjustment in ISF to bring the median deviation to 0 are calculated; 10% is applied.
• Total BGI deviations during observed carb absorption are calculated and compared to total carb intake to calculate new CSF; 10% is applied to the carb ratio.

Self-reported reflections from people using Autotune:

• (n=1)*16 people reported feedback related to their use of Autotune.
• 75% of surveyed users made changes to their insulin pump settings after running autotune.
  • 100% of people felt basal suggestions were accurate: 83% changed their basal rates.
  • They were less sure of carb ratio estimations (only 69% felt the estimates were accurate): 58% changed their carb ratios.
  • 88% of people felt ISF suggestions were accurate: 67% changed their ISF.
• On average in the surveyed population, autotune estimated a needed 10.24% average change in hourly basal rates (net 4.54% increase overall); 29% increase needed in carb ratios; and 19% increase needed in ISF.
• Patients felt strongly that using data to assess changes to pump settings should be the norm rather than relying on the current methods of guessing or weight-based estimations.

Other reflections:

• Most users planned to (or did) discuss Autotune results with their HCP. Most users reported their HCPs were interested and supportive in people using this tool.
• Most users expressed interest in a data-driven tool vs. relying on HCPs guessing about changes.
• Autotune currently works with a single ISF and carb ratio. There is interest from the community to adapt the tool to support use for multiple ISF and carb ratio. There is also interest to use data from this tool to confirm whether multiple ISF and carb ratios are needed or if they are proxies for mistimed insulin dosing at other times of day.

Conclusion:

• These data show many patients are using non-optimal settings.
• Pump users and HCPs could benefit from using this type of tool to help make ongoing changes to ratios and basals.
• The anecdotal number of individuals (hundreds) using this tool reflects the need for pump users and MDI users to have better tools to optimize basic diabetes therapy.

—

Autotune is available for use for anyone who is using Nightscout with CGM data and is uploading insulin and carb treatment information. You can find the documentation and information for using autotune in the OpenAPS documentation here. You can find out more about OpenAPS on OpenAPS.org, from the reference design to frequently asked questions (such as what hardware is needed and where the code and documentation can be found).

• Advanced meal assist (or “AMA)
  • This is an “advanced feature” that can be turned on by OpenAPS users. With reliable entry of carb information, AMA will allow the closed loop to assist sooner with a post-meal BG rise where there is mis-timed or insufficient insulin coverage for the meal. It’s easy to use, because the PWD only has to put carbs and a bolus in – then AMA acts based on the observed absorption. This means that if absorption is delayed because you walk home from dinner, have gastroparesis, etc., it backs off and wait until the carbs actually start taking effect (even if it is later than the human would expect).
• A preferences approach
  • This is the file where people can adjust default safety and other parameters, like maxIOB which defaults to 0 during a standard setup, ultimately creating a low-glucose-suspend-mode closed loop when people are first setting up their closed loops. People have to intentionally change this setting to allow the system to high temp above a netIOB = 0 amount, which is an intended safety-first approach.
• Autosensitivity
  • Autosens is a feature that has to be turned on specifically (like AMA) in order for people to utilize it, because it’s making adjustments to ISF and targets and looping accordingly from those values. It also have safety caps that are set and automatically included to limit the amount of adjustment in either direction that autosens can make to any of the parameters.
• Smaller rigs
  • Thanks to Intel, we were introduced to a board designer who collaborated with the OpenAPS community and inspired the creation of the “Explorer Board”. It’s a multipurpose board that can be used for home automation and all kinds of things, and it’s another tool in the toolbox of off-the-shelf and commercial hardware that can be used in an OpenAPS setup. It’s enabled us, due to the built in radio stick, to be able to drastically reduce the size of an OpenAPS setup to about the size of two Chapsticks.
• Setup script (!)
  • We created the oref0-setup script to streamline the setup process. For anyone building a loop, you still have to set up your hardware and build a system, expressing intention in many places of what you want to do and how…but it’s cut down on a lot of friction and increased the amount of energy people have left, which can instead be focused on reading the code and understanding the underlying algorithm(s) and features that they are considering using.
• Improved and easier documentation overall
  • The OpenAPS “docs” are an incredible labor of love and a testament to dozens and dozens of people who have contributed by sharing their knowledge about hardware, software, and the process it takes to weave all of these tools together. It has gotten to be very long, but given the advent of the Explorer Board hardware and the setup scripts, we were able to drastically streamline the docs and make it a lot easier to go from phase 0 (get and setup hardware, depending on the kind of gear you have); to phase 1 (monitoring and visualizing tools, like Nightscout); to phase 2 (actually setup openaps tools and build your system); to phase 3 (starting with a low glucose suspend only system and how to tune targets and settings safely); to phase 4 (iterating and improving on your system with advanced features, if one so desires). The “old” documentation and manual tool descriptions are still in the docs, but 95% of people don’t need them.
• IFTTT integration
  • … So you can use Alexa, Pebble, and other things to set temp targets (“eating soon” or “activity” modes); enter carbs, etc.

Looking to get started with OpenAPS? Check out the FAQ, read the Reference Design, and look over the OpenAPS documentation. You’ll want to bookmark the Gitter channel, and go there to ask questions about setting up your own DIY closed loop. You may also want to join the openaps-dev Google Group.

—

BACKGROUND:

Over a period of 16 months, over 81 patients (as of June 8, 2016) worldwide have built Artificial Pancreas Systems (APS) with off-label use of existing insulin pumps, continuous glucose monitors (CGM), and open source software (known as OpenAPS).

The patients have been using these systems outside of any clinical trial setting for more than 150,000 total hours.

OpenAPS is designed to be, and has been, far safer than standard pump/CGM therapy, as measured by duration of hypoglycemia and hyperglycemia, with no reports of severe hypo or hyperglycemic events.  It has allowed patients and caregivers remarkable improvements in quality of life due to increased time in range, uninterrupted sleep, and peace of mind.

COMPONENTS OF AN OPENAPS SYSTEM:

1. Continuous glucose monitor
2. Older model insulin pump that allows user to remotely set temporary basal rates
3. A “controller” device (small computer like Raspberry Pi or Intel Edison)
4. Battery or power source for the controller
5. A “translator” device to read/write to the pump (Carelink USB stick or TI radio stick, etc.)

SELF-REPORTED OUTCOMES:

At the time of the abstract submission, 18 users (out of 40 users total using the system at the time) shared and self-reported their data and experiences from using the system.

OpenAPS users (18 respondents, 67% male / 33% female, 61% adults / 39% children, median 27 years old (SD 14.5 years), 15 years with diabetes (SD 11.7 years), 10 years on pump therapy (SD 3.6 years), 3 years on CGM (SD 2.5 years)) were surveyed on quantitative and qualitative measures of their experience using their self-built APS.  While using OpenAPS, self-reported outcome measures showed median HbA1c dropped from 7.1% (SD 0.8%) to 6.2% (SD 0.5%), and median percent time in range (80-180 mg/dL) increased from 58% (SD 14%) to 81% (SD 8%).  All but one respondent reported some improvement in sleep quality, and 56% reported a large improvement.

Users caution that DIY APS implementations require significant effort to build and maintain, and pointed out that these systems cannot be considered a “technological cure,” but were extremely satisfied with the “life changing” improvements associated with using an APS.

DISCUSSION:

• Many users reported their health care providers (HCP) as being supportive, but some expressed disappointment at lack of interest from their HCP.
• These experiences are instructive for what patients can expect from commercial APS when they become widely available, and can help HCPs be prepared to set patients’ expectations properly when discussing or recommending an APS.

QUESTIONS FOR HCPs:

• Artificial pancreas systems are already here. One of your patients may already be building one. Would you know it if they are? Do you discuss with your patients which tools they choose to use to help manage their diabetes?
• APS are a powerful tool, but not a cure. Patients and HCPs will each still need to do a lot of work to use them effectively to improve diabetes management.
• Patients and HCPs must educate themselves and each other on how APS can be used effectively in daily life.

—

You can find out more about OpenAPS on OpenAPS.org, from the reference design to frequently asked questions (such as what hardware is needed and where the code and documentation can be found) and links to news articles on OpenAPS community.

The #OpenAPS community has made some amazing progress toward the end of this year. There are now, as of 12/31/15, (n=1)*22 people with DIY closed loops! (As of 4/28/16, it’s (n=1)*53!) And as always, several others in the testing and development phases, so this number will continue to grow.

(If you’re new to #OpenAPS, we encourage you to check out the reference design, which is now also posted in Github alongside our documentation so you can track changes as it evolves. If you’re starting to close the loop for yourself, or are thinking about it, we invite you to join the OpenAPS-dev google group, and pop over to the #intend-to-bolus channel on Gitter and introduce yourself there. This is the best place to see works in progress, ask questions and get help, or get pointed to various projects. And of course, read the publicly available documentation here to get an overview for the steps of closing the loop.)

There are several iterations and works in progress around both software and hardware to support the vision of #OpenAPS. Originally, #OpenAPS was implemented with an older version of a Medtronic pump and a Raspberry Pi and a Carelink stick. As you’ll see below, there’s been progress made communicating with other pumps; variations on hardware for how to communicate with Medtronic pumps; and iterations on software such as an improved algorithm option to better support meal times.

Hardware update:

• One of the most frequent questions we get is “what pumps can be used with #OpenAPS?”. The answer to that question is explained here in the documentation, but there’s work in progress being made with other (non-Medtronic) pumps.
  • Notably, Marius has made progress with the RF communication protocol with the Animas Ping pump. See his Vine here showing it in action! He’s demonstrating pushing button on the pump remote so the packets are picked up by a CC1110 and the iOS app communicates over BLE to get packets which are buffered by a nRF51. (His goal is to create a custom hardware setup to enable communication from a phone to the device to the Animas Ping in order to close the loop. Here is a picture of what the demo equipment looks like.)
  • There’s also a group of folks working to do the same work to understand the OmniPod pump communications. If you’re interested in this body of work (OmniPod, Animas, or working on another pump), click here to join the Slack collaboration channel where this conversation is happening.
  • The DANA R pump is also being successfully used in some loops; although it is not documented yet, so does not show up on our official list (see our hardware docs) yet of pumps. (The DANA R is not yet FDA-approved, so it’s only available outside the US.  It also uses a proprietary battery, so keep this in mind if you are evaluating this pump for loop reasons; the frequent communication a loop requires will draw more battery than standard operations. This is true for all pumps, but AAA batteries are a little more universal than the DANA R batteries.)
• The next question we get is “Do I have to use a Raspberry Pi and a Carelink stick?”. The answer to that is, no! You don’t have to use anything you don’t want to. Use what you can make work. Which until now…has mostly been a Raspberry Pi (or a laptop) and a Carelink stick. However, there are limitations with the Carelink stick (notably, the range (~3 feet)) and also the Pi (complaints center around power consumption and physical size). This, however, is changing:
  • Although not in the mainstream OpenAPS docs yet, Oskar has been working on a physical setup option that will allow you to skip the Carelink stick and/or the Raspberry Pi. This setup is quite a bit smaller than the Pi/Carelink combo, and he’s got another version in progress that could be even smaller! That being said, please note that it’s a work in progress and will involve more work than simply buying a Pi and a Carelink in order to close your loop. Check out pictures and descriptions here, and the project’s Gitter channel here.
  • Also not in the mainstream docs: Andrew has put together a more compact case for the Raspberry Pi and it’s necessary components. Similar to the above project, it’s much more involved (desoldering, etc.) than the standard setup. (While he has recently closed the loop using a custom algorithm and the openaps toolkit to pull data from devices, bolusing with a pump remote as noted in his link above is not an approach that follows the OpenAPS reference design. Check out the OpenAPS reference design for more about the recommended approach of only utilizing temporary basal rates for safety reasons. Andrew has also done an excellent writeup contrasting the differences in his system.)
  • Another option we’ve mentioned before that is still a work in progress is the RileyLink, which is a custom designed Bluetooth Smart (BLE) to 916MHz module. It can be used to bridge any BLE capable smartphone to the world of 916Mhz based devices. This project is focused on talking to Medtronic insulin pumps and sensors (to replace using the Carelink stick, thus improving the range).
• What about [question about various CGMs]?
  • Some loopers are using a Medtronic CGM and incorporating the data into their loop. It’s not well documented in the docs (mostly references Dexcom G4), but multiple people are using it; same for using xDrip.
  • Dexcom G5 has been confirmed to work if you plug the receiver into the Raspberry Pi (same as Dexcom G4, with or without SHARE). (Details buried in this thread.)
  • Some oref0 implementations are set up to retrieve glucose data directly from Dexcom’s Share servers when the receiver is not plugged in to the Pi (but the Pi has Internet connectivity).  This is also not well documented yet. The same is true for pulling glucose data from Nightscout.
  • Additionally, Nate recently announced xDripG5, which will allow development of a non-Dexcom iOS app that can communicate via BLE with the G5 transmitter.  This could in the future allow a completely offline iPhone-based closed loop system using something like the RileyLink or CC1110.

Software/algorithm update:

• We originally began with “openaps-js” as the backbone of the loop in #OpenAPS. If you haven’t checked out Github in a while, or are wondering what the code looks like, make sure you take a look at the “oref0” repository. As of the time of this post, the most recent release and master branch is oref0 version 0.1.2. This includes some cleanup / refactoring in the code; the addition of tools to make it easier to upload information to Nightscout / elsewhere for visualizations; a fix to IOB calculation; and using “expected delta” as a calculation instead of BGI/2 to improve what the system does if someone is very high when they start looping and/or if they are riding flat and high over a period of time.
• There are some significant additions coming in the development branch of oref0. This includes what we call “meal-assist” (or in cases where you’re rising for no obvious reason, and you haven’t eaten a meal, what some are unofficially calling “wtf-assist”).
  • As noted in the reference design, #OpenAPS is not intended to replace meal boluses. Instead, #OpenAPS has a “bolus snooze” so that it would not interfere with your meal bolus, and would otherwise kick in more if needed after a time period (scaling down based on DIA/2). However, some people still wanted #OpenAPS to do more, so we’re experimenting with the meal-assist option to step in sooner if certain conditions are met (if it is alerted by using the bolus wizard on the pump that carbs are involved in a bolus). Meal-assist will kick in if there are more carbs than insulin, and based on IOB and changes in BG when more insulin is needed.
  • This is an option that people will likely have to specifically enable in their system in the future, if it makes it to the master version of oref0. It is meant to support larger meals where a person can’t do all of their meal bolus up front based on the timing of insulin absorption and carbohydrate absorption rate. It still will not replace a meal bolus (the user must still do an original meal bolus, and must enter carbs by using the pump’s bolus wizard in order to trigger the meal-assist feature), but it will help sooner if more insulin is needed over the course of carbs absorbing from a meal.
• As these features are tested in individual branches; tested more thoroughly in our development environments; and eventually move to the master branch of oref0. We will continue to update the reference design of OpenAPS accordingly so that is is always aligned with the released version of oref0 and vice versa.

What’s next?

Two obvious areas of focus overall this year have been reducing the size/improving the portability of the hardware needed for the loop, and improving the range of devices to better and more efficiently communicate with pumps. As we head into 2016, this community will likely have dozens of other iterations and improvements in hardware, software and protocols (for example, deciding on a common BLE service so that all hardware in this community can easily be interchangeable), all in pursuit of the #WeAreNotWaiting vision of OpenAPS (an open and transparent effort to make safe and effective basic Artificial Pancreas System technology widely available, to help reduce the burden of Type 1 diabetes).

We encourage you to get involved if you are interested in closing the loop for yourself or interested in contributing to the various pieces of hardware, software, and protocol projects. Please contact us at @DanaMLewis ([email protected]) and @ScottLeibrand ([email protected]) if you have questions or ideas about how to contribute to #OpenAPS – we’d love to hear from you! (You can also follow and connect with the community on Twitter at #OpenAPS and @OpenAPS.)

The Open Artificial Pancreas System (#OpenAPS) is an open and transparent effort to make safe and effective basic Artificial Pancreas System (APS) technology widely available to more quickly improve and save as many lives as possible and reduce the burden of Type 1 Diabetes.

Background on the current state of diabetes management

Type 1 diabetes (T1D), an autoimmune disease that destroys pancreatic beta cell functionality, is treated using injections or infusions of synthetic insulin. Insulin is a potentially lethal drug whose dosing must be constantly adjusted based on blood glucose (BG) levels, meal content, activity levels, and many other hard-to-measure factors. Even with state-of-the-art technology (insulin pumps and continuous glucose monitors (CGMs)), every person with T1D (or their caregivers, as T1D often manifests in children) has to make approximately 300 decisions a day related to their diabetes self-care to have any chance at all of mostly avoiding short-term sickness and preserving long-term health. And nearly everyone with T1D, and all their loved ones, live with the ever-present fear that they may not wake up in the morning as a result of severe hypoglycemia. These are incredible burdens for every person with T1D: because treatment is so difficult, even the most diligent, successful, and lucky patients with T1D have both an elevated risk of death from acute hypoglycemia (low blood sugar) and a high rate of complications and early death from acute or usually chronic hyperglycemia (high blood sugar).

Patients are shaping the future of diabetes management

Many patient innovators, industry non-profits, and some device makers have begun backing recent open-source efforts by patient innovators and others to help drive faster innovation in technology for treating T1D. These efforts have been centered around the #WeAreNotWaiting movement, and have gained broad public support and involvement through the CGM in the Cloud group on Facebook. The Facebook group has 10,000+ members, and over 2,000 of them have installed and are actively using an open source project called Nightscout to remotely monitor CGM data. In addition to meeting a very real need in the community, this effort seems to have accelerated the path to regulatory approval and widespread market acceptance of similar FDA-approved commercial solutions. For example, the Dexcom Share was in development for a couple of years and submitted to FDA for approval before widespread adoption of Nightscout, but only recently approved by the FDA, initially as a medical device (a cradle for overnight use) and quickly thereafter as a mobile medical app approved under a de novo application that will pave the way for future products to transmit and display data without requiring FDA pre-market approval (just registration and listing).

Why #WeAreNotWaiting

In order to relieve the incredible burden of T1D, many research teams and manufacturers have developed and are testing Artificial Pancreas Systems (APSs) that connect CGMs to insulin pumps and use various algorithms to automatically adjust insulin dosing (and sometimes dose glucagon, a counter-regulatory hormone) to attempt to mimic some of the functions of a healthy pancreas, and keep blood sugar levels in a safe range. While quite successful in clinical trials so far, current APS systems have been in development for many years, and are still likely at least 3 years away from FDA approval. It is also unclear whether first-generation APS technology will be suitable for, or available to, all patients, even in rich countries.

Why we are building our own DIY Artificial Pancreas Systems

Additionally, some of the patient innovators involved in the #WeAreNotWaiting movement have gone a step further, and have figured out how to connect up existing FDA-approved medical devices such as the Dexcom G4 CGM and the Medtronic Minimed insulin pump, using commodity computer / mobile phone hardware and open-source software, to create a complete closed loop Artificial Pancreas System (APS). The first public example of this was the #DIYPS closed loop system, created in their spare time by @DanaMLewis and @ScottLeibrand in the fall of 2013 based on their earlier work to build the #DIYPS remote monitoring and decision assist system. Shortly thereafter, another independent researcher (@bustavo) created and announced the #simPancreas, an independent implementation using solely Medtronic CGM data and the Medtronic pump.

#DIYPS uses the Nightscout project’s uploader to get Dexcom CGM data off the device. Both #DIYPS and #simPancreas use the open-source decoding-carelink project created by Ben West (@bewestisdoing) to communicate with Medtronic insulin pumps, retrieve data and issue insulin-dosing commands to pumps that support it. In addition to those of us who’ve gone public with our work, there are up to a dozen independent researchers currently implementing DIY insulin control systems of various sorts based on Ben’s work, and probably many more who’ve been working completely independently and have not yet shared their work publicly.

Often, word of systems like #DIYPS are met with interest and a lot of questions – mainly, does it work, and how safe is it? Initial results for #DIYPS closed loop (for n=1) have been excellent, with improvements in time in range, a reduction in time spent low, and a dramatic reduction in overnight alarms.

Now is the time for #OpenAPS

In light of recent success of #DIYPS closed loop and other simple APS systems built by individuals, we have decided that now is the time to further apply the #WeAreNotWaiting ethos to APS research. We believe that we can make safe and effective APS technology available more quickly, to more people, rather than just waiting for current APS efforts to complete clinical trials and be FDA-approved and commercialized through traditional processes. And in the process, we believe we can engage the untapped potential of dozens or possibly hundreds of patient innovators and independent researchers and also make APS technology available to hundreds or thousands of people willing to participate as subjects in clinical trials.

At the end of the process, we hope to have produced an  #OpenAPS reference design and reference implementation that can be used by any individual with diabetes who has the necessary medical equipment and is willing to build their own system – and potentially one day have an FDA-approved algorithm that can be implemented or utilized by medical device manufacturers with minimal additional regulatory burden. We believe this will in turn allow manufacturers (and the academic research teams they work with) to turn more of their attention to designing and testing more advanced APS systems, and thereby accelerate the pace of innovation toward new and improved Type 1 diabetes treatments, and eventually a cure.

But most importantly, in the mean time, it will make basic overnight closed loop APS technology more widely available to anyone with compatible medical devices, thereby reducing the burden of Type 1 diabetes on everyone who lives with the disease.

So what exactly is the #OpenAPS?

The #OpenAPS is an open reference design for and a reference implementation of an overnight closed loop APS system that uses CGM sensors’ estimate of blood glucose (BG) to automatically adjust basal insulin levels, in order to keep BG levels inside a safe range overnight and between meals.

#OpenAPS is not intended to be a “set and forget” APS system. To maximize safety, #OpenAPS only doses basal insulin (not boluses), so patients still need to bolus for meals as they do today. However, #OpenAPS will estimate the size of a meal based on pump-entered carbohydrate counts or based on BG and bolus size, and can adjust basal insulin to help predict and prevent/mitigate any dangerous drop or rise in BG after a meal bolus has taken effect.

For more information on the #OpenAPS design philosophy and details, read more about the #OpenAPS Reference Design.

#OpenAPS will be an open source project

In addition to being a usable Artificial Pancreas System, #OpenAPS is also a project founded on open-source and open-science principles. All versions of the #OpenAPS design are, and will remain, open source: free for open source projects, researchers, and non-profits to use, and available on an open and non-discriminatory basis for all commercial manufacturers to use in proprietary products if desired.

Because #WeAreNotWaiting, #OpenAPS will be initially developed through the collaboration of multiple independent researchers performing their own n=1 studies and publishing their results in open-access journals / databases, where they can be aggregated through meta-analysis. In addition, the #OpenAPS project is now seeking partners with expertise in performing formal phase II/III clinical trials under IRB and IDE approval, to perform randomized clinical evaluations of #OpenAPS in human subjects who are not themselves independent researchers. In keeping with the goals and principles of the #OpenAPS project, we will seek to design the trials to be as open and inclusive as possible.

For more details on our approach to testing, clinical trials, and getting regulatory approval for #OpenAPS, read the #OpenAPS Testing and Clinical Trial Vision.

How you can help with #OpenAPS

We are well along in developing a basic #OpenAPS system (as you can see from the #OpenAPS Reference Design and the “oref0” reference implementation on Github), but we are just getting started on the road toward building a movement of like-minded people, and making #OpenAPS a reality for more people, so we need your help.

• If you are someone who wants to engage in cutting-edge medical technology development, we need your help. (If you have a personal connection to T1D, that’s a great motivation, but it’s not a requirement by any means.)
• If you are with a medical device company that wants to help accelerate the pace of technological improvement for patients, we want to collaborate with you.
• If you have experience with formal clinical trials, especially of APS or similar systems, we’d love to talk to you.
• If you’d like to talk about how to fund the #OpenAPS project, we’re all ears. We will almost certainly need funding to start formal clinical trials.
• If you or someone you love has T1D and you’re not already using Nightscout to remotely view and share BGs with loved ones as needed, join the CGM in the Cloud Facebook group or visit Nightscout.info to get started.
• If you’d like to stay up to date on progress toward an #OpenAPS, you can join the OpenAPS-info mailing list and follow @OpenAPS, @DanaMLewis and @ScottLeibrand on Twitter.
• If you’re a developer or independent researcher interested in getting involved, please join the OpenAPS-dev Google Group and review the available OpenAPS documentation on Github.
• If you’re still reading this, you undoubtedly have other skills that can be applied to this project. Let us know what you can and would like to do: the more help we can get the faster we can get to the goal of #OpenAPS technology for everyone with T1D.

Please contact us at @DanaMLewis ([email protected]) and @ScottLeibrand ([email protected]). And #OpenAPS is of course a hashtag: please use it to join the conversation on Twitter.