Open-source automated insulin delivery (AID) systems collect a rich array of data and the sheer volume and complexity can be daunting. For providers unfamiliar with these platforms, it's not always clear where to start or how to make safe and meaningful insulin adjustments. While each open-source algorithm (Loop, Trio and AndroidAPS) uses different logic and settings, the clinical foundation remains the same. Providers should still identify patterns in the data in order to make appropriate adjustments to insulin settings and limits. Diabetes Care and Education Specialists (DCESs) play a key role in guiding patients to interpret reports, recognize trends and analyze the data to optimize glycemic outcomes.

Understanding the Data Ecosystem

Nightscout is the data platform typically used for Loop, Trio, and AndroidAPS.  Nightscout is also an open-source project that is customized for users. It is a real-time web-based platform that displays all CGM and insulin data along with meal entries and custom overrides. All variables that may impact the algorithm’s decision-making process are shown. Nightscout provides the richest depot of all open-source data and highlights how insulin delivery is being adjusted.

Tidepool, an FDA-registered data platform, can also import open-source data. Tidepool imports information from either Apple HealthKit or Android health data services, depending on the smartphone being used by the open-source user. Tidepool also generates reports from CGM data and insulin delivery but does not have a real-time website display like Nightscout.  Notably, while Tidepool is not an open-source platform; it can be easily downloaded and connected to an open-source app with little effort. Tidepool also has a clinic portal that can be incorporated into a practice as part of data analysis for most AID systems, not just open-source systems.

Additionally, since each open-source system runs from a smartphone app, data can and does collect into Apple HealthKit and Android health data services. As such, additional metrics like average carbohydrate intake and total insulin delivered can be evaluated for trends and patterns.

Each open-source system also displays a rich set of data points within the apps themselves. There is real-time and retrospective history within the apps, but this is typically displayed only for a limited period of time.  

Making Informed Adjustments

To a certain extent, open-source systems lack the “guardrails” that are present in the commercially available systems. While not common, there is potential for users to make setting changes (intentionally or inadvertently) that may be inappropriate. Checking insulin delivery and algorithm settings at each interaction is suggested.

Loop, Trio and AndroidAPS have many settings and safety limits that will reduce or increase insulin delivery in very specific ways. Yet, the basics still hold true: If frequent post-meal spikes or repeated correction boluses are observed, the carb ratio or insulin sensitivity might require adjustment. Overnight patterns of lows or wide basal fluctuations may indicate the need for basal adjustments. Blood glucose targets set too high or too low can prevent the algorithm from achieving ideal time-in-range. Additionally, insulin timing and behavioral patterns should continue to be assessed.  As best practice, adjustments should be made in small (~10%) increments and based on repeated patterns, not isolated events. DCESs can guide users in making these changes thoughtfully, reducing the risk of hypoglycemia and boosting confidence in the AID system.

The Role of the DCES

DCESs are in a unique position to help translate data into safe and actionable changes. Emphasizing pattern awareness over one-time excursions can help reduce diabetes burnout and keep adjustments within a safe and structured framework. As in all diabetes technology, it is best practice for the DCES to frame setting changes as part of normal optimization rather than failure of the (open-source) algorithm.

Practice Pearls from Diabetes Care & Education Specialists

• Focus on identifying patterns, not perfection. A day or two of glucose excursions should not trigger broad adjustments unless they are part of a consistent trend.
• Look beyond Time-in-Range (TIR). Frequent overrides, correction boluses, or basal changes can be a sign of user frustration or less than optimized settings even if TIR appears at goal.
• Encourage reflection on the current system settings. Frequent user interventions may indicate a need for further customizations of the open-source system.
• Fundamentals are still key. Open-source platforms allow for a highly individualized approach, but self-management fundamentals (food quantification, timely bolusing, lifestyle choices) are still the basis for optimization.  

Helpful Resources

• Nightscout: 
• Tidepool for Clinicians: Clinician Onboarding Resources – Tidepool
• Data for Loopers