Systems and methods for analyzing, interpreting, and addressing continuous glucose monitoring data

The method leverages CGM data to create an optimization path for improving glucose management in diabetes patients, addressing the limitations of sporadic measurements by providing personalized adjustments to daily habits and treatments.

JP7699605B2Active Publication Date: 2025-06-27WELLDOC INC
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
JP2022556184
Authority / Receiving Office
JP · JP
Patent Type
Patents
Current Assignee / Owner
Priority Date
2021-01-11
Filing Date
2021-03-19
Publication Date
2025-06-27
Estimated Expiration
2041-03-19

AI Technical Summary

Technical Problem

Current healthcare systems face challenges in managing diabetes effectively due to sporadic glucose measurements, which limit the data available for treatment decisions, leading to inadequate medical, dietary, and lifestyle changes.

Method used

A computer-implemented method using continuous glucose monitoring (CGM) data to determine time-in-range (TIR) and glucose variability (GV) values, which are then used to generate an optimization path to improve a user's glucose state by adjusting account vectors such as blood glucose values, medicine, food intake, exercise, and psychosocial parameters.

Benefits of technology

This method provides a comprehensive and data-driven approach to managing glucose levels, enabling users to achieve and maintain an ideal glucose state by offering personalized adjustments to daily habits and treatments.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 0007699605000003
    Figure 0007699605000003
  • Figure 0007699605000004
    Figure 0007699605000004
  • Figure 0007699605000005
    Figure 0007699605000005
Patent Text Reader

Abstract

The method and device include automated coaching for management of glucose status by receiving a user's blood glucose levels using a continuous glucose monitoring (CGM) device, determining a time-in-range (TIR) ​​value, determining a TIR status, receiving a blood glucose variability (GV) value, determining a GV status, determining a starting state based on the TIR status and the GV status, determining that the starting state corresponds to a non-ideal state, and generating an optimized pathway to reach an ideal state based on one or more accounting vectors, such as addressing self-management behaviors including diet, activity, and medication use. Additionally, the optimized pathway may be based on computer detection and classification of significant events of interest over time.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] (Related Applications) This application is a continuation of 1) U.S. Provisional Application No. 63 / 135,818, filed on January 11, 2021, 2) U.S. Provisional Application No. 62 / 992,385, filed on March 20, 2020, and 3) U.S. Provisional Application No. 62 / 992,409, filed on March 20, 2020, and claims the benefit of priority, each of which is incorporated herein by reference in its entirety.

[0002] Generally, the present disclosure relates to obtaining and processing data to generate an optimized route and improve a user's health. In some embodiments, in particular, it relates to optimizing a user's glucose status via a mobile application.

Background Art

[0003] Increasing healthcare costs are limiting users' access to appropriate care. At the same time, healthcare companies are increasing the workload of providers and limiting the interaction between physicians and users. The treatment of diabetes often relies on sporadic measurements (e.g., glucose measurements) that do not provide sufficient data to effectively offer treatment options. Such measurements are often used alone such that changes are recommended based on very few measurements. Thus, any medical, dietary, and / or lifestyle changes recommended as a result of a given measurement are limited considering the sparse data received via sporadic measurements.

[0004] The present disclosure is directed to addressing one or more of the above problems. The introductory portion provided herein is for generally indicating the context of the present disclosure. Unless otherwise indicated herein, the materials described in this section are not prior art to the claims of the present application and are not admitted to be prior art or an implication of prior art by including them in this section.

Summary of the Invention

[0005] The present disclosure is directed to a computer-implemented method for managing a user's glucose state, which includes receiving a user's blood glucose value using a continuous glucose monitoring (CGM) device, determining a time in range (TIR) value of the user's blood glucose value, where the TIR value is based on the amount of time the user's blood glucose value is within a threshold band over a reference period, determining a TIR state based on the TIR value, receiving a glucose variability (GV) value based at least on the user's blood glucose value, where the GV value is one of a standard deviation or a coefficient of variation (CV), and the CV indicates the variability of the user's blood glucose value considering the standard deviation of the blood glucose value over the reference period, determining a GV state based on the GV value, determining a start state based on the TIR state and the GV state, determining that the start state corresponds to a non-ideal state, generating an optimization path to reach an ideal state based on one or more account vectors, where the optimization path includes one or more adjustments to one or more of the one or more account vectors, and providing the optimization path to the user.

[0006] The threshold band may be between approximately 70 mg / dL and 180 mg / dL, and the reference period may be 24 hours. The CV value may be determined by dividing the standard deviation of the blood glucose value by the average value of the blood glucose values in the reference period. The TIR state may be a binary state selected from one of a good TIR state or a bad TIR state. The good TIR state may correspond to a TIR value greater than the TIR threshold. The GV state may be a binary state selected from one of a good GV state or a bad GV state. The good GV state may correspond to a GV value greater than the GV threshold. The account vector may include one or more of a blood glucose value, medicine, food intake, exercise value, psychosocial parameter, or social determinant parameter. The account vector may include a blood glucose value based on one or more CGM events classified based on a severity score. The optimization path is further based on user attributes, and the user attributes are selected from one or more of social attributes, medical attributes, user preferences, metabolic attributes, or user demographics. The optimization path may include an increase in one or more state-improving habits and / or a decrease in one or more state-worsening habits.

[0007] The present disclosure is directed to a computer-implemented method for managing a user's glucose state, generating a plurality of optimization profiles for reaching an ideal state from a non-ideal state, wherein the ideal state corresponds to a good time-in-range (TIR) state and a good glucose variability (GV) state, the non-ideal state includes at least one of a poor TIR state or a poor GV state, generating; determining a current TIR state based on a TIR value of the user's blood glucose level, wherein the TIR value is based on the amount of time the user's blood glucose level is within a threshold band over a reference period, and the current TIR state is one of a good TIR state or a poor TIR state, determining; determining a current GV state based on a GV value associated with the user's blood glucose level, wherein the GV value indicates a standard deviation (SD) or coefficient of variation (CV) of the blood glucose level, and the CV indicates the variability of the user's blood glucose level considering the standard deviation of the blood glucose level over a reference period, determining; receiving one or more account vectors of the user; identifying one of the optimization profiles based on the one or more account vectors, the TIR state, and the CV state; identifying an optimization path based on the identified optimization profile, wherein the optimization path includes one or more adjustments of the one or more account vectors, identifying; and providing the optimization path to the user.

[0008] The plurality of optimization profiles may be generated by a machine learning model configured to receive, as input, an account vector and output one or more adjustments to the received account vector. The plurality of optimization profiles may be further generated by associating one or more adjustments to the received account vector with one or more TIR states or GV states. Each of the plurality of optimization profiles may correspond to a potential TIR state, a potential GV state, and one or more potential account vectors. One or more user attributes may be received, and one of the optimization profiles may be further specified based on the one or more user attributes. The CV value may be determined by dividing the standard deviation of blood glucose values by the average value of blood glucose values over a reference period.

[0009] The present disclosure is also directed to a system for managing a user's blood glucose level, the system including a memory storing processor-readable instructions and a processor configured to access the memory and execute the processor-readable instructions. The processor-readable instructions, when executed by the processor, are configured to electronically receive the user's blood glucose level using a continuous glucose monitoring (CGM) device configured to obtain glucose values using a component that penetrates the user's skin, determine a time in range (TIR) value for the user's blood glucose level, where the TIR value is based on the amount of time the user's blood glucose level is within a threshold band over a reference period, the threshold band being between approximately 70 mg / dL and 180 mg / dL, and the reference period being 24 hours, determine a TIR state based on the TIR value, where the TIR state is selected from a good TIR state or a bad TIR state, receive a glucose variability (GV) value based at least on the user's blood glucose level, where the GV value is one of a standard deviation or a coefficient of variation (CV), and the CV indicates the variability of the user's blood glucose level considering the standard deviation of the blood glucose levels over the reference period, determine a GV state based on the GV value, where the GV state is one of a good GV state or a bad GV state, determine a start state based on the TIR state and the GV state, determine that the start state corresponds to a non-ideal state, detect a CGM event based on the user's blood glucose level, characterize the CGM event based on one or more of a multi-parameter CGM classification or severity and a characterization of the CGM event trace shape, where the multi-parameter CGM classification includes the blood glucose level at the start of the CGM event, the severity, and the blood glucose level at the end of the CGM event, generate an optimization path to reach an ideal state based on one or more account vectors and characterizing the CGM event, where the optimization path includes one or more adjustments to one or more of the account vectors, and provide the optimization path to the user.Providing an optimized route to a user may configure a processor to execute a method that includes providing context-based instructions to the user based on the optimized route.

Brief Description of the Drawings

[0010] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate embodiments of the present disclosure and, together with the detailed description, are used to explain the principles of the present disclosure.

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4A

Figure 4B

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Figure 6C

Figure 6D

Figure 6E

Figure 6F

Figure 6G

Figure 7A

Figure 7B

Figure 8A

Figure 8B

Figure 8C

Figure 8D

Figure 9

Figure 10A

Figure 10B

Figure 11

Figure 12

Figure 13A

Figure 13B

Figure 13C

Figure 13D

Figure 14

[0011] The appendix is provided with this specification and includes descriptions using examples of the present disclosure including experimental results.

DETAILED DESCRIPTION OF THE INVENTION

[0012] Next, reference is made in detail to embodiments of the present disclosure shown in the accompanying drawings. As far as possible, the same reference numbers are used throughout the drawings to refer to the same or similar parts.

[0013] In the following discussion, relative terms such as "about," "substantially," "approximately," etc. are used to indicate a possible variation of ±10% in the recited numerical values. It should be noted that the descriptions provided herein are essentially merely examples and are not intended to limit the embodiments of the subject matter or the application and use of such embodiments. No implementation form described herein as exemplary should be construed as more preferred or advantageous than other implementation forms. Rather, as mentioned above, the term "exemplary" is used in the sense of "an example" rather than "ideal." The terms "comprise," "include," "have," "together with," and any variations thereof are used synonymously to indicate non-exclusive inclusion or to describe. Therefore, a process, method, article, or apparatus using such terms does not include only those steps, structures, or elements, but may include other steps, structures, or elements not explicitly described or inherent to such a process, method, article, or apparatus. Further, the terms "first," "second," etc. in this specification are not used to indicate any order, quantity, or importance, but are used to distinguish one element from another. Further, the singular notations such as the terms "a" and "an" in this specification do not indicate a limitation in quantity, but indicate the existence of at least one of the items referred to.

[0014] (Healthcare and Computing Environment) FIG. 1 is a block diagram of a health management system 100 according to an embodiment of the present disclosure. A user 8 (e.g., a patient, a consumer, etc.) having an electronic device 19, such as a mobile device, a computer, a medical device, or any other electronic device configured to access an electronic network 32 such as the Internet, can communicate with a mobile health (mHealth) application 1 or access it in other ways. In some embodiments, the network 32 may include wireless or wired links such as a cellular phone network, Wi-Fi, LAN, WAN, Bluetooth®, near field communication (NFC), or any other suitable form of network communication. A plurality of electronic devices 19 may be configured to access the electronic network 32. The user 8 may access the mHealth application 1 with a single account linked to the plurality of electronic devices 19 (e.g., via one or more of a cellular phone, a tablet, and a laptop computer). The electronic device 19 may also be a mobile health device, a desktop computer or workstation, a laptop computer, a mobile handset, a personal digital assistant (PDA), a cellular phone, a network device, a camera, a smartphone, a smartwatch, a cellular phone with enhanced general packet radio service (EGPRS), a media player, a navigation device, a game console, a set-top box, a biosensing device with communication capabilities, a smart TV, or any combination thereof, or any other type of computing device having at least one processor, local memory, a display (e.g., a monitor or a touch screen display), one or more user input devices, and a network communication interface, but is not limited thereto.The electronic device 19 may include any type or combination of input / output devices such as a display monitor, keyboard, touchpad, accelerometer, gyroscope, mouse, touch screen, camera, projector, touch panel, pointing device, scrolling device, button, switch, motion sensor, audio sensor, pressure sensor, thermal sensor, and / or microphone. The electronic devices 19 may also communicate with each other by 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 transmit and receive information.

[0015] The mHealth application 1 can communicate with other entities or networks to send and receive information. In some embodiments, the mHealth application 1 may communicate with one or more applications associated with the user 8, such as, for example, a motion tracking (e.g., step counting) application and / or other health-related applications. The mHealth application 1 can import data from other applications, analyze it, and use it when creating a treatment plan for the user 8. For example, the mHealth application 1 may import activity tracking data from another application, use that data, and identify patterns between the user 8's exercise and glucose values collected prior to the use of the mHealth application 1. The mHealth application 1 may also import any other appropriate data from other mobile health applications, such as, for example, blood pressure, BMI, A1C, type of exercise, exercise time, exercise distance, calories burned, total steps, exercise days, exercise start and end times, and sleep. The mHealth application 1 may also export data to other mobile applications, including, for example, other mobile health applications having social or interactive features. A healthcare provider 7, such as a physician, may prescribe this application. However, the mHealth application 1 may not require a prescription and may be, for example, a commercially available consumer application that is accessible without a prescription from a digital distribution platform for computer software. The mHealth application 1 may be customized for a particular user 8 and may be activated directly by the user 8 by visiting a pharmacy 9 or other approved entity. For example, the user 8 may receive an access code from the pharmacy to approve access to the mHealth application 1. The user 8 may receive training on using the mHealth application 1 by 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. The user's treatment plan may include a prescription (for example, for drugs, devices, and / or treatments) that can be dispensed by a pharmacy 9. After receiving approval based on compliance with the user 8's healthcare treatment plan, the pharmacy 9 may enable the re-prescription of the prescribed product / treatment. The approval may be received by the pharmacy 9 through communication from the application 1 via, for example, a network 32 and various servers 29. The use of drugs or other medical products / treatments may also be transmitted to the manufacturer 37 via the network 32, and the manufacturer 37 may be notified of the amount of medical products or treatments being used by the user 8. This information can help the manufacturer 37 evaluate the demand for medical products or treatments and plan the supply. The healthcare provider 7 may also receive a report based on the user information received by the application 1 and may update the user's treatment plan based on this information. The user's electronic medical record (EMR) 14 may also be automatically updated via the network 32 based on user information that may include electronically transmitted feedback of the user 8 received by the mHealth application 1. The healthcare provider 7 may be any suitable healthcare provider, including, for example, physicians, specialists, nurses, educators, social workers, MAs, PAs, etc.

[0016] Figure 2 is a schematic diagram of additional aspects of the system 100. For example, the system 100 may access a decision-making model stored in a decision-making model database 270 via a network 32. The retrieved decision-making model may be used for display and / or processing by one or more electronic devices 19, such as a mobile device 215, a tablet device 220, a computer 225 (e.g., a laptop or desktop), a kiosk 230 (e.g., in a healthcare and / or prescription information kiosk, pharmacy, clinic, or hospital), and / or any device connected to the network 32.

[0017] In the embodiment shown in FIG. 2, the mobile device 215, the tablet 220, and the computer 225 may each be provided with, or include, for example, a GPS receiver for obtaining and reporting position information, such as GPS data, via the network 32 between each of them and any server 29 and / or one or more GPS satellites 255.

[0018] Each of the electronic devices 19, including the mobile device 215, the tablet device 220, the computer 225, and / or the kiosk 230, may be configured to transmit and receive data (e.g., clinical information) to and from the system of the server 29 via the network 32. Each of the devices 19 may receive information such as clinical data from the server 29 via the network 32. The server 29 may include a clinical data server 240, an algorithm server 245, a user interface (UI) server 250, and / or any other suitable server. The electronic device 19 may include a user interface that is in data communication with the UI server 250 via the network 32. Each server may access the decision-making model database 270 and search for a decision-making model. Each server may include a memory, a processor, and / or a database. For example, the clinical data server 240 may have a processor configured to search for clinical data from a provider's database and / or a patient's electronic medical record. The algorithm server 245 may have a database containing various algorithms and a processor configured to process clinical data. The UI server 250 may be configured to receive and process inputs from the user 8, such as preferences for clinical decision-making. The satellite 255 may be configured to transmit and receive information between the server 29 and the device 19.

[0019] The clinical data server 240 may receive clinical data, such as data related to the user, from the electronic device 19 via the network 32 or indirectly via the UI server 250. The clinical data server 240 may store the information in a memory, such as a computer-readable memory.

[0020] The clinical data server 240 may also communicate with one or more other servers, such as the algorithm server 245 and / or an external server. The server 29 may include data about the provider's preferences and / or the health history of the user 8. Further, the clinical data server 240 may include data from other users. The algorithm server 245 may include machine learning and / or other suitable algorithms. The algorithm server 245 may also communicate with other external servers and may be updated as desired. For example, the algorithm server 245 may be updated with new algorithms, more powerful programming, and / or more data. The clinical data server 240 and / or the algorithm server 245 may process information and send data to the model database 270 for processing. In one embodiment, the (one or more) algorithm servers 245 obtain pattern definitions in a simple format and use classification models, such as Markov models, Gaussian, Bayesian, PCA (Principal Component Analysis), multivariable linear or non-linear regression, and / or linear discriminant functions, non-linear discriminant functions, synthetic discriminant functions, random forest algorithms, etc., to predict some future time steps, optimize results based on the predictions, detect transitions between patterns, obtain abstract data, extract information, infer higher-level knowledge, combine high-level and low-level information, understand the user 8 and clinical behavior, infer from multi-time (e.g., different time scales) data and related information, use variable-degree Markov models, and / or use clustering algorithms such as gradient-based and curve smoothing algorithms, k-means clustering, etc., to reduce noise over time.

[0021] Each server in the system of server 29, including clinical data server 240, algorithm server 245, and UI server 250, may represent any of a variety of types of servers, including but not limited to a web server, application server, proxy server, network server, or server farm. Each server in the system of server 29 may be implemented using 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 may include, but is not limited to, a server device having a processor and memory for executing and storing instructions. The memory may include any type of random access memory (RAM) or read-only memory (ROM) embodied in a physical storage medium, such as magnetic storage including a floppy disk, hard disk, or magnetic tape, semiconductor storage such as a solid state disk (SSD) or flash memory, optical disk storage, or magneto-optical disk storage. The software may include one or more applications and an operating system. The hardware may include, but is not limited to, a processor, memory, and graphical UI display. Each server may also have a plurality of processors and a plurality of shared or individual memory components configured to function together, for example, within a clustered computing environment or server farm.

[0022] Figure 3A is another representation of a portion of system 100 showing additional 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, an application-specific 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, that store one or more software modules. Memories 301-2 and 304-2 may be implemented using any computer-readable storage medium, such as a hard drive, a CD, a DVD, flash memory, RAM, ROM, etc. Memory 301-2 may store module 301-3, which may be executed by processor 301-1. Similarly, memory 304-2 may store module 304-3, which may be executed by processor 304-1.

[0023] The electronic device 19 may further include one or more UIs. The UI may enable one or more interfaces for presenting information such as plans or interventions to the user 8. The UI may be web-based, such as a web page, or may be a stand-alone application. The UI may also be configured to receive information about the user 8, such as data input and user feedback. The user 8 may manually input the information, or the information may be automatically input. In one embodiment, the user 8 (or the user's caregiver) may input information such as when the medicine was taken, or what food and drink the user 8 consumed. The electronic device 19 may also include an inspection device (not shown) or an interface for receiving information from an inspection device. The inspection device may include, for example, a blood glucose meter, a heart rate monitor, a weighing scale, a blood pressure cuff, etc. The electronic device 19 may also include one or more sensors (not shown), such as a camera, a microphone, or an accelerometer, for collecting feedback from the user 8. In one embodiment, the device may include a blood glucose meter for reading the user's blood glucose level and automatically reporting it.

[0024] The electronic device 19 may also include a presentation layer. The presentation layer may be a web browser, an application, a messaging interface (e.g., email, instant message, SMS, etc.). The electronic device 19 may present notifications, warnings, readings, references, guides, reminders, or suggestions to the user 8 via the presentation layer. For example, the presentation layer may present articles determined to be relevant to the user 8, reminders to purchase medicine, tutorials on a topic (e.g., a tutorial on carbohydrates), testimonials of others with similar symptoms, and / or one or more goals (e.g., a carb count goal). The presentation layer may also present information such as tutorials (e.g., user guides or explanatory videos), and / or may enable communication between a healthcare provider and the user 8, e.g., a patient. The communication between the healthcare provider and the user 8, e.g., a patient, may be via an electronic message (e.g., email or SMS), voice, or real-time video. One or more of these items may be presented based on a treatment plan or an updated treatment plan, as described below. The presentation layer may also be used to receive feedback from the user.

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

[0026] System 100 can be used for a wide range of applications, including, for example, addressing a user's healthcare, maintaining the user's finances, and monitoring and tracking the user's nutrition and / or sleep. In some implementations of System 100, any received data may be stored in a database in encrypted form to enhance the security of the data against unauthorized access and to comply with HIPAA privacy and / or other legal, healthcare, financial, or other regulations.

[0027] With respect to any server or server system 29 depicted in System 100, the server or server system may include one or more databases. In one embodiment, the database may be any type of data store or recording medium that can be used to store any type of data. For example, database 302 may store data received by or processed by server 29 that includes information related to the user's treatment plan, including the timing and dosage associated with each prescription drug of the treatment plan. Database 302 may also store information related to user 8, including the literacy level of user 8 associated with each of the plurality of prescription drugs.

[0028] As further disclosed herein, one or more components of the disclosed subject matter may be implemented using machine learning models. FIG. 3B shows an exemplary training module 310 for training one or more machine learning models disclosed herein. It will be understood that the training module may be used to train each of the machine learning models disclosed herein and / or a single training module 310 may be used to train more than two machine learning models.

[0029] As shown in FIG. 3B, the training data 312 may include one or more of stage inputs 314 and known results 318 related to the machine learning model to be trained. The stage inputs 314 may be from any applicable source including healthcare providers 7, one or more servers 29, electronic devices 19, EMRs 14, outputs from steps (e.g., one or more outputs from steps from the flowchart 500 of FIG. 5A or the flowchart 900 of FIG. 9, time in range (TIR) values, time above range (TAR) values, time below range (TBR) values, severity scores, continuous glucose monitoring (CGM) classifications, etc.). The known results 318 may be included for a machine learning model generated based on supervised or semi-supervised training. An unsupervised machine learning model may not be trained using the known results 318. The known outputs 318 may include known or desired outputs for future inputs that are in the same or a similar category as the stage inputs 314 that do not have corresponding known outputs.

[0030] The training data 312 and the training algorithm 320 may be provided to a training component 330 that can apply the training data 312 to the training algorithm 320 to generate a machine learning model. According to one implementation, the training component 330 may be provided with a comparison result 316 that compares previous outputs of the corresponding machine learning model, apply the previous results, and retrain the machine learning model. The comparison result 316 may be used by the training component 330 to update the corresponding machine learning model. The training algorithm 320 may utilize machine learning networks and / or models including, but not limited to, deep learning networks such as deep neural networks (DNNs), convolutional neural networks (CNNs), fully convolutional networks (FCNs), and recurrent neural networks (RCNs), probabilistic models such as Bayesian networks and graphical models, and / or discriminative models such as decision trees and maximum margin methods.

[0031] (Health status) Diabetes mellitus, commonly referred to as diabetes, is a chronic, persistent metabolic disorder (or condition) in which the patient's body cannot produce insulin at all or sufficiently, or cannot use the produced insulin (insulin resistance), causing elevated levels of glucose in the patient's blood. The three identifiable types of diabetes include prediabetes, type 1 diabetes, and type 2 diabetes. Prediabetes is a state in which blood sugar is high but not high enough to be type 2 diabetes. Type 2 diabetes is a chronic condition that affects the way the body processes blood sugar. Finally, type 1 diabetes is a chronic condition in which the pancreas produces little or no insulin.

[0032] Generally, diabetes is diagnosed in several ways. Diagnosing diabetes may require repeating tests on multiple days to confirm a positive diagnosis of the type of diabetes. Some of the health parameters used by a physician or other appropriate healthcare provider when confirming a diabetes diagnosis include the glycated hemoglobin (A1C) value in the blood, the fasting plasma glucose (FPG) value, the oral glucose tolerance test, and / or the random blood glucose test. Generally, healthcare providers are interested in the patient's A1C value to assist in the diagnosis of diabetes. Glycated hemoglobin is a form of hemoglobin that is mainly measured to identify the average plasma glucose concentration over a three-month period and can be used by physicians and / or other appropriate healthcare providers. Health parameters include weight, age, nutritional intake, physical activity, cholesterol levels, triglyceride levels, obesity, tobacco use, and family history.

[0033] Once the diagnosis of the type of diabetes is confirmed by a physician or other appropriate healthcare provider, the patient may receive treatment to manage the diabetes. Patients who are being followed or monitored for diabetes by a physician or other healthcare provider may be treated by combining controlling blood sugar through diet, exercise, oral medications, and / or insulin therapy. Regular testing for complications may also be required, depending on the patient. Depending on the period since the patient was diagnosed with diabetes, the mHealth application 1 may propose a specific treatment plan to manage the patient's condition. Oral medications typically include tablets that are taken orally to reduce the production of glucose by the liver and make the muscles more sensitive to insulin. In other instances, when the diabetes is more severe, additional medications, including injections, may be required to treat the patient's diabetes. Injections of basal insulin, also known as background insulin, may be used by healthcare providers to keep fasting blood glucose levels at a constant value. When fasting, the patient's body steadily releases glucose into the bloodstream to supply energy to the cells. Therefore, injections of basal insulin are required to control blood sugar levels and enable the cells to take in glucose as energy. Basal insulin is typically administered once or twice a day, depending on the type of insulin. Since basal insulin acts for a relatively long period, it is considered to be long-acting insulin or intermediate-acting insulin. In contrast, bolus (additional) insulin may be used to act quickly. For example, bolus insulin may be administered specifically at mealtime to control blood sugar levels after a meal. In some instances, when creating a treatment plan for a patient to manage their diabetes, a physician may create a basal-bolus dosing regimen that includes, for example, making several injections throughout the day. The basal-bolus regimen may include injections with each meal and attempts to approximate how the bodies of non-diabetic patients release insulin. The basal-bolus regimen may be applicable to people with type 1 and type 2 diabetes.In addition to a basal bolus regimen that requires insulin injections, the treatment plan can be augmented with the use of prescribed oral medications. Patient compliance with the treatment plan can be important in managing the patient's disease state. For example, if a patient has been diagnosed with diabetes for over six months, a very specific treatment regimen should be adhered to by the patient in order to obtain, for example, healthy or favorable blood glucose levels. Ultimately, the weekly pattern of treatment with those types of medications can be important in managing diabetes. The mHealth application 1 can recommend a treatment plan to assist the patient in managing diabetes.

[0034] (Exemplary method) Diabetes is a chronic disease in which a patient is unable to keep glucose within a normal or recommended target range. Such fluctuating blood glucose levels (i.e., outside of the normal or recommended target range) can lead to serious health complications. With sporadic blood glucose monitoring (BGM), it is difficult to gain meaningful insights, and the few intermittent measurements taken a few times a week may not provide a basis for understanding patterns and any underlying causes of these patterns (e.g., determining an increase in BGM based on meal type).

[0035] Continuous glucose monitoring (CGM) offers the possibility of high-density data (e.g., data based on a collection frequency of less than 5 minutes) being automatically collected through a wearable sensor (e.g., a subcutaneous sensor) that provides regular glucose values (e.g., the blood glucose value of user 8). CGM can improve diabetes care by providing the user 8 or another entity (e.g., healthcare provider 7) with continuous (e.g., every 5 minutes or less) or semi - continuous (e.g., longer than every 5 minutes) readings of glucose data so that the user 8's blood glucose values can be more readily recognized at all times of the day. Such data can enable the healthcare provider 7 to more optimally adjust the treatment plan for the user 8.

[0036] A CGM monitor can be a continuous analyte sensor system that includes any sensor configuration that provides an output signal indicative of the concentration of an analyte. The CGM monitor may sense the concentration of the analyte, for example, to determine a glucose value, based on a body fluid (e.g., interstitial fluid). The body fluid may be accessed through the user's skin. The output signal, which can be in the form of sensor data such as a raw data stream, filtered data, smoothed data, and / or sensor data converted in other ways, may be connected to the CGM monitor via a wired or wireless connection and transmitted to a receiver that can be local or remote from the sensor. According to an implementation, the CGM monitor may include a transcutaneous glucose sensor, a subcutaneous glucose sensor, a continuously refillable subcutaneous glucose sensor, a continuous intravascular glucose sensor, etc. The CGM monitor may be a compact medical system having one or more sensors inserted on the abdomen of user 8 and including a small cannula that penetrates the skin of user 8. An adhesive patch may hold the monitor in place. The sensor may sense glucose measurements in the interstitial fluid continuously or semi - continuously.

[0037] The transmitter may be connected to the sensor to enable the CGM monitor to wirelessly transmit glucose measurement values to the monitoring device. The monitoring device may be a monitoring device dedicated to the CGM monitor, a third-party device, the electronic device 19, or any other applicable device. The monitoring device may be a dedicated monitoring device or the 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 glucose measurement values and related data via the monitoring device. The monitoring device may be used to analyze and / or view data associated with the glucose measurement values. Alternatively or additionally, the CGM monitor may include a display for viewing the glucose measurement values and / or related data. The CGM monitor and / or an external device may be configured to generate and / or provide warnings based on the glucose data (e.g., when the blood glucose level is too high or too low, or shows an unfavorable trend).

[0038] By using the CGM data, the time in range (TIR) value may be determined such that the TIR value is based on the amount of time that the blood glucose level of user 8 is within the threshold band over a reference period. The threshold band may be pre-determined, user-specific, or dynamically determined.

[0039] The threshold band may be a value determined in advance, for example, based on a patient cohort. The lifestyle, habits, and medical test results of each patient within the cohort may be used to determine the pre-determined value. For example, one or more patient cohorts may be determined based on the patient's lifestyle, habits, demographics, etc., and the threshold band may be generated for each of the one or more cohorts. The threshold band may be determined based on optimal results (e.g., a preferred A1C value) based on the analysis of blood glucose levels over a certain period. For example, a machine learning model may be generated using the training module 310. The machine learning model may be trained using the blood glucose levels of a patient cohort as the stage input 314 and may receive the corresponding A1C value as the known result 318. The machine learning model for training may receive, as input, data (e.g., A1C value) of a patient cohort and may output the threshold band of the blood glucose levels of that patient cohort (i.e., having a glucose upper limit value and a glucose lower limit value). Alternatively, the threshold band may be a pre-determined value of the general population so as not to be cohort-specific. According to an implementation form, the TIR threshold band is between approximately 70 mg / dL and approximately 180 mg / dL. The TIR value may be the amount of time during which the blood glucose level of user 8 is within the TIR threshold band for the reference period. According to an implementation form of the disclosed subject matter, the reference period may be 24 hours, but it will be understood that finer-grained changes in the TIR value may be determined based on reducing the reference period that is less than 24 hours, and broader changes may be determined based on increasing the reference period that is longer than 24 hours.

[0040] The user-specific threshold band can be determined based on the attributes of user 8. The attributes may be medical history, physical history, demographics, etc. According to one implementation form, the user-specific threshold may be generated using a machine learning model trained using training module 310. The machine learning model may receive updated attributes based on user 8 and may retrain itself by using the updated attributes through the comparison result 316 component. As an example, the change in the weight of user 8 may be a change in the attributes provided to the comparison result 316 component such that the machine learning model updates the previously provided threshold band based on the updated weight. Therefore, the user-specific threshold band may be changed from time to time based on one or more attributes of user 8. Similarly, the dynamically determined threshold band may be determined based on changes in one or more attributes related to user 8, the user's cohort, external conditions, environmental conditions, updated recommendations, etc.

[0041] As applied herein, a user vector (e.g., patient vector) may be any action, activity, article (e.g., consumable), service, parameter, or value that is associated with or may be associated with and changed for a given patient. The patient vector may be changed to improve the TIR state or GV state of user 8 as further disclosed herein. As an example, the patient vector may include one or more of medications, food intake characteristics, exercise values, psychosocial parameters, social determinant parameters, etc.

[0042] As applied herein, a user attribute (e.g., patient attribute) may be an attribute or characteristic associated with a patient. As compared with the patient vector, the patient attribute may be easily modified or may not be changeable. As an example, the patient attribute may include social attributes, medical history or status, patient preferences, metabolic attributes, patient demographics, etc.

[0043] Figure 4A shows an exemplary CGM-based blood glucose trace 402 of user 8. The period shown via Figure 4A can be one full day (i.e., 24 hours). As shown, the blood glucose level of user 8 can have TIR by being within the threshold range represented by upper threshold 404A and lower threshold 404B for a portion of the day excluding during the TAR period 402A and the TBR period 402B. User 8 may be provided with such a graph display during the day or after the end of the day. Thus, CGM data may be provided to user 8, and user 8 may be notified of user 8's current blood glucose level and / or trends associated with user 8's current blood glucose level.

[0044] Figure 4B shows an exemplary CGM-based report 406 that may be provided to user 8 or healthcare provider 7. The report may be in Ambulatory Glucose Profile (AGP) format and may include not only graph data but also a number of metrics (e.g., 10 metrics). The report may include glucose statistics and goals 408, AGP profile 410, daily glucose profile 412, time range 414, etc. However, most diabetic patients may not be able to interpret such CGM data and / or AGP information that affects changes in blood glucose levels. Similarly, healthcare provider 7 may need to communicate with multiple patients, interpret the data provided via CGM monitoring and / or AGP information, and optimize the blood glucose level even temporarily. The techniques disclosed herein provide tracking of essential parameters and manage the health of user 8.

[0045] According to the implementations disclosed herein, CGM data may be used to recommend changes based on one or more patient vectors, as further disclosed herein. A CGM event (e.g., a change in CGM status, a portion of a CGM trace, etc.) may be defined as a distinguishable region of a CGM trace that correlates with diabetes self-management activities (DSMA). As further applied herein, the CGM trace may be used to identify a CGM trend or may be a CGM trend. The DSMA may be a change or addition of medication, a change or addition of food, a change or addition of exercise, etc. The CGM may drive automatic coaching for user 8. Similarly, CGM-based results (e.g., results of glucose characteristics based on automatic coaching and / or DSMA) may drive coaching for future DSMA and / or provide specific decision support adjusted to medical provider 7.

[0046] According to an implementation form, a Detect, Inform, Classify, and Engage (DICE) framework can detect various diabetes-related events from CGM traces, inform healthcare providers 7 and / or users 8 about progress along an optimization path via one or more visualizations, classify the detected events into one or more classifications and / or two-dimensional CGM quadrant starting states for additional intervention, and / or engage with and guide patients towards improved outcomes. The technology associated with the DICE framework integrates data from multiple fields such as metabolic data, lifestyle data, socioeconomic data, clinical data, etc., to enhance patient care. The technology for automatic CGM event detection and classification disclosed herein makes it possible to improve the quality of care by increasing accuracy and reducing errors. Automatic coaching based on various quantitative methodologies enables scalability and reach improvement for any patient in need of care and / or support. The visualizations provided herein reduce the data burden on users 8 and / or healthcare providers 7 by narrowing down high-density CGM data and other applicable data into user-friendly charts, graphs, and / or other visualizations. FIG. 5A shows a method 500 for providing an optimization path to improve the glucose state of user 8. At 502, the blood glucose value of user 8 may be received. As disclosed herein, the blood glucose value may be provided continuously or semi-continuously by a CGM monitor. The blood glucose value may be received by a component of the CGM monitor itself, or by local or remote components such as electronic device 19, mHealth application 1, one or more servers 29, etc. The blood glucose value may be automatically provided from the CGM monitor to one or more components, pushed at the time of blood glucose value collection, or the CGM monitor may be pinged to transmit one or more collected blood glucose values.

[0047] As an example, user 8 may attach a CGM monitor to the body, and the CGM monitor may collect measured blood glucose values every 5 minutes. The CGM monitor may be connected to the mobile device of user 8 (e.g., via a network connection, a local area network connection, a wide area network connection, a WiFi connection, a Bluetooth connection, etc.). According to a first exemplary implementation, the CGM monitor may automatically transmit the measured blood glucose values to the mobile device of user 8 every time a measurement value is collected (e.g., every 5 minutes). Alternatively or additionally, one or more measured blood glucose values may be transmitted to the mobile device of user 8 as a group of multiple measurement values, and / or the CGM monitor may store one or more measured blood glucose values when the mobile device of user 8 or another component requests that one or more measured blood glucose values be transmitted.

[0048] In 504 of FIG. 5A, a time-in-range (TIR) value associated with the measured blood glucose value is determined. The in-range glucose value may correspond to, for example, the amount of time the measured blood glucose value is within a predetermined range, the ratio of the in-range measured blood glucose value to the out-of-range value, the count of the in-range and out-of-range measured blood glucose values, etc. The TIR value can distinguish when the blood glucose value of user 8 is in range and when the blood glucose value of user 8 is out of range. As shown in FIG. 4A, the blood glucose value may be considered in range when it is within the range of the upper threshold 404A and the lower threshold 404B. The upper threshold 404A may be 180 mg / dL and the lower threshold 404B may be 70 mg / dL so that the TIR value of a given patient may correspond to the amount of time the patient's blood glucose value is between 70 mg / dL and 180 mg / dL.

[0049] The TIR value determined at 504 in FIG. 5A may be based on the amount of time that the blood glucose level of user 8 is within the threshold band over a reference period. The reference period may be a single 24-hour day, or may be different reference periods. The reference period may be determined in advance (e.g., by user 8, by healthcare provider 7, pre-programmed, etc.), or may be determined dynamically based on one or more factors. The one or more factors may be a patient vector, patient attributes, current or previous TIR status, etc.

[0050] According to one implementation, the TIR value may be that of the reference period, or may be the TIR value associated with the patient over a number of reference periods. For example, the TIR value of user 8 may be determined for each day of a total of 10 days. The TIR values from each of the 10 days may be combined using any applicable technique (e.g., average value) such that the TIR associated with user 8 over the 10 days is the combined TIR value.

[0051] According to one implementation form, the TIR value may be filtered such that the abnormal value of the blood glucose level is excluded, or is weighted lower than the measured value of the blood glucose level that cannot be flagged as an abnormal value. As an example, during the first measurement, the measured value of the blood glucose level of 65 mg / dL may increase to 200 mg / dL in the next second measurement 5 minutes after the first measurement. The third measurement 5 minutes after the second measurement may indicate a blood glucose level of 68 mg / dL. Filters using density-based techniques (e.g., k-nearest neighbor method, local outlier factor method, isolation forest, etc.), filters using outlier detection of high-dimensional data based on subspace, correlation, and / or tensor, filters using one-class support vector machines, filters using replicator neural networks, autoencoders, variational autoencoders, long short-term memory neural networks, filters using Bayesian networks, filters using hidden Markov models (HMMs), filters using outlier detection based on cluster analysis, filters using deviations from association rules and frequent item sets, filters using outlier detection based on fuzzy logic, filters using ensemble techniques, filters using feature bagging, score normalization, and diverse sources, filters using convolutional LSTM using a mixture of probabilistic principal component analyzers, etc. may be used to identify outliers and / or measured values of blood glucose levels that may be misread and unimportant outliers. One or more of such filtering techniques may also be used in conjunction with the machine learning models disclosed herein. According to this implementation form, the TIR value associated with user 8 may consider the measured values of blood glucose levels filtered through one or more such filters. As further disclosed, such filtering may prevent providing an optimized path that is impaired due to outliers, outlier data, and / or irregular measurements.

[0052] In 506 of FIG. 5A, the TIR state of user 8 can be determined based on one or more TIR values associated with user 8. The TIR state may be a state associated only with the TIR value, or may be based on one or more other factors (e.g., frequency of glucose measurements, quality of glucose measurements, other sensed measurements, patient-based factors, etc.). For simplicity, in this disclosure, a binary state of TIR based only on the TIR value (i.e., a good TIR state and a bad TIR state) will be discussed. However, it will be understood that the TIR state may be a multi-dimensional state based on the TIR value and one or more other factors. As applied herein, a good TIR state (e.g., a first TIR state) corresponds to a TIR ratio greater than the TIR cutoff, and a bad TIR state (e.g., a second TIR state) corresponds to a TIR ratio less than the TIR cutoff.

[0053] FIG. 6A shows a chart 600 of the TIR states of a plurality of different patients. As further disclosed herein, the chart includes four quadrants based on the TIR ratio and the GV ratio. The TIR state is based on a TIR axis corresponding to the Y-axis in chart 600. The TIR ratio is the percentage of time over a reference period during which a patient's blood glucose value is within a threshold band. Alternatively, the TIR ratio may be the percentage of time over a reference period during which a patient's blood glucose value is within the threshold band of a plurality of reference periods, such that the TIR ratio is a value calculated (e.g., averaged) over the plurality of reference periods.

[0054] The value of the TIR ratio may be specified as a cut-off for a good TIR state versus a bad TIR state. Chart 600 of FIG. 6A includes a cut-off value of 0.5 such that a TIR ratio above 0.5 is considered a good TIR state (e.g., where the blood glucose value of user 8 is above 50% of the time or within a threshold band for a calculated measurement value), and a TIR ratio below 0.5 is considered a bad TIR state (e.g., where the blood glucose value of user 8 is outside the threshold band for more than 50% of the time or for a calculated measurement value). The cut-off may be pre-determined or may be determined dynamically. A pre-determined cut-off may be based on medical criteria or may be specified by a healthcare provider 7 for a cohort or user 8. A dynamically determined cut-off may be based on a cohort or a given user 8 or may be determined by a machine learning model. The machine learning model may receive as input a patient vector, patient attributes, past patient TIR values or GV values or changes, etc., and may output a cut-off specifically for the user 8 or cohort to which the input is associated. Thus, the cut-off may be adjusted to a value considered optimal for the corresponding user 8 or cohort based on which the input data was based.

[0055] As shown in chart 600, patients having a TIR value above the cut-off of 0.5 are considered to have a good TIR state, and patients having a TIR value below the cut-off of 0.5 are considered to be in a bad TIR state. It will be appreciated that if the cut-off is shifted, the number of patients having a good or bad TIR state will change accordingly. For example, if the TIR ratio is adjusted to 0.9 instead of 0.5, most patients will be in a bad TIR state.

[0056] In 508 of FIG. 5A, a glucose variability (GV) value associated with a measured value of the blood glucose level of a predetermined user 8 is determined. The glucose variability value can measure the amount of change in glucose over a certain period, utilize the variation in glucose levels, and can improve diabetes management. The GV value may be a standard deviation (SD) value, a coefficient of variation (CV), or any other applicable variation measurement value.

[0057] SD can be a measure of the amount of variation or dispersion of a set of glucose values (e.g., collected over 1 hour, 1 day, or any other applicable period). A low SD may indicate that the glucose values tend to be close to the average value of the set of glucose values. A high SD may indicate that the values are spread over a wider range. The SD of the glucose values can be the square root of the variance of the glucose values. The SD of the glucose values can be calculated as shown in Equation 1.

Equation

[0058] CV can be a standardized measure of the dispersion of a probability distribution or frequency distribution. The CV of a patient's blood glucose level can be calculated by determining the ratio of the standard deviation of the blood glucose levels to the average value of the blood glucose levels. The CV can indicate the degree of variation associated with the average value of the blood glucose levels over a certain period. The CV can be calculated as shown in Equation 2.

Equation

[0059] As described above, the GV value may be an SD value or a CV value. According to one implementation, the type of GV value (e.g., SD value, CV value, etc.) may be based on the user 8, or may be based on the current or past patient vector, patient attributes, or other information related to the user 8. According to another implementation, the type of GV value may be determined by a machine learning model configured to output the optimal type of GV value by the healthcare provider 7 or based on one or more inputs such as patient vector, patient attributes, past analysis, etc.

[0060] In 510 of FIG. 5A, the GV state of the user 8 can be determined based on one or more GV values associated with the user 8. The GV state may be a state associated only with the GV value, or may be based on one or more other factors (e.g., frequency of glucose measurements, quality of glucose measurements, other perceived measurements, patient-based factors, etc.). For simplicity, the present disclosure will discuss a binary state of GV based only on the GV value (i.e., a good GV state and a bad GV state). However, it will be understood that the GV state may be a multi-dimensional state based on the GV value and one or more other factors. As applied herein, a good GV state (e.g., the first GV state) corresponds to a GV value greater than the GV cut-off, and a bad GV state (e.g., the second GV state) corresponds to a GV value less than the GV cut-off.

[0061] FIG. 6A shows a chart 600 of the GV states of a plurality of different patients. As disclosed herein, the chart includes four quadrants based on the TIR ratio and the GV ratio. The GV state is based on the GV axis corresponding to the X-axis in the chart 600. The GV may be an SD or a CV associated with the blood glucose value of the patient over a certain period. Alternatively, the GV may be an SD or a CV associated with the blood glucose values of the patient over a plurality of periods such that the GV is a value calculated (e.g., averaged) over the plurality of periods.

[0062] The GV value may be specified as a cut-off between a good GV state and a bad GV state. Chart 600 in FIG. 6A includes a cut-off of 0.8 such that GV values above 0.8 are considered to be in a good GV state and GV values below 0.8 are considered to be in a bad GV state. The cut-off may be determined in advance or may be determined dynamically. A pre-determined cut-off may be based on medical criteria or may be specified by the healthcare provider 7 of the cohort or user 8. A dynamically determined cut-off may be based on the cohort or a given user 8 or may be determined by a machine learning model. The machine learning model may receive, as input, a patient vector, patient attributes, past patient TIR values or GV values or changes, etc., and may output a cut-off specifically for the user 8 or cohort to which the input is associated. Thus, the cut-off may be adjusted to a value that is considered optimal for the corresponding user 8 or cohort on which the input data was based.

[0063] As shown in chart 600, patients with GV values above the cut-off of 0.8 are considered to have a good GV state, and patients with GV values below the cut-off of 0.8 are considered to be in a bad GV state. It will be understood that if the cut-off is shifted, the number of patients with a good or bad GV state will change accordingly. For example, if the GV value is adjusted to 0.9 instead of 0.8, more patients will be in a bad GV state compared to when the cut-off was 0.8. According to one implementation, the optimal cut-off value for distinguishing between a good state and a bad state may be 0.7.

[0064] As shown in FIG. 6A, four quadrants are created based on the Y-axis (TIR ratio) and X-axis (GV value) divided based on the TIR cut-off value (i.e., 0.5 in the embodiment shown in FIG. 6A) and the GV cut-off value (i.e., 0.8 in the implementation example shown in FIG. 6A). Patients in the upper left quadrant 602 correspond to patients within a good TIR state (i.e., above the TIR cut-off value) and a poor GV state (i.e., lower than the cut-off GV). This state can be considered a good-bad (G-B) state where the first characterization (i.e., good) corresponds to the TIR state and the second characterization (i.e., bad) corresponds to the GV state. Patients in the lower left quadrant 604 correspond to patients within a poor TIR state (i.e., below the TIR cut-off) and a poor GV state (i.e., lower than the cut-off GV). This state can be considered a bad-bad (B-B) state. Patients in the lower right quadrant 606 correspond to patients within a poor TIR state (i.e., below the TIR cut-off) and a good GV state (i.e., higher than the cut-off GV). This state can be considered a bad-good (B-G) state. Patients in the lower left quadrant 604 correspond to patients within a poor TIR state (i.e., below the TIR cut-off) and a poor GV state (i.e., lower than the cut-off GV). This state can be considered a bad-bad (B-B) state. Patients in each of quadrants 602, 604, and 606 may be considered patients with a non-ideal state such that at least one of the TIR state or the GV state is in a non-optimal state (e.g., a "poor" state). Patients in the upper right quadrant 606 correspond to patients within a good TIR state (i.e., above the TIR cut-off) and a good GV state (i.e., higher than the cut-off GV). This state can be considered a good-good (G-G) state. Patients in quadrant 608 can be considered patients in an ideal state such that both the TIR state and the GV state are in an optimal state (e.g., a "good" state).

[0065] As shown at 512 in FIG. 5A, the starting state of a given patient can be based on the patient's TIR state and GV state. As shown in FIG. 6A, the starting state of user 8 can correspond to the quadrant in which the TIR state and GV state of user 8 are classified. For example, as shown in FIG. 6A, user 610 has a TIR ratio that does not meet the TIR cutoff and thus is in a poor TIR state, and has a GV that is higher than the GV cutoff and thus may be in a good GV state. Thus, as determined at 514 in FIG. 5A, in the embodiment shown in FIG. 6A, it may be the poor-good state of a non-ideal start, represented by the lower right quadrant 606. As further disclosed herein, the overall poor-good state of the non-ideal start of user 610 may be the state of user 610 at one point in time and may change over time.

[0066] As determined at 514 in FIG. 5A, a non-ideal starting state can indicate that the diabetes management of user 8 is not optimal. For example, a non-ideal starting state may indicate a low TIR and / or a non-optimal GV. Thus, a non-ideal starting state may require an adjustment to the diabetes management of the corresponding user 8 so that the state of user 8 can change from a non-ideal state to an ideal state.

[0067] According to one implementation, as described herein and as shown in FIG. 6A, the two-dimensional framework may be implemented in a production system via a novel data integration extract, transform, load (ETL) process. The process may extract CGM data obtained by a CGM monitor and analyzed by the CGM monitor, electronic device 19, and / or any other applicable component. The extracted data may be converted and / or written to a production database that includes one or more machine learning models and can determine a starting state (e.g., at 512 in FIG. 5A).

[0068] Thus, the macro view of the state-based data (e.g., the starting state) of user 8 can be represented by two orthogonal parameters, the TIR state and the GV state. As disclosed herein, the corresponding states (e.g., as shown in FIG. 6A) can be visualized to evaluate the overall glucose health state and reported to user 8, healthcare provider 7, etc. The state-based data may be used (e.g., via an optimization path as further disclosed herein) to provide overall glucose health recommendations.

[0069] In 516 of FIG. 5A, an optimization path can be generated to reach an ideal state. The optimization path may be one or more adjustments of one or more patient vectors and may be determined based on a non-ideal state (i.e., good-bad, bad-bad, or bad-good state), patient vectors, and / or patient attributes. The optimization path may be one or more adjustments of patient vectors including, but not limited to, medications, food intake characteristics, exercise values, psychosocial parameters, and / or social determinant parameters.

[0070] The adjustment of medications may be provided based on the user 8's current medications or may be provided based on new medications that the user 8 may be provided. The adjustment may be made by adjusting the dosage of the medication, adding or eliminating the medication, changing the time or frequency at which the medication is taken, changing the environment associated with the medication (e.g., the type of food taken with the medication), etc. For example, the dosage of a particular medication that the user 8 is currently taking may be adjusted to a higher dosage.

[0071] The adjustment of food intake characteristics may include changing, eliminating, adding, or otherwise modifying one or more foods, food groups, food types, food intake times, food pairings, food and drug pairings, etc. For example, based on patient attributes indicating that the patient's blood glucose level increases beyond a threshold band after consuming food, the patient may be provided with a warning to consume food during times when the current blood glucose level is low.

[0072] Adjustment of the exercise value may include changing, eliminating, adding, or otherwise modifying one or more exercises, exercise types, exercise durations, exercise times, etc. For example, if a patient exercises at the beginning of the day, the GV of a given patient may be more stable, and thus, the adjustment may be made to prioritize exercising in the morning.

[0073] Psychosocial parameters and / or social determinant parameters may also be adjusted or modified, and may include changing, eliminating, adding, or otherwise modifying meditation schedules or types, social activities, interactions, and / or the same durations or frequencies.

[0074] In 516, the optimization path may be generated using a machine learning model. As shown in FIG. 3B, the machine learning model may be trained. The machine learning model may receive, as input, one or more of a patient vector, a starting state (e.g., TIR state, GV state, good - bad state, bad - bad state, bad - good state, etc.), patient attributes, and CGM characteristics. The machine learning model may generate an output of the optimization path based on such input. As disclosed herein, the optimization path may be an adjustment of one or more patient vectors.

[0075] In 518 of FIG. 5A, the optimization path can be provided directly to the patient (e.g., via mHealth application 1, using electronic device 19, etc. to user 8), to healthcare provider 7, or to both. The optimization path may be an overview of changes to one or more patient vectors, may be an automatic adjustment of one or more patient vectors, or may be provided gradually based on one or more actions, timings, levels, values, etc. The optimization path provided gradually is provided based on the corresponding one or more patient vectors and may result in changes to one or more patient vectors. As an example, when the patient's blood glucose level is at the lower end of the threshold range and the change to the patient vector includes consuming food, a warning on the mobile device may be provided when the patient's CGM monitor records such a blood glucose level. The warning on the mobile device may provide an instruction to the user that the user should consume food within a predetermined period based on the warning.

[0076] The optimization path may also be provided periodically (e.g., daily, hourly, weekly, etc.) or based on a trigger, and the pre-determined time is based on the changes based on the optimization path. For example, an optimization path that modifies the patient's meal schedule may be provided using a warning during meal times. As another example, an optimization path that changes the patient's medication may be provided using a warning during dosing times.

[0077] The frequency, method, and / or manner of providing the optimized route may be based on the key operations or variables associated with the successful implementation of the optimized route. The habit index may be determined for a patient or cohort of patients having one or more similar attributes. The habit index may be a classification of a patient's behavior, a designation of a habit (e.g., frequent communication, infrequent communication, technical communication, telephone communication, human communication, graphic communication, time communication, etc.), a value or score, or any other applicable designation that provides an indication of the patient's behavior to appropriately adjust the optimized route.

[0078] The habit index may be determined based on habits or preferences, including frequency-based factors, time-cubed-based factors, context-cubed-based factors, etc. The habit index may be used to provide the optimized route to the patient such that the optimized route may be provided to the patient based on the habit index. As an example, the habit index may indicate that User 8 prefers minimal communication and any communication conducted via the mHealth application. Thus, the change in the patient vector via the optimized route may be provided to User 8 via the mHealth application once a day. Thus, the habit index may be used to provide the optimized route to the patient in an individual manner based on the individual behavior preferences of the patient.

[0079] FIG. 5B shows a flowchart 540 of an exemplary implementation based on CGM. Step 512 in FIG. 5B corresponds to step 512 in FIG. 5A and includes determining a starting state of a given patient based on the patient's TIR state and GV state as disclosed herein. At 520, a determination is made as to whether the starting state determined at 512 is an ideal state. If the starting state is an ideal state, at 522, the CGM monitor may continue to perform CGM. If the starting state is not an ideal state (i.e., a non-ideal state such as a good-bad, bad-bad, or bad-good state), at 524, attributes of one or more non-ideal states may be determined. The attributes of the non-ideal state may be, for example, the value of TIR or GV, the change in TIR or GV, etc. At 526, a patient vector associated with the patient may be identified. The patient vector may be provided by the user 8, by the healthcare provider 7, and may be obtained via the electronic device 19, via the server 29, or via any other applicable method.

[0080] At 528, an optimization path can be generated to transition a patient from a non-ideal state to an ideal state. It will be understood that reaching an intermediate non-ideal state can be part of reaching the ideal state. For example, a patient having an initial non-ideal state of poor-poor (i.e., a poor TIR state and a poor GV state) may be provided with an optimization path to first transition the patient to a good-poor state or a poor-good state before reaching a good-good state. The machine learning model outputs an optimization path including a change in one or more patient vectors based on an input including one or more of a TIR state or value, a GV state or value, one or more patient vectors, one or more patient characteristics, CGM events, etc. At 530, the optimization path can be provided to the patient. The optimization path may be provided based on a habit index associated with the patient to increase the probability that the patient follows the optimization path. In addition to providing the optimization path at 530, and / or after providing the optimization path at 530, at 522, the CGM monitor continues the CGM, and flowchart 540 can repeat itself by starting at 512 based on the continuation of the CGM at 522. Flowchart 540 may occur over any applicable period that is determined in advance or dynamically for a given patient or cohort of patients.

[0081] Figure 6B shows charts 612 and 614. The first chart 612 shows multiple states of a given patient over several months. For example, the initial state of the patient indicated by 613A is a good - good state (i.e., a good TIR state and a good GV state), and the subsequent state after the initial state indicated by 613B is a poor - good state (i.e., a poor TIR state and a good GV state). Chart 612 shows various states of the patient over several months. Each state (e.g., 613A, 613B, etc.) can be a representative state during that period. For example, the initial state indicated by 613A may be the average value of all states during the first month, or it may be the state on a predetermined day, such that the same day of the month is used for each month shown in chart 612. Chart 614 in Figure 6B shows the same states as chart 612. However, when the two - dimensional state - based quadrants are related to the corresponding TIR state and GV state, chart 614 shows two - dimensional state - based quadrants that enable the viewer to see the distribution of the states. Chart 612 and / or chart 614 may be provided to user 8 or healthcare provider 7 to enable the viewer to better understand the state status of user 8.

[0082] Figure 6C shows charts 616, 618, and 620, each having various amounts of data. Chart 616 contains the most data with 15 months of CGM - based state information. Chart 618 shows 8 months of CGM - based state information, and chart 620 shows 3 months of CGM - based state information. More data points can enable the viewer to understand the patient's blood - glucose - based history more holistically than fewer data points.

[0083] FIG. 6D shows each of charts 621A and 621B showing the GV values of a given patient over 15 months. Chart 621A shows the standard deviation (SD) of the measured blood glucose values, and chart 621B shows the coefficient of variation (CV) of the measured blood glucose values. As shown, the type of GV applied (e.g., SD, CV, etc.) can change the GV state at a given time. For example, 621C in chart 621A shows the SD-based GV value of the 9th measurement. As shown, 621C corresponds to a poor GV state. However, the CV-based GV value of the same corresponding 9th measurement, represented by 621D in chart 621B, corresponds to a good GV state. The type of GV applied (e.g., SD, CV, etc.) may be selected based on one or more factors, such as the patient vector, past glucose information, patient characteristics, etc., but is not limited thereto.

[0084] FIG. 6E shows a chart 622 of various states of each of a plurality of patients represented by anonymized patient IDs. For example, patient 624 (i.e., patient ID 42799) may have a number of missing states represented by bar 626A (e.g., due to missing CGM data), a number of good-good states represented by bar 626B (i.e., good TIR state and good GV state), a number of bad-good states represented by bar 626C, and a number of bad-bad states represented by bar 626D. A medical institution or healthcare provider 7 monitoring a given patient cohort may be provided with chart 622 periodically. By reviewing the visual changes in the states shown in chart 622, a viewer may be able to easily determine the trend of state changes for all or a subset of the users implementing the technology disclosed herein.

[0085] The medical institution or healthcare provider 7 may also be provided with the chart 628 and / or diagram 630 of FIG. 6F. The medical institution or healthcare provider 7 may use the chart 628 to review the trend of changes in the status of the patient population. For example, a viewer provided with the chart 628 may be able to determine that the count of patient status changes from good-bad to bad-good (i.e., 11) is greater than that in the opposite direction (i.e., 9). Such data may be used in an updated machine learning algorithm (e.g., to improve the network layer, weights, etc. and provide an improved optimization path), and may be used, for example, to improve the way the optimization path is provided / implemented (such as based on changes added to the habit index).

[0086] Similarly, the diagram 630 may be utilized by the medical institution or healthcare provider 7 to review the trend of changes in the status of the patient population. By using the diagram 630, a viewer can quickly view the trend of status changes and may compare such trends over multiple periods. For example, a viewer provided with the diagram 630 may easily compare the number of status changes from bad-good to good-good (i.e., 20) and compare it with the changes of the previous month. It will be understood that although the chart 628 and diagram 630 are shown in terms of the number of status changes, the status changes may be represented in any applicable way, such as using the rate of change.

[0087] As disclosed herein, the optimized path generated at 516 in FIG. 5A may be generated based on one or more patient vectors. FIG. 6G shows a chart 632 of glucose measurements 634 of a patient (e.g., collected using a CGM monitor) over the course of a day. A filter or other smoothing mechanism may be used to generate a corresponding trend line 636. Chart 638 shows the first derivative 640 of the chart representing the rate of change of the smoothed trend line 636 of the glucose measurements 634 or chart 632. Both charts 632 and 638 include patient vectors including exercise vector 642, food vector 644, drug vector 646, and another food vector 648 such that a machine learning model can receive such vectors and their associated attributes (e.g., characteristics of the vectors such as the time of each predetermined vector, duration of exercise, food type, drug type, and / or dosage). The glucose measurements 634 of the patient may be used as an input to the machine learning model along with the first derivative 640 of the glucose measurements 634 of the patient, or either the glucose measurements 634 or the first derivative 640 of the patient may be used individually. Thus, the output optimized path provided by the machine learning model may be based on the glucose measurements 634 of the patient, the patient vectors (e.g., exercise vector 642, food vector 644, drug vector 646, and another food vector 648), and / or the first derivative 640.

[0088] As shown in FIG. 4B, the AGP report can include a number of metrics (e.g., 10 metrics) in addition to the graph data. These metrics can be numerous and difficult to understand for both the patient and the healthcare provider 7. Since not all 10 metrics are necessary as they do not provide unique, independent information, the components of one metric of the AGP report are determined by other metrics, and the techniques disclosed herein are based in part on minimizing the number of metrics. FIGS. 7A and 7B show that the techniques disclosed herein can be implemented using the average glucose 704, the time above range (TAR) and time in range (TIR) 706, the variability of glucose 710, the time below range (TBR), the percentage of CGM activation time 722, and / or the variability of the standard deviation and the principal component value (PCV) of glucose 724. The average glucose 704 may be based on the average glucose and the glucose management indicator (GMI), which is a predicted display of the blood glucose value. The TAR and TIR 706 may be based on the display of very high TAR (TAR_VH), high TAR (TAR_H), and / or the display of TIR. The variability of glucose 710 may be based on the standard deviation and PCV of glucose. The TBR 712 may be based on the display of low TBR (TBR_L), very low TBR (TBR_VL), and the display of TBR.

[0089] According to one implementation of the disclosed subject matter, one or more CGM events may be classified based on a patient's blood glucose levels. The classification may be based at least on a severity score associated with each of the one or more CGM events and / or on one or more characteristics of a curve associated with the patient's blood glucose levels. FIGS. 8A, 8B, and 8C show exemplary classifications of CGM events. The optimization path generated at 516 in FIG. 5A may be based in part on one or more classified CGM events. For example, the severity or other characteristics of a CGM event may be provided to a machine learning model, and the optimization path may be output based at least in part on one or more classified CGM events. As an example, the severity score may indicate the presence of a sharp peak, or the frequency of high severity scores may indicate a high amount of variation in the patient's blood glucose levels. Such CGM-based event information may be particularly useful, for example, when a patient has a high TIR since the TIR does not indicate an unhealthy amount of variation in the patient's blood glucose levels.

[0090] Applying CGM events to determine an optimization path may include detecting the events from a CGM trace (e.g., a series of measured glucose values) and classifying the events into one or more classes. The classification may include severity score-based classification and / or glucose categories. The severity score may be determined using the time and shape characteristics of the CGM trace.

[0091] Severity scores and / or CGM events may be determined with respect to individual variations in CGM data and may be part of the microview of CGM. Severity scores and / or CGM events may be used for real-time coaching or action outputs (e.g., current coaching regarding medications, diet, exercise, etc.). Accordingly, the techniques disclosed herein provide both a macroview of CGM data (e.g., using state data as illustrated in FIG. 5A) and a microview of CGM data (e.g., using severity scores and / or CGM events), and provide both real-time feedback and comprehensive health improvement feedback.

[0092] FIG. 8A shows a chart 800 having a CGM trace 802 that includes a CGM event 802A. FIG. 8B shows a chart 804 having a CGM trace 806 that includes a CGM event 806A. The CGM event 802A may be detected based on one or more mathematical methods. In the example provided in FIG. 8A, the CGM event 802A may be classified based on a multi-parameter CGM classification with clinical significance, such as three parameters: glucose at start, severity, glucose at end (b, s, d).

[0093] Parameter b may correspond to a glucose category at or near the start of a given CGM event. The glucose category b may be on a scale such as very high (e.g., +2), high (e.g., +1), within range (e.g., 0), low (e.g., -1), or very low (e.g., -2). In an example of CGM event 802A, when trace 802 bends towards the peak of CGM event 802A, the blood glucose value indicated by trace 802 is within threshold range 803 at the start of CGM event 802A, as indicated via trace 802 that is within the threshold range indicated by 803 at the start of CGM trace 802, and thus b corresponds to 0. In an example of CGM event 806A of FIG. 8B, when trace 806 bends towards the peak of CGM event 806A, the blood glucose value indicated by trace 806 is within threshold range 805 at the start of CGM event 806A, as indicated via trace 806 that is within the threshold range 805 at the start of CGM event 806A, and thus b corresponds to 0.

[0094] Parameter s may correspond to a severity score that encompasses both the height of the curve of the CGM event and the time the curve remains above the target. The severity score s may be represented as a value (e.g., from 0 to 9) indicating the height of the curve of the CGM event and the duration the curve remains above the target. The severity score may be calculated via any applicable technique that provides a severity score based on a combination of the height of the CGM curve and the duration of the corresponding trace outside the threshold range. As a simplified example, the value associated with the height of the curve may be multiplied by the value associated with the duration of the trace outside the threshold range. One or both of the height and duration values may be greater than 1. According to one implementation, the height and duration may be assigned different weights such that the severity score is more based on one of the height or duration. A higher severity score may indicate a higher combination of height and duration above the target. A lower severity score may indicate a lower combination of height and duration above the target. Thus, a lower severity score may be more desirable than a higher severity score.

[0095] In an example of CGM event 802A, parameter s corresponds to a severity score of 6, which is determined based on the height of the curve associated with CGM event 802A and the duration that trace 802 is outside threshold range 803. In an example of CGM event 806A, parameter s corresponds to a severity score of 2, which is determined based on the height of the curve associated with CGM event 806A and the duration that trace 806 is outside threshold range 805. As shown in FIGS. 8A and 8B, the height of the curve of CGM event 802A and the duration of time outside the target threshold range are greater than the height of the curve of CGM event 806A and the duration of time outside the target threshold range. Thus, the severity score of CGM event 802A is higher (i.e., 6) when compared to CGM event 806A (i.e., 2).

[0096] Parameter e may correspond to the glucose category at or near the end of a given CGM event. The glucose category b may be on a scale such as very high (e.g., +2), high (e.g., +1), within range (e.g., 0), low (e.g., -1), or very low (e.g., -2). In an example of CGM event 802A, when trace 802 flattens after the peak of CGM event 802A, the blood glucose value indicated by trace 802 is higher than range 803 at the end of CGM trace 802A as indicated via trace 802 that is outside the approximate threshold range indicated by 803 at the end of CGM trace 802, so e corresponds to 1. In an example of CGM event 806A in FIG. 8B, when trace 806 flattens below threshold range 805 and changes direction, the blood glucose value indicated by trace 806 is below threshold range 805 at the end of CGM event 806A as indicated via trace 806 that is within threshold range 805 at the end of CGM event 806A, so e corresponds to -1.

[0097] According to another implementation, the CGM event may be characterized using one or more other techniques. For example, the CGM event may be characterized based on the severity score and shape of the CGM event. FIGS. 8C and 8D show exemplary CGM events characterized by the severity score and CGM event trace shape. As disclosed herein, the severity score may be calculated based on the height of the CGM trace outside the threshold glucose range and the duration of the trace. The shape of the CGM event may be classified in any applicable manner, such as, for example, a broad category, a high category, and a normal category. Such categories may also be based on the start, peak, and end of a given CGM event, and the parameters associated with classifying the CGM trace into a given category may be determined in advance or may be determined based on a given patient, multiple CGM traces, etc. For example, the ratio of the area outlined by a given CGM trace to the height of the trace may be used to classify the CGM trace.

[0098] Figure 8C shows a chart 810 having a CGM trace 812, a threshold range 803, and three CGM events 812A, 812B, and 812C. The first CGM event 812A has a severity score of 8 and a CGM trace shape characterized as broad. The second CGM event 812B has a severity score of 5 and a CGM trace shape characterized as high. The third CGM event 812C has a severity score of 0 and a CGM trace shape characterized as normal. The severity score of the third CGM event 812C is 0 because the trace 812 at the peak of the CGM event 812C is within the threshold range 813.

[0099] According to an implementation form, the CGM trace shape may also be characterized as short. Further, the machine learning model may be used to identify the CGM trace shape based on, for example, past CGM trace shapes. The machine learning model may be updated based on updated CGM traces. For example, updated glucose values may be calculated by a CGM monitor after an optimization path is provided based on a severity score, a CGM trace shape, etc. The updated glucose values may include the impact the optimization path has on the user. The updated glucose values may be used to generate updated CGM traces that are provided to the machine learning model to update the model. For example, if the optimization path does not improve the user's condition, the machine learning model may be updated to improve its output during subsequent or future iterations.

[0100] Figure 8D shows a chart 820 having a CGM trace 822, a threshold range 823, and two CGM events 822A and 822B. The first CGM event 822A has a severity score of 9 and a CGM trace shape characterized as high. The second CGM event 822B has a severity score of 8 and a CGM trace shape characterized as normal.

[0101] One or more clinically significant CGM events for a given user 8 may be classified using a CGM classification (e.g., b, s, e of FIGS. 8A and 8B, or severity score and shape characterization of FIGS. 8C and 8D, or any other applicable characterization). An optimization pathway (e.g., via an automated coaching message, DSMA, etc.) may then be sent to user 8 further based on the characterization of the CGM event.

[0102] FIG. 9 includes a flowchart 900 for one implementation of the disclosed subject matter. At 902, a plurality of optimization profiles for reaching an ideal state from a non-ideal state may be generated. The plurality of optimization profiles may not be patient-specific, but may each be generated for a combination of a plurality of patient vectors and patient attributes. As disclosed herein, the plurality of optimization profiles may be generated using a machine learning model trained as provided in FIG. 5B. The plurality of optimization profiles may be provided as an output to the machine learning model, may be based on a past patient cohort, and may further be based on successful or failed attempts to reach an ideal state from a non-ideal state.

[0103] Each of the plurality of optimization profiles may be associated with one or more patient attributes and / or patient vectors. For example, for a given set of patient vectors and patient attributes, a particular optimization profile may be generated for each possible non-ideal state (e.g., good-bad, bad-bad, bad-good, etc.).

[0104] At 904, the TIR state of a given patient is determined, and at 906, the GV state of a given patient may be determined by the techniques disclosed herein. At 908, one or more patient vectors and one or more patient attributes of a given patient may be received. The patient vectors and / or patient attributes may be provided by the given patient, by a healthcare provider 7, and may be obtained via an electronic device 19, via a server 29, or via any other applicable means.

[0105] At 910, an optimization profile can be identified based on the patient vector and patient attributes. The optimization profile may include a limited number of optimization paths, and each optimization path may correspond to a predetermined combination of the TIR state and the GV state. For example, the optimization profile may include optimization paths for a good-bad start state, a bad-bad start state, and a bad-good start state. Thus, a predetermined optimization profile may be identified based on the patient attributes and vector, and may include a limited number of optimization profiles based on the patient's start state.

[0106] At 912, the optimization path can be identified from the optimization profile based on the TIR state and GV state of a given patient. The optimization path may vary for the same patient, even if all patient vectors and attributes remain the same. For example, during a first iteration, the optimization profile of a given patient may be identified based on the patient's attributes and vector at the time of the first iteration. Based on the patient's TIR state and GV state (e.g., good-bad state) during the first iteration, a first optimization path may be identified. However, during a second iteration, even if the given patient vector is the same (i.e., the same optimization profile is identified), a different optimization path may be identified based on a change in state (e.g., bad-good state). At 914, the identified optimization path can be provided to a given patient and / or healthcare provider 7 by the techniques disclosed herein.

[0107] Although steps 502 - 517 of FIG. 5A, 512 - 530 of FIG. 5B, and 902 - 914 of FIG. 9 are depicted in a particular order, the principles of the present disclosure are not limited to the order depicted therein.

[0108] Figure 10A shows a diagram 1000 that includes a chart 1002 of CGM events by time and date. Such a diagram or other visual output may be provided to a healthcare provider 7 or user 8 via an application (e.g., mHealth application 1) to more easily understand a CGM journey over a given period. Diagram 1000 includes the number of journey days as the Y-axis and time as the X-axis. A viewer may receive diagram 1000 and easily determine patterns over a given day, time, and / or number of days or occurrences.

[0109] Figure 10B shows a diagram 1010 that includes a chart 1012 of total carbohydrates consumed by time and meal type. Such a diagram or other visual output may be provided to a healthcare provider 7 or user 8 via an application (e.g., mHealth application 1) to more easily understand eating habits over a given period. Diagram 1010 includes the number of total carbohydrates as the Y-axis and time as the X-axis. A viewer may receive diagram 1010 and easily determine patterns over a given day, time, and / or number of days or occurrences. For example, a user can easily see the meal types consumed during a day and the calories associated with the meal types.

[0110] FIG. 11 shows the count of severity scores for a first patient, as shown via chart 1102, and a second patient, as shown via chart 1104. Each bar in chart 1102 and chart 1104 represents the number of times a given severity score was shown in the CGM data of the respective first and second patients. Generally, such a distribution may indicate better diabetes management, so a higher count for lower severity scores may be preferred. Healthcare institution or provider 7 may receive distribution diagrams (e.g., charts 1102 and 1104) for one or more patients over one or more periods, use the distribution diagrams, and monitor the progress of the entire patient population. Alternatively or additionally, the distribution diagrams may be generated for a particular patient group (e.g., based on treatment time, based on the medical team, patient attributes, patient vectors, etc.), the trends of a particular patient group may be analyzed, or the trends between multiple patient groups may be compared.

[0111] FIG. 12 shows a diagram 1200 of a CGM-based implementation for providing coaching to a patient based on CGM data. As shown, one or more attributes may be provided to CGM message generator 1212. Attributes may include, but are not limited to, glucose value 1202, glucose trend 1204 (e.g., CGM trend, CGM event data, etc.), carbohydrate information 1206, activity information 1208, insulin information 1210, etc., or combinations thereof. Based on the attributes, a message level may be determined. For example, the message level may be an action level 1222 where immediate action is required (e.g., the user should administer insulin or ingest carbohydrates to avoid harm), a warning level 1224 where action may be needed soon but is not urgent (e.g., the user should carefully monitor glucose), or an advice level 1226 where an information message is provided (e.g., action by the user is not required).

[0112] The CGM message generator 1212 may be used to provide an optimized route based on a patient vector (e.g., attributes 1202-1210), and thus may be applied at 518 in FIG. 5A or 914 in FIG. 9. For example, the optimized route may be determined based at least in part on attributes 1202-1210 and provided to the corresponding patient via the CGM message generator 1212.

[0113] FIG. 13A shows an exemplary message 1302 provided using the CGM message generator 1212. The message 1302 may be provided via the electronic device 19 of user 8. In the example provided in FIG. 13A, the message is a message at action level 1222 and may include the required action. As shown, the exemplary message 1302 is "Action required: Hey, Charlie, your glucose is high and rising rapidly. Go to the insulin computer and get an insulin dose to get back within range." The message 1302 may be provided to user 8 via the mobile phone 1300 to be sent with high importance. The high importance may result in the electronic device 19 providing, in addition to the message 1302, an audible warning, a tactile warning, a visual warning, etc.

[0114] FIG. 13B shows another exemplary message 1314 provided using the CGM message generator 1212 via the mobile phone 1300. The message 1314 is a message at warning level 1224 and may not include an urgent action. As shown, the exemplary message 1314 is "No action required: Charlie, your glucose is within target but rising slightly. There is no need to take any action at this time." Additionally, additional information such as the blood glucose value 1312 may also be provided via the mobile phone 1300 and provided near the related message 1314.

[0115] Figure 13C shows another exemplary message 1322 provided using the CGM message generator 1212 via the mobile phone 1300. The message 1322 is a message at the advice level 1226 and includes general advice to the patient. As shown in Figure 13C, the message 1322 may also include other patient vectors such as carbohydrate information, blood glucose level, insulin dosage, etc.

[0116] Thus, as shown through the embodiments of FIGS. 13A-13C, machine learning-driven automatic user coaching or CGM feedback can be provided to the user 8. For example, the system and method can be used to provide warnings when extremely important actions are required, such as in the case of hypoglycemia or extreme hyperglycemia. Notification messages for less critical glucose measurements may also be provided. Insulin administration support can provide corrective insulin based on the glucose trend as one of the patient vector corrections via an optimization path. According to one implementation, the insulin dosage may be a patient vector that can be adjusted based on the glucose trend (e.g., CGM event). The current blood glucose level may also be a factor when determining the insulin adjustment amount. For example, bolus insulin may require a period (e.g., 30 minutes) to provide the intended result, and accordingly, the trend prediction at the end of that period may be more useful than just the current blood glucose level, so the trend can be an important component.

[0117] According to one implementation of the disclosed subject matter, an insulin computer may be provided. The insulin computer may be, for example, a context computer that receives one or more factors as input to provide an action output including the amount of insulin to be administered at a predetermined time. The insulin computer may be part of the CGM monitor or may be external to the CGM monitor (e.g., may be part of one or more electronic devices 19). The external insulin computer may be connected to the CGM monitor via a wired or wireless connection such as the electronic network 32.

[0118] The insulin computer may be software or an application that operates on a CGM monitor or an external device. For example, the insulin computer may be part of the mHealth application 1. The insulin computer may receive one or more complex inputs and may provide an action output. The action output may be an instruction or a numerical value having one or more action output categories including, but not limited to, whether insulin is needed, how much insulin is needed, whether glucose is needed, how much glucose is needed, whether food intake is needed, how much food intake is needed, whether exercise is needed, how much exercise is needed, etc. The function of the insulin computer may vary based on the user's condition. For example, the action output may vary to keep the user's blood glucose level within an optimal range safely and effectively. In this embodiment, the CGM trend may be used as an input for determining the optimal blood glucose level.

[0119] The insulin computer may receive a CGM trend as an input. As disclosed in detail herein, the CGM trend may include CGM traces, CGM events, etc., or may be based on CGM traces, CGM events, etc. The CGM may be based on changes in two or more glucose measurements over a period of time. The CGM trend may be based on glucose measurements provided by a CGM device. The CGM trend may change over time such that additional glucose measurements may result in a modified or updated trend. Past CGM trends may also be used as an input.

[0120] The insulin computer may receive dietary information as input. The dietary information may be provided to the insulin computer in any applicable way, such as by user input, entering the content of the food before ingestion (e.g., image, video, etc.) or an exemplary food (e.g., an image of pizza found online to represent the food eaten), etc. The content may be input using the electronic device 19, or received from a resource such as an application that tracks the user 8's food intake. The dietary information may include an insulin-carbohydrate ratio with respect to the user 8 at a certain point in time (e.g., when the computer is used to determine the action output), or the insulin computer may calculate the insulin-carbohydrate ratio. The insulin computer may individualize the impact of the user 8's food intake so that the action output based on the dietary information regarding the user 8 may vary from that of another user having the same dietary information on a given day. The insulin computer may adjust one or more action outputs based on the dietary information and / or the insulin-carbohydrate ratio. Past dietary information may also be used as input.

[0121] The insulin computer may receive exercise (e.g., any activity) information as input. The exercise information may be provided to the insulin computer in any applicable way, such as by user input (e.g., past or planned exercise), by an exercise or health tracker (e.g., from the electronic device 19), by one or more components of the CGM monitor, by one or more sensors, etc. The exercise information may include calorie information, heart rate information, duration of exercise, exercise intensity, physical burden, etc. The insulin computer may individualize the impact of the user 8's exercise so that the action output based on the exercise information regarding the user 8 may vary from that of another user having the same exercise information on a given day. The insulin computer may adjust one or more action outputs based on the exercise information. Past exercise information may also be used as input.

[0122] The insulin computer may receive, as input, information regarding previous insulin dosages. As further discussed herein with reference to FIG. 13D, the insulin computer may determine an action output based on previous dosages and previous administration times, taking into account one or more factors associated with the user 8 (e.g., diet, exercise, individual body characteristics, CGM trends, past data, etc.). For example, when determining whether the user 8 should administer additional insulin, based on the half-life of the administered insulin, the insulin computer may determine how much insulin is still present in the user 8's body from the previous dosage.

[0123] The insulin computer may receive, as input, information regarding the current blood glucose level. Additionally, the insulin computer may receive, as input, information regarding CGM trends (e.g., the rate of change of glucose in the user 8's body). The current blood glucose level and / or CGM trends may enable the insulin computer to determine the trend (e.g., increasing, decreasing, stable, etc.) and rate of change of the blood glucose level in the user 8's body. Based on such information, the insulin computer may adjust one or more action outputs. Past blood glucose levels may also be used as input.

[0124] The insulin computer may receive, as input, the user 8's sensitivity to insulin. The sensitivity to insulin may be based on a pre-determined value, or may be based on past data received by the insulin computer, CGM monitor, etc. According to one implementation, the sensitivity may be adjusted over time based on the user 8's use of insulin. Thus, the insulin computer may update the sensitivity to insulin periodically, or each time the user's action output is calculated.

[0125] The insulin computer may receive, as input, the hypoglycemia history of user 8. When providing an action output, the insulin computer may take into account the period between a hypoglycemia event and the calculation of the action output. The insulin computer may also take into account the severity of the hypoglycemia event when providing an action output. As an example, if the history of user 8 indicates a hypoglycemia event within the past two days from the calculation of the action output, or if user 8 experiences hypoglycemia exceeding 4% for three consecutive days, the recommendation by the insulin computer may be more conservative than if there were no hypoglycemia event.

[0126] Figure 13D provides an exemplary insulin computer 1330 according to one implementation of the disclosed subject matter. As shown, one of the four time zones provided in Figure 13D can be provided as an input to the insulin computer 1330 such that the action output provided by the insulin computer 1330 can be modified based on the time zone at the time the action output is provided. Each time zone can be determined based on the last time the user 8 received insulin (e.g., a bolus injection). The first zone 1334 can be the meal bolus from the time of the insulin meal bolus 1332. The second zone 1336 can be within two hours from the meal bolus administration 1332. The third zone 1338 can be from two hours to four hours from the meal bolus administration 1332. The fourth zone 1340 can be greater than four hours from the meal bolus administration 1332. Each of the four zones can have associated attributes, including, as provided in Figure 13D, insulin on board (IOB), correction factor (CF), insulin carbohydrate ratio (ICR), and the like. When within the first zone 1334, all of the IOB, CF adjusted based on the CGM trend, and ICR administration can be considered. When within the second zone 1336, the IOB and CF may not be considered, but the ICR administration can be considered. When within the third dime zone 1338, the IOB, CF without CGM adjustment, and ICR administration can be considered. When within the fourth zone 1340, all of the IOB, CF adjusted based on the CGM trend, and ICR administration can be considered.

[0127] Accordingly, based on the factors discussed herein, the insulin computer may provide an action output, such as whether insulin is needed, how much insulin is needed, whether glucose is needed, how much glucose is needed, whether food intake is needed, how much food intake is needed, whether exercise is needed, how much exercise is needed, or combinations thereof, but not limited thereto. The insulin computer may provide an individualized contextual action output such that a first user having an input may receive a different action output than a second user having a similar input as a result of one or more factors such as the different histories of each patient.

[0128] According to one implementation, one or more action outputs may be determined using a machine learning model that is part of the insulin computer or associated with the insulin computer. The machine learning model may be a supervised model trained to provide an action output based on known good outputs and / or based on past action outputs provided by the machine learning model and corresponding changes in past CGM trends after the past action outputs were provided. For example, the machine learning model may be configured to provide an action output based on one or more inputs as discussed herein. The machine learning mode may receive an updated CGM trend after providing the action output. The machine learning model may analyze the CGM trend and update the model (e.g., update weights, neural networks, layers, etc.) based on the CGM trend to improve future action outputs provided by the machine learning model. The machine learning model may update the model for an individual or for multiple users based on feedback from one or more users (i.e., CGM trends), e.g., based on the action output provided to the user and the subsequent CGM trend of the user.

[0129] FIG. 14 is a simplified functional block diagram of a computer that can be configured as a host server to function as, for example, a decision-making server for a healthcare provider. FIG. 14 shows a network or host computer platform 1400. Those skilled in the art are presumed to be proficient in the structure, programming, and general operation of such computer equipment, and as a result, the drawings are assumed to be self-explanatory.

[0130] For example, a platform such as server 1400 may include a data communication interface 1460 for packet data communication. The platform may also include a central processing unit (CPU) 1420 in the form of one or more processors for executing program instructions. The platform typically includes an internal communication bus 1410, program storage, and data storage for various data files processed by and / or communicated by the platform, such as ROM 1430 and RAM 1440. The hardware elements, operating systems, and programming languages of such devices are in fact conventional, and those skilled in the art are presumed to be sufficiently proficient in them. Server 1400 may also include an input / output port 1450 and a communication port 1460 for connecting to input / output devices such as a keyboard, mouse, touch screen, monitor, display, etc. Of course, various server functions may be implemented in a way that distributes the processing load across a number of similar platforms. Alternatively, the server may be implemented by appropriate programming of a single computer hardware platform.

[0131] As will be appreciated by one skilled in the art in the relevant art, the present disclosure may be implemented in many different embodiments of software, hardware, firmware, and / or entities shown in the figures. Any actual software code that involves specialized control of hardware for implementing the embodiments is not limited to the detailed description. Therefore, the embodiments are described with the understanding that changes and modifications to the embodiments are possible in view of the level of detail presented herein. The aspects described may be considered as a "product" or "manufactured article" in the form of executable code and / or associated data that is executed or embodied on a type of machine-readable medium. A "storage" type medium includes any or all of the tangible memories of a computer, processor, etc., or their associated modules such as various semiconductor memories, tape drives, disk drives, etc., and can provide non-transitory storage for software programming at any time. All or part of the software may sometimes be communicated via the Internet or various other electrical communication networks. For example, such communication may enable the loading of software from, for example, a management server or host computer of a mobile communication network to a server computer platform and / or from the server to a mobile device, from one computer or processor to another computer or processor. Therefore, another type of medium that may involve software elements includes light waves, radio waves, and electromagnetic waves, such as those used via a physical interface between local devices, via wired and optical fixed-line networks, and via various air links. Physical elements such as wired or wireless links, optical links, etc., that carry such waves may also be considered as a medium involving software. As used herein, the term such as a computer or machine "readable medium" refers to any medium involved in providing instructions to a processor for execution, unless limited to a non-transitory, tangible "storage" medium.

[0132] It should be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosed embodiments as claimed.

[0133] Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and examples of the invention disclosed herein. The specification and examples are considered to be exemplary only, and it is intended that the true scope and spirit of the invention be indicated by the following claims.

[0134] As will be apparent from the figures, text, and examples presented above, various embodiments are possible but not limited thereto.

[0135] 1. A computer-implemented method for managing a user's glucose state, comprising: Receiving the user's blood glucose value using a continuous glucose monitoring (CGM) device; Determining a time-in-range (TIR) value of the user's blood glucose value, wherein the TIR value is based on an amount of time that the user's blood glucose value is within a threshold band over a reference period; Determining a TIR state based on the TIR value; Receiving at least a glucose variability (GV) value based on the user's blood glucose value, wherein the GV value is one of a standard deviation or a coefficient of variation (CV), and the CV indicates the variability of the user's blood glucose value in consideration of the standard deviation of the blood glucose value over the reference period; Determining a GV state based on the GV value; Determining a start state based on the TIR state and the GV state; Determining that the start state corresponds to a non-ideal state; Generating an optimization path to reach an ideal state based on one or more user vectors and the start state, wherein the optimization path includes one or more adjustments of the one or more user vectors; Providing the optimized route to the user; A method comprising.

[0136] 2. The method according to embodiment 1, wherein the threshold band is between approximately 70 mg / dL and 180 mg / dL.

[0137] 3. The method according to embodiment 1, wherein the reference period is 24 hours.

[0138] 4. The method according to embodiment 1, wherein the value of the CV is determined by dividing the standard deviation of the blood glucose value by the average value of the blood glucose value over the reference period.

[0139] 5. The method according to embodiment 1, wherein the TIR state is a binary state selected from one of a good TIR state or a bad TIR state.

[0140] 6. The method according to embodiment 5, wherein the good TIR state corresponds to a TIR value greater than the TIR cut-off.

[0141] 7. The method according to embodiment 1, wherein the GV state is a binary state selected from one of a good GV state or a bad GV state.

[0142] 8. The method according to embodiment 7, wherein the good GV state corresponds to a GV value greater than the GV cut-off.

[0143] 9. The method according to embodiment 1, wherein the user vector includes one or more of medicine, food intake, exercise value, psychosocial parameters, or social determinant parameters.

[0144] 10. Classifying one or more CGM events based on the blood glucose value of the user, wherein the classifying is at least based on a severity score associated with each of the one or more CGM events, and further generating the optimized route based on the classified one or more CGM events. The method according to embodiment 1.

[0145] 11. The method according to Embodiment 1, wherein the optimized route is further based on user attributes, and the user attributes are selected from one or more of social attributes, medical attributes, user preferences, metabolic attributes, or user demographics.

[0146] 12. The method according to Embodiment 1, wherein the optimized route includes an increase in one or more state-improving habits and / or a decrease in one or more state-deteriorating habits.

[0147] 13. A computer-implemented method for managing a user's glucose state, comprising: receiving a plurality of optimization profiles to reach from a non-ideal state to an ideal state, wherein the ideal state corresponds to a time in range (TIR) state within a good range and a good glucose variability (GV) state, and the non-ideal state includes at least one of a poor TIR state or a poor GV state, the receiving; determining a current TIR state based on the TIR value of the user's blood glucose level, wherein the TIR value is based on the amount of time the user's blood glucose level is within a threshold band over a reference period, and the current TIR state is one of a good TIR state or a poor TIR state, the determining; determining a current GV state based on the GV value associated with the user's blood glucose level, wherein the GV value indicates the standard deviation (SD) or coefficient of variation (CV) of the blood glucose level, and the CV indicates the variation of the user's blood glucose level considering the standard deviation of the blood glucose level over the reference period, the determining; receiving one or more user vectors of the user; identifying one of the optimization profiles based on the one or more user vectors and one or more user attributes; Identifying an optimization path based on the specified optimization profile, the TIR state, and the GV state, wherein the optimization path includes one or more adjustments of the one or more user vectors; Providing the optimization path to the user; A method comprising:

[0148] 14. The method according to embodiment 13, wherein each of the plurality of optimization profiles includes different combinations of a plurality of user vectors and a plurality of user attributes.

[0149] 15. The method according to embodiment 14, wherein each of the plurality of optimization profiles is associated with a plurality of optimization paths, and each of the plurality of optimization paths is identified based on one or more of a potential TIR state or a potential GV state.

[0150] 16. The method according to embodiment 13, wherein a machine learning model receives, as input, the optimization profile, the TIR state, and the GV state and outputs the optimization path.

[0151] 17. The method according to embodiment 13, further comprising receiving one or more user attributes and identifying one of the optimization profiles based further on the one or more user attributes.

[0152] 18. The method according to embodiment 13, wherein the value of the CV is determined by dividing the standard deviation of the blood glucose values by the average value of the blood glucose values over the reference period.

[0153] 19. A system for managing a user's blood glucose values, comprising: A memory storing processor-readable instructions; A processor configured to access the memory and execute the processor-readable instructions; Including: When the processor-readable instructions are executed by the processor, Using a continuous glucose monitoring (CGM) device configured to obtain glucose values using a component that penetrates the user's skin, electronically receiving the glucose values of the user, determining a time in range (TIR) value for the glucose values of the user, wherein the TIR value is based on the amount of time the user's glucose values are within a threshold band over a reference period, the threshold band being between approximately 70 mg / dL and 180 mg / dL, and the reference period being 24 hours, said determining, determining a TIR state based on the TIR value, wherein the TIR state is selected from a good TIR state or a poor TIR state, said determining, receiving at least a glucose variability (GV) value based on the glucose values of the user, wherein the GV value is one of a standard deviation or a coefficient of variation (CV), and the CV indicates the variability of the user's glucose values considering the standard deviation of the glucose values over the reference period, said receiving, determining a GV state based on the GV value, wherein the GV state is one of a good GV state or a poor GV state, said determining, determining a start state based on the TIR state and the GV state, determining that the start state corresponds to a non-ideal state, detecting a CGM event based on the glucose values of the user, characterizing the CGM event based on one or more of a multi-parameter CGM classification or severity and a characterization of the CGM event trace shape, wherein the multi-parameter CGM classification includes the glucose value at the start of the CGM event, the severity, and the glucose value at the end of the CGM event, said characterizing, generating an optimization path to reach an ideal state based on one or more account vectors and said characterizing of the CGM event, wherein the optimization path includes one or more adjustments of the one or more account vectors, said generating, providing the optimized route to the user; A system comprising a processor configured to execute a method including .

[0154] 20. The system according to embodiment 19, wherein providing the optimized route to the user includes providing context-based instructions to the user based on the optimized route.

[0155] Additional embodiments include the following.

[0156] 1. A system for providing glucose trend-based action outputs, comprising: A continuous glucose monitoring (CGM) device configured to output a plurality of glucose measurements based on analyzing a body fluid over a period of time; A memory configured to store the plurality of glucose measurements; A processor, configured to determine a CGM trend based on changes in the plurality of glucose measurements output by the CGM device and / or stored in the memory, determine at least one action output based on the CGM trend and at least one additional factor, and configured to provide the at least one action output to a user. A system comprising the above.

[0157] 2. The system according to embodiment 1, wherein the CGM device is further configured to output subsequent glucose measurements based on the body fluid after the period of time, and the processor is further configured to determine an updated CGM trend based on the subsequent glucose measurements.

[0158] 3. The at least one action output corresponds to at least one action category selected from whether insulin is needed, how much insulin is needed, whether glucose is needed, how much glucose is needed, whether food intake is needed, how much food intake is needed, whether exercise is needed, or how much exercise is needed, for the system according to Embodiment 1.

[0159] 4. The at least one action output category is selected based on the type of the one additional factor, for the system according to Embodiment 3.

[0160] 5. The at least one additional factor includes dietary information, for the system according to Embodiment 1.

[0161] 6. The dietary information includes an insulin-carbohydrate ratio, for the system according to Embodiment 5.

[0162] 7. The at least one additional factor includes exercise information, for the system according to Embodiment 1.

[0163] 8. The exercise information may include at least one of calorie information, heart rate information, exercise duration, exercise intensity, or physical burden, for the system according to Embodiment 7.

[0164] 9. The at least one additional factor includes information regarding previous insulin dosages, for the system according to Embodiment 1.

[0165] 10. The at least one additional factor includes blood glucose levels, for the system according to Embodiment 1.

[0166] 11. The at least one additional factor includes information regarding a history of hypoglycemia, for the system according to Embodiment 1.

[0167] 12. The system according to embodiment 11, wherein the occurrence of hypoglycemia within a threshold time makes the action output of the insulin recommendation action category more conservative by comparing it with the action output of the insulin recommendation action category without the occurrence of the hypoglycemia within the threshold time.

[0168] 13. The system according to embodiment 1, wherein the processor includes a machine learning model configured to output the at least one action output based on one or more past action outputs and corresponding changes in past CGM trends.

[0169] 14. The system according to embodiment 1, wherein the at least one action output is provided to the user using at least one of the CGM monitor, the electronic device, or the application.

[0170] 15. A computer-implemented method for providing a glucose trend-based action output, comprising: receiving a plurality of glucose measurements from a continuous glucose monitor (CGM) device based on the CGM device that analyzes body fluids over a period of time; determining a CGM trend based on changes in the plurality of glucose measurements output by the CGM device; determining at least one action output based on the CGM trend; providing the at least one action output to the user. The method includes.

[0171] 16. The method according to embodiment 15, wherein the at least one action output corresponds to at least one action category selected from whether insulin is required, how much insulin is required, whether glucose is required, how much glucose is required, whether food intake is required, how much food intake is required, whether exercise is required, or how much exercise is required.

[0172] 17. The CGM device is further configured to output subsequent glucose measurement values based on the body fluid after the certain period, and further includes determining an updated CGM trend based on the subsequent glucose measurement values, the method according to embodiment 15.

[0173] 18. The method according to embodiment 17 further includes receiving, by the processor, the updated CGM trend, determining at least one updated action output based on the updated CGM trend, and providing the at least one updated action output to the user.

[0174] 19. A system for providing glucose trend-based action outputs, A continuous glucose monitoring (CGM) device configured to output a plurality of glucose measurement values based on analyzing a body fluid over a certain period, the CGM device accessing the body fluid through the user's skin, the CGM device being configured to obtain glucose measurement values in units of 5 minutes or less, the continuous glucose monitoring (CGM) device; A memory configured to store the plurality of glucose measurement values; A processor, Determining a CGM trend based on changes in the plurality of glucose measurement values output by the CGM device and / or stored in the memory, the CGM trend being determined using a CGM trace that maps the glucose measurement values over a certain period, the CGM trend being further based on at least one of a CGM event or a severity score; Receiving at least one additional factor, the at least one additional factor including one or more of meal information, exercise information, carbohydrate-insulin ratio, information on previous insulin dosages, blood glucose levels, and information on a history of hypoglycemia; Based on the CGM trend and at least one additional factor, determining whether insulin is needed, how much insulin is needed, whether glucose is needed, how much glucose is needed, whether food intake is needed, how much food intake is needed, whether exercise is needed, and how much exercise is needed, and identifying at least one action category selected therefrom, Based on the CGM trend and the at least one additional factor, determining at least one action output, wherein the at least one action output is from the at least one identified action category, and the at least one action output is determined using a machine learning model configured to output the at least one action output based on one or more past action outputs and corresponding changes in past CGM trends, the determining, Generating a graphical user interface (GUI) based on the at least one identified action category, Providing the at least one action output to the user via the generated GUI, After providing the at least one action output to the user, receiving an updated CGM trend, wherein the updated CGM trend is based on glucose measurements after providing the at least one action output to the user, the receiving, Updating the machine learning model based on the updated CGM trend, A system comprising.

[0175] 20. Further comprising providing the updated CGM trend as an input to the insulin computer, determining, by the insulin computer, at least one updated action output based on the updated CGM trend, and providing the at least one updated action output to the user, the system according to embodiment 19.

[0176] Additional embodiments include the following.

[0177] 1. A system for managing a user's glucose state, a continuous glucose monitoring (CGM) device configured to output a plurality of glucose measurements based on analyzing body fluid over a period of time, a memory configured to store the plurality of glucose measurements, a processor, generating a CGM trace based on the plurality of glucose measurements over the period of time, identifying a severity score of the CGM trace, the severity score being based on a height of the CGM trace and a duration of time the CGM trace remains above a target value, the identifying, identifying a starting state based on the severity score, the starting state indicating the user's glucose health state, the identifying, generating an optimization path to reach an ideal state based on one or more user vectors and the starting state, the optimization path including one or more adjustments of the one or more user vectors, the generating, providing the optimization path to the user, comprising a system.

[0178] 2. Identifying starting parameters, the starting parameters being scaled values determined based on a starting point of the CGM trace as compared to a target range, the identifying, and further generating the optimization path based on the starting parameters, the system according to embodiment 1 further comprising.

[0179] 3. The system according to embodiment 2, wherein the starting parameter is selected from one of a very high parameter, a high parameter, a parameter within range, a low parameter, and a very low parameter.

[0180] 4. Identifying an end parameter, the end parameter being a scaled value determined based on an end point of the CGM trace as compared to a target range, the identifying, and further generating the optimization path based on the end parameter, the system according to Embodiment 1.

[0181] 5. The severity score is determined by multiplying a height of the CGM trace by a duration for which the CGM trace exceeds the target value, the system according to Embodiment 1.

[0182] 6. The height of the CGM trace is given a first weight, and the duration for which the CGM trace exceeds the target value is given a second weight different from the first weight, the system according to Embodiment 5.

[0183] 7. A lower severity score corresponds to a starting state closer to the ideal state when compared to a higher severity score, the system according to Embodiment 1.

[0184] 8. The user vector includes one or more of medications, food intake, exercise values, psychosocial parameters, or social determinant parameters, the system according to Embodiment 1.

[0185] 9. The optimization path is selected from an optimization profile, the optimization profile being specified based on the severity score and one or more user characteristics, the system according to Embodiment 1.

[0186] 10. Determining an in-range time (TIR) value of the CGM trace, the TIR value being based on an amount of time for which the CGM trace is within a threshold band over a reference period, the determining, determining a TIR state based on the TIR value, Receiving a glucose variability (GV) value based at least on the CGM trace, wherein the GV value is one of a standard deviation or a coefficient of variation (CV), and the CV indicates the variation of the glucose measurement values over the reference period in consideration of the standard deviation of the glucose measurement values over the reference period, the receiving; Determining a GV state based on the GV value; The system according to Embodiment 1, further comprising determining the start state based on the TIR state and the GV state.

[0187] 11. A computer-implemented method for managing a user's glucose state, comprising: Receiving, from a continuous glucose monitoring (CGM) device, the user's glucose measurement values over a certain period of time; Generating a CGM trace based on the received glucose measurement values; Identifying a severity score of the CGM trace, wherein the severity score is based on the height of the CGM trace and the duration of time the CGM trace stays above a target value, the identifying; Identifying a CGM trace shape of the CGM trace, wherein the CGM trace shape is based on at least one of the height or width of the CGM trace, the identifying; Identifying a start state based on the severity score and the CGM trace shape, wherein the start state indicates the user's glucose health state, the identifying; Generating an optimization path to reach an ideal state based on one or more user vectors and the start state, wherein the optimization path includes one or more adjustments of the one or more user vectors, the generating; Providing the optimization path to the user; A method comprising.

[0188] 12. The method according to Embodiment 11, wherein the CGM trace shape is one of a wide shape, a narrow shape, a short shape, and a tall shape.

[0189] 13. The method according to Embodiment 12, wherein the CGM trace shape is identified by a machine learning model configured to output a CGM trace shape based on the CGM trace.

[0190] 14. The method according to Embodiment 13, wherein the machine learning model can be configured to output a CGM trace shape based on past CGM trace shapes.

[0191] 15. A system for managing a user's glucose state, a continuous glucose monitoring (CGM) device configured to output a plurality of glucose measurements based on analyzing body fluid over a period of time, the CGM device accessing the body fluid through the user's skin, the CGM device being configured to obtain glucose measurements in units of 5 minutes or less, the continuous glucose monitoring (CGM) device; a memory configured to store the plurality of glucose measurements; a processor, generating a CGM trace that maps the glucose measurements over a period of time; identifying a severity score of the CGM trace, the severity score being based on a height of the CGM trace and a duration of time the CGM trace stays above a target value; identifying a CGM trace shape of the CGM trace using a machine learning model, the CGM trace shape being based on at least one of a height or a width of the CGM trace; identifying a starting state based on the severity score and the CGM trace shape, the starting state indicating the user's glucose health state; Generating an optimization path to reach an ideal state based on one or more user vectors and the starting state, wherein the optimization path includes one or more adjustments of the one or more user vectors, the generating, Generating a graphical user interface (GUI) based on the optimization path, Providing the at least one optimization path to a user via the generated GUI, Receiving an updated CGM trace after providing the optimization path to the user, wherein the updated CGM trace is based on glucose measurements after providing the optimization path to the user, the receiving, Updating the machine learning model based on the updated CGM trace, A system comprising.

[0192] 16. Identifying starting parameters, wherein the starting parameters are scaled values determined based on the starting point of the CGM trace compared to a target range, the identifying, and further generating the optimization path based on the starting parameters, the system according to embodiment 15.

[0193] 17. The system according to embodiment 16, wherein the starting parameters are selected from one of a very high parameter, a high parameter, a parameter within range, a low parameter, and a very low parameter.

[0194] 18. Identifying ending parameters, wherein the ending parameters are scaled values determined based on the ending point of the CGM trace compared to a target range, the identifying, and further generating the optimization path based on the ending parameters, the system according to embodiment 15.

[0195] 19. The system according to embodiment 15, wherein the CGM trace shape is one of a wide shape, a narrow shape, a short shape, and a tall shape.

[0196] 20. The system according to embodiment 15, wherein the user vector includes one or more of a drug, food intake, exercise value, psychosocial parameter, or social determinant parameter.

Claims

1. A computer-implemented method for managing a user's glucose state, comprising: Receiving the user's blood glucose value using a continuous glucose monitoring (CGM) device; Determining a time-in-range (TIR) value of the user's blood glucose value, wherein the TIR value is based on an amount of time that the user's blood glucose value is within a threshold band over a reference period; Said determining; Determining a TIR state based on the TIR value; Receiving at least a glucose variability (GV) value based on the user's blood glucose value, wherein the GV value is one of a standard deviation or a coefficient of variation (CV), and the CV indicates the variability of the user's blood glucose value in consideration of the standard deviation of the blood glucose values over the reference period; said receiving; Determining a GV state based on the GV value; Determining a start state based on the TIR state and the GV state; Determining that the start state corresponds to a non-ideal state; Generating an optimization path to reach an ideal state based on one or more user vectors and the start state, wherein the optimization path includes one or more adjustments of the one or more user vectors; said generating; Providing the optimization path to the user; A method comprising the above.

2. The method according to claim 1, wherein the threshold band is between approximately 70 mg / dL and 180 mg / dL.

3. The method according to claim 1, wherein the reference period is 24 hours.

4. The method according to claim 1, wherein the value of the CV is determined by dividing the standard deviation of the blood glucose values by the average value of the blood glucose values over the reference period.

5. The method according to claim 1, wherein the TIR state is a binary state selected from one of a good TIR state or a bad TIR state.

6. The method according to claim 5, wherein the good TIR state corresponds to a TIR value greater than a TIR cut-off.

7. The method according to claim 1, wherein the GV state is a binary state selected from one of a good GV state or a bad GV state.

8. The method according to claim 7, wherein the good GV state corresponds to a GV value greater than a GV cut-off.

9. The method according to claim 1, wherein the user vector includes one or more of medicine, food intake, exercise value, psychosocial parameters, or social determinant parameters.

10. Classifying one or more CGM events based on the blood glucose level of the user, wherein the classifying is at least based on a severity score associated with each of the one or more CGM events, the classifying; The method according to claim 1, further comprising generating the optimization path based on the classified one or more CGM events.

11. The method according to claim 1, wherein the optimization path is further based on user attributes, and the user attributes are selected from one or more of social attributes, medical attributes, user preferences, metabolic attributes, or user demographics.

12. The method according to claim 1, wherein the optimization path includes an increase in one or more state-improving habits and / or a decrease in one or more state-deteriorating habits.

13. A system for managing a user's blood glucose level, a memory storing processor-readable instructions, a processor configured to access the memory and execute the processor-readable instructions, comprising, when the processor-readable instructions are executed by the processor, electronically receiving the user's blood glucose level using a continuous glucose monitoring (CGM) device configured to obtain a glucose value using a component that penetrates the user's skin; determining a time in range (TIR) value of the user's blood glucose level, wherein the TIR value is based on the amount of time the user's blood glucose level is within a threshold band over a reference period, the threshold band being between approximately 70 mg / dL and 180 mg / dL, and the reference period being 24 hours, the determining; determining a TIR state based on the TIR value, wherein the TIR state is selected from a good TIR state or a bad TIR state, the determining; receiving at least a glucose variability (GV) value based on the user's blood glucose level, wherein the GV value is one of a standard deviation or a coefficient of variation (CV), and the CV indicates the variability of the user's blood glucose level considering the standard deviation of the blood glucose level over the reference period, the receiving; Determining a GV state based on the GV value, wherein the GV state is one of a good GV state or a bad GV state, said determining; Determining a start state based on the TIR state and the GV state; Determining that the start state corresponds to a non-ideal state; Detecting a CGM event based on the user's blood glucose value; Characterizing the CGM event based on one or more of a multi-parameter CGM classification or severity and a characteristic of the CGM event trace shape, wherein the multi-parameter CGM classification includes a blood glucose value at the start of the CGM event, a severity, and a blood glucose value at the end of the CGM event, said characterizing; Generating an optimization path to reach an ideal state based on one or more account vectors and said characterizing of the CGM event, wherein the optimization path includes one or more adjustments of the one or more account vectors, said generating; Providing the optimization path to the user; A system comprising a processor configured to execute a method comprising: Claims 14 The system of claim 13, wherein providing the optimization path to the user includes providing context-based instructions to the user based on the optimization path.

Citation Information

Patent Citations

  • Analytic and interpretive system for diabetes data

    JP1992348747A

  • Method and apparatus for managing glucose control

    JP2010510866A

  • Methods, systems, and computer program products for observing blood glucose fluctuations in diabetes.

    JP2012509748A

  • Diabetes therapy management system for recommending adjustments to an insulin infusion device

    WO2013184896A1