Systems and methods for continuous glucose monitoring outcome predictions

Abstract

Methods and devices include predicting future glucose and participation levels of a user by receiving glucose levels of the user collected by a continuous glucose monitoring (CGM) device over a period of time; receiving participation data associated with the user, wherein the participation data is associated with drug intake, diet, physical activity, laboratory results, and educational activity of the user; determining a first glycemic risk index (GRI) value; determining one or more predictions of a future glucose level of the user using a machine learning model and in response to the glucose level of the user and the participation data collected over the time period, the one or more predictions including a prediction that a future GRI value is greater than or less than the first GRI value; and determining, using the machine learning model and in response to participation data of the user collected over the time period, one or more predictions of future participation levels.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202480037663.2 (22) Application Date 2024.04.09 (30) Priority Data 63 / 495,468 2023.04.11 US (85) PCT International Application Entering National Phase Date 2025.12.04 (86) PCT International Application Application Data PCT / US2024 / 023736 2024.04.09 (87) PCT International Application Publication Data WO2024 / 215674 EN 2024.10.17 (71) Applicant: Wildcom Corporation, Address: Maryland, USA (72) Inventors: Anard K. Iyeabmanu Kombala, Mansur E. Saomari, Luo Junjie, Gao Guodong (74) Patent Agency: Beijing Gaowo Law Firm, 11569 Patent Attorney: Wan Huihua (51) Int.Cl. G16H 50 / 20 (2006.01) A61B 5 / 145 (2006.01) A61B 5 / 00 (2006.01) G16H 50 / 30 (2006.01) (54) Invention Title: System and Method for Predicting Continuous Glucose Monitoring Results (57) Abstract: The method and apparatus include predicting a user's future glucose and engagement levels by: receiving a user's glucose level collected by a continuous glucose monitoring (CGM) device over a time period; receiving engagement data associated with the user, wherein the engagement data is associated with the user's medication intake, diet, physical activity, laboratory results, and educational activities; determining a first glycemic risk index (GRI) value; using a machine learning model and in response to the user's glucose level and the engagement data collected over the time period, determining one or more predictions for the user's future glucose level, the one or more predictions including predictions that the future GRI value is greater than or less than the first GRI value; and using the machine learning model and in response to the user's engagement data collected over the time period, determining one or more predictions for future engagement levels. Claims (3 pages), Description (24 pages), Drawings (48 pages), CN 121263852 A 2026.01.02 CN 1 21 26 38 52 A 1. A computer-implemented method for predicting a user's health and engagement levels, the method comprising: receiving a user's glucose level collected by a continuous glucose monitoring (CGM) device over a time period; receiving engagement data associated with the user, the engagement data being collected by a computing device over the time period, wherein the engagement data is related to the user's medication activities, dietary activities, physical activities, laboratory results, or educational activities.The method comprises: 1. Associating the user's glucose level with a first time interval of hypoglycemia and a second time interval of hyperglycemia during the time interval; 2. Using a machine learning model and in response to the user's glucose level and participation data collected during the time interval, determining one or more predictions for the user's future glucose level, the one or more predictions including predictions that the future GRI value is greater than or less than the first GRI value; and using the machine learning model and in response to the user's participation data collected during the time interval, determining one or more predictions for the future participation level. 2. The computer-implemented method of claim 1, further comprising: determining a time-in-target range (TIR) ​​value for the user's glucose level, wherein the determined TIR value is based on the amount of time the user's glucose level is within a threshold band during the time interval, wherein the one or more predictions for the user's future glucose level include predictions that the future TIR value is within a threshold of the determined TIR value; greater than the determined TIR value exceeding a threshold; or less than the determined TIR value exceeding a threshold. 3. The computer-implemented method of claim 1, further comprising: determining a time-in-target range (TIR) ​​value for the user's glucose level, wherein the TIR value is based on the amount of time the user's glucose level is within a threshold band during the time period, wherein the one or more predictions of the user's future glucose level further include predictions of future TIR values ​​being greater than or less than the TIR value. 4. The computer-implemented method of claim 2, wherein the one or more predictions of the user's future glucose level include predictions of future TIR values ​​being greater than or less than a threshold TIR value. 5. The computer-implemented method of claim 1, further comprising: deriving a feature set from the user's glucose level and the participation data; and providing the feature set as input to the machine learning model to determine the one or more predictions of the user's future glucose level and the one or more predictions of future participation levels. 6. The computer-implemented method of claim 1, further comprising: determining a first GRI zone based on the first GRI value, wherein the one or more predictions of the user's future glucose level include predictions of future GRI values ​​being in a GRI zone higher than the first GRI zone or in a GRI zone lower than the first GRI zone. 7. The computer-implemented method of claim 6, wherein the prediction of one or more of the user's future glucose levels includes predictions of future GRI values ​​that are in the first GRI zone or higher than the first GRI zone.8. A prediction in a second GRI zone or in a third GRI zone lower than the first GRI zone. 9. The computer-implemented method of claim 1, wherein the one or more predictions of the user's future glucose level include predictions of a future GRI value greater than or less than a threshold GRI value. 10. The computer-implemented method of claim 1, wherein the one or more predictions of future engagement levels include predictions of a future engagement level of high engagement or low engagement. 11. The computer-implemented method of claim 1, wherein the one or more predictions of future engagement levels include predictions of a future manual engagement level of a first manual engagement state or a second manual engagement state. 12. The computer-implemented method of claim 1, wherein the one or more predictions of future engagement levels include predictions of a future CGM device engagement level higher than or lower than a CGM device engagement threshold amount, wherein CGM device engagement includes measurements of CGM device usage performed by the user. 12. The computer-implemented method of claim 1, wherein at least some of the participation data is collected via user input from one or more applications on the computing device. 13. The computer-implemented method of claim 1, wherein at least some of the participation data is collected using one or more sensors associated with the user, the one or more sensors including at least one of a scale, blood pressure monitor, activity tracker, heart rate monitor, multi-functional wearable device, blood glucose monitor, and ketone tracking device. 14. A computer-implemented method for training a machine learning model to predict a user's health and engagement levels, the method comprising: receiving a first glucose level of the user collected by a continuous glucose monitoring (CGM) device during a first time period; receiving a second glucose level of the user collected by the CGM device during a second time period following the first time period; receiving first engagement data associated with the user, the first engagement data being collected by a computing device during the first time period; receiving second engagement data associated with the user, the second engagement data being collected by the computing device during the second time period, wherein the first engagement data and the second engagement data are associated with one or more of the user's medication intake, diet, physical activity, laboratory results, and educational activities; training a machine learning model based on a machine learning algorithm and using training data to generate a trained machine learning model, the training data including the first glucose level, the second glucose level, the first engagement data, and the second engagement data; and15. The computer-implemented method of claim 14, further comprising: deriving one or more feature sets from the first glucose level and the first participating data, wherein the training data includes the derived one or more feature sets. 16. The computer-implemented method of claim 15, further comprising extracting one or more sub-features from each of the one or more feature sets. 17. The computer-implemented method of claim 14, wherein determining one or more patterns in the training data comprises: determining a relationship between the first glucose level and the second glucose level; and determining a relationship between the first participating data and the second participating data. 18. The computer-implemented method of claim 14, wherein training the machine learning model further comprises: updating one of the weights, layers, biases, or synapses of the machine learning model based on the determined patterns to generate the trained machine learning model. Claims 2 / 3 Page 3 CN 121263852 A 19. The computer-implemented method of claim 14, further comprising: receiving a third glucose level for the user collected by the CGM device during a third time period following the second time period; receiving third engagement data associated with the user, the third engagement data being collected by the computing device during the third time period, wherein the third engagement data is associated with the user's medication intake, diet, physical activity, laboratory results, and educational activities; using the trained machine learning model and in response to the third glucose level and the third engagement data collected during the third time period, determining one or more predictions for the user's future glucose level; and using the trained machine learning model and in response to the user's third engagement data collected during the third time period, determining one or more predictions for the future engagement level. 20. A system for predicting future glucose levels and participation, the system comprising: a memory having processor-readable instructions stored therein; and a processor configured to access the memory and execute the processor-readable instructions, the processor-readable instructions configuring the processor, when executed by the processor, to perform a method comprising: receiving a user's glucose levels over a time period using a continuous glucose monitoring (CGM) device, the CGM device being configured to acquire glucose values ​​using a component that penetrates the user's skin; and receiving participation data associated with the user, the participation data being collected by one or more electronic sensors via a computing device over the time period, wherein the participation data is associated with the user's medication intake, diet, physical activity, and other factors.The laboratory results and educational activities are correlated; a first glucose risk index (GRI) value is determined based on a first time period during which the user is in a hypoglycemic state and a second time period during which the user is in a hyperglycemic state; one or more predictions for the user's future glucose level are determined using a machine learning model in response to the user's glucose level collected during the time period and the participation data, the one or more predictions including predictions that the future GRI value is greater than or less than the first GRI value; and one or more predictions for the future participation level are determined using the machine learning model in response to the user's participation data collected during the time period. Claims 3 / 3 Page 4 CN 121263852 A System and method for predicting continuous glucose monitoring results

[0001] Related Applications

[0002] This application claims priority to U.S. Provisional Application No. 63 / 495,468, filed April 11, 2023, the entire disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure generally relates to predicting a user's future glucose and engagement levels, and in some embodiments, more specifically relates to using one or more machine learning models to determine health and engagement predictions. Background Art

[0004] Increasing healthcare costs limit users' access to appropriate care. Meanwhile, healthcare companies increase the workload of providers and limit doctor-patient interactions. Diabetes treatment often relies on sporadic readings (e.g., blood glucose readings) that do not provide sufficient data to effectively provide treatment options or to predict health and / or engagement outcomes. Such readings are often used alone, making it possible to suggest changes based on only one or two readings. Due to the limited data received via sporadic readings, any medical, dietary, and / or lifestyle changes suggested based on a given reading are limited.

[0005] The introduction provided herein is for the purpose of presenting the background of this disclosure in its entirety. Unless otherwise indicated herein, the material described in this section is not prior art to the claims of this application and is not admitted by inclusion in this section as prior art or a suggestion of prior art. Summary of the Invention

[0006] This disclosure relates to a computer-implemented method for predicting a user's health and engagement levels. The method includes receiving a user's glucose level collected by a continuous glucose monitoring (CGM) device over a time period. The method further includes receiving user-associated engagement data collected by a computing device during that time period, wherein the engagement data is correlated with the user's medication intake, diet, physical activity, laboratory results, and educational activities. The method also includes:Based on a first time period during which the user is in a state of hypoglycemia and a second time period during which the user is in a state of hyperglycemia, a first glycemic risk index (GRI) value is determined. The method further includes: using a machine learning model and in response to glucose level and engagement data collected during the time period to determine one or more predictions for the user's future glucose levels, including predictions that the future GRI value is greater than or less than the first GRI value; and using a machine learning model and in response to user engagement data collected during the time period to determine one or more predictions for future engagement levels.

[0007] This disclosure relates to a computer-implemented method for training a machine learning model to predict a user's health and engagement levels. The method includes: receiving a user's first glucose level collected by a continuous glucose monitoring (CGM) device during a first time period; receiving a user's second glucose level collected by the CGM device during a second time period following the first time period; receiving first engagement data associated with the user, the first engagement data being collected by a computing device during the first time period; and receiving second engagement data associated with the user, the second engagement data being collected by the computing device during the second time period, wherein the first engagement data and the second engagement data are associated with one or more of the user's medication intake, diet, physical activity, laboratory results, and educational activities. The method further includes: training a machine learning model based on a machine learning algorithm and using training data, including the first glucose level, the second glucose level, the first engagement data, and the second engagement data, to generate a trained machine learning model, and determining one or more patterns in the training data.

[0008] This disclosure also relates to a system for predicting glucose levels and engagement, the system comprising: a memory storing processor-readable instructions; and a processor configured to access the memory and execute the processor-readable instructions, wherein, when the processor-readable instructions are executed by the processor, the processor is configured to perform a method. The method includes: receiving a user's glucose level over a time period using a continuous glucose monitoring (CGM) device configured to acquire blood glucose values ​​using a component that penetrates the user's skin; and receiving engagement data associated with the user, the engagement data being collected by one or more electronic sensors via a computing device over the time period, wherein the engagement data is associated with one or more of the user's medication intake, diet, physical activity, laboratory results, and educational activities. The method further includes: determining a first glycemic risk index (GRI) value based on a first time period during which the user is in a hypoglycemic state and a second time period during which the user is in a hyperglycemic state. The method also includes: using a machine learning model...The system, in response to user glucose levels and engagement data collected during the time period, determines one or more predictions for the user's future glucose levels, including predictions that the future GRI value is greater than or less than a first GRI value; and uses a machine learning model and, in response to user engagement data collected during the time period, determines one or more predictions for future engagement levels. Brief Description of the Drawings

[0009] The accompanying drawings, incorporated and constituting a part of this specification, illustrate examples of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0010] FIG1 shows a schematic diagram of a health management system according to one or more embodiments.

[0011] FIG2 shows a schematic diagram of a portion of the health management system of FIG1 according to one or more embodiments.

[0012] FIG3A shows a schematic diagram of another portion of the health management system of FIG1 according to one or more embodiments.

[0013] FIG3B shows a schematic diagram of training an exemplary machine learning model according to one or more embodiments.

[0014] FIG4 shows a diagram depicting GRI regions according to one or more embodiments.

[0015] FIG5 shows a flowchart for determining one or more predictions for future glucose and engagement levels according to one or more embodiments.

[0016] Figure 6 illustrates a flowchart for training a machine learning model to predict health and engagement outcomes according to one or more embodiments.

[0017] Figures 7A to 7C illustrate graphs depicting the use of blood glucose and engagement data to predict future health and engagement outcomes according to one or more embodiments.

[0018] Figures 8A to 8D illustrate graphs depicting early-stage feature selection according to one or more embodiments.

[0019] Figures 9A to 9X illustrate graphs depicting the results of a machine learning model according to one or more embodiments.

[0020] Figures 10A to 10D illustrate example graphs showing the change of the average GRI value of an individual group over time according to one or more embodiments.

[0021] Figures 11A to 11C are graphs depicting the relationship between precision, recall, specificity, and sensitivity according to one or more embodiments.

[0022] Figure 12 is a simplified functional block diagram of a computer according to one or more embodiments. Specification 2 / 24 pages 6 CN 121263852 A Detailed Description

[0023] Reference will now be made in detail to examples of this disclosure, which are illustrated in the accompanying drawings. Where appropriate, the same reference numerals will be used throughout the accompanying drawings to refer to the same or similar parts.

[0024] In the following discussion, relative terms such as “about,” “substantially,” and “approximately” are used to indicate possible variations of ±10% in the stated values. It should be noted that the descriptions herein are illustrative only and are not intended to limit the subject matter or such examples.Application and use of examples. Any embodiment described herein as “exemplary” is not to be construed as preferred or advantageous over other embodiments. Rather, as noted above, the term “exemplary” is used in an illustrative or “illustrative” rather than “ideal” sense. The terms “comprising,” “including,” “having,” “with,” and any variations thereof are used synonymously to indicate or describe a non-exclusive inclusion. Thus, a process, method, article, or apparatus using such terms may include not only those steps, structures, or elements, but may also include other steps, structures, or elements not expressly listed or inherent to such process, method, article, or apparatus. Furthermore, the terms “first,” “second,” etc., do not indicate any order, quantity, or importance herein, but are used to distinguish one element from another. Furthermore, the terms “an (a)” and “a (an)” do not indicate a limitation on quantity herein, but indicate the presence of at least one of the referenced items.

[0025] Healthcare and Computing Environment

[0026] FIG1 is a block diagram of a health management system 100 according to an example of the present disclosure. A user (e.g., a patient, consumer, etc.) 8 having electronic devices 19 (such as mobile devices, computers, medical devices, or any other electronic devices configured to access electronic networks 32, such as the Internet) can communicate with or otherwise access the mobile health (mHealth) application 1. In some examples, network 32 may include wireless or wired links such as mobile phone networks, Wi-Fi, LAN, WAN, Bluetooth, near field communication (NFC), or other suitable forms of network communication. Multiple electronic devices 19 may be configured to access electronic network 32. The user 8 can access the mHealth application 1 using a single account linked to multiple electronic devices 19 (e.g., via one or more of mobile phones, tablets, and laptops). Electronic device 19 may also include, but is not limited to, mobile health devices, desktop computers or workstations, laptops, mobile handheld devices, personal digital assistants (PDAs), cellular phones, network application devices, cameras, smartphones, smartwatches, enhanced general packet radio service (EGPRS) mobile phones, media players, navigation devices, game consoles, set-top boxes, biometric sensing devices with communication capabilities, smart TVs, or any combination of these or other types of computing devices, which have at least one processor, local memory, a display (e.g., a monitor or touchscreen display), one or more user input devices, and a network communication interface. Electronic device 19 may include any type or combination of input / output devices, such as display monitors, keyboards, touchpads, accelerometers, gyroscopes, mice, touchscreens, cameras, projectors, touchpads, pointing devices, scrolling devices, buttons, switches, motion sensors, audio sensors, pressure sensors, thermal sensors, and / or microphones. Electronic device 19 may also...The mHealth application 1 can communicate with each other via any suitable wired or wireless means (e.g., via Wi-Fi, radio frequency (RF), infrared (IR), Bluetooth, near field communication, or any other suitable means) to send and receive information.

[0027] The mHealth application 1 can communicate with other entities or networks to send and receive information. In some examples, the mHealth application 1 can communicate with one or more applications associated with the user 8, such as, for example, exercise tracking (e.g., step tracking) applications and / or other health-related applications. The mHealth application 1 can be configured to import data from other applications, analyze it, and use it to generate a treatment plan for the user 8. For example, the mHealth application 1 can import activity tracking data from another application and use the data to identify patterns between exercise values ​​and blood glucose values ​​collected by the user 8 before using the mHealth application 1. The mHealth application 1 can also import any other suitable data from other mobile health applications, such as, for example, blood pressure, body mass index (BMI), glycated hemoglobin (A1C), exercise type, exercise duration, exercise distance, calorie consumption, total steps, exercise date, start and stop times of exercise, and sleep. The mHealth application 1 can also export data to other mobile applications, such as other mobile health applications with social or interactive features. A healthcare provider 7 (such as a doctor) can prescribe the application. However, it is also conceivable that the mHealth application 1 may not require a prescription; for example, the mHealth application could be a commercially available consumer application accessible without a prescription from a digital distribution platform for computer software. The mHealth application 1 can be customized for a specific user 8 and can be activated by the user 8 in person at a pharmacy 9 or other authorized entity. For example, the user 8 can receive an access code authorizing access to the mHealth application 1 from a pharmacy. The user 8 can receive training on using the mHealth application 1 through the mHealth support system 25 and / or the application trainer 24. The mHealth application 1 may include various forms of programming 28, such as machine learning programming algorithms 26. A user's treatment plan may include prescriptions (e.g., for medications, devices, and / or therapies), which may be dispensed by pharmacy 9. Pharmacy 9 may, upon receiving authorization, allow the replenishment of prescription products / therapies based on the user's adherence to their healthcare treatment plan. Pharmacy 9 may receive authorization, for example, via network 32 and various servers 29, through communication from the mHealth application 1. Usage information for medications or other medical products / therapies may also be sent to the manufacturer 37 via network 32 for notification.The manufacturer 37 knows the quantity of medical products or therapies being used by user 8. This information can help the manufacturer 37 assess the demand for medical products or therapies and plan their supply. The healthcare provider 7 can also receive reports based on user information received by the mHealth application 1 and can update user treatment plans based on this information. The user's electronic medical record (EMR) 14 can also be automatically updated via network 32 based on user information, which may include feedback from user 8 to the application received electronically by the mHealth application 1. The healthcare provider 7 can be any suitable healthcare provider, including, for example, doctors, specialists, nurses, educators, social workers, medical assistants (MAs), physician assistants or assistants (PAs), etc.

[0028] Figure 2 is a schematic diagram of other aspects of the system 100. For example, the system 100 can access decision models stored in the decision model database 270 via network 32. The retrieved decision model can be displayed and / or processed by one or more electronic devices 19, such as mobile device 215, tablet device 220, computer (e.g., laptop or desktop computer) 225, self-service terminal 230 (e.g., in a self-service terminal with medical and / or prescription information, pharmacy, clinic or hospital) and / or any device connected to network 32.

[0029] In the example shown in FIG2, mobile device 215, tablet device 220 and computer 225 may each be equipped with or include, for example, a Global Positioning System (GPS) receiver for acquiring and reporting location information (e.g., GPS data) to and from server 29 and / or any of one or more GPS satellites 255 via network 32.

[0030] Each of the electronic devices 19 (including mobile device 215, tablet device 220, computer 225 and / or self-service terminal 230) may be configured to send and receive data (e.g., clinical information) to and from server 29 via network 32. Each of the devices 19 can receive information, such as clinical data, from server 29 via network 32. Server 29 may include clinical data server 240, algorithm server 245, user interface (UI) server 250, and / or any other suitable server. Electronic device 19 may include a user interface that communicates data with UI server 250 via network 32. Each server can access decision model database 270 to retrieve decision models. Each server may include memory, a processor, and / or a database. For example, clinical data server 240 may have a processor configured to retrieve clinical data from a provider's database and / or patients' electronic medical records. Algorithm server 245 may have a database including various algorithms and a processor configured to process clinical data. UI server 250 may be configured to receive...And process user 8's input, such as clinical decision preferences. Satellite 255 can be configured to send and receive information between server 29 and device 19.

[0031] Clinical data server 240 can receive clinical data, such as data about the user, from electronic device 19 via network 32 or indirectly via UI server 250. Clinical data server 240 can store information in memory, such as computer-readable memory.

[0032] Clinical data server 240 can also communicate with one or more other servers, such as algorithm server 245 and / or external servers. Server 29 can include data about provider preferences and / or user 8's health history. In addition, clinical data server 240 can also include data from other users. Algorithm server 245 can include machine learning and / or other suitable algorithms. Algorithm server 245 can also communicate with other external servers and can be updated as needed. For example, algorithm server 245 can be updated with new algorithms, more powerful programming and / or more data. Clinical data server 240 and / or algorithm server 245 can process information and transmit data to model database 270 for further processing. In one example, algorithm server 245 can acquire pattern definitions in a simple format, predict several future time steps using models (e.g., Markov models, Gaussian, Bayesian, PCA (principal component analysis), multivariate linear or nonlinear regression and / or classification models (such as linear discriminant functions, nonlinear discriminant functions, synthetic discriminant functions, random forest algorithms, etc.), optimize based on its predictions, detect transitions between patterns, acquire abstract data and extract information to infer higher-level knowledge, combine higher and lower-level information to understand user behavior and clinical behavior, make inferences from multi-temporal (e.g., different time scales) data and associated information, use variable-order Markov models, and / or reduce noise over time by employing slope and curve smoothing algorithms, clustering algorithms (such as k-means clustering).

[0033] Each server in the server 29 system, including the clinical data server 240, algorithm server 245, and UI server 250, can represent various types of servers, including but not limited to web servers, application servers, proxy servers, network servers, or server clusters. Each server in the server 29 system can be implemented using, for example, any general-purpose computer capable of providing data to other computing devices (including but not limited to device 19 or any other computing device (not shown)) via network 32. Such a general-purpose computer can include, but is not limited to, server devices having processors and memory for executing and storing instructions. The memory can include: any type of random access memory (RAM) or read-only memory.The memory (ROM) is embodied in a physical storage medium, such as magnetic storage devices, including floppy disks, hard disks, or magnetic tapes; semiconductor storage devices, such as solid-state drives (SSDs) or flash memory; optical disk storage devices; or magneto-optical disk storage devices. Software may include one or more applications and an operating system. Hardware may include, but is not limited to, processors, memory, and a graphical user interface (GUI) display. Each server may also have multiple processors and multiple shared or independent memory components configured to work collaboratively in environments such as clustered computing environments or server groups.

[0034] Figure 3A is another representation of a portion of system 100, showing further details of electronic device 19 and server 29. Electronic device 19 and server 29 may each include one or more processors, such as processors 301-1 and 304-1. Processors 301-1 and 304-1 may each be a central processing unit, a microprocessor, a general-purpose processor, a special-purpose processor, or any device that executes instructions. Electronic device 19 and server 29 may also include one or more memories, such as memories 301-2 and 304-2 storing one or more software modules. Memory 301-2 and 304-2 can be implemented using any computer-readable storage medium, such as hard disk, CD, DVD, flash memory, RAM, ROM, etc. Memory 301-2 can store module 301-3, which can be executed by processor 301-1. Similarly, memory 304-2 can store module 304-3, which can be executed by processor 304-1.

[0035] Electronic device 19 may further include one or more UIs. The UI may allow one or more interfaces to present information, such as plans or interventions, to user 8. The UI may be web-based, such as a webpage, or a standalone application. The UI may also be configured to accept information about user 8, such as data input and user feedback. User 8 may enter the information manually or automatically. In the example, user 8 (or the user's caregiver) may enter information such as medication time or food and drinks consumed by user 8. Electronic device 19 may also include testing equipment (not shown) or an interface for receiving information from testing equipment as described on page 5 / 24 of the specification, CN 121263852 A. The testing equipment may include, for example, a blood glucose meter, a blood glucose monitor, a heart rate monitor, a scale, a blood pressure cuff, etc. The electronic device 19 may also include one or more sensors (not shown), such as a camera, microphone, or accelerometer, for collecting feedback from the user 8. In one example, the device may include a blood glucose meter for reading and automatically reporting the user's glucose levels.

[0036] The electronic device 19 may also include a presentation layer. The presentation layer may be a web browser, an application, a messaging interface, etc.The electronic device 19 can present notifications, alerts, reading materials, references, guides, reminders, or suggestions to the user 8 via a presentation layer. For example, the presentation layer can present articles identified as relevant to the user 8, reminders to purchase medication, topical tutorials (e.g., carbohydrate tutorials), recommendations from others with similar symptoms, and / or one or more goals (e.g., carbohydrate counting goals). The presentation layer can also present information such as tutorials (e.g., user guides or instructional videos) and / or facilitate communication between the healthcare provider and the user 8 (e.g., the patient). Communication between the healthcare provider and the user 8 (e.g., the patient) can be conducted via electronic messaging (e.g., email or SMS), voice, or live video. One or more of these items can be presented based on a treatment plan or an updated treatment plan, as described below. The presentation layer can also be used to receive feedback from the user.

[0037] System 100 may also include one or more databases, such as database 302. Database 302 can be implemented using any database technology known to those skilled in the art, such as relational database technology or object-oriented database technology. Database 302 may store data 302-1. Data 302-1 may include a knowledge base, statistical models, and / or user information for making inferences. Data 302-1 or a portion thereof may be stored alternatively or simultaneously in server 29 or electronic device 19.

[0038] System 100 can be used for a wide range of applications, including, for example, addressing a user's healthcare problems, maintaining a user's financial situation, and monitoring and tracking a user's nutrition and / or sleep. In some embodiments of system 100, any received data may be stored in encrypted form in the database to improve data security, prevent unauthorized access, and comply with HIPAA privacy regulations and / or other laws and regulations, healthcare regulations, financial regulations, or other regulations.

[0039] For any server or server system 29 depicted in system 100, the server or server system may include one or more databases. In the example, the database may be any type of data storage or recording medium that can be used to store any type of data. For example, database 302 may store data received or processed by server 29, including information related to a user's treatment plan, including the dosing time and dosage associated with each prescription drug in the treatment plan. Database 302 may also store information related to user 8, including user literacy levels associated with each of the various prescription drugs.

[0040] As further disclosed herein, one or more components of the subject matter of this disclosure may be implemented using machine learning models. Figure 3B illustrates an example training module 310 for training one or more machine learning models disclosed herein.It should be understood that different training modules can be used to train each of the machine learning models disclosed herein, and / or a single training module 310 can be used to train two or more machine learning models.

[0041] As shown in FIG3B, training data 312 may include one or more of stage inputs 314 and known results 318 associated with the machine learning model to be trained. Stage inputs 314 may come from any applicable source, including healthcare provider 7, one or more servers 29, electronic device 19, EMR 14, outputs from steps (e.g., one or more outputs from steps in flowchart 500 of FIG5 or flowchart 600 of FIG6, time within target range (TIR) ​​values, time above target range (TAR) values, time below target range (TBR) values, severity scores, continuous glucose monitoring (CGM) classifications, GRI values, participation data, etc.). For machine learning models generated based on supervised or semi-supervised training, known results 318 may be included. Unsupervised machine learning models may not be able to be trained using known results 318. The known output 318 may include known or expected outputs of future inputs that are similar to or belong to the same category as the stage input 314, which has no corresponding known output.

[0042] Training data 312 and training algorithm 320 may be provided to training unit 330, which may apply the training data 312 to training algorithm 320 to generate a machine learning model. According to an embodiment, a comparison result 316 may be provided to training unit 330, which is compared with the previous output of the corresponding machine learning model to apply the previous result to retrain the machine learning model. Training unit 330 may use comparison result 316 to update the corresponding machine learning model. Training algorithm 320 may utilize machine learning networks and / or models, including but not limited to deep learning networks such as deep neural networks (DNN), convolutional neural networks (CNN), fully convolutional networks (FCN), and recurrent neural networks (RCN), probabilistic models such as Bayesian networks and graphical models, and / or discriminative models such as decision forests and maximum margin methods.

[0043] Health Status

[0044] Diabetes (commonly referred to as diabetes) can be a chronic, lifelong metabolic disease (or condition) in which the body is unable to produce any or enough insulin, or is unable to use the insulin it produces (insulin resistance), resulting in elevated blood glucose levels. The three most easily identifiable types of diabetes include: prediabetes, type 1 diabetes, and type 2 diabetes. Prediabetes refers to a condition where blood sugar is high but not yet at the level of type 2 diabetes. Type 2 diabetes is a chronic condition that affects how the body processes blood sugar. Finally, type 1 diabetes is when the pancreas produces almost no insulin.Or a chronic condition that does not secrete insulin at all.

[0045] There are generally several ways to diagnose diabetes. Diagnosing diabetes may require repeated testing over several consecutive days to confirm a positive diagnosis of a certain type of diabetes. Some health parameters that a doctor or other appropriate healthcare provider will use to confirm a diagnosis of diabetes include glycated hemoglobin (A1C) levels in the blood, fasting plasma glucose (FPG) levels, oral glucose tolerance tests, and / or random blood glucose tests. Typically, healthcare providers will look at a patient’s A1C levels to help diagnose diabetes. Glycated hemoglobin is a form of hemoglobin and is measured primarily to determine the average blood glucose concentration over three months that a doctor and / or other appropriate healthcare provider can use, including weight, age, nutritional intake, exercise activity, cholesterol levels, triglyceride levels, obesity, smoking status, and family history.

[0046] Once diagnosed with diabetes by a doctor or other appropriate healthcare provider, a patient can receive treatment to manage their diabetes. Treatment for patients with diabetes who are tracked or monitored by a doctor or other healthcare provider can be achieved through a combination of blood glucose control measures such as diet, exercise, oral medications, and / or insulin therapy. Some patients will also need to be screened for complications regularly. Depending on how long a patient has had diabetes, the mHealth app may recommend specific treatment options to manage their condition. Oral medications typically involve oral tablets to reduce glucose production by the liver and make muscles more sensitive to insulin. In other instances, if the diabetes is more severe, additional medications may be needed to treat the patient's diabetes, including injections. Healthcare providers may use basal insulin (also known as background insulin) injections to keep glucose levels stable during fasting. During fasting, the body steadily releases glucose into the bloodstream to provide energy for cells. Therefore, basal insulin injections are needed to control glucose levels and allow cells to absorb glucose for energy. Basal insulin is typically injected once or twice a day, depending on the type of insulin. Basal insulin has a relatively long duration of action and is therefore considered long-acting or intermediate-acting insulin. Conversely, bolus insulin can be used for a faster onset of action. For example, bolus insulin can be taken specifically with meals to control postprandial glucose levels. In some instances, when a doctor or healthcare provider develops a treatment plan to manage a patient's diabetes, the doctor may create a basal-meal dosing regimen, which may involve multiple injections throughout the day. The basal-meal regimen may involve injections after each meal, attempting to roughly mimic how the body delivers insulin in non-diabetic individuals. The basal-meal regimen may be suitable for patients with both type 1 and type 2 diabetes. In addition to the basal-meal regimen, which requires insulin injections, treatment plans may also include…Enhanced by the use of prescription oral medications. Patient adherence to the treatment plan can be very important for managing a patient’s condition. In cases where a patient has been diagnosed with diabetes, for example, for more than six months, the patient must follow a very specific instruction manual 7 / 24 page 11 CN 121263852 A treatment regimen to achieve healthy or ideal glucose levels. Ultimately, the weekly pattern of these medication types can be critical for diabetes management. mHealth app1 can suggest treatment plans to help patients manage their diabetes.

[0047] Exemplary Methods

[0048] Diabetes is a chronic disease that causes patients to be unable to keep their blood glucose within the normal or recommended target range. This fluctuating glucose level (i.e., outside the normal or recommended target range) can lead to serious health complications. It is difficult to draw meaningful insights and predictions about health and engagement outcomes using intermittent blood glucose monitoring (BGM), where only a few intermittent readings throughout the week may not be used as a basis for understanding patterns and any potential causes of these patterns (e.g., determining BGM elevation based on meal type). Rapid blood glucose monitoring (FGM) may also have similar problems, as the readings are sporadic and irregular or continuous.

[0049] Continuous glucose monitoring (CGM) can automatically collect dense data (e.g., based on data collected every 5 minutes or less) via wearable sensors (e.g., subcutaneous sensors) to provide periodic glucose values ​​(e.g., user 8's glucose level). CGM can improve diabetes care by providing user 8 or other entities (e.g., healthcare provider 7) with continuous (e.g., approximately every five minutes or less) or semi-continuous (e.g., more than approximately every five minutes) blood glucose data readings, enabling user 8 or other entities to better understand user 8's glucose levels at any time of day. Such data can allow machine learning models to be trained to predict future health and engagement levels and outcomes based on glucose levels and participation data input.

[0050] A CGM monitor can be a continuous analyte sensor system comprising any sensor configuration that provides an output signal indicating analyte concentration. The CGM monitor can sense the concentration of the analyte to determine, for example, a blood glucose value, based on bodily fluids (e.g., interstitial fluid). Bodily fluids can be obtained through the user's skin. The output signal can be, for example, in the form of sensor data, such as raw data streams, filtered data, smoothed data, and / or other transformed sensor data, which can be sent to a receiver connected to the CGM monitor via a wired or wireless connection and can be located locally or remotely to the sensor. According to an embodiment, the CGM monitor may include a transdermal glucose transducer.Sensors, subcutaneous glucose sensors, continuously refillable subcutaneous glucose sensors, continuously intravascular glucose sensors, etc. A CGM monitor may be a compact medical system with one or more sensors, insertable into the abdomen of a user 8, and including a small cannula that penetrates the skin of the user 8. An adhesive patch can hold the monitor in place. The sensors can continuously or semi-continuously sense blood glucose readings in the interstitial fluid.

[0051] A transmitter can be attached to the sensor to allow the CGM monitor to wirelessly transmit blood glucose readings to the monitoring device. The monitoring device may be a dedicated monitoring device for the CGM monitor, a third-party device, an electronic device 19, or any other suitable device. The monitoring device may be a dedicated monitoring device or an electronic device 19 that provides one or more functions in addition to CGM monitoring. An application or other software may be used to facilitate the analysis and / or display of blood glucose readings and related data via the monitoring device. The monitoring device may be used to analyze and / or view data associated with blood glucose readings. Alternatively, or additionally, the CGM monitor may include a display for viewing blood glucose readings and / or associated data. CGM monitors and / or external devices can be configured to generate and / or provide alerts based on blood glucose data (e.g., if glucose levels are too high or too low, or show an unfavorable trend).

[0052] By using CGM data, a target time interval (TIR) ​​value can be determined, where the TIR value is the amount of time that a user's glucose level is within a threshold band within a baseline time period. The threshold band can be predetermined, user-specific, or dynamically determined.

[0053] The threshold band can be based on, for example, a predetermined value for a group of patients. The lifestyle, habits, and medical test results of each patient in the same group can be used to determine the predetermined value. For example, one or more groups of patients can be identified based on their lifestyle, habits, demographics, etc., and a threshold band can be generated for each of these groups. The threshold band can be determined based on an analysis of glucose levels within a time period and based on the best outcome (e.g., a preferred A1C value).

[0054] GRI values ​​can be determined using CGM data, where GRI values ​​can be a comprehensive indicator from CGM plethysmography, which can indicate the glycemic quality of user 8 and can assist in the basic clinical interpretation of CGM data. "Glycemic quality" can be characterized by the time proportions of low / very low and high / very high glycemic concentrations. GRI values ​​are based on hypoglycemic and hyperglycemic components. The hypoglycemic component can be associated with the amount of time user 8 is in a hypoglycemic state during a specified time period, while the hyperglycemic component can be associated with the amount of time user 8 is in a hyperglycemic state during that specified time period.

[0055] GRI values ​​can be determined using the following equation. In the following equation, "VLow" represents the percentage of time the user experiences extremely low blood sugar.The percentage of time, and “Low” represents the percentage of time the user experiences low blood sugar. “VHigh” represents the percentage of time the user experiences very high blood sugar, and “High” represents the percentage of time the user experiences high blood sugar. “HypoComponent” represents the low blood sugar component, and “HyperComponent” represents the high blood sugar component.

[0056] Hypoglycemia Component = VLow + (0.8 × Low)

[0057] Hyperglycemia Component = VHigh + (0.5 × High)

[0058] GRI = (3.0 × HypoComponent) + (1.6 × HyperComponent)

[0059] Another equivalent equation for GRI includes:

[0060] GRI = (3.0 × VLow) + (2.4 × Low) + (1.6 × VHigh) + (0.8 × High)

[0061] Figure 4 shows a diagram 400 depicting five GRI regions according to one or more embodiments. Because glycemic control is a two-dimensional quality, the hypoglycemic and hyperglycemic components of the GRI can be displayed on a two-dimensional graph, as shown in Figure 400. In Figure 400, the hypoglycemic component is displayed on the horizontal axis, and the hyperglycemic component is displayed on the vertical axis. However, it should be understood that the hypoglycemic and / or hyperglycemic components can be visualized in any applicable manner. A set of diagonals divides Figure 400 into five glycemic risk regions, labeled 401, 402, 403, 404, and 405. Each of these regions corresponds to a quintile of overall glycemic quality, ranging from best (0th to 20th percentile, region A 401) to worst (81st to 100th percentile, region E 405). Users with diabetes may receive a GRI score for a given time period, and this score can be mapped to one of the five GRI regions. Additional information regarding the comprehensive glycemic quality index (GRI) for CGM, provided by Klonoff et al., is offered in the following literature (Klonoff DC, Wang J, Rodbard D et al. A glycemia risk index (GRI) of hypoglycemia and hyperglycemia for continuous glucose monitoring validated by clinician ratings. J Diabetes Sci Technol. 2022-03-29), is incorporated herein by reference.

[0062] Figure 5 illustrates a flowchart 500 for determining one or more predictions of future glucose and engagement levels according to one or more embodiments. As used herein, engagement levels may correspond to user input or interaction levels associated with adherence to medical care, diet, exercise, etc. At 502, the blood glucose level of user 8 may be received. Blood glucose levels may be provided continuously or semi-continuously via a CGM monitor, as described herein. Blood glucose levels may also be provided via a standard blood glucose monitor (BGM), a rapid blood glucose monitor (FGM), or a combination of CGM, BGM, and / or FGM. Blood glucose levels may be received at a component of the CGM monitor itself, or at a local or remote component (such as electronic device 19, mHealth application 1, one or more servers 29, etc.). Blood glucose levels may be automatically provided from the CGM monitor to one or more components, may be pushed when blood glucose levels are collected, or may be requested from the CGM monitor to transmit one or more collected blood glucose levels.

[0063] For example, user 8 may wear the CGM monitor, and the CGM monitor may collect blood glucose level readings approximately every five minutes. The CGM monitor can connect to user 8's mobile device (e.g., via a network connection, LAN connection, WAN connection, WiFi connection, Bluetooth® connection, etc.). According to the first example embodiment, whenever a reading is collected (e.g., every 5 minutes), the CGM monitor can automatically transmit the blood glucose level reading to user 8's mobile device. Alternatively, or additionally, the CGM monitor can store one or more blood glucose level readings, such that they are sent to user 8's mobile device as a set of multiple readings, and / or when user 8's mobile device or another component requests the transmission of one or more blood glucose level readings.

[0064] At 504 in FIG. 5, engagement data associated with the user can be received. Engagement data can be collected by a computing device (such as electronic device 19) over a predetermined period of time (e.g., the same time period as when glucose levels are collected at step 502). Engagement data may include and / or be associated with user 8's medication intake, diet, physical activity, laboratory results, and / or educational activities (e.g., "MEDAL" activities), which will be discussed in more detail herein. Engagement data may also include CGM engagement associated with user 8. CGM engagement may include glycemic activity, which can be collected using a CGM device.

[0065] In some cases, engagement data may be collected via user input through an application (such as mHealth application 1). For example, user 8 may use mHealth application 1 to record the time each time user 8 takes any medication.User 8 can record the time and date of medication intake, as well as the name, type, and / or dosage of the medication. User 8 can also record the method of medication intake, such as whether the medication is taken orally or via some other method of intake (e.g., by injection, inhalation, topical application, etc.). User 8 can record the reason for taking the medication, such as to treat pain or other symptoms. User 8 can further record whether the medication relieves any symptoms and can further record any side effects that may occur from taking a particular medication.

[0066] As another example, user 8 may receive a prompt via mHealth application 1 to take a specific medication at a specific time. mHealth application 1 may send a push notification at the scheduled medication time to remind the user to take the medication. In some cases, mHealth application 1 may prompt user 8 in advance (e.g., one hour in advance) to remind user 8 to take a specific medication at a specific time. After receiving the medication prompt (e.g., push notification), mHealth application 1 may follow up by requesting user 8 to enter information confirming that the medication has been taken. This can be done via mHealth application 1 through a user interface on electronic device 19, which requires confirmation of medication intake. In some instances, there may not be a prescribed time to take a specific medication, and user 8 may not receive a reminder to take a specific medication. In these instances, user 8 may access the mHealth app 1 to enter details about regular medication intake (e.g., once a week, once a day, multiple times a day).

[0067] In some embodiments, medication intake may refer to insulin delivery. As described herein, insulin delivery may refer to injecting basal insulin or administering bolus insulin to help the user's body regulate glucose levels (i.e., glucose levels). In some cases, user 8 delivers insulin manually using a syringe, insulin pen, insulin pump, or insulin inhaler. User 8 may manually calculate and determine when to administer the basal dose and bolus dose via any of these methods. User 8 may also use the mHealth app 1 to remind and calculate the timing and dosage of insulin administration. Manual calculation and automatic reminders and calculations may be used in combination. For example, a user may receive regular (e.g., hourly) basal insulin doses automatically via an insulin pump, but may need to manually calculate the amount of bolus insulin to administer with meals (typically via the same insulin pump). CGM can be used in conjunction with an insulin pump to act as an "artificial pancreas," where the CGM device monitors blood glucose levels and determines a basal or bolus dose based on current and predicted glucose levels. When the CGM device and insulin pump work together to administer insulin to user 8, records of the time, dose, glucose level, and insulin type for each administration can be stored for future analysis by user 8 or user 8's physician.

[0068] Other devices and sensors can be used to measure and record the user 8's medication intake. For example, the user 8 can place a certain amount of tablets into a pill dispenser or tablet dispenser that can be connected to an electronic device 19 and / or a network 32. The tablet dispenser may include one or more sensors to automatically detect when a tablet (e.g., a tablet from a specific date, page 10 / 24, CN 121263852 A) has been removed from the dispenser, indicating that the medication has been taken by the user 8. For example, the tablet dispenser may include a weight sensor that can detect subtle differences in weight and determine whether the tablet is still in the compartment or has been removed. The tablet dispenser may also include a light sensor that can be blocked by one or more tablets, indicating that the tablet is still present. There is also a periodically lit light, and if the light sensor receives all the light, the tablet dispenser can determine that the tablets have been used up because one or more tablets will block at least some of the light. The light sensor can also determine the color of the pill by measuring the wavelength of any reflected light from the pill. A camera can be used to distinguish the shape and color of the pills, thereby determining which pills are present and which have been taken. The pill dispenser may also include an automatic dispenser programmed to dispense pills when the user 8 is supposed to take them. The pill dispenser can save and track the dispensing times of the pills and can automatically dispense pills to the user 8. The pill dispenser can save a record of pill consumption and can transmit these records to the electronic device 19 for analysis.

[0069] The user 8's diet can be tracked via mHealth application 1 through user input. The user 8 can input the food consumed between meals and between meals into mHealth application 1. In some cases, the user 8 will calculate some or all nutritional information, including calories, fat content, sugar content, etc. In other cases, mHealth application 1 will estimate nutritional information based on a food database containing nutritional information. mHealth application 1 can remind the user 8 to record dietary information at specific times during the day. In one or more embodiments, the mHealth application 1 can interact with a CGM device to determine if the user 8 has eaten. If the glucose level exceeds a threshold or rises at a rate higher than the threshold, the mHealth application 1 and / or the CGM device can determine that the user 8 has eaten. Based on this rise in glucose level, the mHealth application 1 prompts the user 8 to record dietary information. In one or more embodiments, the user can take and provide a photo of any food before consuming it as input to the mHealth application 1.

[0070] According to an embodiment, the mHealth application 1 can use food intake machine learning to determine the type of food and its...Nutritional details. A food intake machine learning model can be trained using historical or simulated foods and their corresponding nutritional details. Based on the training, the food intake machine learning model can generate nutritional details based on food intake information such as food type, preparation type, ingredients, quantity, etc.

[0071] Similar to drug intake or diet, physical activity can also be manually recorded by user 8 via mHealth application 1. After any type of physical activity (e.g., exercise or workout), user 8 can record the activity, including the type of activity, intensity of activity, feelings and emotions before, during, and after the activity, and / or any other records, including unexpected difficulties. User 8 can also record workout details associated with a particular physical activity. For example, if the activity is running, user 8 can record the distance covered, running time, percentage of steps taken during the run, etc.

[0072] Physical activity can be automatically collected and recorded via one or more activity trackers (e.g., smartwatches, smart rings, fitness trackers, smartphones, etc.) that utilize one or more sensors to measure one or more metrics associated with physical activity. For example, activity trackers can track a user's steps, altitude gain / loss, heart rate, body temperature, etc. Activity trackers may include one or more electronic sensors, including accelerometers, gyroscopes, altimeters, photoplethysmography (PPG) sensors, pulse oximeter sensors (e.g., SpO2 monitors), bioimpedance sensors (e.g., one or more electrodes or EKG / ECG sensors), conductance skin activity sensors, GPS sensors, light / optical sensors, compasses, UV sensors, magnetometers, gesture sensors, temperature sensors, microphones, and / or conductance skin sensors. One or more of these sensors may operate independently or in combination to detect motion, movement, acceleration, altitude, heart rate and / or other cardiac activity, blood oxygen levels, device orientation, position, orientation, and rotation, etc. Raw electronic data can be acquired from these one or more electronic sensors and analyzed and synthesized to obtain useful metrics for determining and analyzing physical activity. For example, data related to motion or acceleration can be used to determine the number of steps, step intensity (e.g., whether the user is walking, jogging, or sprinting, see page 11 / 24 of specification 15 CN 121263852 A). Altitude-related data can be aggregated into activity data to obtain inferred values ​​such as the number of stairs climbed or descended, or the distance and altitude during a hike.

[0073] Other health-related data can be collected automatically by user input or via a connected electronic device, such as blood pressure and weight. For example, blood pressure can be a useful indicator providing information about a user's cardiovascular system and can be measured manually or automatically using an inflatable blood pressure cuff. If a standard blood pressure cuff with manual blood pressure readings is used, the user can...Blood pressure is entered in the user interface associated with the mHealth application 1. An electronic blood pressure monitor device can measure blood pressure and transmit the value to the mHealth application 1 for storage and analysis. Other methods of measuring blood pressure may include arterial blood pressure monitors and oscillometric blood pressure measurements. Similarly, a user's weight can be measured using a standard (e.g., non-electronic) scale, with the result manually entered by the user 8 in the mHealth application 1. Weight can also be measured using an electronic scale (“smart scale”) connected to electronic device 19 or network 32. The measured weight can be automatically transmitted to the mHealth application 1.

[0074] Results of laboratory tests or other medical examinations can be collected via user input in the mHealth application 1 or automatically transmitted directly from the laboratory performing the laboratory test or the hospital or clinic performing the medical examination via network 32. Laboratory tests or other medical examinations may include A1C tests, lipid profile tests, renal function tests (e.g., urine albumin tests), ophthalmological examinations, foot examinations, liver function tests, thyroid function tests, C-peptide tests, and / or hemoglobin tests.

[0075] Educational activities may include any activity a user undertakes to understand their condition, manage the condition, and how to prevent or manage complications. For example, diabetes-related educational activities can take many forms, including one-on-one consultations with a healthcare provider or diabetes coach, small group classes or support groups, online resources and applications, and written or audio / video materials. Diabetes education can cover a wide range of topics, including understanding the causes and symptoms of diabetes, how to monitor glucose levels and interpret results, the role of medications and insulin therapy in diabetes management, how to manage diet and nutrition to control glucose levels, the importance of physical activity and exercise in diabetes management, strategies for preventing or managing diabetes-related complications such as nerve damage, kidney disease, and vision problems, and techniques for coping with the emotional and psychological challenges of people with diabetes.

[0076] Educational activities can be facilitated via the mHealth application 1. For example, a user 8 can engage with the mHealth application 1 by opening an article about the role of medications and insulin therapy in diabetes management. Another example may include providing consultations to a healthcare provider or diabetes coach via the mHealth application 1, which may include video conferencing. Engagement with the mHealth app 1 (such as opening and reading articles or participating in video conferences with instructors or providers) can be recorded and documented as completed educational activities. User 8 can also manually enter completed educational activities that are not supported by the mHealth app 1.

[0077] As described above, engagement data related to medication intake, diet, physical activity, laboratory results, and educational activities...(For example, “MEDAL” data) can be aggregated and synthesized to generate an engagement score (e.g., engagement status) for user 8 over a predefined time period. As discussed herein, engagement refers to the degree of interaction with mHealth application 1 through manual input of data into mHealth application 1, through direct interaction with mHealth application 1, and / or through interaction with one or more entities that transmit data to mHealth application 1 on behalf of the user (e.g., automated engagement). For example, one or more entities may include laboratories, support groups, devices, platforms, activity trackers, pill dispensers, online calorie trackers, etc. Therefore, engagement data refers to any data indicating engagement with mHealth application 1, such as user 8’s manual user input in mHealth application 1, automated input (e.g., using one or more electronic devices 19), and transmissions received from third-party sources that receive any interactions with user 8 regarding medication intake, diet, physical activity, laboratory results, and educational activities.

[0078] In some embodiments, the engagement state can be binary and can be classified as a high engagement state or a low engagement state. If the user 8 interacts with the mHealth application 1 or an entity transmitting data to the mHealth application 1 to a level equal to or greater than a threshold, the engagement state can be classified as a high engagement state. If the user 8 interacts with the mHealth application 1 or an entity transmitting data to the mHealth application 1 to a level less than a threshold, the engagement state can be classified as a low engagement state. In some embodiments, the engagement state can be determined based on the number of “engagement activities” that the user 8 participates in within a time period. An engagement activity can be a single activity or an interaction with the application 1, or an entity transmitting data to the mHealth application 1 on behalf of the user 8. For example, engagement activities may include the user entering or inputting medications, meals and nutritional information, exercise, laboratory test results, and / or educational activities into the mHealth application 1. As a further example, engagement activities may include transmissions received by the mHealth application 1 from an activity tracker regarding user 8's activities, transmissions received from a networked pill dispenser, transmissions including laboratory test results received from a third-party laboratory, and / or transmissions received from a networked educational website. According to embodiments, any interaction between user 8 and the mHealth application 1 can be considered an engagement activity. Any educational activity facilitated via the mHealth application 1 or other suitable platforms can be recorded as an engagement activity. Taking a binary engagement state as an example, the threshold for high engagement can be...This means approximately five engagement activities within a ten-day period. Using this example threshold, if user 8 performs approximately five or more engagement activities during the ten-day period, user 8's engagement state can be determined as "high engagement." If user 8 performs fewer than approximately five or more engagement activities during the ten-day period, the engagement state can be determined as "low engagement."

[0079] There can be more than two engagement states. In one example, there can be three engagement states, including "high engagement," "low engagement," and "no engagement." In this example, the high and low engagement states may be the same as in the example above with two engagement states. The difference is that if the number of engagement activities during the period is zero, it is recorded as a no engagement state. There can be a scale for engagement such that the number of engagement activities is stored, rather than a discrete number of engagement states, and used for analysis and prediction. Furthermore, in some embodiments, engagement activities can have different weights, such that some engagement activities are counted as higher levels of engagement, while others are counted as lower levels of engagement. When determining the engagement status, the weight of each engagement activity can be considered.

[0080] The engagement data received at 504 may also include measurements of CGM device usage by user 8 (“CGM engagement”). For example, if user 8 uses (e.g., wears) the CGM device continuously day and night with very short intervals between sensor replacements, the received engagement data may indicate high CGM engagement. In some embodiments, the CGM engagement status is determined based on a threshold number of collected CGM readings. For example, if user 8’s CGM device records approximately 70% or more of the possible CGM readings during the time period, the CGM engagement status may be classified as “high engagement.” If user 8’s CGM device records less than approximately 70% of the possible CGM readings during the time period, the CGM engagement status may be classified as “low engagement.” The number of possible CGM readings during the time period is approximately 288 readings per day (e.g., approximately one reading every five minutes) and may refer to the frequency at which the CGM device is configured to read blood glucose levels.

[0081] At 506 in FIG5, a GRI value can be determined based on a hypoglycemic component and a hyperglycemic component according to one or more techniques disclosed herein. The hypoglycemic component can be associated with the amount of time during which user 8 is in a hypoglycemic state over a period of time (e.g., the time periods during which blood glucose and participation levels are collected at steps 502 and 504, respectively). The hyperglycemic component is associated with the amount of time during which user 8 is in a hyperglycemic state over the same time period. A GRI region can also be determined based on the GRI value and the hypoglycemic and hyperglycemic components.

[0082] In some embodiments, a time-in-recess (TIR) ​​value within a target range is determined in relation to the blood glucose level reading. Target rangeThe blood glucose value within a given range may correspond to the amount of time a blood glucose level reading is within a given range, the ratio of blood glucose level readings within and outside the range, the count of blood glucose level readings within and outside the range, etc. For example, the TIR value may be based on blood glucose level readings that are between approximately 70 mg / dL and approximately 180 mg / dL. The TIR value can distinguish the time when user 8's blood glucose level is within the range and the time when it is outside the range. The determined TIR value may be based on the amount of time user 8's blood glucose level is within the threshold band within a reference time period. The reference time period may be a single 24-hour period or may be different reference time periods. The reference time periods may be predetermined (e.g., by user 8, by healthcare provider 7, pre-programmed, etc.) or may be dynamically determined based on one or more factors. One or more factors may be a patient vector, patient attributes, current or previous TIR status, etc.

[0083] According to an embodiment, the TIR value may be the TIR value of a reference time period or may be the TIR value associated with a patient over multiple reference time periods. For example, the TIR value for each day of a total of ten days for user 8 can be determined. The TIR values ​​for each day of these ten days can be combined using any applicable technique (e.g., averaging) such that the TIR associated with user 8 over the ten days is a combined TIR value.

[0084] At 508 in FIG5, one or more predictions for future glucose levels are determined based on the glucose level and engagement data for user 8 received at steps 502 and 504. One or more predictions may be based on the glucose level and engagement data for user 8 over a given time period (e.g., ten days), which may be considered the initial time period. The one or more predictions may be determined using a machine learning model trained to determine predictions for blood glucose and / or engagement levels, according to one or more techniques disclosed herein. The predictions may be estimates or calculated values ​​based on current or historical values ​​(e.g., values ​​determined during the initial time period).

[0085] Predicted values ​​may include quantitative measurements (such as blood glucose levels) or qualitative indicators derived from quantitative measurements (such as GRI values). Therefore, one or more predictions may include predictions for one or more future GRI values. Future GRI values ​​can be predicted based on current and historical received and / or determined GRI values. Furthermore, it can be determined that the future GRI value is greater than or less than the first GRI value determined at step 506. A future GRI region can also be determined based on the future GRI value. The future GRI region can be compared with a currently determined GRI region, and it can be determined that the future GRI region is the same as or different from the currently determined GRI region.

[0086] In some embodiments, the prediction of the user 8's future glucose level is based on the user's current and historical...Glucose levels and engagement levels. In other embodiments, predictions of future glucose levels for user 8 are based solely on the user's current and historical glucose levels, without considering engagement levels.

[0087] One or more predictions of future glucose levels in step 508 may also include predictions of one or more future TIR values. Predictions may include predicting that a future TIR value is greater than or less than a determined current or historical TIR value in response to a comparison between a current / historical TIR value and a predicted future TIR value. In some embodiments, predictions of future TIR values ​​include predictions that a future TIR value is within a specific percentage of the currently determined TIR value, or much larger or smaller than a specific percentage. For example, a future TIR value may be predicted to be within approximately 5% of the currently determined or historical TIR value, greater than approximately 5%, or less than approximately 5%.

[0088] At 510 in FIG5, one or more predictions of future engagement levels (e.g., future MEDAL levels) are determined based on engagement levels collected over a time period. According to an embodiment, one or more predictions of future engagement levels may be based on glucose levels collected over a time period. A trained machine learning model can be used to determine one or more predictions of future engagement levels. This model is trained to acquire current and / or historical engagement levels and outputs predictions of future engagement levels. In some embodiments, predictions of future engagement levels may be based on current and historical values ​​of glucose levels and engagement levels, or in some cases, on only current and historical values ​​of engagement levels, or only current and historical values ​​of glucose levels. (See specification for future engagement levels, page 14 / 24, 18 CN 121263852 A). Predictions may include predictions of future engagement states. For example, a predicted future engagement state may be a high engagement state, a low engagement state, a no engagement state, an engagement state value or level, etc. Furthermore, the predicted future engagement state may be compared with currently received or determined engagement states to determine whether these states are the same or different. Predictions of future engagement may include predictions of how user 8 might interact and / or engage with the mHealth application 1, tracking devices, etc., as described herein. For example, a machine learning model can receive input engagement data (e.g., MEDAL values) reflecting how user 8 interacts with mHealth application 1 in a specific way, and predict how user 8 will interact with mHealth application 1, tracking devices, etc., such as how user 8 will interact with specific foods, specific medications, specific exercise routines, etc.

[0089] Future engagement level prediction may also include one or more predictions of future CGM engagement. For example, if in the participationIf user 8's CGM engagement is classified as high engagement during the data collection period, it can be predicted that user 8 will continue to exhibit high engagement or usage of the CGM device, or, based on other factors, that user 8 will exhibit low engagement in the future.

[0090] According to one or more embodiments of this disclosure, one or more feature sets can be derived from a user's glucose level and / or engagement data. Further details regarding features derived from CGM data and engagement data will be disclosed herein with reference to Figures 8A through 8D. The derived feature sets can be used as input to a machine learning model to determine predictions of future glucose levels and future engagement. For example, a machine learning model can be trained to extract features based on glucose level and / or engagement data, and / or to make feature-based predictions based on the derived features.

[0091] Figure 6 illustrates a flowchart 600 of training a machine learning model to predict a user's health and engagement levels according to one or more embodiments. At 602, a first set of glucose levels collected by the CGM device during a first time period is received. In one or more embodiments, two or more first sets of glucose levels are received. For example, first sets of glucose levels from multiple users, including user 8, can be received. Two or more sets of first glucose levels may also refer to multiple iterative collections of glucose levels for the same user (e.g., user 8) over multiple fixed time periods. According to an embodiment, the glucose levels received at 602 can be simulated (e.g., using a simulation model configured to output representative glucose levels).

[0092] At 604, a second set of glucose levels collected by the CGM device during a second time period is received. The second time period may be after the first time period and may be the same or different in length from the first time period. In one or more embodiments, two or more sets of second glucose levels are received, wherein each set of glucose levels is associated with the same user (e.g., user 8) or, in some cases, with different users. Each first set of glucose levels and each second set of glucose levels corresponding to the same user can be associated with each other, thus allowing analysis and determination of patterns and relationships between them.

[0093] According to an embodiment, the CGM device used to collect glucose levels during the first time period and the CGM device used to collect glucose levels during the second time period may be the same. According to another embodiment, the CGM device used to collect glucose levels during the first time period and the CGM device used to collect glucose levels during the second time period may be different. According to this embodiment, differences in CGM devices can be considered during the training of the machine learning model. For example, the machine learning model can be provided with technical information associated with each CGM device (e.g., drift values, calibration metrics, etc.), andIt can be configured to normalize the CGM values ​​output by each corresponding CGM device. The first group of glucose levels and the second group of glucose levels may include the same or substantially similar number of glucose level measurements, but in some cases, the first group of glucose levels and the second group of glucose levels may include different numbers of glucose level measurements.

[0094] At 606, a first group of participation data is received. In some embodiments, two or more first groups of participation data are received, wherein each group is associated with a user (e.g., user 8). The other group may be associated with multiple different users, or the participation data may be collected multiple times for the same user within multiple fixed time periods. The first group of participation data is collected by a computing device (e.g., electronic device 19) within a first time period. The first time period for collecting the first group of participation data may correspond to the first time period for collecting the first group of glucose levels (e.g., the initial time period).

[0095] At 608, second participation data is received. In some embodiments, two or more second groups of participation data are received, wherein each group is associated with a user (e.g., user 8). The second set of participation data can be associated with multiple different users, or it can be participation data collected multiple times for the same user within multiple fixed time periods. The second set of participation data is collected by a computing device (e.g., electronic device 19) within a second time period. The second time period for collecting the second set of participation data can correspond to the second time period for collecting the second set of glucose levels. Both the first and second sets of participation data can be associated with one or more of the user's medication intake, diet, physical activity, laboratory results, and educational activities (e.g., MEDAL activities).

[0096] At 610, one or more machine learning models (e.g., a blood glucose and participation machine learning model) are trained based on a machine learning algorithm. The machine learning model can be trained using training data that includes the first glucose level received at step 602, the second glucose level received at step 604, the first participation data received at step 606, and the second participation data received at step 608. According to an embodiment, the first machine learning model can be trained specifically for users with type 1 diabetes, and the second machine learning model can be trained specifically for users with type 2 diabetes. In some cases, a single machine learning model can be trained for all diabetes users, regardless of their type.

[0097] A feature set can be derived from the first set of glucose levels received at step 602 and the first participation data received at step 606. In some cases, features can be derived from the second set of glucose levels received at step 604 and the second participation data received at step 608. The derived features can be used as part of the training data, or can be derived from a...One or more machine learning models are determined based on the input training data from steps 602 to 608.

[0098] According to an embodiment, the data received at steps 602 to 608 may be cleaned before being input as training data. Cleaning the data includes identifying and correcting or removing any errors, inconsistencies, or irrelevant information in the dataset. Missing data may be handled by identifying any missing values ​​in the dataset and determining data modifications, including removing rows or columns containing missing values, replacing missing values ​​with estimated values, or estimating missing values ​​using machine learning algorithms. Duplicates are removed to avoid skewed results. If data is received from multiple different sources, the data may be standardized, including converting the data to a consistent format and / or units. Outliers (e.g., extreme values ​​that may significantly affect training) may be modified (e.g., removed or corrected). The data received at steps 602 to 608 may be checked for human or technical errors and corrected when such errors are identified. Irrelevant data may be removed so that training is focused on the data most relevant and important for predicting future health and engagement outcomes.

[0099] As described herein, relevant features are identified and selected. According to embodiments, relevant features may include those most important in predicting future health and engagement outcomes (e.g., glucose levels and engagement levels). Irrelevant and / or redundant features may negatively impact the performance of the machine learning model and may increase its complexity, and may be removed. Selecting relevant features may involve exploratory data analysis, correlation analysis, feature importance ranking, and domain knowledge.

[0100] Exploratory data analysis may include visualizing training data and analyzing the relationships between different variables, which can be used to identify features that are highly correlated with the target variable and features that are less correlated. Correlation analysis may involve calculating the correlation coefficient between each feature and the target variable. Features with high correlation coefficients may be more relevant than features with low correlation coefficients. Feature importance ranking involves using statistical algorithms such as decision trees or random forests to rank the importance of each feature based on its contribution to model accuracy. Domain knowledge may be used to identify relevant features not captured by statistical methods. For example, as described in this disclosure, those skilled in the art may know that food and drug features are most relevant to glucose level prediction, while comment features (e.g., user-input comments in mHealth app 1) and educational activity features have lower relevance and may therefore only increase model complexity and reduce its usability. Once the most relevant features are selected, the training dataset can be transformed to include only those features most important to the model. This reduces model complexity, reduces the risk of overfitting, and improves the overall accuracy of the model when making predictions. In some embodiments, feature selection can...It is automatic and the most relevant features can be selected without human intervention.

[0101] According to an embodiment, any applicable features can be identified such that no relevant features are extracted. Therefore, these features can include known relevant features as well as unknown relevant features. One or more machine learning models can be trained to apply all or some of these features based on applicable weights, layers, biases, synapses, training algorithms, etc. According to this embodiment, one or more machine learning models can be provided, or any such applicable features can be determined for training or for generating predictive outputs.

[0102] According to embodiments disclosed herein, features can be determined based on any applicable attributes, such as categories, variances, segments, etc., associated with given data. Such attributes can be based on (but are not limited to) time or time range (e.g., time of day, hour, day, etc.), data type (e.g., CGM data, MEDAL data, TIR data, TBR data, GRI data, Glucose Management Index (GMI) data, etc.), type of analysis associated with the data (e.g., mean, sum, value, etc.), etc.

[0103] According to one or more techniques of this disclosure, including those discussed with respect to FIG. 3B, a model is trained using a training dataset. Training includes using statistical algorithms to find patterns and relationships (e.g., associations, correlations, dependencies, connections, similarities, etc.) in the data that can be used for prediction. For example, the model is trained using inputs including a first set of glucose levels and a second set of glucose levels, as well as a first set of participation data and a second set of participation data, as described with reference to steps 602 to 608. Statistical algorithms can be used to train the model to determine patterns and relationships between the first set of glucose levels received at step 602 and the second set of glucose levels received at step 604. Alternatively, or additionally, the model can be trained to determine patterns and relationships between the first set of participation data received at step 606 and the second set of participation data received at step 608.

[0104] At 612, one or more patterns in the training data are determined. For example, the model can be trained to determine patterns and relationships between the first set of glucose levels and participation data and the second set of glucose levels and participation data. Determining patterns in the training data may include determining the relationship between a first set of glucose levels received at step 602 and a second set of glucose levels received at step 604. Determining patterns may also include determining the relationship between a first set of participating data received at step 606 and a second set of participating data received at step 608. Weights, layers, biases, and / or synapses associated with the machine learning model may be updated based on the determined patterns. Furthermore, test data may be provided to the machine learning model to determine its accuracy, and the model may be retrained, updated, or adjusted based on the results of one or more accuracy tests.

[0105] In one or more embodiments, as disclosed herein, a machine learning model trained based on the method provided in flowchart 600 can be used to make one or more predictions on a new set of unknown data. For example, a third set of glucose levels can be received, wherein the third set of glucose levels is collected by the CGM device in a third time period following the second time period. A third set of engagement data can also be received, which is collected by the computing device in the third time period. The third set of glucose levels and the third set of engagement data can be associated with the same user (such as user 8). Using the third set of glucose levels and the third set of engagement data as input, the trained machine learning model can be used to determine one or more predictions of future glucose levels or engagement levels (e.g., for a future “fourth” subsequent time period).

[0106] Figure 7A is a diagram depicting the prediction of future health and engagement outcomes using blood glucose (“CGM usage”) and engagement data according to one or more embodiments. Figure 700 is a timeline that includes an “early stage” time period 702 (e.g., an initial time period, such as approximately ten days) and a “future time period” time period 704. The early stage time period 702 can be a predefined period of time during which blood glucose and participation data are collected to predict glucose and participation levels during the future time period 704. In some embodiments, the early stage time period 702 and the future time period 704 can be the same amount of time, but in some cases, they can be different lengths of time. For example, the early stage time period 702 can range from ten to thirty days, while the future time period 704 can range from approximately five to ninety days. The early stage time period 702 may precede the future time period 704 directly, or there may be a time interval between the early stage time period 702 and the future time period 704. Patterns indicative of behavior and outcomes during the future time period 704 may be displayed during the early stage time period 702.

[0107] Figure 7B is a table 710 depicting an embodiment of future outcome prediction according to one or more embodiments. Column 712 includes questions about how to use early stage data to predict different types of future health and participation outcomes. Column 714 includes observable outcome variables to determine the corresponding outcome predictions. Column 716 includes a number assigned to each question and different scenarios of possible outputs. Column 718 includes a description of the different possible outcome predictions for each observed variable. As shown in Figure 7B, in some embodiments, based on, for example, three different outcome probabilities (e.g., as illustrated by the question in Column 712), there may be nine different categories of outcome predictions. This contrasts with predictions based on index values ​​(e.g., TIR value, GRI value, MEDAL participation value, etc.).Compared to value prediction or bi-state prediction, the result prediction can be based on, for example, bi-state and tri-state orientations, or on value prediction based on the relative difference with historical inputs (e.g., based on CGM data, based on compliance data, based on MEDAL data, based on time information, etc.).

[0108] Figure 7C is a graph depicting example MEDAL and CGM data collected for an example user according to one or more embodiments. Each entry on the horizontal axis represents five days, while each entry on the vertical axis represents a 45-minute time period in a day. For example, at index point 726, the values ​​of a 30-day historical time period 722 (e.g., three 10-day time periods) are input into a machine learning model to determine a prediction of a 30-day future time period 724. Figure 720 also shows MEDAL data input in the mHealth application 1, including exercise / activity, height, steps, and weight input. The top portion 728 of Figure 720 depicts the TIR, where one point indicates that the user uses (e.g., wears) the CGM device for more than 70% of the time.

[0109] Figures 8A to 8D illustrate diagrams depicting feature selection at an early stage according to one or more embodiments of the present disclosure. Records may be data extracted based on glucose values ​​(CGM usage) and / or engagement data (MEDAL usage) 810. Glucose values ​​and / or engagement data 810 may be divided into known data and unknown data 808. Records may be summarized and represented by a single value or record, represented in Figure 8A by a complete record 802, which may represent the average of glucose levels and other potential features. Records may be segmented into smaller, independent portions (e.g., segmented by time), represented by summary slices, such as MAEN values ​​(e.g., morning, afternoon, evening, nighttime averages) for records 804 and hourly records 806. From each record, one or more features 820 may be extracted, including, for example, CGM features, food features, drug features, review features, etc., as shown in Figure 8A.

[0110] In some embodiments, a single feature may include several attributes that can themselves be used as features, as shown in Figures 8B to 8D. This feature extension may help improve the accuracy of machine learning models used to predict future health and engagement outcomes. For example, as shown in Figure 8B, metadata associated with CGM glucose values ​​and / or averages can be an attribute or sub-feature 812 of a single CGM glucose value feature 802A. A single CGM glucose value feature 802A can include several feature sub-features 812, such as meanBGValue (mean blood glucose value over a time period), meanVeryLow (mean percentage of time with extremely low blood glucose values), meanLow (mean percentage of time with low blood glucose values), and meanTIR (mean percentage of time within a target range).The features include meanHigh (average percentage of time with high blood glucose), meanVeryHigh (average percentage of time with extremely high blood glucose), meanGRI (average GRI value within a time period), meanTBR (average percentage of time below the target range), meanTAR (average percentage of time above the target range), meanGMI (average blood glucose management index), and wearableTimeRate (percentage of time spent wearing the wearable CGM device). In some embodiments, sub-features are predefined and classified under supervision. The machine learning model can rank each feature to determine which features have the greatest impact on the outcome. In some embodiments, the machine learning model can determine features and sub-features without human intervention. For example, the machine learning model can provide predicted blood glucose and / or engagement levels based on historical blood glucose and / or engagement levels (e.g., collected during an initial time period). The machine learning model can also output a ranking of features (or sub-features) in order of their dependence on each feature in determining the predicted blood glucose and / or engagement levels. For example, the ranking of features can be provided as an ordered list via a graphical user interface (GUI). The list can be sorted based on ranking and can be updated based on updated machine learning output.

[0111] According to an embodiment, an instance of user 8's mHealth application 1 can be automatically updated based on the ranking of features associated with user 8. For example, the ranking of features can be used to identify one or more features that meet a threshold for glucose levels and / or engagement that influences good predictions for that user. Therefore, an instance of user 8's mHealth application 1 can be automatically updated to generate reminders that encourage performance (e.g., reminders based on medication, diet, activity, etc.) based on one or more features that meet a threshold for glucose levels and / or engagement that influences good predictions. For example, mHealth application 1 can be updated to generate alerts and / or notifications based on one or more features that meet a threshold for glucose levels and / or engagement that influences good predictions, or generate alerts and / or notifications more frequently.

[0112] Figure 8C illustrates sub-features 814 that can be extracted from a single example food feature 802B. For example, a single food feature could be user input that user 8 ate a sandwich. Multiple sub-features can be extracted from the food eaten by the user input. For example, calories and other nutritional indicators (e.g., carbohydrates, fiber, fat, protein, sodium, fat type, vitamins, minerals, sugars, etc.) can be used as features for machine learning models.

[0113] Figure 8D illustrates sub-features 816 that can be extracted from example single drug feature 802C. For example, single drug featureFeatures may include user input regarding the use of a specific medication. User input may include multiple sub-features, including average dose, duration of use, medication type, prescription category, etc. Similar feature extension principles apply to other features, such as educational activities, physical activities, and / or laboratory test results.

[0114] Figures 9A to 9E illustrate graphs depicting experimental results of applying machine learning models according to one or more embodiments disclosed herein. Figure 9A shows the results of several different machine learning models trained to predict TIR differences. In this example, samples from three ten-day time periods [1,2,3] (totaling over approximately 2880 CGM readings and at least one engagement activity) were input into various machine learning models. The model with the highest accuracy in this experiment is listed in Figure 9A, while several models with lower accuracy are not listed. Table 902 depicts models predicting three different TIR states (e.g., more than 5% worse than the TIR of the input period, less than 5% worse than the measured TIR, and more than 5% better than the TIR), separated by diabetes type and the number of future time periods predicted. It should be noted that "DT1" and "DT2" refer to type 1 diabetes and type 2 diabetes, respectively. "AUC" refers to the area under the curve, which indicates the model's ability to distinguish between classes. As shown in Table 902, the accuracy of this example experiment ranges from 43% to approximately 55%. Table 902 and all subsequent tables shown in Figures 9A through 9E include other metrics, including recall, precision, and F1 score. Recall is a performance metric used to measure the ability of a model to correctly identify all positive instances in a dataset. It is the proportion of true positive instances correctly identified by the model out of all positive instances present in the dataset. Precision is a performance metric used to measure the ability of a model to correctly identify positive instances out of all instances identified as positive by the model. It is the proportion of true positive instances correctly identified by the model out of all instances identified as positive by the model. The F1 score is a single performance metric that combines precision and recall into an overall measure of model performance. Table 19 / 24, page 23, CN 121263852 A 904, describes models that predict two different states (e.g., a better or worse TIR based on the TIR measured within the input period). The accuracy of these predictions is improved, ranging from 58.33% to 64.33%.

[0115] Figure 9B shows the results of several models' ability to predict engagement. In this example, we input samples from three ten-day time periods [1,2,3] (with at least some records of CGM activity and other engagement (MEDAL) activities) into various machine learning models to predict different engagement results for the three ten-day time periods [7,8,9]. Table 910 depicts the predictions of...Models for CGM participation (e.g., high or low participation status) achieved an accuracy of 76.25% for type 1 diabetes and 79.29% for type 2 diabetes. Table 912 depicts models for predicting future participation (e.g., high or low participation status) using mobile applications (such as the mHealth app1), achieving approximately 90% accuracy for both type 1 and type 2 diabetes.

[0116] Figure 9C illustrates the results of several models' ability to predict health outcomes (e.g., TIR values ​​and changes). In this example, samples from three ten-day time periods [1, 2, 3] (totaling over approximately 2880 CGM readings and at least one participation activity in some cases) were fed into various machine learning models. As shown in Table 920, including participation data (MEDAL data) improved the accuracy of the model output from 47.58% to 51.59% when considering three-state TIR predictions. As shown in Table 922, when considering two-state TIR predictions, including participation data (MEDAL data) improves the accuracy of the model output from 61.21% to 62.95%.

[0117] Figure 9D shows the results of several models' ability to predict health outcomes (TIR values ​​and changes). The main difference between the examples in Figure 9C and Figure 9D is that the input tested in Figure 9D included more than 5 participation activities, indicating higher participation with the mobile application (e.g., mHealth application 1). Table 930 shows that if user 8 has higher initial participation with mHealth application 1 and also higher CGM participation, the prediction accuracy can be improved to more than approximately 68% when considering three-state TIR predictions. Table 932 shows that if user 8 has higher initial participation with mHealth application 1 and also higher CGM participation, the prediction accuracy can be improved to more than approximately 61% when considering two-state TIR predictions.

[0118] Figure 9E shows additional results regarding the ability of several models to predict engagement outcomes (CGM engagement and mHealth app 1 engagement). This experiment differs from the one shown in Figure 9B because the input tested in Figure 9E included more than 5 engagement activities. Table 940 shows that the model accuracy for predicting bistate CGM engagement is approximately 78%, while Table 942 shows that the model accuracy for predicting bistate engagement with mHealth app 1 is approximately 68% to 69%.

[0119] Figures 9F and 9G show additional results regarding model proficiency (accuracy, AUC, precision, recall, and F1 score) when predicting TIR values ​​based on an initial dataset (e.g., CGM data, compliance data, MEDAL data, etc.). Table 950 in Figure 9F shows the model's proficiency in determining whether a future TIR value will be one of the following three states: morePoor (e.g., more than 5% lower than the current value); Same (e.g., within about 5% of the current value); or Better (e.g., more than 5% higher than the current value). Table 952 in Figure 9G shows the model’s proficiency in determining whether a future TIR value will be one of the following two states: worse than the current / historical TIR value or better than the current / historical TIR value.

[0120] Figure 9H is a graph 954 depicting Shapley Additive Explanation (SHAP) values ​​and eigenvalues ​​of the feature set and / or sub-feature set used in a model for predicting TIR value differences, according to one or more embodiments. For example, the horizontal axis of Figure 954 depicts the SHAP values, which indicate the influence of a given feature or sub-feature on the model output. Each point in Figure 954 represents an individual (e.g., a user). The pattern of each point represents an eigenvalue, where the first pattern represents a small eigenvalue, the second pattern represents a medium eigenvalue, and the third pattern represents a large eigenvalue. In the example Figure 954, the feature that has the greatest influence on the model output is associated with the CGM value. For example, when there are many high CGM glucose values ​​(e.g., greater than 180 mg / dL), users are more likely to obtain a better future TIR value relative to the current or historical TIR value. As another example, when historical data indicates relatively low CGM glucose values ​​(e.g., less than 54 mg / dL), users are more likely to have a worse future TIR value. Specification 20 / 24 pages 24 CN 121263852 A

[0121] Figure 9I shows the results of the model's ability to predict absolute (e.g., non-relative) TIR values ​​over a future time period. Table 956 in Figure 9I shows the model's proficiency in determining whether a future TIR value will be in one of two states: greater than or equal to the target TIR value (e.g., approximately 70% TIR); or less than the target TIR value.

[0122] Figure 9J is a diagram 958 depicting the SHAP values ​​and eigenvalues ​​of the feature set and / or sub-feature set used in the model for predicting TIR values ​​according to one or more embodiments. For example, a high historical TIR value 959A and a high historical exercise duration 959E may have a positive impact on the TIR value for future time periods. However, a high historical TIR value 959B, male status 959C, a high historical GRI value 959D, a long sleep duration in the historical record 959F, and a type 1 diabetes status 959G may have a negative impact on the TIR value for future time periods.

[0123] Figures 9K and 9L show the results of the model's ability to predict the difference between the future GRI value and the current / historical GRI value. Table 960 in Figure 9K shows the model's proficiency in determining whether the future GRI value will be one of the following two states: worse than the current / historical TIR value or better than the current / historical TIR value. Table 962 in Figure 9L shows the model's proficiency in determining whether the future GRI value will be worse than the current / historical TIR value or better than the current / historical TIR value.The model's proficiency in determining whether a future GRI value will be in one of three states: worse (e.g., more than 5% lower than the current value); the same (e.g., within about 5% of the current value); or better (e.g., more than 5% higher than the current value).

[0124] Figure 9M shows the results of the model's ability to predict absolute (e.g., non-relative) GRI values ​​over a future time period. Table 964 in Figure 9M shows the model's proficiency in determining whether a future GRI value will be in one of two states: greater than or equal to a target GRI value (e.g., a GRI value of about 40); or less than a target GRI value.

[0125] Figure 9N shows the results of the model's ability to predict mHealth application 1 engagement over a future time period. Table 966 shows the model's proficiency in determining whether a user's future engagement with mHealth application 1 will be in one of two states: high engagement (e.g., more than or equal to about five engagement activities); or low engagement (e.g., less than about five engagement activities).

[0126] Figure 9O is a figure 968 depicting the SHAP values ​​and eigenvalues ​​of the feature set and / or sub-feature set used in a model for predicting engagement levels, according to one or more embodiments. For example, studies have found that steps, sleep time, and exercise volume all have an impact on accurately determining future engagement. More step counts and more steps may have a positive impact on morning engagement, while longer wear of the wearable device in the morning may have a positive impact on overall engagement.

[0127] Figure 9P shows the results of the model's ability to predict manual engagement in the mHealth app 1 over a future time period. Manual engagement refers to engagement activities that typically require manual input from the user in the mHealth app 1. Therefore, since many engagement activities are automatically measured by the wearable device, activity engagement can be excluded when determining manual engagement. Table 970 shows the model’s proficiency in determining whether a user’s future manual engagement with the mHealth application 1 will be in one of two states: high manual engagement (e.g., more than or equal to approximately five engagement activities, including medication intake, educational activities, diet, and laboratory results); or low manual engagement (e.g., fewer than approximately five engagement activities, including medication intake, educational activities, diet, and laboratory results).

[0128] Figure 9Q is Figure 972, which depicts the SHAP values ​​and eigenvalues ​​of the feature set and / or sub-feature set used in the model for predicting manual engagement levels according to one or more embodiments. For example, as shown in Figure 972, it was found that medication administration, weight input, and sleep recordings of manual input affect the accurate determination of future manual engagement.

[0129] Figure 9R shows the results of the model’s ability to predict CGM engagement over a future time period. Table 974 of Figure 9R showsThe model's proficiency in determining whether future CGM participation levels will be in one of two states: greater than or equal to the target CGM device wearing time (e.g., approximately 70% of the time, or approximately 70% of the week or a total of 2880 possible readings); or less than the target CGM device wearing time. Specification 21 / 24 pages 25 CN 121263852 A

[0130] Figure 9S is a figure 976 depicting the SHAP values ​​and eigenvalues ​​of the feature set and / or sub-feature set used in a model for predicting CGM participation levels according to one or more embodiments. For example, as shown in Figure 976, in M11 (e.g., November or November), a large number of nighttime CGM records, as well as CGM records in the evening, afternoon, morning, after breakfast, after lunch, and after dinner, may have a negative impact on CGM participation. However, in M7 (July), more CGM records may have a positive impact on CGM participation. More nighttime records are generally likely to have a positive impact on CGM participation, and individuals classified as male may exhibit a positive impact in future time periods.

[0131] Figure 9T illustrates the results of the model's ability to predict CGM participation over a future time period based on historical participation data. Table 978 of Figure 9T shows the model's proficiency in determining whether future CGM participation levels (as determined based on participation data as input to the model) will be one of two states: greater than or equal to the target CGM device wearing time (e.g., approximately 70% of the time, or approximately 70% of a week or a total of 2880 possible readings); or less than the target CGM device wearing time.

[0132] Figure 9U is a graph 980 depicting the SHAP values ​​and eigenvalues ​​of the feature set and / or sub-feature set used in the model for predicting CGM participation levels according to one or more embodiments. For example, male status may be negatively correlated with CGM participation, while patients over 65 years of age with type 1 diabetes status may be positively correlated with CGM participation. Individuals with more exercise records may be positively correlated with CGM participation. Other features, including exercise distance, evening exercise, and exercise duration, affect the model output, but demographic features often have a more significant impact on the output.

[0133] Figure 9V is a confusion matrix 982 based on predicted CGM participation and actual CGM participation according to one or more embodiments. As shown in the random forest classifier confusion matrix 982, the model tends to make more positive predictions than the actual number of users participating in CGM devices, i.e., users are more likely to participate in CGM devices in the future.

[0134] Figures 9W and 9X are examples of graphs depicting the AUC of different models according to one or more embodiments. For example, Figure 984 of Figure 9W depicts the AUC of the random forest classifier model, while Figure 986 of Figure 9X depicts the AUC of the light gradient boosting machine.The AUC of the (LGBM) model. Although the accuracy and recall values ​​of the two models are similar, the AUC of the random forest classifier is higher, indicating its stronger ability to distinguish classes and can be used as a summary of the receiver operating characteristic (ROC) curve.

[0135] In some embodiments, a TIR value of approximately 0.7 or greater may be a clinically meaningful target value for optimal diabetes management. Therefore, the binary outcome variable of TIR can be set as a first state where TIR is greater than or equal to approximately 0.7 and a second state where TIR is less than approximately 0.7. Different types of models can be implemented, such as LGBM, random forest classifier, quadratic discriminant analysis, Naive Bayes, and / or logistic regression models, to predict whether TIR will be greater than approximately 0.7 over a prediction time period. In experiments with different models implemented (e.g., five different models), test results from 304 subjects showed that the LGBM model had a prediction accuracy of 0.80 and an AUC of 0.88. The random forest classifier model had a performance accuracy of 0.77 and an AUC of 0.82. The recall score for the quadratic discriminant analysis model was 0.94. Regarding feature importance, high baseline TIR and long exercise duration were shown to increase the probability of a future TIR exceeding 0.7. High baseline TAR, male sex, and type 1 diabetes negatively impacted TIR, meaning they reduced the probability of a TIR exceeding 0.7. Various model output statistics suggest that decision tree-based models (such as LGBM and random forest classifiers) may be suitable for predicting health outcome variables (such as TIR) above or below clinically meaningful thresholds. Feature importance analysis may help understand which baseline CGM and MEDAL features are important and their impact on future health outcomes. These features can be used to design meaningful personalized interventions for population and individual health management.

[0136] Figures 10A through 10D depict example graphs showing the change of mean GRI values ​​over time for different individual groups according to one or more embodiments. Figure 10A depicts an example graph 1000 showing the change of mean GRI values ​​over time for a group of individuals according to one or more embodiments. The vertical axis shows the GRI values ​​for CGM users. The horizontal axis shows the number of days for which GRI values ​​were determined for CGM users. Example diagram, page 22 / 24, CN 121263852 A 1000: Each line in Figure 1000 represents the average GRI value of a group of individuals starting from each of the five regions. As shown in the example in Figure 1000, individuals whose baseline GRI values ​​start from regions A and B typically end up with higher GRI values ​​but remain in the same corresponding regions (regions A and B). However, individuals whose baseline GRI values ​​start from regions C, D, and E typically improve their GRI values ​​so that by the end of the 14-day period, each group of individuals has improved to a higher region. In other words, from region...Individuals starting in region C typically end up in region B, individuals starting in region D typically end up in region C, and individuals starting in region E typically end up in region D. In some cases, one or more improvements are the result of one or more techniques disclosed herein.

[0137] Figure 10B depicts another example figure 1010 showing the change of the average GRI value of a group of individuals over time according to one or more embodiments. Example figure 1010 shows three distinct groups of individuals grouped by age. Top line 1012 represents individuals aged 18 to 39. Middle line 1014 represents individuals aged 40 to 64. Bottom line 1016 represents individuals aged 65 and above. The average GRI value of individuals aged 65 and above remains in region B, while the average GRI value of individuals aged 18 to 64 remains in region C. As the data captured in Figure 1010 shows, the GRI value appears to decrease with age.

[0138] Figure 10C depicts another example figure 1020 showing the change of the average GRI value of a group of individuals over time according to one or more embodiments. Example Figure 1020 shows two distinct groups of individuals grouped by sex. The upper line 1022 represents males, and the lower line 1024 represents females. As shown in the data captured in Figure 1020, the GRI value of females is lower than that of males.

[0139] Figure 10D depicts another example figure 1030 showing the change of the average GRI value of a group of individuals over time according to one or more embodiments. Example Figure 1030 shows two distinct groups of individuals grouped by diabetes type. Line 1032 represents individuals with type 2 diabetes, and line 1034 represents individuals with type 1 diabetes. As shown in the data captured in Figure 1030, there is no significant difference in GRI values ​​between different diabetes types.

[0140] Figures 11A to 11C are graphs depicting the relationship between precision, recall, specificity, and sensitivity according to one or more embodiments. In Figure 11A, Figure 1102 shows that positive and negative value groups can be classified and their values ​​predicted.

[0141] Figure 11B is a graph 1104 depicting the classification results shown in Figure 1102 of Figure 11A. The results shown in Graph 1104 indicate that two negative values ​​were incorrectly predicted as positive values. Figure 11C depicts Equation 1106, which shows how precision, recall, specificity, and sensitivity are determined. In this example, recall may be the same as sensitivity, but precision may be different from specificity.

[0142] Figure 12 depicts a high-level functional block diagram of an exemplary computer device or system, wherein embodiments of this disclosure or portions thereof may be implemented as, for example, computer-readable code. Furthermore, each of the exemplary computer servers, databases, user interfaces, modules, and methods described above with respect to Figures 1 through 11C may be used in device 1200 as hardware, software, firmware,The invention can be implemented using a tangible computer-readable medium storing instructions or a combination thereof, and can be implemented in one or more computer systems or other processing systems. Hardware, software, or any combination thereof can implement each of the exemplary systems, user interfaces, and methods described above with reference to Figures 1 to 11C.

[0143] If programmable logic is used, such logic can be executed on a commercial processing platform or a dedicated device. Those skilled in the art will understand that embodiments of the subject matter of this disclosure can be implemented in a variety of computer system configurations, including multi-core multiprocessor systems, minicomputers, mainframe computers, linked or clustered computers with distributed capabilities, and ubiquitous computers or microcomputers that can be embedded in virtually any device.

[0144] For example, at least one processor device and a memory can be used to implement the embodiments described above. The processor device can be a single processor or multiple processors, or a combination thereof. The processor device can have one or more processor “cores”. Specification 23 / 24 pages 27 CN 121263852 A

[0145] Various embodiments of the present disclosure as described above in the examples of Figures 1 to 11C can be implemented using device 1200. After reading this description, it will become apparent to those skilled in the art how to implement the various embodiments of this disclosure using other computer systems and / or computer architectures. Although operations may be described as sequential processes, in practice some of these operations may be executed in parallel, concurrently, and / or in a distributed environment, and program code may be stored locally or remotely for access by a single-processor or multi-processor machine. Furthermore, in some embodiments, the order of operations may be rearranged without departing from the spirit of the disclosed subject matter.

[0146] For example, an apparatus 1200 for a computer or server may include a data communication interface port (COM) 1260 for packet data communication. The apparatus may also include a central processing unit (CPU) 1220 in the form of one or more processors for executing program instructions. The platform typically includes an internal communication bus 1210, a program storage device, and data storage devices such as ROM 1230 and RAM 1240 for various data files to be processed and / or communicated by the platform. The hardware components, operating system, and programming language of such apparatus are conventional in nature and are assumed to be well familiar to those skilled in the art. The device 1200 may also include input and output ports (I / O) 1250 for connecting input and output devices such as a keyboard, mouse, touchscreen, monitor, and display, as well as a communication port 1260. Of course, various server functions can be implemented in a distributed manner on multiple similar platforms to distribute the processing load. Alternatively, the server can be implemented by appropriately programming a computer hardware platform.

[0147] It will be apparent to those skilled in the art that, as described herein, this disclosure can be implemented in many different examples of software, hardware, firmware, and / or the entities shown in the figures. Any actual software code having dedicated control hardware to implement the examples does not limit the specific implementation. Therefore, examples are described herein, but it should be understood that modifications and variations of the examples are possible given the level of detail provided herein. Aspects of the subject matter can be considered generally as a “product” or “artifact” in the form of executable code and / or associated data carried or embodied in a type of machine-readable medium. “Storage” type media includes any or all tangible memory or associated modules of a computer, processor, etc., such as various semiconductor memories, magnetic tape drives, hard disk drives, etc., that can provide non-transitory storage for software programming at any time. All or part of the software can sometimes be communicated via the Internet or various other telecommunications networks. For example, such communication can enable the loading of software from one computer or processor to another computer or processor, such as from a management server or host computer of a mobile communication network to a server's computer platform and / or from a server to a mobile device. Therefore, another type of medium that can carry software elements includes light waves, radio waves, and electromagnetic waves, such as physical interfaces between local devices, through wired and fixed leased fiber optic networks, and over various air links. Physical elements carrying such waves, such as wired or wireless links, optical links, etc., can also be considered as media carrying software. As used herein, unless limited to non-transitory tangible “storage” media, terms such as “readable medium” for a computer or machine refer to any medium that participates in providing instructions to a processor for execution.

[0148] It should be understood that the foregoing general description and the following detailed description are merely illustrative and explanatory and do not limit the disclosed examples as claimed.

[0149] Other examples of this disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the invention disclosed herein. The specification and examples are intended to be illustrative only, and the true scope and spirit of the invention are indicated by the following claims. Instruction manual 24 / 24 pages 28 CN 121263852 A Figure 1 Instruction manual drawing 1 / 48 pages 29 CN 121263852 A Figure 2 Instruction manual drawing 2 / 48 pages 30 CN 121263852 A Figure 3A Instruction manual drawing 3 / 48 pages 31 CN 121263852 A Figure 3B Instruction manual drawing 4 / 48 pages 32 CN 121263852 A Figure 4 Instruction manual drawing 5 / 48 pages 33 CN 121263852 A Figure 5 Instruction manual drawingPage 6 / 48, 34 CN 121263852 A, Figure 6, Instruction Manual Drawing; Page 7 / 48, 35 CN 121263852 A, Figure 7A, Instruction Manual Drawing; Page 8 / 48, 36 CN 121263852 A, Figure 7B, Instruction Manual Drawing; Page 9 / 48, 37 CN 121263852 A, Figure 7C, Instruction Manual Drawing; Page 10 / 48, 38 CN 121263852 A, Figure 7C (continued); Page 11 / 48, 39 CN 121263852 A, Figure 7C (continued-1); Page 12 / 48, 40 CN 121263852 A, Figure 7C (continued-2); Page 13 / 48, 41 CN 121263852 A, Figure 7C (continued-3); Page 14 / 48, 42 CN 121263852 A Figure 7C (continued - 4) Instruction Manual Figure 15 / 48 Page 43 CN 121263852 A Figure 8A Instruction Manual Figure 16 / 48 Page 44 CN 121263852 A Figure 8B Instruction Manual Figure 17 / 48 Page 45 CN 121263852 A Figure 8C Instruction Manual Figure 18 / 48 Page 46 CN 121263852 A Figure 8D Instruction Manual Figure 19 / 48 Page 47 CN 121263852 A Figure 9A Instruction Manual Figure 20 / 48 Page 48 CN 121263852 A Figure 9B Instruction Manual Figure 21 / 48 Page 49 CN 121263852 A Figure 9C Instruction Manual Figure 22 / 48 Page 50 CN 121263852 A Figure 9D Instruction Manual Figure 23 / 48 Page 51 CN 121263852 A Figure 9E Instruction manual illustrations, pages 24 / 48, 52 CN 121263852 A, Figure 9F; Instruction manual illustrations, pages 25 / 48, 53 CN 121263852 A, Figure 9G; Instruction manual illustrations, pages 26 / 48, 54 CN 121263852 A, Figure 9H; Instruction manual illustrations, pages 27 / 48, 55 CN 121263852 A, Figure 9I; Instruction manual illustrations, pages 28 / 48, 56 CN 121263852 A, Figure 9J; Instruction manual illustrations, pages 29 / 48, 57 CN 121263852 A, Figure 9K; Instruction manual illustrations, pages 30 / 48, 58 CN.121263852 A Figure 9L Instruction Manual Illustration Page 31 / 48 59 CN 121263852 A Figure 9M Instruction Manual Illustration Page 32 / 48 60 CN 121263852 A Figure 9N Instruction Manual Illustration Page 33 / 48 61 CN 121263852 A Figure 9O Instruction Manual Illustration Page 34 / 48 62 CN 121263852 A Figure 9P Instruction Manual Illustration Page 35 / 48 63 CN 121263852 A Figure 9Q Instruction Manual Illustration Page 36 / 48 64 CN 121263852 A Figure 9R Instruction Manual Illustration Page 37 / 48 65 CN 121263852 A Figure 9S Instruction Manual Illustration Page 38 / 48 66 CN 121263852 A Figure 9T Instruction Manual Illustration Page 39 / 48 67 CN 121263852 A Figure 9U, Instruction Manual Appendix, Page 40 / 48, 68 CN 121263852 A; Figure 9V, Instruction Manual Appendix, Page 41 / 48, 69 CN 121263852 A; Figure 9W, Instruction Manual Appendix, Page 42 / 48, 70 CN 121263852 A; Figure 9X, Instruction Manual Appendix, Page 43 / 48, 71 CN 121263852 A; Figure 10A; Figure 10B, Instruction Manual Appendix, Page 44 / 48, 72 CN 121263852 A; Figure 10C; Figure 10D, Instruction Manual Appendix, Page 45 / 48, 73 CN 121263852 A; Figure 11A; Figure 11B, Instruction Manual Appendix, Page 46 / 48, 74 CN 121263852 A; Figure 11C, Instruction Manual Appendix, Page 47 / 48, 75 CN 121263852 A; Figure 12, Instruction Manual Appendix, Page 48 / 48, 76 CN 121263852 A

Claims

1. A computer-implemented method for predicting a user's health and engagement levels, the method comprising: Receives the user's glucose level collected over a period of time by a continuous glucose monitoring (CGM) device; Receive engagement data associated with the user, the engagement data being collected by the computing device during the time period, wherein the engagement data is associated with the user's medication activities, dietary activities, physical activities, laboratory results, or educational activities; A first glycemic risk index (GRI) value is determined based on a first time period during which the user is in a state of hypoglycemia and a second time period during which the user is in a state of hyperglycemia. Using a machine learning model and in response to the user’s glucose level and the participation data collected during the said time period, one or more predictions of the user’s future glucose level are determined, the one or more predictions including predictions of future GRI values ​​being greater than or less than the first GRI value. as well as Using the machine learning model and in response to user engagement data collected during the said time period, one or more predictions for future engagement levels are determined.

2. The computer-implemented method according to claim 1, further comprising: Determine a time-in-target range (TIR) ​​value for the user's glucose level, wherein the determined TIR value is based on the amount of time the user's glucose level is within a threshold band during the time period, wherein the one or more predictions of the user's future glucose level include a prediction of a future TIR value that is: within a threshold of the determined TIR value; greater than the determined TIR value exceeding a threshold; or less than the determined TIR value exceeding a threshold.

3. The computer-implemented method according to claim 1, further comprising: Determine a time-in-target range (TIR) ​​value for the user's glucose level, wherein the TIR value is based on the amount of time the user's glucose level is within a threshold band during the time period, wherein the one or more predictions of the user's future glucose level further include predictions of future TIR values ​​being greater than or less than the TIR value.

4. The computer-implemented method of claim 2, wherein the one or more predictions of the user's future glucose level include predictions of future TIR values ​​greater than or less than a threshold TIR value.

5. The computer-implemented method according to claim 1, further comprising: A feature set is derived from the user's glucose level and the participation data; as well as The feature set is provided as input to the machine learning model to determine one or more predictions of the user's future glucose level and one or more predictions of the user's future participation level.

6. The computer-implemented method according to claim 1, further comprising: The first GRI region is determined based on the first GRI value. The predictions of the user's future glucose levels include predictions that the future GRI value will be in a GRI zone higher than the first GRI zone or in a GRI zone lower than the first GRI zone.

7. The computer-implemented method of claim 6, wherein the prediction of one or more of the user's future glucose levels includes a prediction that the future GRI value is in the first GRI zone, in a second GRI zone higher than the first GRI zone, or in a third GRI zone lower than the first GRI zone.

8. The computer-implemented method of claim 1, wherein the one or more predictions of the user's future glucose level include predictions of future GRI values ​​greater than or less than a threshold GRI value.

9. The computer-implemented method of claim 1, wherein the one or more predictions of future participation levels include predictions of whether future participation levels are high or low.

10. The computer-implemented method of claim 1, wherein the prediction of the one or more future participation levels includes a prediction of whether the future manual participation level is a first manual participation state or a second manual participation state.

11. The computer-implemented method of claim 1, wherein the prediction of the one or more future participation levels includes prediction of whether the future CGM device participation level is higher than or lower than the CGM device participation threshold, wherein CGM device participation includes a measurement of CGM device usage performed by the user.

12. The computer-implemented method of claim 1, wherein at least some of the participation data is collected through user input from one or more applications on the computing device.

13. The computer-implemented method of claim 1, wherein at least some of the participation data is collected using one or more sensors associated with the user, the one or more sensors including at least one of a scale, a blood pressure monitor, an activity tracker, a heart rate monitor, a multi-functional wearable device, a blood glucose monitor, and a ketone tracking device.

14. A computer-implemented method for training a machine learning model to predict a user's health and engagement levels, the method comprising: Receive the user's first glucose level collected by the continuous glucose monitoring (CGM) device during a first time period; Receive the user's second glucose level collected by the CGM device during a second time period following the first time period; Receive first engagement data associated with the user, the first engagement data being collected by the computing device during the first time period; Receive second engagement data associated with the user, the second engagement data being collected by the computing device during the second time period, wherein the first engagement data and the second engagement data are associated with one or more of the user's medication intake, diet, physical activity, laboratory results, and educational activities; A machine learning model is trained based on a machine learning algorithm and using training data to generate a trained machine learning model, wherein the training data includes the first glucose level, the second glucose level, the first participation data, and the second participation data; as well as Identify one or more patterns in the training data.

15. The computer-implemented method according to claim 14, further comprising: One or more feature sets are derived from the first glucose level and the first participating data. The training data mentioned therein includes one or more feature sets derived therefrom.

16. The computer-implemented method of claim 15, further comprising extracting one or more sub-features from each of the one or more feature sets.

17. The computer-implemented method of claim 14, wherein determining one or more patterns in the training data comprises: Determine the relationship between the first glucose level and the second glucose level; as well as Determine the relationship between the first participation data and the second participation data.

18. The computer-implemented method of claim 14, wherein training the machine learning model further comprises: The trained machine learning model is generated by updating one of the weights, layers, biases, or synapses of the machine learning model based on a determined pattern.

19. The computer-implemented method according to claim 14, further comprising: Receive a third glucose level for the user collected by the CGM device during a third time period following the second time period; Receive third engagement data associated with the user, the third engagement data being collected by the computing device during the third time period, wherein the third engagement data is associated with the user's medication intake, diet, physical activity, laboratory results, and educational activities; Using the trained machine learning model and in response to the third glucose level and the third participation data collected during the third time period, one or more predictions of the user's future glucose level are determined. as well as Using the trained machine learning model and in response to third engagement data of the user collected during the third time period, one or more predictions for future engagement levels are determined.

20. A system for predicting future glucose levels and related activities, the system comprising: A memory having processor-readable instructions stored therein; as well as A processor configured to access the memory and execute processor-readable instructions, which, when executed by the processor, configure the processor to perform a method comprising: A continuous glucose monitoring (CGM) device is used to receive a user's glucose level over a period of time. The CGM device is configured to use a component that penetrates the user's skin to obtain glucose values. Receive engagement data associated with the user, the engagement data being collected by one or more electronic sensors via a computing device during the time period, wherein the engagement data is associated with one or more of the user's medication intake, diet, physical activity, laboratory results, and educational activities; A first glycemic risk index (GRI) value is determined based on a first time period during which the user is in a state of hypoglycemia and a second time period during which the user is in a state of hyperglycemia. Using a machine learning model and in response to the user's glucose levels and participation data collected during the said time period, determine one or more predictions for the user's future glucose levels, said one or more predictions including a prediction that a future GRI value is greater than or less than a first GRI value; and Using the machine learning model and in response to user engagement data collected during the said time period, one or more predictions for future engagement levels are determined.

Images