Program Information
OmniCore RADD was originally meant to be released together with the launch of OmniCore Oyster. However, release of Oyster has been postponed and is still in progress.
The RADD algorithm in the meantime has been consistently providing excellent results and reached a maturity stage deemed fit for public use.
In order to allow patients and caregivers to experience RADD sooner than later, we decided to make necessary modifications to the OmniCore software platform and release it as part of an early access program, since the new hardware that brings extended features to OmniCore and RADD in general, won't be available during this phase.
Is the software in alpha or beta status?
Yes, Yes and No.
All core components that make up RADD (algorithmic components, data processing, storage, cross communication) are extremely stable and have been thoroughly tested.
OmniCore Mobile App is in beta status, the required architectural changes for compatibility with legacy hardware is at the moment in testing.
OmniCore Website (account details, settings, profiles, dashboard) is in alpha status and is actively developed.
Program Features
Following your entry into the RADD early access program, you will be able to use the OmniCore Web application and install the OmniCore mobile app on your devices.
Your profile will be synchronized in realtime across your devices and you will be able to remotely / locally control pods on your account.
You will have access to full functionality of OmniCore RADD except for the limitations mentioned below.
What's Next
Following features are currently in testing and will be gradually made available as additional opt-in programs.
Glucagon Infusion
Divergent decision functions
Third party integrations
Certain features are in the development pipeline and will be introduced gradually. Among them:
Omnipod Dash support for the OmniCore App
Parallel / Redundant infusions
Heart rate and activity integration
Stochastic site failure detection
Simulation reports: Carbohydrates, Metabolic profile, Insulin effect
Performance reports: Outcome evaluation of prediction and decision functions
If you want to learn more or have questions, get in touch with us: omnicore@balya.net
Program Limitations
The financing of the early access program is completely out of our pockets, and that is severely limited.
As it is very difficult to estimate demand and align server capacity, certain limitations are put on the system that apply to the early access program, most notably to availability and performance.
You can help keep the program alive, increase capacity and performance by donating to the OmniCore project. Monetary donations as well as credits for cloud computing resources will be most useful and welcome.
We intend to keep the early access program freely available as long as humanly possible.
Availability Limitations
Access to the program will be granted to users in batches. That will allow us to carefully review existing capacity and determine the required expansion.
Currently we estimate a threshold of 24 program entry requests to warrant an expansion of server resources, but that might change. Once the threshold has been reached, it will take about a week for your account to get activated. You can see the current threshold, your position in the waiting queue and an estimated starting date in your account profile.
If you have previously donated to either of the OmniCore or Omnipy projects, your entry is already pre-approved and you should have received the details via e-mail. If not, let us know.
Performance Limitations
For the same cost optimization reasons as stated above, there will be an observable performance degradation for some tasks. This will be notably visible in the following:
First optimizer run
This is the pre-requisite to start looping, where RADD will go through a lot of past data and create an initial profile. Unless insulin type has been changed, it will run only once for each user.
This might take up to 24 hours to complete, as it will use reserve capacity.
Loop processing time
This is total time it takes to reach a decision after a new BG value is received. We expect this to have a mean duration of 90 seconds, within a range of 30 to 180 seconds. The expected variability is due to the nature of differences in the range of possible algorithms that will be different for each individual, and not due to variances of server load.
While it's not ideal, the increased time to decision will not negatively affect the RADD algorithm, so long as it doesn't stretch beyond the CGM data frequency.
The CGM update frequency for Dexcom Sensors is currently once every 300 seconds.
Note on Continuous Optimizer performance
Continuous optimization is a core function of the RADD algorithm and lays the groundwork for both its reactive and adaptive abilities.
It is also the most computing intensive function, as the optimizer runs wide parameter searches and performs functional evaluations for 3 drastically different subsystems. The work is normally prioritized based on the starting model with respect to error rates reported by each subsystem.
Time to output for the optimization function is dependent on the complexity of the problem and its dependencies. It's therefore difficult to quantify, what is good enough and what isn't.
Due to limitations on the available processing power, the optimization function will take a hit when compared to an ideal setup.
In order to minimize the effect on the overall qualitative performance of RADD, this function will run in higher priority than everything else, thus resulting in decreased performance of other functions such as described above.
Profile Limits
As a convenience for parents and other caregivers responsible for several T1D patients, OmniCore provides the ability to define multiple profiles on your account.
In order to save processing power and space, each OmniCore account will be limited to a single profile in the early access program.
You can however log in to your account on an unlimited amount of OmniCore clients (mobile devices) to manage the profile, execute pod actions, modify RADD configuration and alike.
Note: This is not to be mistaken with "profile"s found in other closed loop systems or in settings of pumps (e.g. Basal Profiles, Sensitivity Profiles etc). In OmniCore RADD, the notion of "multiple profiles to account for different situations" does not exist.
Each profile corresponds to an individual and each individual has exactly one profile.
Pod Connections
Due to RileyLink's hardware and firmware design, following must be taken into consideration while looping or manually executing commands on the Pod:
Robust connections to the pod cannot be guaranteed. If the BLE link between the RL compatible device and the managing android device breaks up during command execution, it might lead to unrecoverable pod errors.
Depending on the internal antenna configuration of your RileyLink; connection and command execution time on the pod might be significantly increased in contrast to the Omnipod PDM or the OmniCore Oyster, allowing more room for the error case described above.
Even though you can have multiple RL compatible devices connect to an OmniCore client, the mesh radio feature (increasing range with multiple devices) will not work.
CGM connections
We are heavily opinionated on NOT running mission critical applications on a mobile phone operating system such as Android or iOS.
We have invested a lot of time into developing the OmniCore Oyster, a capable device that isolates the complexity of communicating with external devices (Pods, CGM Transmitters and more) and provides a simplified interface to applications. So radio communications can be resilient and apps can be apps. Neither of them wasting effort to work around the restrictions of their environment.
In order to make the RADD program accessible to the public early, the OmniCore Android app compromises on this principle by keeping an unattended BLE connection in the background and perform continuous data exchange during pod command execution.
We believe that expanding the functionality of the mobile app by adding direct CGM reading support would further compromise the reliability of the system and end up hurting users.
For this reason, the early access program requires you to install an additional app (such as xDrip or Dexcom Mobile) and let OmniCore access the CGM readings indirectly.
Omnipod Dash
The same principle above applies to communicating with Omnipod Dash via BLE.
However we do acknowledge the demand for Omnipod Dash support. Additionally a direct BLE connection is less likely to fail, when compared to the dual failure pathway involving the RileyLink & OmniPod Eros.
To that end, if the launch of OmniCore Oyster (which supports the Omnipod Dash out of the box) gets further delayed; its Dash communication code will be ported to the Android environment and integrated into the OmniCore client app.
Service interruptions
During the early access period, you may experience brief service interruptions at times of upgrades and development related actions. Under certain circumstances, you may have to update the OmniCore App to continue using the service.
Future of Development
RADD may perform quite well, but our work is not done.
Even a tiny improvement can have a huge impact on our lives. So, why not.