Mobile Software Development Kit for Real Time Multivariate Blood Glucose Prediction

In the field of blood glucose prediction, the literature is abounded with algorithms that demonstrate potential in glucose management. However, these propositions face an issue common to many machine learning algorithms: the repeated reuse of datasets (overfitting) and a tendency to develop algorithms in isolation, detached from practical scenarios. Compounding these challenges is that many insulin pump vendors and continuous glucose monitor vendors use closed and proprietary protocols, restricting researchers’ data access and the ability to deploy complex, multivariate optimizers. This study seeks to bridge the gap between theoretical algorithms and their real-world applications by devising a software development kit. This kit collects real-time data from continuous glucose monitors, carbohydrate intake, insulin deliveries from insulin management systems, and metrics like physical activity, stress, and sleep from wearables. Our methodology leverages the open-source insulin management system, Loop, integrated with Apple Health and various wearable devices. Although navigating through diverse communication protocols to link these devices presented challenges, we succeeded in aggregating a comprehensive dataset for blood glucose predictions. To underscore the utility of our software development kit, we executed a technical proof-of-concept on this platform, illustrating real-time, individualized, data-driven multivariate blood glucose predictions. We hope that our platform can contribute to transforming machine learning algorithms from technical developments into actionable tools with real-world benefits in blood glucose management. It provides a foundation for researchers to refine their predictive algorithms and decision support systems within a more dynamic, data-rich environment.


I. INTRODUCTION
Predicting blood glucose (BG) levels is important for managing diabetes and can also be helpful for non-diabetics [1].BG prediction models can assist in decision-making or be part of a system that helps regulate insulin in the body [2].Continuous glucose monitoring (CGM) devices can measure and transmit BG levels to a smartphone or insulin pump.
The associate editor coordinating the review of this manuscript and approving it for publication was Chan Hwang See.
BG dynamics are influenced by various factors such as meals, sleep, exercise, stress (MESS) [3], and the menstrual cycle [4].BG predictions using CGM, insulin infusion data, and physiological sensor data would greatly benefit people interested in better glycemic control and researchers in developing accurate prediction models and utilizing them in products to benefit users.Researchers have attempted to create smartphone applications for predicting future BG levels, but these have been tested only on simulation data or rely heavily on user manual input.
Commercially available wearable sensors can provide raw physiological signals that can non-invasively indicate the occurrence of stress, physical activity, sleep [5], and even menstrual cycle patterns [6].Developing lightweight physiological sensors will lead to more comfortable and less costly wearable devices to monitor various activities [7].BG measurements, insulin injections, and carbohydrate intakes are commonly used parameters in BG prediction.This study will focus on research using additional variables from non-invasive sensors or user-reported events.Types of additional inputs can be heart rate, galvanic skin response, skin temperature, sleep events, exercise events, or accelerometer data [8], [9].Biometric variables might contribute to enhanced glycemic control [10].
Most studies in multivariate BG prediction have only focused on comparing the prediction accuracy to other studies rather than universal requirements for prediction accuracy.To the authors' knowledge, there are no such defined requirements, and such requirements must depend on the use case of the BG predictions.The OhioT1DM dataset [9] is a common benchmark dataset to train and evaluate multivariate BG predictions because of its input feature space containing both wearable sensor data and self-reported live-event data.Researchers have proposed numerous BG prediction algorithms in the literature.However, BG prediction accuracy is statistically and clinically different between datasets [11].
Previous research has established that real-life validation for multivariate BG prediction algorithms is a remaining gap in the research [12] and that most algorithms are trained on small datasets or clinically obtained datasets from highly motivated patients.Assessments in field conditions will help develop products and evaluate and compare BG prediction models.
Researchers have attempted to create mobile systems that display BG predictions.In 2020, Krivenstov et al. developed Diabits [13], a smartphone application directly connected to CGM data.Users could input meals, insulin, and physical activity manually.They claim that most users need to provide more manual inputs; hence, CGM values are the most significant factor in the predictive models.The 280 most long-standing users observed a correlation between increased frequency of app use and improved standard BG control metrics.He et al. [14]   In this study, we aim to fill a gap in real-time data access from wearable devices by developing a modular software development kit (SDK) that can integrate with arbitrary blood glucose prediction algorithms.Unlike previous approaches, our SDK enables reading insulin pump data and other sensor inputs, eliminating the need for manual user inputs.We have illustrated the main components of the study in Fig. 1.Our research question focuses on whether our SDK can capture the essential factors influencing BG dynamics, including MESS and menstrual cycles.To address this, our SDK interfaces with three distinct peripherals: HealthKit, Empatica SDK, and Oura API.The SDK provides data access endpoints and can be adapted to alternative predictive methodologies.We evaluate the SDK by deploying a machine learning prediction model, a Ridge Regressor, to a smartphone application.The proof-of-concept app displays real-time BG predictions and can export experimental data for further analysis.

II. METHODS
In this study, our aim is to develop an SDK capable of interfacing with various wearable devices to provide essential inputs for BG prediction.We structure our study as follows: First, we identify the required inputs through a literature review.Following this, we design and implement the system, including the SDK.For validation, we create a proof-ofconcept smartphone application utilizing the SDK to predict BG in real-time while also collecting and exporting data for analysis.In the validation experiment, one participant, an author of this study, wears the system for a continuous 24-hour period.This validation phase adopts an observational approach.Lastly, we qualitatively analyze the results of our observational validation experiment to assess our study objectives.
In accordance with ethical guidelines, the human subject involved in this study provided their informed consent to participate.

A. INTRODUCTION OF SYSTEM
Our primary objective is to develop an SDK that facilitates access to diverse data sources for BG prediction.This achievement holds significance as current technology lacks a real-time method for predicting BG levels without relying on manual user inputs.While previous studies have explored various prediction approaches, ranging from linear models to deep neural networks [17], our software application, built using this SDK, serves as an experimental platform to address this gap.Fig. 1 provides an overview of the system developed in this study.

TABLE 1.
A list of the required variables for the SDK and which factors of impact on the BG dynamics the variables can explain.Green background means that the relationship is well established in the literature.Yellow cells refer to smaller studies, and further research on how to apply the information in BG prediction might be needed.
In pursuit of our research objectives, we identified the essential data input sources for our system through a review of the current literature.Table 1 presents a comprehensive list of the identified input variables, along with references to studies elaborating on the influence of these features on BG dynamics.The selection of input types was made strategically to encompass significant factors affecting BG dynamics, specifically focusing on MESS and the menstrual cycle.These input features conform to existing multi-input artificial pancreases [8] and are integral components of a benchmark dataset for predicting BG levels using multiple inputs [9].
The core purpose of our SDK is to provide a proof-ofconcept for evaluating various BG prediction algorithms in real-time scenarios, while minimizing the need for manual user inputs.Therefore, while ensuring functionality and effectiveness, our emphasis is not on achieving the high degree of robustness required for clinical-grade applications [18].Such clinical-grade requirements represent a substantial undertaking beyond the scope of our current study.

B. OVERVIEW OF SYSTEM 1) HARDWARE COMPONENTS
The hardware components used in our system are listed below.Fig. 2 shows the experimental setup with all hardware components and a smartphone application predicting BG levels.

Wireless communication unit:
We use an iPhone as the wireless communication unit and for running mobile applications on top of the SDK.
Insulin management system: An IMS consists of an insulin pump and a CGM.We use a Dexcom G6 and an OmniPod.The hardware units are managed through the Loop app running on an iPhone [19].The controller writes insulin deliveries, carbohydrate intakes, and CGM measurements to Apple Health.The CGM records measurements with a 5-minute sampling rate.
Empatica E4 wristband: Empatica E4 provides users with raw, continuous physiological sensor measurements.The communication protocol is Bluetooth low energy.A complete list of available raw sensor values can be found in the SDK documentation [20].The sample rates are between 1 and 32 Hz.
Oura ring: Oura Ring is a smartring focusing on sleep and activity tracking.Data can be accessed through a web API [21].The user must open the Oura smartphone application to synchronize new sensor readings.Activities and sleep are sampled as events, and sensor measurements are available at 5-minute intervals or averaged during a sleep or activity event.
Apple Watch: The last hardware component is an Apple Watch, which automatically records workouts and biometric variables to Apple Health.Signals available in our SDK are heart rate (5-10-minute sample rate), heart rate variability (2-5-hour sample rate), energy expenditure (1-minute sample rate), and workout events.

2) SDK
Our SDK interfaces with the hardware components above using three distinct communication protocols: HealthKit, Oura Web API, and Bluetooth Low Energy (BLE), as depicted in Fig. 1.Through these protocols, we access realtime data from five hardware components, comprising both components of an IMS and non-invasive wearable devices.
-HealthKit: Data from Apple Health is inherently integrated into an iPhone.Users will be prompted with a consent form on initial use.Subsequently, users can access the data.-Oura API: The SDK requires an API key during calls to access data from the Oura Ring.-Empatica E4: The Empatica E4 connects directly to the SDK via BLE.Our SDK facilitates the establishment and verification of these connections.It's worth noting that our SDK focuses on providing endpoints for various data types.While it does not include machine learning algorithms or BG prediction capabilities, it offers comprehensive data access and integration functionalities.The rationale behind excluding machine learning algorithms is that such algorithms can vary significantly, making data preprocessing a user-dependent task.

C. IMPLEMENTATION 1) PLATFORM SDK
The SDK is written in the programming language Swift and works for iOS applications.It provides access to several input values from wearable devices and IMS.Table 1 lists all the input values accessible from our SDK.We will describe how we solved the three main technical challenges to overcome during the development: Software architecture, interoperability of input values, concurrency, and BG prediction responsiveness.

2) SOFTWARE ARCHITECTURE
The proposed software architecture of the SDK aims to provide a unified interface for accessing real-time data from diverse sources, including the HealthKit framework, Empatica wristbands, and Oura Rings.Fig. 3 shows the class diagram for the proposed SDK.Specifically, access to HealthKit data is facilitated through singleton objects, which possess a startObserver method that incorporates an update handler.This design enables applications to receive updates in real-time as data changes are detected.In contrast, the Empatica wristband and OuraRing objects provide access to all relevant data types through a single object.This design choice is consistent with the protocols to access data from these peripherals.However, this architecture only provides access to real-time data and does not incorporate any data persistence and storage mechanisms.
One key benefit of the proposed architecture is the utilization of a singleton object for HealthKit data access, which enables a centralized and efficient management of updates.Furthermore, using separate objects for Empatica wristband and OuraRing data access simplifies the development process by conforming to protocols for accessing data from these peripherals.The proposed SDK architecture is based on object-oriented programming principles and adopts a modular design, with distinct classes allocated to each data source.Additionally, the SDK class is designed to be adaptable, making it capable of accommodating new data sources and peripherals in the future.Finally, the observer pattern is utilized to deliver updates for the datatypes accessed through HealthKit, making the SDK highly responsive, which explains why real-time updates are possible.

3) INTEROPERABILITY
BG prediction algorithm inputs represent some state of an individual at a point in time.The platform SDK is connected to several sources of data inputs, which differ in sample intervals and might have some delay in their impact on BG levels.Three solutions for this problem are implemented depending on the input value: -Aggregating values using the sum or average -Using the most recent value -Using physiological models to represent the delay and the relationship between the value and the BG response Energy expenditure is an example of a value where data aggregation is used over a given time interval.In this study, sleep was recorded each morning, which is not as frequently as required for real-time prediction.Hence, our solution is to use the most recent sleep analysis value for predictions the whole day.
The effect of insulin injected subcutaneously has a slow onset and lasts for several hours.Physiological modeling of the insulin effect can improve BG prediction [22].The amount of active insulin in the body at a given time is referred to as insulin on board (IOB).We used the insulin-on-board algorithm provided by the LoopKit library [23].The SDK has been designed to allow developers the flexibility to select the parameters most appropriate for their specific application.This algorithm allows for user-defined insulin delay, peak activity time, and total activity time, as these vary across individuals and types of insulin.The same algorithm is used to model carbohydrate absorption.In our proof-of-concept software, the insulin model utilizes the default parameters specific to adults utilizing rapid-acting insulin provided by the LoopKit library.The parameters utilized in the meal model were determined through trial and error, utilizing validation data to determine the optimal parameters.Table 2 lists the parameters used in our algorithms, and Fig. 4 plots the models.

4) CONCURRENCY
DispatchGroup is implemented in the SDK to synchronize the execution of concurrent calls and ensure that the calls for data from all the different peripherals have been completed before executing a BG prediction.

5) PREDICTION RESPONSE TIME
Two factors can impact BG prediction response times: The choice of prediction algorithm and the fetching of the input data values from wearable sensors or the IMS.For the SDK in this study, only the last factor is relevant, as users will choose their prediction approach.Three communication protocols are used, and different challenges are tied to them regarding response time optimization.
To observe changes in the Oura Ring web API data, we have used Swift to periodically request the API to retrieve and compare the latest data to the previous data.There is no preset time of day when the API updates, so we must always assume new data might be available.The response time of the retrieval from a web API is dependent on the wireless network speed.Empatica E4 is a Bluetooth Low Energy peripheral.The SDK is the host that sends continuous requests for data, and the wristband responds with the current measurement.
Hence, if the request interval of the host is lower than the sample interval of the wristbands, measurements will be lost.Both the Oura Ring and the Empatica E4 data are accessed with requests, and the request intervals can be adjusted if the prediction run time becomes a problem.
Data from the Apple Watch and the IMS is retrieved using HealthKit's HKAnchoredObjectQuery, which uses an ''anchor'' to track the position of the last item returned in the previous query.The anchor allows you to retrieve data that has been added to the HealthKit store since the last query efficiently.The SDK receives notifications whenever new data is added to the HealthKit store, allowing apps to update in real-time as new data becomes available, which leads to improved response time.

D. PROOF-OF-CONCEPT SMARTPHONE APPLICATION
The primary objective of developing a smartphone application using our proposed SDK is to showcase the SDK's capability to create real-time BG prediction applications.This demonstration involves the creation of a technical proofof-concept, resulting in a smartphone app that leverages a Ridge regression model for these predictions.Our models are trained using Python and then exported to a compatible model format for iOS development using coremltools.Please note that our proposed SDK primarily focuses on data retrieval, and we expect users to develop and deploy their predictive models.

1) RIDGE REGRESSION MODEL
Users of our SDK can employ any BG prediction approach.In our proof-of-concept, we implement a Ridge Regressor within our smartphone application.This decision is anchored in the findings of Xie and Wang [17], who demonstrated that Ridge Regression outperforms other stateof-the-art algorithms in predicting BG levels.Their analysis spanned a range of predictive algorithms, from conventional machine learning models to advanced deep neural networks.We further justify the selection of Ridge Regression by its comparative simplicity, reduced computational demands, and greater interpretability relative to alternative algorithms.
We employ a direct prediction strategy to generate future glucose level sequences, opting against a recursive approach.Direct predictions can mitigate the propagation of errors [24].Hence, we implement two models that estimate BG levels at 30 and 60 minutes into the future.The optimization of the alpha parameter within the Ridge Regression algorithm is conducted through a grid search bolstered by a 5-fold crossvalidation process.
Guided by the optimal results presented in the benchmark study by Xie and Wang [17], we add 12 time-lagged features for each feature.Each model is trained on an individual basis.
We compare two models with different feature spaces.The first model has only CGM measurements as an input, while the other model has CGM measurements, absorbed insulin, absorbed carbohydrates, and the energy expenditure.

2) DATA PROCESSING
Our study utilized two datasets to validate the Ridge Regression model.Initially, the Ohio T1DM dataset was employed to confirm that our implementation yielded comparable performance with the benchmarks established in [17].Subsequently, this verified implementation was applied to train and test the model using data collected from our study participant.
To align our predictive performance with [17], we engaged the same OhioT1DM dataset from 2018, which comprises data from six individuals diagnosed with Type 1 Diabetes Mellitus (T1DM) [9].The dataset spanned eight weeks and designated approximately 20% of its data for testing.Details on the division of test and train samples are delineated in [9].We obtained this dataset under a Data Use Agreement (DUA no.D201804) between Ohio University and the Norwegian University of Science and Technology.
For our proof-of-concept application, data sourced from an author with T1D was extracted from the Apple Health app.This dataset, encompassing three months of monitoring, served to train the personalized prediction model.The train test split approach mirrors the protocol used with the Ohio T1DM dataset, where 20% of data was reserved for testing, culminating in 20685 training samples and 5211 test samples.In order to prevent data leakage between the train and the test samples, we omitted a segment of 12 * 24 data points (equivalent to one day) from the sequence.
The preprocessing steps were conducted using the procedures outlined in [17].Initially, disparate features were resampled to a unified temporal resolution of 5-minute intervals.Subsequently, any missing values were imputed using the Akima method.Imputed target values were excluded from our evaluation.Finally, feature normalization was executed, scaling values to a [0,1] range.

3) PERFORMANCE METRICS
Following the best practices for BG prediction algorithm evaluation as outlined by Jacobs et al. [25], our analysis employs recommended metrics.In accordance with Best Practice 33, root mean squared error (RMSE) serves as our primary measure of accuracy.RMSE is defined in (1).Additionally, adhering to Best Practice 34, we include a measure of relative error by the mean relative error (MRE), defined in (2).
Here, ŷ (k + PH) denotes the predicted BG level at a future time point k plus the prediction horizon (PH), and y (k + PH) represents the actual measured BG level at that same time point.

A. SOFTWARE DEVELOPMENT KIT
The core objective of this study was to engineer a versatile platform SDK capable of real-time data acquisition from an IMS and non-invasive wearable devices.The data acquired encompassed critical information related to physical activity, stress levels, and sleep patterns, intending to establish endpoints for input variables suitable for multivariable BG predictions.We addressed this challenge by utilizing an opensource IMS named Loop, which facilitated data transmission to Apple Health.Concurrently, several wearable devices were employed to achieve our objectives successfully.Ultimately, our SDK seamlessly provided all the requisite feature inputs identified and detailed in Table 1.
In summary, our SDK provides the following endpoints based on the communication protocols: -HealthKit: To assess the proficiency of our newly developed SDK, we chose to implement a proof-of-concept application that harnessed the capabilities of the SDK.Our primary goal was to determine the feasibility of constructing a smartphone application leveraging our SDK, capable of presenting realtime BG predictions without necessitating manual inputs.As illustrated in Fig. 2, our mobile system established connections with our wearable devices, thus enabling the provision of real-time mobile BG predictions.Furthermore, we incorporated a feature within the smartphone application that facilitates the export of input values and BG predictions to an Excel sheet, facilitating further in-depth analysis.

B. PREDICTION ALGORITHM PERFORMANCE
We benchmarked our Ridge Regression model against [17] using the OhioT1DM dataset, conducting individualized training for each subject and then computing the mean performance.Table 3 presents the RMSE results across different PHs and input features, comparing the OhioT1DM dataset with our data.Including additional features consistently yielded superior RMSE values compared to using only CGM inputs, both in the benchmark dataset and our participant's data.
Relative to the findings reported in Table 4 in [17], our model-incorporating CGM, insulin, carbohydrates, and heart rate with 12 time-lagged features over a 30-minute TABLE 3. Accuracy in RMSE for models using a benchmark dataset compared to the data from our validation experiment, with respect to the input features and prediction horizons.All models use 12 time-lagged features for each input feature.

TABLE 4.
Accuracy in MRE for models using a benchmark dataset compared to the data from our validation experiment, with respect to the input features and prediction horizons.All models use 12 time-lagged features for each input feature.
PH-achieved a RMSE of 18.87 (± 2.91), compared to the benchmark's 19.52 (± 2.90).This enhancement is likely attributable to our physiological modeling of insulin and carbohydrates.Table 4 illustrates the MRE results, indicating balanced predictions without significant skewness.

C. VALIDATION EXPERIMENT
To validate our SDK, one of the authors participated in a 24-hour experiment using the proof-of-concept smartphone application.The experiment encompassed various scenarios, resulting in the collection of a diverse set of data, including metrics related to absorbed carbohydrates, absorbed insulin, and calorie expenditure, as well as measured and predicted BG levels.The subject of the experiment was one of the authors, who has diabetes.The experiment was structured around three primary scenarios: -Carbohydrate intake: The subject added carbohydrates to the IMS in conjunction with meals.-Insulin administration: The subject administered insulin in response to meals or to correct elevated BG levels.-Physical activity: Thirty minutes of high-intensity physical activity was included as a part of the experiment.
As the smartphone application was utilized throughout the experiment, real-time changes in BG predictions were observed in response to all the varying scenarios.As depicted in Fig. 5, the consumption of a carbohydrate-rich meal corresponded with an increase in predicted BG levels, while insulin administration decreased predicted BG levels.Upper picture shows the initial BG prediction.The middle one shows the updated prediction after adding 60 g of carbohydrate to the insulin management system, and the lower picture is after 6 U of insulin is injected.During the 24-hour duration of the experiment, an array of data was tracked, including absorbed carbohydrates, absorbed insulin, and active calorie expenditure.These metrics were standardized and plotted in Fig. 6.The graphical representation allowed us to discern how the levels of absorbed carbohydrates and insulin evolved over the course of the day, along with fluctuations in calorie expenditure.Notably, there was a rise in calorie expenditure during periods of high-intensity physical activity, accompanied by corresponding declines in BG levels.In Fig. 7, we saw that the Ridge regression model using multiple parameters resulted in better predictions of glycemic responses to food, insulin, and physical activity compared to the model using only one parameter.However, these models were implemented to illustrate the potential benefits of providing access to more parameters in such prediction models, but the model approach still has room for improvement.
Overall, our experiment was a success, showing us that our SDK can provide data inputs in real-time without requiring manual inputs from the user.As we can see in Fig. 5, our app was able to make predictions in various situations, and the predictions were updated without requiring manual inputs.We observed that predictions increased after we registered carbohydrates in the IMS and decreased after we injected insulin and performed physical activity.

IV. DISCUSSION
One of the major challenges we encountered in implementing the platform SDK was the need to use multiple communication protocols, such as HealthKit, Bluetooth Low Energy, and a Web API, to connect to different wearable devices and the IMS.It required significant effort to ensure compatibility and interoperability but ultimately allowed us to collect a wide range of data types, as outlined in Table 1.
There has been a missing gap in research to evaluate multivariate BG predictions in real-life scenarios [12].Some attempts have been made, but the solutions have required manual user inputs [13], [14].In prior work, Kriventsov et al. created Diabits, an app that displayed BG predictions.They found a statistical connection between better glucose control and more frequent app use [13].However, a drawback was that the predictions strongly relied on manual inputs from the users because most users failed to provide them.A significant challenge for developing a system that does not require manual inputs from user is that insulin pump and CGM vendors usually have closed protocols so that researchers cannot access the data or the insulin delivery algorithms.Closed protocols are also the case for many wearable devices; they do not provide any raw data for users or researchers because they want to protect their algorithms.This might slow research in many health-related projects because it might require research groups to develop their own devices or go with unpractical, non-mobile solutions, making it challenging to run long-term experiments.
The potential applications of the platform SDK are numerous and varied.For example, the platform could be used to develop decision support systems for people with diabetes, providing real-time BG predictions and personalized recommendations for insulin dosing and lifestyle changes.The platform could also be integrated with other wearable devices, such as smart scales and smart clothing, to provide a more comprehensive view of an individual's health and well-being.Additionally, the platform could be used to evaluate different multivariate BG prediction algorithms in real-life scenarios.Various predictive methodologies have been explored, including traditional machine learning techniques, advanced deep neural networks, and physiological modeling [22].Transformer models represent a novel and growing area in glucose level prediction [26].Our SDK provides a more realistic testbed for developing new and improved BG prediction models.
A limitation of this study is that the developed platform SDK depends on whether the IMS can write data to Apple Health in real-time.We solved this by using Loop, an opensource system without medical approval.Hence, doctors can not recommend that patients use this system.Also, it would be beneficial to know more about the insulin delivery algorithms of the IMS to create proper machine-learning models.For example, the interval between insulin deliveries for basal rates is unknown.Another consideration is the system's limitation regarding robustness, which falls short of the stringent clinical regulation requirements.Robustness pertains to the system's resilience in managing errors, which may arise from communication breakdowns between units or intermittent signal loss.Predictive adjustments to channel fluctuations can facilitate stable connectivity and data fidelity in remote sensor-smartphone communications [27].However, the primary focus of this study was to establish data endpoints.We intended to develop a system capable of supporting reallife exploration of BG prediction algorithms, irrespective of the stringent regulatory demands.In this context, our system aligns with our intended objectives and scope.

V. CONCLUSION
Overall, our study provides proof of concept for a platform SDK that could be used to develop tools and decision support systems for people with diabetes or non-diabetics who want to optimize their health.This platform might contribute to a broader understanding of multivariate BG prediction algorithms by allowing for testing algorithms in real-life scenarios.Previous work has usually evaluated the algorithms on small, benchmark datasets from controlled environments.Currently, available simulators do not incorporate other multiple inputs, although this would generally be a good way to evaluate prediction algorithms.Further research is needed to explore the platform's potential applications in a broader range of BG prediction approaches, settings, and populations.
created a smartphone application, CausalBG, that could collect CGM data and other external factors impacting BG levels.Insulin, meals, and other factors were based on manual inputs, although the smartphone-embedded sensors could automatically record sleep and calorie expenditure.The BG predictions were tested on three subjects for one day, showing promising results in terms of prediction accuracy.Li et al. deployed their BG prediction on an Android mobile phone [15].Zhu et al. implemented a wearable wrist-worn device to run a machine-learning BG prediction model in real-time [16].Li et al. and Zhu et al. evaluated their smartphone system on simulated data.Researchers still need to address the issue of automatically reading data from various sources of wearable sensors and insulin management systems (IMS) in mobile BG prediction systems.It is crucial to fill this gap to help users avoid the burden of manual inputs while conducting experiments in real-life scenarios.

FIGURE 1 .
FIGURE 1.Visual representation of key components within the system, highlighting the distinction between the primary contributions and the validation experiment.

FIGURE 2 .
FIGURE 2. A CGM, an insulin pump and various non-invasive smart devices are connected to our SDK allowing real time BG prediction in a smartphone application.

FIGURE 3 .
FIGURE 3. Class diagram for the proposed SDK.

FIGURE 4 .
FIGURE 4. The physiological absorption models for insulin and carbohydrates.

FIGURE 5 .
FIGURE 5. Screenshots from mobile predictions in different scenarios.Upper picture shows the initial BG prediction.The middle one shows the updated prediction after adding 60 g of carbohydrate to the insulin management system, and the lower picture is after 6 U of insulin is injected.

FIGURE 7 .
FIGURE 7. Comparison of predictions of a model trained on only BG measurements and another model using all the parameters plotted in Fig. 6.
MIRIAM K. WOLFF was born in Ålesund, Norway, in 1997.She received the M.Sc.degree in engineering and ICT from the Department of Mechanical and Industrial Engineering, Norwegian University of Science and Technology, Trondheim, in 2021, where she is currently pursuing the Ph.D. degree with the Department of ICT and Natural Sciences.She was an Exchange Student with Valencia Polytechnic University, Valencia, Spain, from 2019 to 2020.During the master's degree, she had a summer internship with the Offshore Simulator Centre AS, in Summer 2018, and Holte Consulting AS, in 2019 and 2020.She was a Software Developer with Schibsted, in 2021.Her research interests include medical technology for enhanced glycemic control, sensor applications, rapid prototyping, humancentered design, and machine learning.

TABLE 2 .
Parameters used in the physiological models for calculating insulin and carbohydrates on board.