Technique for determining patterns in blood glucose measurement data and user interface for displaying same

Abstract

Techniques, devices and computer products are disclosed in which a processor is operable to access blood glucose measurements and insulin data from a data memory. The processor may be operable to identify, based on the blood glucose measurements, high events where the blood glucose measurements exceed an upper target blood glucose set point and low events where the blood glucose measurements are below a lower target blood glucose set point. Rules may be applied to the high and low events. Based on the results of the rules, high event patterns may be identified as well as low event patterns. Respective pattern weights may be applied to each identified high event and each identified low event, and a number of high event patterns and a number of low event patterns may be added to a graphical user interface.

Description

[Technical field]

[0001] This application claims the benefit of U.S. Patent Application No. 17 / 746,461, filed May 17, 2022, the contents of which are incorporated by reference in their entirety herein.

[0002] Various systems are available for visualizing the results and behavior of a diabetes treatment program. One example is Ambulatory Glucose Profile (AGP), a data visualization system that provides a user, such as a diabetic, with a dashboard showing the user's blood glucose measurement data over several days. However, the user is forced to make their own inferences from the data displayed in the dashboard and / or have a medical professional interpret the data. [Background technology]

[0003] In a data visualization system such as AGP, the daily glucose profiles are combined to provide a full day (24 hour) picture for display on a dashboard. The daily display shows the user's blood glucose readings as lines, ideally the lines stay within an outlined area that indicates (represents) that the user's blood glucose readings are staying within the range of the user's goal set (e.g., 10-25%). For example, the dashboard may display a median line, a medium opacity, and a light opacity. The median line is a center line with half the number of blood glucose readings above the midline and the other half of the number of blood glucose readings below the midline. The median opacity indicates 50% of the blood glucose readings, ideally with a narrower interval indicating stable blood glucose readings. The light opacity indicates 5% of the blood glucose readings are above (95% above) and 5% are below (5% below). Any exceptions to the above are highlighted in red. Blood glucose data may be aggregated over a period of time, with the daily data displayed at a higher level as well as the median of the data aggregated over a period of time.

[0004] While the AGP reports provide summaries of information related to blood glucose information, the AGP reports do not provide analysis or statistics of the information to identify trends or patterns related to how well a user stays within target blood glucose set points, nor do they provide analysis or visualizations that would allow for an improved display of the amount of data available. Summary of the Invention [Problem to be solved by the invention]

[0005] It would be beneficial for a user to have a system that utilizes techniques for data visualization of information derived from the user's blood glucose measurements and analytical techniques that are also incorporated into the data visualization. [Means for solving the problem]

[0006] An example of a non-transitory computer readable medium embodied with programming instructions for causing a computer to access blood glucose measurements and insulin data from a data memory is disclosed. Blood glucose measurements above an upper target blood glucose setpoint may be identified as high events and blood glucose measurements below a lower target blood glucose setpoint may be identified as low events. A high event overlap rule set may be applied to the high events and a low event overlap rule set may be applied to the low events. Based on applying the high event overlap rule set to the high events and the low event overlap rule set to the low events, overlapping high events and overlapping low events may be identified for analysis. Overlapping high events within a set high event overlap period and number of days may be identified as a high event pattern. The processor may be operable to identify overlapping low events within a set low event overlap period and number of days as a low event pattern. Based on the high event specific criteria and the low event specific criteria, a respective pattern weight may be applied to each identified high event and each identified low event, and a number of event patterns and another number of low event patterns may be added to the graphical user interface.

[0007] An example of a non-transitory computer readable medium is disclosed that embodies programming instructions that, when executed, cause a processor to access blood glucose measurements and insulin data from a memory. The processor may identify blood glucose measurements above an upper target blood glucose setpoint as high events and blood glucose measurements below a lower target blood glucose setpoint as low events. A high event pattern may be identified in the overlapping high events and a low event pattern may be identified in the overlapping low events, and the overlap is determined based on a window of time. A bolus event rule set may be applied to the identified overlapping high event patterns and the identified overlapping low event patterns. Based on the application of the bolus event rule set to each of the identified overlapping low events and each of the identified low events, a bolus event corresponding to each of the identified high events and each of the identified low events may be identified for analysis. The identified bolus event may be added to the corresponding identified high event or the corresponding identified low event in the memory. A number of low event patterns to which a bolus event has been added and another number of high events to which a bolus event has been added may be added to a graphical user interface.

[0008] A system is disclosed having a memory and a data analysis processor. The memory may be operable to store a user's continuous blood glucose monitoring data and data from the user's personal diabetes management device, the user's continuous blood glucose monitoring data including blood glucose measurements and the data from the user's personal diabetes management device including insulin delivery data. The data analysis processor may have circuitry operable to execute program code stored in the memory, and the data analysis processor may be operable to obtain blood glucose measurements and insulin delivery data and data from the user's personal diabetes management device during a predetermined period of time. The data analysis processor may be operable to identify blood glucose measurements above an upper target blood glucose set point as high events and blood glucose measurements below a lower target blood glucose set point as low events in the normalized data. A high event overlap rule set may be applied by the data analysis processor to the high events and a low event overlap rule set may be applied to the low events. The data analysis processor may identify overlapping high events and overlapping low events for analysis based on applying the high event overlap rule set to the high events and the low event overlap rule set to the low events. The data analysis processor may identify overlapping high events within a set high event overlap period and number of days as a high event pattern and overlapping low events within a set low event overlap period and number of days as a low event pattern. A respective pattern weight may be applied to each identified high event and each identified low event based on high event specific criteria and low event specific criteria. The data analysis processor may add a number of high event patterns and another number of low event patterns to the graphical user interface. [Brief description of the drawings]

[0009] [Figure 1A] FIG. 1A illustrates an example of a wearable drug delivery system suitable for use with and implementing the subject matter described herein.

[0010] [Figure 1B] FIG. 1B illustrates an exemplary system flow diagram for obtaining and processing data used by the subject matter described herein.

[0011] [Figure 2A] FIG. 2A illustrates a flow chart of an example of a data visualization algorithm for determining time-of-day patterns present in glucose blood measurements and insulin levels over a period of time in accordance with the subject matter described herein.

[0012] [Figure 2B] FIG. 2B illustrates a flow chart of an example data visualization algorithm for determining post-bolus high and low events present in glucose blood measurements and insulin values ​​over a given period of time according to the subject matter described herein.

[0013] [Diagram 3] FIG. 3 illustrates an example of a graphical user interface displaying a user's time within blood glucose range as well as low and high event patterns as determined by a data visualization algorithm according to the subject matter described herein.

[0014] [Figure 4] FIG. 4 illustrates an example of a graphical user interface displaying trends in blood glucose measurements according to the subject matter described herein, low event patterns representing when blood glucose measurements were below a low target set point, and high event patterns representing when blood glucose measurements were above a high target set point.

[0015] [Figure 5A] FIG. 5A illustrates an example of a graphical user interface displaying details of a particular hyperglycemic event in accordance with the subject matter described herein.

[0016] [Figure 5B]FIG. 5B illustrates an example of the graphical user interface of FIG. 5A with descriptions showing modes of a drug delivery device and insulin usage in accordance with the subject matter described herein.

[0017] [Figure 5C] FIG. 5C illustrates an example of the graphical user interface of FIG. 5A with a pop-up window showing bolus delivery time, bolus amount, and estimated carbohydrates in accordance with the subject matter described herein.

[0018] [Figure 5D] FIG. 5D illustrates an example of a graphical user interface displaying information related to multiple high event patterns occurring in the evening along with recommendations according to the subject matter described herein.

[0019] [Figure 6A] FIG. 6A illustrates an example of a graphical user interface displaying a particular hypoglycemic event in accordance with the subject matter described herein.

[0020] [Figure 6B] FIG. 6B illustrates an example of the graphical user interface of FIG. 6A with descriptions showing drug delivery device modes and insulin usage for a drug delivery device according to the subject matter described herein.

[0021] [Figure 6C] FIG. 6C illustrates an example of the graphical user interface of FIG. 6A with a pop-up window showing bolus delivery time, bolus amount, and estimated carbohydrates in accordance with the subject matter described herein.

[0022] [Figure 6D] FIG. 6D illustrates an example of a graphical user interface displaying information related to multiple high event patterns occurring in the evening along with recommendations according to the subject matter described herein.

[0023] [Figure 7A] FIG. 7A illustrates an example of a graphical user interface displaying post-bolus high events in accordance with the subject matter described herein.

[0024] [Figure 7B] FIG. 7B illustrates an example of the graphical user interface of FIG. 7A with descriptions showing drug delivery device modes and insulin usage for a drug delivery device according to the subject matter described herein.

[0025] [Figure 7C] FIG. 7C illustrates an example of the graphical user interface of FIG. 7A with a pop-up window showing bolus delivery time, bolus amount, and estimated carbohydrates in accordance with the subject matter described herein.

[0026] [Figure 8A] FIG. 8A illustrates an example of a graphical user interface displaying low post-bolus events in accordance with the subject matter described herein.

[0027] [Figure 8B] FIG. 8B illustrates an example of the graphical user interface of FIG. 8A with descriptions showing drug delivery device modes and insulin usage for a drug delivery device according to the subject matter described herein.

[0028] [Figure 8C] FIG. 8C illustrates an example of the graphical user interface of FIG. 8A with a pop-up window showing bolus delivery time, bolus amount, and estimated carbohydrates in accordance with the subject matter described herein.

[0029] [Figure 9A] FIG. 9A illustrates an example of a graphical user interface providing a daily summary over a period of time in accordance with the subject matter described herein. [Figure 9A-1]FIG. 9A-1 illustrates an example of a graphical user interface providing a daily summary over a period of time in accordance with the subject matter described herein.

[0030] [Figure 9B] FIG. 9B illustrates an example detailed graphical user interface display of an example day with explanations from the example daily summary graphical user interface of FIG. 9A in accordance with the subject matter described herein.

[0031] [Figure 10A] FIG. 10A illustrates an example of a graphical user interface providing a weekly summary according to the subject matter described herein. [Figure 10A-1] FIG. 10A-1 illustrates an example of a graphical user interface providing a weekly summary according to the subject matter described herein.

[0032] [Figure 10B] FIG. 10B illustrates an example detailed graphical user interface display of a range of week hours from the example weekly summary graphical user interface of FIG. 10A in accordance with the subject matter described herein.

[0033] [Figure 10C] FIG. 10C illustrates an example detailed graphical user interface view of the weekly bolus and insulin summary from the example weekly summary graphical user interface of FIG. 10A in accordance with the subject matter described herein.

[0034] [Figure 11-24] 11-24 illustrate decorative features of example graphical user interfaces. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0035] Certain drug delivery algorithms (MDAs) may include "artificial pancreas" algorithm-based systems, or more generally, either automated insulin delivery (AID) applications / algorithms or artificial pancreas (AP) applications. For ease of discussion, computer programs and computer applications that implement drug delivery algorithms or applications may be referred to herein as "AID applications." The AID applications or algorithms may be configured to provide automatic delivery of insulin based on analyte sensor inputs, such as signals received from an analyte sensor, such as continuous blood glucose monitors. The signals from the analyte sensors may include blood glucose measurements, timestamps, etc.

[0036] Additionally or alternatively, although the disclosed embodiments may be described with reference to closed-loop algorithm implementations, variations of the disclosed embodiments may be implemented to allow for open-loop use. Open-loop implementations allow for the use of different modalities of insulin delivery, such as smart pens, syringes, etc. For example, the disclosed AID application and algorithms may be operable to perform various functions associated with open-loop operation, such as generating prompts requesting input of information such as type of diabetes, weight, or age. Similarly, insulin doses may be received from a user via a user interface by the AID application or algorithm. Other open-loop operations may be implemented by adjusting user settings, etc. in the AID application or algorithm.

[0037] The systems, devices, computer-readable media, and methods according to the present disclosure are described in more detail below with reference to the accompanying drawings, which show one or more embodiments. The systems, devices, and methods described herein may be embodied in many different forms and are not to be construed as being limited to the examples set forth herein. Instead, these examples are provided so that the disclosure will be thorough and complete, and will fully convey the scope of the techniques and devices to those skilled in the art. Each of the systems, devices, media, and methods disclosed herein provides one or more advantages over conventional systems, components, and methods.

[0038] FIG. 1A illustrates an example of a wearable drug delivery system suitable for use with and implementing the subject matter described herein.

[0039] In some examples, the drug delivery system 100 is adapted to deliver insulin to a user in accordance with the disclosed embodiments. The drug delivery system 100 may include a wearable drug delivery device 102, a controller 104, and an analyte sensor 106.

[0040] The wearable drug delivery device 102 may be a wearable device that is attached to the body of a user. The wearable drug delivery device 102 may be directly coupled to the user (e.g., attached directly to the user's skin via an adhesive, etc.). In one example, the surface of the wearable drug delivery device 102 may include an adhesive to facilitate attachment to the user's skin.

[0041] The analyte sensor 106 may be operable to collect physiological condition data, such as blood glucose measurements, and in some examples may provide a timestamp of when each of the blood glucose measurements was collected.

[0042] The wearable drug delivery device 102 may have a processor 114. The processor 114 may be implemented in hardware, software, or any combination thereof. The processor 114 may be, for example, a microprocessor, a logic circuit, a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), or a microprocessor coupled to a memory. The processor 114 may be operable to maintain date and time and perform other functions (e.g., calculations, etc.). The memory 112 may include random access memory (RAM), read only memory (ROM), optical storage, magnetic storage, removable storage media, solid state storage, etc. The memory 112 may be operable to store settings 121, any control applications 126, and historical data 129. The processor 114 may be operable to execute any control applications 126 stored in the memory 112, allowing the processor 114 to direct the operation of the wearable drug delivery device 102. The control application 126 may be an AID algorithm operable to control insulin delivery to the user according to the AID control approach as described herein. Additionally, the memory 112 may store settings 121 for the user, such as graphical user display settings, healthcare provider communication settings, AID / MDA algorithm settings, control application settings, etc. The ADI and / or control application settings may include information and settings such as maximum insulin delivery, insulin sensitivity settings, insulin correction factor settings, insulin vs. carbohydrate settings, total daily insulin (TDI) settings, etc. The historical data 129 may include different data items.In a first example, the historical data 129 may have data entries, which include an insulin output history, which may include at least the basal insulin doses (i.e., the amount of insulin delivered in each of the basal insulin doses), the respective times of each of the basal insulin doses, the bolus insulin doses (i.e., the amount of insulin delivered in each of the bolus insulin doses), and the respective times of each of the bolus insulin doses. In a second example, the historical data 129 may have data entries, which include an insulin output history, which may include at least the basal insulin doses (i.e., the amount of insulin delivered in each of the basal insulin doses), the respective times of each of the basal insulin doses, the bolus insulin doses (i.e., the amount of insulin delivered in each of the bolus insulin doses), and the respective times of each of the bolus insulin doses and blood glucose measurements (and corresponding timestamps of each of the measurements) received from the analyte sensor 106.

[0043] The wearable drug delivery device 102 may have a reservoir 120. The reservoir 120 may be operable to store a drug, medication or therapeutic suitable for automated delivery, such as insulin, morphine, methadone, hormones, glucagon, glucagon-like peptides, blood pressure medications, chemotherapy drugs, combinations of medications such as insulin and glucagon-like peptides, etc. To that end, although this specification may primarily refer to insulin, the wearable drug delivery device 102 and controller 104 may be configured to output the drug, medication, therapeutic or combinations thereof listed above according to each of the algorithms that may replace the AIDs or control algorithms / applications described above. A fluid path (not shown) from the reservoir 120 to the user may be provided via a tube coupled to a needle / cannula (not shown) that allows the output drug, medication, therapeutic or combinations thereof to be delivered to the user, such as subcutaneously. The wearable drug delivery device 102 may be operable, based on a control signal from the processor 114, to pump or output a drug, medication or therapeutic agent, such as insulin, from the reservoir 120 via a fluid path to deliver a dosage of the drug, medication or therapeutic agent to a user.

[0044] For example, there may be one or more communication links 128 with one or more devices of the user (or the user's caregiver) that are physically separate from the wearable drug delivery device 102 including the controller 104 and / or the sensor 106. The communication link 128 may be any wired or wireless communication link operating according to any known communication protocol or standard, such as Bluetooth®, Wi-Fi®, a short-range wireless communication standard, a cellular standard, or any other wireless protocol.

[0045] The wearable drug delivery device 102 may also include a user interface 116, such as an integrated display device, to display information to the user and, in some embodiments, to receive information from the user. For example, the user interface 116 may include a touch screen. Additionally or alternatively, the user interface 116 may include one or more input devices, such as buttons, knobs, or a keyboard, that allow the user to provide input.

[0046] Additionally, the processor 114 may be operable to receive data or information from the analyte sensor 106 as well as other devices that may be operable to communicate with the wearable drug delivery device 102.

[0047] The wearable drug delivery device 102 may communicate with a network 108. The network 108 may include a local area network (LAN), a wide area network (WAN), or a combination thereof. A computing device 132 may communicate with the network, and the computing device may be operable to communicate with the wearable drug delivery device 102. In one example, the computing device 132 may be a healthcare provider device and is operable to communicate with the user's controller 104 to obtain information about the wearable drug delivery device 102, the controller 104, and / or the analyte sensor 106, etc., and to interact to save and / or update settings. For example, the computing device 132 may be operable as a backup device, such as the control application 141 or 126. The AID algorithm operating as the control application 141 or in cooperation with the control application 141 may display a graphical user interface on the computing device 132 that allows for input and display of information related to the AID algorithm.

[0048] The drug delivery system 100 may include an analyte sensor 106 that senses the level of one or more analytes of the user. The analyte level may be used as physiological condition data and transmitted to the controller 104 and / or the wearable drug delivery device 102. The sensor 106 may be coupled to the user, for example, by adhesive or the like, and may provide information or data regarding one or more medical conditions and / or physical attributes of the user. The sensor 106 may be another type of device or sensor that provides operable to provide continuous glucose monitoring (CGM) or blood glucose concentration measurements. In addition to or instead of blood glucose measurements, the sensor 106 may be operable to provide other metabolic or blood-related measurements. The sensor 106 may be physically separate from the wearable drug delivery device 102 or may be an integrated component. The sensor 106 may provide physiological condition data indicative of the measured or detected blood glucose level of the user to the processor 114 and / or the processor 119. The information or data provided by the sensor 106 may be used to calculate summary data reports, statistical analyses, display results of the summary data reports and statistical analyses, and to be operable to calculate and implement adjustments to the drug delivery operation of the wearable drug delivery device 102.

[0049] In an embodiment, the controller 104 of the drug delivery system 100 may include a processor 119 and a memory 118. The controller 104 may be a dedicated device, such as a dedicated personal diabetes manager (PDM) device. The controller 104 may be a programmed general-purpose device, such as any portable electronic device, smartphone, smart watch, fitness device, tablet, etc., that includes a dedicated controller, such as a processor, microcontroller, etc. The controller 104 may be used to program or coordinate the operation of the wearable drug delivery device 102 and / or the sensor 106. The processor 119 may execute processes to manage the user's blood glucose levels and control the delivery of drugs or therapeutic agents from the wearable drug delivery device 102. The processor 119 may be operable to execute program code stored in the memory 118. For example, the memory 118 may be operable to store a control application 141, such as an AID algorithm, for execution by the processor 119. The control application 141 may be responsible for controlling the wearable drug delivery device 102, including the automatic delivery of insulin, based on recommendations and instructions from the AID algorithms, such as those described herein.

[0050] The memory 118 may store one or more control applications 141, settings 121 of the insulin delivery device 102, and historical data 139, as described above. The memory 118 may be operable to store other data and / or programs. In a first example, the historical data 139 may have data entries including an insulin output history, which may include at least basal insulin doses (i.e., the amount of insulin delivered in each of the basal insulin doses), the respective times of each of the basal insulin doses, bolus insulin doses (i.e., the amount of insulin delivered in each of the bolus insulin doses), and the respective times of each of the bolus insulin doses. In a second example, the history data 139 may have data entries including an insulin output history, which may include at least basal insulin doses (i.e., the amount of insulin delivered in each basal insulin dose), the respective times of each of the basal insulin doses, bolus insulin doses (i.e., the amount of insulin delivered in each bolus insulin dose), and the respective times of each of the bolus insulin doses and blood glucose measurements received from the analyte sensor 106 (and corresponding timestamps for each of the measurements).

[0051] The controller 104 may have a user interface (UI) 123 for communicating with a user. The user interface 123 may have a display, such as a touch screen, for displaying information. If the user interface 123 is a touch screen, the touch screen may be used to receive input. The user interface 123 may also have input elements, such as a keyboard, buttons, knobs, etc. In an operational example, the user interface 123 may have a touch screen display controllable by the processor 119 and operable to display a graphical user interface, and in response to the received input, the touch screen display is operable to generate a signal indicative of the subjective insulin need parameter. In an operational example, the user interface may be a touch screen display controllable by the processor and operable to display a graphical user interface. The touch screen display may be operable under the control of the processor 119 to generate a signal indicative of the subjective insulin need parameter, as described with reference to the previous example, in response to the received input.

[0052] The controller 104 may communicate with a network, such as a LAN or WAN or combination of such networks, that provides one or more servers or cloud-based services 161 via a communication device 142 via a wireless communication link 128. The communication device 142, which may have transceivers 127 and 125, may be coupled to the processor 119. The communication device 142 may be operable to transmit communication signals (e.g., command and control signals) to the wearable drug delivery device 102 and the analyte sensor 106 and to receive communication signals (e.g., via the transceiver 127 or 125). In one example, the communication device 142 may have a first transceiver, such as 125, which is a Bluetooth transceiver operable to communicate with the communication device 142 of the wearable drug delivery device 102, and a second transceiver, such as 127, which is a cellular or Wi-Fi transceiver operable to communicate with the computing device 132 or the cloud-based service 110 via the network 108.

[0053] The cloud-based service 161 may be operable to store user history information such as blood glucose measurements over a period of time (e.g., days, months, years), insulin delivery amounts (both basal and bolus doses), insulin delivery times, insulin type, prescribed meal times, trends or deviations in blood glucose measurements or other user-related diabetes treatment information, specific factor settings including default settings, current settings and past settings.

[0054] Other devices such as smart accessory devices 130 (e.g., smart watches, etc.), fitness devices 133, and other wearable devices 134 may be part of the drug delivery system 100. These devices may communicate with the wearable drug delivery device 102 to receive information and / or issue commands to the wearable drug delivery device 102. These devices 130, 133, and 134 may execute computer programming instructions to perform some of the control functions otherwise performed by the processor 114 or the processor 119. These devices 130, 133, and 134 may have a user interface such as a touch screen display for displaying information and / or receiving inputs such as current blood glucose levels, on-board insulin, insulin delivery history, or other parameters or treatment related information, as described with reference to the examples of Figs. 1-3. The display may be operable to display a graphical user interface providing inputs such as, for example, a request to change a basal insulin dose or a request to deliver a bolus of insulin. These devices 130, 133 and 134 may have a wireless communication connection with the sensor 106 to receive the blood glucose data directly or in parallel with the display of a graphical user interface such as that shown in FIG.

[0055] In another example of operation, the controller 104 may be operable to execute program code that causes the processor 119 of the controller 104 to perform the following functions: The processor 119 of the controller 104 may execute an AID algorithm that is one of the control applications 120 stored in the memory 112 or memory 118. The processor may be operable to provide a graphical user interface for displaying data as described with reference to the following examples.

[0056] In response to displaying the graphical user interface, when receiving input at the user interface 123, the processor 119 may be operable to display a medication summary page that includes different event pattern information windows, visual displays, and tables and / or information graphics that provide information in a visual format different from a list of values. The graphical user interfaces discussed herein provide information enhanced by data visualization techniques.

[0057] The processor 119 is also operable to collect physiological condition data related to the user from sensors such as the analyte sensor 106 or the heart rate monitor of the fitness device 133 or the smart accessory device 130. In one example, the processor 119 executing the AID algorithm may determine a dose of insulin to be delivered based on certain factors determined based on the collected physiological condition and subjective insulin need parameters of the user. The processor 119 may output a control signal to the wearable drug delivery device 102 via one of the transceivers 125 or 127. The output signal may cause the processor 114 to deliver a command signal to the pump 118 to deliver to the user an amount of insulin related to the determined dose of insulin in the reservoir 120 based on the output of the AID algorithm implemented by the control app 141. These signals related to the determined doses, etc. may be stored as historical data (129, 139) in the memory 112 and / or 118.

[0058] FIG. 1B illustrates an exemplary system flow diagram for obtaining and processing data used by the subject matter described herein.

[0059] The information environment 105 may include multiple components such as a system 170, a cloud-based service 190, a network 198, and user devices 192 and 194. The system 170 may include a data repository 175, a data extraction, conversion, and loading component 177, a data analysis processor 180, and a data storage / memory 186. The data repository 175 may be operable to store a continuous glucose monitoring / personal diabetes management device parquet file. The CGM / PDM parquet file may store all received CGM / PDM readings, AID algorithm settings including bolus / extended bolus doses, basal doses, patient history buffer (PHB) measurements, target glucose settings, etc., basal programs, and application site information.

[0060] The memory 186 may be operable to store the user's continuous blood glucose monitoring data and data from the user's personal diabetes management device. The data extraction, conversion and loading circuitry 177 may be operatively coupled to the memory 186 to normalize the data for evaluation and analysis by the data analysis processor 180. The data analysis processor 180 may include a combination of circuitry and software. The data analysis processor 180 may include pattern processing 181 and bolus determination 183. The pattern processing 181 may include processing circuitry and / or program code or instructions and, when executed by the processing circuitry, may be operable to identify patterns in the user's continuous blood glucose monitoring data and data from the user's personal diabetes management device.

[0061] The bolus determination 183 may be program code or instructions that, when executed by the processing circuitry, are operable to utilize data from the user's personal diabetes management device to further analyze the user's continuous glucose monitoring data to identify additional patterns associated with both the data from the user's personal diabetes management device and the user's continuous glucose monitoring data.

[0062] In a specific example, the pattern processing 181 and bolus determination 183 of the data analysis processor 180 may be implemented using a collection of databricks, such as a notebook, operable to generate high and low event patterns on a scheduled basis. The notebook may be, for example, a web-based interface to documents containing executable code, visualizations, and / or explanatory text. As an example, a separate notebook may be established for each of the data visualizations displayed in the graphical user interface, which will be further described with reference to Figs. 2A-10C. In a weekly summary, also called insight, the data visualization may be generated by reading data from last Sunday (start of the day) to the current Saturday (end of the day), and the generation is performed on a schedule, such as at 1:00 AM EST. A scheduler executed by the data visualization application may trigger different notebooks operable to generate generated display files 188, such as a high pattern file, a low pattern file, a time period file, and a bolus file.

[0063] The patterns may be used to identify events that may help the user better understand and implement a diabetes treatment plan. Based on the analysis performed by the data analysis processor 180, the identified patterns and events may be stored in the data storage / memory 186. For example, the data storage / memory 186 may include generated events, blood glucose measurements, basal delivery data and bolus delivery files, as well as generated display data 188 such as high pattern files, low pattern files, time period files and bolus files that may be displayed via a data visualization application on the user device.

[0064] Alternatively or additionally, memory 186 may be populated with generated display files 188 and generated events 187 residing on a storage device 191 coupled to a cloud based service 190. Messages regarding completion of display files 188 may be sent to the cloud based service 190, such as a messaging service of a cloud platform. With this arrangement, residing display files 188 and generated events 187 are available to downstream systems for processing and user consumption.

[0065] The data visualization application may be a computer application that enables the display data 188 and the generated events 187 to be displayed on a user device, such as a tablet device 192 or a smartphone 194. The smartphone 194 may include the components and functionality of the controller 104 of FIGURE 1, as described above. For example, the tablet device 192 may host an instance of the data visualization application 192A, and the smartphone 194 may host another instance of the data visualization application 194A.

[0066] Time Zone Pattern Algorithm

[0067] FIG. 2A illustrates a flow chart of an example of a data visualization algorithm for determining time-of-day patterns present in glucose blood measurements and insulin levels over a period of time in accordance with the subject matter described herein.

[0068] The algorithm shown in FIG. 2A may be referred to as a daily time pattern detection algorithm. The algorithm 200 is operable to find recurrent hyperglycemic or hypoglycemic patterns during a week (i.e., 168 hours). For example, in step 210, a processor executing a program code implementing the algorithm 200 may be operable to access blood glucose measurements and insulin data from a memory. In one example, the memory is operable to store at least one week of blood glucose measurements (and corresponding timestamps) and at least one week of doses of insulin output by the drug delivery device (and corresponding insulin output timestamps). The doses of insulin include both basal and bolus doses, as well as timestamps. For example, the processor may be operable to perform a data extraction operation by obtaining weekly blood glucose measurements and insulin data. The processor may also obtain a user's upper (i.e., high) target blood glucose set point (e.g., 180 mg / dL) and lower (i.e., low) target blood glucose set point (e.g., 70 mg / dL) from the memory, for example, from a user setting.

[0069] Additionally, the processor may execute a data preparation process to clean the data by considering blood glucose measurements between 39-401 mg / dL and prepare the date and time fields of the different rows. In the case of limited data visualization mode, blood glucose measurements (and associated data such as date, time, etc.) outside this range may also be considered only for the output chart, but not for the algorithm. In some examples of data, the date / time field and the UtcOffset field (e.g., the adjusted universal time offset for each of the time zones) are present in the historical data set retrieved from memory.

[0070] Additionally, historical data may only be considered if the time zone change frequency (i.e., how often the user changes time zones) is expected to be less than (<) 2 (i.e., occurring only once a week) and for changes that occur only once a week, the change is expected to be (<=) 1 hour or less. When evaluating blood glucose measurements, the algorithm 200 causes the processor to filter each high or low event, regardless of duration, that has a time zone change within a 2 hour (or 3 hour for post-bolus high / low) time slot before each high or low event and within a 1 hour time slot after each high or low event.

[0071] The algorithm 200 causes the processor to look for high and low events in the accessed blood glucose measurements of the historical data. For example, in step 220, the processor executing the algorithm 200 may be operable to identify blood glucose measurements above an upper target blood glucose set point as a high event and blood glucose measurements below a lower target blood glucose set point as a low event. The processor may be operable to obtain the user's upper and lower target blood glucose set points from user settings stored in memory.

[0072] More specifically, when identifying high and low events, the processor may determine the start and end times of the high and low events by identifying the logged blood glucose measurements from a data structure containing historical data and noting when each of the blood glucose measurements crossed a respective upper target blood glucose measurement set point and returned to a clinically normal range (e.g., 70-180 mg / dL, etc.). In the case of a low event, the processor may consider the blood glucose measurement to be at or above the low target blood glucose measurement set point when the next 3-6 consecutive measurements are greater than the low target blood glucose measurement set point, otherwise the processor may consider the user's blood glucose measurement to remain below the low target blood glucose measurement set point if the measurements fluctuate across the low target blood glucose measurement set point.

[0073] The identified events may be stored in memory and / or may reside in a cloud storage device such as 161 in FIG.

[0074] The identified high events may be identified in the previous week of historical data, and the processor evaluates the identified high events at 230 to determine any overlapping time between each of the respective identified high events and generate a corresponding high event pattern based on any overlapping time determined. For example, the algorithm 200 may apply a high event overlap rule set having high event criteria that define the extent of overlap in duration of overlapping time and number of days. Additionally, the algorithm 200 may apply a low event overlap rule set having low event criteria that define the extent of overlap in duration of overlapping time and number of days. The high event overlap rules may be different from the low event overlap rules. Examples of such high event overlap rules include evaluating high events that overlap (more than 30 minutes or less than 6 hours as a high event duration rule) over three days (i.e., number of overlapping days) and evaluating low events that overlap (more than 15 minutes or less than 6 hours as a low event duration rule) over two days (i.e., number of overlapping days). The events may cross day boundaries, such as Monday to Tuesday, Friday to Sunday, etc.

[0075] At 240, overlapping high events and overlapping low events are identified for analysis based on application of high event overlap rules set for high events and low event overlap rules set for low events. The analysis is performed in steps 250 and 260, in any order.

[0076] In step 250, the processor may identify high events that fall within a set high event overlap period and number of days as a high event pattern of overlapping high events.

[0077] For example, when identifying a high event pattern, the processor may calculate an average of the blood glucose measurements for all of the identified high events by summing the estimated blood glucose measurements during each of the high event durations and dividing the sum by the total number of identified high events in the window of time (the first time window and / or number of days) that encompasses each of the high event durations.

[0078] In step 260, the processor may identify those low events that fall within the set low event overlap period and number of days as a low event pattern of overlapping low events. Similarly, when identifying a low event pattern, the processor may calculate an average of the blood glucose measurements of all low events by summing the estimated blood glucose measurements during each of the low event durations and dividing the sum by the total number of low events in the window of time (second time window and / or number of days) that encompasses each of the low event durations. The first time window may be used to identify each of the low event patterns.

[0079] In one example, each of the high and low patterns may be identified through the following detailed steps.

[0080] 1) Upon identifying high and low events, the next step for the identified high event may be to load the existing high events (i.e., previously identified high events currently stored in memory and / or cloud storage) and find the overlapping time between them. Similarly, the processor loads the existing (i.e., previously identified) low events for the identified low event and finds the overlapping time between them by cross-joining the different events (i.e., the identified high event, the existing high events, the identified low event, and the existing low events) to find the intersecting time ranges.

[0081] 2) In response to finding the intersecting time ranges and establishing high-event and low-event patterns, calculate and update overlapping start and end times for each of the established patterns.

[0082] 3) After updating the start and end times for each of the patterns, remove events that do not fall within the 30 minute overlap and recalculate the overlap time based on the remaining events.

[0083] 4) In the purification process, patterns that have 30 minutes of overlap but only have a single event are removed as patterns since they no longer constitute a pattern.

[0084] 5) After purifying all patterns, if merging overlapping patterns still maintains the overlap time at 30 minutes, merge such patterns.

[0085] 6) The merged patterns may be evaluated for intersecting time ranges, and a reduceByKey or similar operation is performed by the processor to determine counts for these intersecting time ranges. Identified high event patterns require a count greater than 3, and identified low event patterns require a count greater than 2.

[0086] 7) After generating a table data structure using the identified high-event patterns and the identified low-event patterns, assign a pattern weight to each of the patterns, as described in more detail below.

[0087] The algorithm 200 may generate additional insights based on the remaining events for use in providing recommendations or suggestions, as described with reference to other examples.

[0088] At 270, the processor may apply a respective pattern weight to each identified high event and each identified low event based on the high event specific criteria and the low event specific criteria. The pattern weight may be coefficient A * overlap time + coefficient B * number of days a particular high event pattern or low event pattern is found, where coefficient A and coefficient B are in the range of 0.2-0.8, preferably in the range of 0.3-0.7, and optimally in the range of 0.4-0.6. An example of a pattern weight includes: pattern weight = 0.50 * overlap time +. 0.50 * number of days a particular high event pattern or low event pattern is found. The pattern weight for each high event pattern or low event pattern may be added to a column corresponding to each high event pattern or low event pattern. After adding the weight column to the different identified high event patterns and low event patterns, the table may be converted to a json file or the like and saved to a cloud storage platform.

[0089] At 280, the processor may generate a data visualization for display in a graphical user interface that includes at least three high event patterns and at least two low event patterns. Additionally, a cue message may be generated to notify downstream processes that algorithmic data is now available for consumption. Examples and discussion of improved data visualizations are provided with reference to subsequent figures.

[0090] FIG. 2B illustrates a flow chart of an example data visualization algorithm for determining post-bolus high and low events present in glucose blood measurements and insulin values ​​over a given period of time according to the subject matter described herein.

[0091] A post-bolus high / low algorithm 205 may be implemented based on the results provided by the algorithm 200, as described with reference to and shown in FIG. 2B. The algorithm 205 is operable to find high and low events that occur after a bolus event in a week. Each identified high or low event may have multiple boluses preceding it, as long as the boluses fall within the bolus identification window. The bolus identification window is around (event start time-30 minutes to event start time-3 hours).

[0092] Data will only be considered if the time zone change frequency is <2 (occurs no more than once a week) and for changes that occur no more than once a week it must be <=1 hour. The algorithm filters events with time zone changes within the event, a 2 hour event time slot before the event, and a 1 hour event time slot after the event (either high or low), regardless of event duration, or after a bolus event with an aggregate or 3 hour window to identify high / low events.

[0093] The processor may execute steps 210 to 260 or 270 before starting execution of the algorithm 205.

[0094] The processor when executing the algorithm 205 may apply a bolus event rule set to the identified overlapping high event patterns and the identified overlapping low event patterns at 255. The bolus event rule set may have criteria for the identified overlapping high event patterns and the identified overlapping low event patterns. For example, the processor may apply a rule to determine whether a bolus event preceding each of the identified high event patterns or low event patterns occurred during a defined time window, such as t-3 hours or tt-15 minutes, where t is the start time of the identified high event or the identified low event. The defined time window may be the same or different for the identified high event patterns or the identified low event patterns. For the identified high event patterns or the identified low event patterns, if it is determined that a bolus (either a correction, manual, automatic or extended bolus) occurred within the defined time window, the bolus corresponds to the identified high event pattern or the identified low event pattern.

[0095] At 265, the processor may be operable to identify for analysis a bolus event corresponding to each of the identified high events and each of the identified low events based on application of the bolus event rule set to each of the identified overlapping low events and each of the identified low events.

[0096] At 275, the processor may append the identified bolus event to the corresponding identified high event or the corresponding identified low event in the memory. The final bolus low pattern table and the bolus high pattern table may be converted to, for example, a json file and stored in a cloud storage platform. A queue message may be generated to notify a downstream process that the algorithm data is now available for consumption. The downstream process may be, for example, a back-end application programming interface (API) service that retrieves the generated file based on the message. The back-end API may process the file and store the file in a database. A web portal is operable to display data based on the information stored in the database.

[0097] The processor may generate 285 data visualizations for two or more low event patterns and three or more high events.

[0098] FIG. 3 illustrates an example of a graphical user interface displaying a user's time within blood glucose range as well as low and high event patterns as determined by a data visualization algorithm according to the subject matter described herein.

[0099] The graphical user interface 300 is a weekly summary of the number of days in range 310 for user Jane Smith. The days of the week are Sunday through Saturday and are represented using the first letter of each day (i.e., Sunday (S) - the first S, Monday is M, Tuesday is T, etc.). The summary 310 displays the user's hypoglycemia target set point (i.e., 70 mg / dL) and the user's hyperglycemia target set point (i.e., 180 mg / dL). Time in range is a time measurement that indicates how long the user's blood glucose stayed between the user's hypoglycemia target set point and the user's hyperglycemia target set point. The time in range is shown as a percentage of the 24-hour time period that makes up a day. The graphical user interface 300 shows the total "Days in Range" 311 that the user was in range, in this case 3. The weekly description 312 shows the percentage of time the user was within the hyperglycemia and hypoglycemia target set points on a particular day.

[0100] The weekly summary graphical user interface 300 also displays the identified low value patterns 320. The low value pattern details are shown under the heading "Low Events in Afternoon" 323. The low pattern details 321 indicate the time during the day of the week that the low pattern was identified, and the low pattern description 322 indicates which day the low pattern was found. The heading "Low Events in Afternoon" 323 and the low pattern details 321 may be one of four different time frames: morning (e.g., 5:00 AM - 12:00 PM), afternoon (e.g., 12:00 PM - 4:00 PM), evening (e.g., 4:00 PM - 10:00 PM), and night (e.g., 10:00 PM - 5:00 AM). In some examples, the time frame may be fixed to a default time frame listed. In other examples, the time frame may be set, such as in a user preference setting that is part of the application.

[0101] Under the low patterns heading 320, the graphical user interface 300 also displays post-bolus low event patterns 330. The post-bolus low event patterns 330 also include post-bolus low event details 331 that indicate the number of post-bolus low event patterns that occurred during the summary week. The post-bolus low event pattern description 332 indicates on which days the post-bolus low event patterns were found, in this case Monday (M) and Wednesday (W).

[0102] Beneath the high pattern heading 340 is an Evening High label 343. Beneath the Evening High label 343 are high pattern details 341 that are displayed in the summary graphical user interface 300. The high pattern details 341 may indicate, for example, the time window during which the high pattern was identified. In the illustrated example, the time window is "5:00 PM to 7:00 PM." Of course, the time window can have different times, such as 4:00 PM to 6:00 PM, 6:15 PM to 8:30 PM, etc. The high event pattern description 342 indicates on which days the high event pattern was discovered, in this case Tuesday (T), Thursday (2nd T), and Saturday (2nd S).

[0103] Also displayed in the summary graphical user interface 300 is a high event after bolus pattern 350. The high post bolus event pattern 350 also includes a high post bolus event detail 351 that indicates the number of high post bolus event patterns that occurred during the summary week. The high post bolus event pattern description 352 indicates on which days the low post bolus event pattern was found, in this case Sunday (first S), Tuesday (T) and Wednesday (W).

[0104] Of course, more or less information may be displayed in the weekly summary displayed in the graphical user interface 300. For example, "Afternoon Low Events" (323), "Post-Bolus Low Events" (330), "Evening High Events" (343), and "Post-Bolus High Events" (350) each have a "Show Details" soft button that may be selected to view more details about the respective event.

[0105] 4 shows an example of a graphical user interface displaying low and high event patterns and trends in blood glucose measurements. The low and high event patterns represent when blood glucose measurements according to the subject matter described herein were below a low target set point and above a high target set point.

[0106] The graphical user interface 400 is a weekly summary 410 of a user's glucose trend for the same week as displayed in the graphical user interface 300 of FIG. 3. The glucose trend summary 410 shows that the weekly trend is upward (represented by an up arrow) by, for example, 8%, which may be a percentage compared to the glucose measurements from the previous week. The glucose trend details 411 show the overall percentage of time during the summarized week that the user's blood glucose measurements were in range, which in this specific example is 75% of the blood glucose measurements taken during the summarized week. Additionally, the glucose trend summary 410 may include range lines identifying the percentage of blood glucose measurements collected during the summarized week that were below the low target blood glucose measurement set point (in this example, 9%) and the percentage of blood glucose measurements taken during the summarized week that were above the high target blood glucose measurement set point (in this example, 16%). In this example, the low target blood glucose measurement set point is 70 mg / dL and the high target blood glucose measurement set point is 180 mg / dL. Of course, these values ​​may be altered depending on each user's preferences and diabetes treatment plan.

[0107] Graphical user interface 400 shows low pattern 420 and high pattern 440 below glucose trend summary 410. Low pattern 420 includes afternoon low event 421 and low event after bolus 430 that are identical to those described with reference to afternoon low event 323 and low event after bolus 330 in Figure 3. Similarly, high pattern 440 includes evening high event 441 and high event after bolus 450 that are identical to those described with reference to evening high event 343 and high event after bolus 350 in Figure 3. Accordingly, a detailed description of these items will not be presented with respect to Figure 4.

[0108] Of course, more or less information may be displayed in the weekly summary displayed in the graphical user interface 400. For example, under or around each of the "Afternoon Low Events" (421), "Low Post-Bolus Events" (430), "Evening High Events" (441), and "High Post-Bolus Events" (450) are "Show Details" soft buttons such as 445 that can be selected to view more details about the respective event.

[0109] FIG. 5A illustrates an example of a graphical user interface that displays information related to multiple high event patterns occurring in the evening along with recommendations according to the subject matter described herein.

[0110] To access information in the recommendation related to multiple high event patterns that occurred in the evening, the user may select the "View Details" button 344 under the high event pattern description 342 of Evening High Events 343 or the "View Details" button 444 under the high event pattern description of Evening High Events 441 in FIG. 3. In response to the selection, details of the multiple high event patterns (e.g., "Evening High Events") are displayed in the graphical user interface 500. The graphical user interface 500 displays details of each of the three high event patterns 545 in respective high event windows 547, 548, 549. Although the number 3 is shown for the number of high event patterns 545, the number shown may be greater than three if the number of identified high event patterns is greater and / or based on user settings (i.e., three is the minimum default, but the user can set the number of high events displayed to greater than three). High event window 547 shows details of the Tuesday high event pattern, high event window 548 shows details of the Thursday high event pattern, and high event window 549 shows details of the Saturday high event pattern. In an embodiment, the details of each of the high event windows 547-549 may include the highest blood glucose reading obtained during the high event, the duration of the high event, such as 30 minutes, 45 minutes, 1 hour, etc., and a user interface operator such as 588 that allows for viewing of further details regarding the particular high event pattern.

[0111] Additionally, the graphical user interface 500 displays recommendations or "factors to consider" 546 based on each high event pattern. The recommendations 546 may be based on the highest blood glucose reading obtained during the high event, the duration of the high event, and / or other information.

[0112] FIG. 5B illustrates an example of a graphical user interface displaying details of a particular hyperglycemic event in accordance with the subject matter described herein.

[0113] In response to selection of the user interface operator 588 of FIG. 5A or selection of a "Show Details" soft button such as that associated with an evening high event such as 441 of FIG. 4, a graphical user interface 501 of FIG. 5B may be displayed to display details of the evening high event. In the example graphical user interface 501, a "Highest Evening Events" heading 510 may be displayed. Under the "Highest Evening Events" heading 510 may be displayed a time window 512 and high event dates 514 of the high events that met the criteria for a high event for this particular user. The graphical user interface 501 may include the highest blood glucose reading measured during the high event time window 512 and the duration 521 of that highest blood glucose reading.

[0114] Also displayed on the graphical user interface 501 is a glucose time axis 530. The glucose time axis 530 is a graphic having a curve 533 that indicates the user's blood glucose readings over a time axis 537 from approximately 2:30 PM to just after 7 PM, such as approximately 7:05 PM in this example. The glucose time axis 530 has boundaries that represent a high blood glucose target set point boundary 532 (in this example, 180 mg / dL) and a low blood glucose target set point boundary 535 (in this example, 70 mg / dL), and a bolus indicator 531. The bolus indicator 531 also includes a label that indicates the number of units of insulin delivered. In this example, the bolus indicator 531 indicates that a bolus of 3.5 units (U) was delivered from approximately 4:30 PM to 4:40 PM. The graphical user interface 501 also includes a color-coded time axis mode indicator 541 that indicates the mode of the drug delivery system during the time axis 537. The modes are color coded, but explanations may be displayed by selecting the "Show Explanations" soft button 540.

[0115] Figure 5C shows an example of the graphical user interface of Figure 5B with an illustration showing the modes of a drug delivery device and insulin usage according to the subject matter described herein. The graphical user interface 502 of Figure 5C includes elements from the graphical user interface 501 of Figure 5B that function similarly as described with reference to Figure 5B, and therefore a detailed discussion of those elements will not be repeated.

[0116] In response to selection of the "Show Description" soft button 540, the graphical user interface 502 may display a description 545 beneath a soft button 540A displaying "Hide Description." The description 545 may indicate different modes, such as automated mode 547 and automated mode only 548, which may be color coded. Additionally or alternatively, the description 545 may indicate when a threshold (both positive and negative) has been reached or exceeded, such as in the case of "Insulin Max Reached (Automated)" 549.

[0117] The automated mode limit 548 is a color coded label that spans the color coded timeline mode indicator 541 of FIG. 5B between approximately 3:45 PM and 4:15 PM. In one embodiment, the data visualization algorithm described with reference to other embodiments may be operable to identify when blood glucose measurements are missing during a period such as gap 536. As described above with reference to FIG. 1, blood glucose measurements may be received from a continuous blood glucose monitor (CGM) at different time intervals during operation of the wearable drug delivery device. For example, some CGMs may output a signal including a blood glucose measurement every 5 minutes or less, e.g., every minute. There are various reasons why the data visualization application may not display a blood glucose measurement at a particular time. For example, the CGM may not be able to output a signal due to a bad reading or loss of connectivity, the controller may not be able to receive a signal from the CGM due to interference or is out of range, the signal is corrupted due to interference, etc. Also, the data visualization application (shown and described with other embodiments) may receive a subsequent blood glucose measurement that is much higher or lower than the immediately preceding blood glucose measurement, which is considered an outlier and not used. Whatever the reason a blood glucose reading was not received or used at the expected time, the data visualization algorithm is operable to show the missing blood glucose reading as a gap 536 in the curve 533 and also to indicate on the color coded timeline that the AID algorithm has entered automated only mode.

[0118] FIG. 5D illustrates an example of the graphical user interface of FIG. 5B with a pop-up window showing bolus delivery time, bolus amount, and estimated carbohydrates in accordance with the subject matter described herein.

[0119] The graphical user interface 503 includes a bolus indicator 531 having a label indicating the number of units of insulin delivered (i.e., 3.5 U) between approximately 4:30 PM and 4:40 PM. In response to selection of the bolus indicator 531, a pop-up window 534 may be displayed indicating the time the bolus was delivered (e.g., approximately 4:30 PM), the number of carbohydrates provided to the AID algorithm's bolus calculator (e.g., 25 U), and the amount of total bolus dose delivered to offset the carbohydrates (e.g., 3.5 U). The pop-up window 534 may display for a predetermined period of time (e.g., 30 seconds, 1 minute, 3 minutes, etc.). Alternatively or additionally, the pop-up window 534 may be displayed until an interaction is made by the graphical user interface 503 following selection of the bolus indicator 531.

[0120] FIG. 6A illustrates an example of a graphical user interface displaying information related to multiple low event patterns occurring in the afternoon along with recommendations according to the subject matter described herein.

[0121] To access information in the advisory related to multiple high event patterns that occurred in the evening, the user may select the "Show Details" button 324 in FIG. 3 or 424 in FIG. 4 under the description of the afternoon low event pattern heading. In response to the selection, details of multiple low event patterns are displayed in the graphical user interface 600. The graphical user interface 600 displays details of two low event patterns under a low event header 645. The number 2 is shown, but the number shown may be more than two if there are more low event patterns and / or based on user settings (i.e., 2 is the minimum default, but the user can set the number of low events to display to be more than 2). Each of the low event patterns has a low event window 647 and 648, respectively. The low event window 647 shows details of the low event patterns for Monday, and the low event window 648 shows details of the low event patterns for Wednesday. As shown, the details of each of the high event windows 647 and 648 may include the lowest blood glucose reading obtained during the low event, the duration of the low event, such as 20 minutes, 30 minutes, 45 minutes, 1 hour, etc., and an operator such as 688 that allows for viewing of further details regarding the particular low event pattern. Additionally, the graphical user interface 600 displays recommendations or "factors to consider" 646 based on each of the high event patterns. The recommendations 646 may be based on the lowest blood glucose reading obtained during the low event, the duration of the low event, and / or other information.

[0122] FIG. 6B illustrates an example of a graphical user interface for displaying a particular hypoglycemic event in accordance with the subject matter described herein.

[0123] In response to selection of the user interface operator 688 of Figure 6A or selection of a "Show Details" soft button associated with an PM low event, such as 324 of Figure 3 or 424 of Figure 4, a graphical user interface 601 of Figure 6B may be displayed to display details of the PM low event. In the exemplary graphical user interface 601, an "PM Low Event" heading 610 may be displayed. Under the "PM Low Event" heading 610, a time window 612 of the low event and a low event date 614 may be displayed. The graphical user interface 601 may include the lowest blood glucose reading measured during the time window 612 of the low event and the duration 621 of that lowest blood glucose reading.

[0124] Also displayed on the graphical user interface 601 is a glucose time axis 630. The glucose time axis 630 is a graphic having a curve 633 showing the user's blood glucose readings over a time axis 637 from approximately 2:30 PM to just after 7 PM, such as approximately 7:05 PM in this example. The glucose time axis 630 has boundaries representing a high target blood glucose set point boundary 632 (180 mg / dL in this example) and a low target blood glucose set point boundary 635 (70 mg / dL in this example), and a bolus indicator 631. The curve 633 shows a red colored segment that extends below the low target blood glucose set point boundary 635. The red coloring indicates that the user's blood glucose readings were in a hypoglycemic range below the user's low target blood glucose set point boundary 635. The bolus indicator 631 includes a label indicating the number of units of insulin delivered. In an embodiment, the bolus indicator 631 indicates that a bolus of 3.5 units (U) was delivered between approximately 1:15 and 1:30 PM. The graphical user interface 601 also includes a color coded timeline mode indicator 61 that indicates the mode of the drug delivery system during the timeline 637. Although the modes are color coded, explanations may be displayed by selection of a "Show Explanation" soft button 640.

[0125] Figure 6C shows an example of the graphical user interface of Figure 6B with an illustration showing drug delivery device modes and insulin usage of a drug delivery device according to the subject matter described herein. The graphical user interface 602 of Figure 6C includes elements from the graphical user interface 601 of Figure 6B that function similarly as described with reference to Figure 6B, and therefore a detailed discussion of those elements will not be repeated.

[0126] In response to selection of the "View Description" soft button 640, the graphical user interface 602 may display a description 645 beneath a soft button 640A displaying "Hide Description." The description 645 may indicate different modes, which are color coded, such as Automated Mode 647, Automated Only Mode 648, and Insulin Pause (Automated) Mode 649. Additionally or alternatively, the description 645 may indicate when thresholds (both positive and negative thresholds) have been reached or exceeded, such as in the case of "Insulin Pause (Automated)" 649.

[0127] The automated mode limit 648 is a color coded label that spans the color coded timeline mode indicator 641 of FIG. 6B from about 12:45 to 13:15. In an embodiment, the data visualization algorithm described with reference to other embodiments may be operable to identify when blood glucose measurements are missing during a time period such as gap 636. As described above with reference to FIG. 1, blood glucose measurements may be received from a continuous blood glucose monitor (CGM) at different time intervals during operation of the wearable drug delivery device. For example, some CGMs may output a signal including a blood glucose measurement every 5 minutes or less, e.g., every minute. There are various reasons why the data visualization application may not display a blood glucose measurement at a particular time. For example, the CGM may not be able to output a signal due to a bad reading or loss of connectivity, the controller may not be able to receive a signal from the CGM due to interference or is out of range, the signal is corrupted due to interference, etc. Also, the data visualization application (shown and described with other embodiments) may receive a subsequent blood glucose measurement that is much higher or lower than the immediately preceding blood glucose measurement, which is considered an outlier and not used. Whatever the reason a blood glucose reading was not received or used at the expected time, the data visualization algorithm is operable to show the missing blood glucose reading as a gap 636 in the curve 633 and to indicate on a color coded timeline that the AID algorithm has entered automated only mode.

[0128] FIG. 6D illustrates an example of the graphical user interface of FIG. 6B with a pop-up window showing bolus delivery time, bolus amount, and estimated carbohydrates in accordance with the subject matter described herein.

[0129] The graphical user interface 603 includes a bolus indicator 631 having a label indicating the number of units of insulin delivered (i.e., 3.5 U) from approximately 1:15 to 1:30 PM. In response to selection of the bolus indicator 631, a pop-up window 634 may be displayed indicating the time the bolus was delivered (e.g., 1:22 PM), the number of carbohydrates provided to the AID algorithm's bolus calculator (e.g., 25 U), and the amount of the total bolus dose delivered to offset the carbohydrates (e.g., 3.5 U). The pop-up window 634 may be displayed for a predetermined period of time (e.g., 30 seconds, 1 minute, 3 minutes, etc.). Alternatively or additionally, the pop-up window 634 may be displayed until an interaction is made by the graphical user interface 603 following selection of the bolus indicator 631.

[0130] FIG. 7A illustrates an example of a graphical user interface displaying post-bolus high events in accordance with the subject matter described herein.

[0131] The graphical user interface 700 may display information related to a high event after the user administered a bolus, called a "Post-bolus High Event." The graphical user interface 700 may display a post-bolus high event duration 702, which in this example shows a start time of the post-bolus high event at 6:10 PM, an end time of the post-bolus high event at 6:40 PM, and a date 704 on which the post-bolus high event occurred. Bolus details 705 include information about the bolus, such as the time the bolus was delivered (e.g., 6 PM), the number of grams of carbohydrates (carbs) provided to the AID algorithm's bolus calculator (e.g., 45 grams), the most recent blood glucose reading (e.g., "144 mg / dL"), and the total number of units the bolus delivered (e.g., 3.5 U). A high event bolus delay indicator 706 indicates the amount of time after the bolus that the post-bolus high event occurred (in this case, 10 minutes). The high event details indicator 707 shows details of the post-bolus high event such as the start time of the post-bolus high event (i.e., 6:10 pm), the highest blood glucose reading during the high event (e.g., 280 mg / dL), and the duration of the post-bolus high event (e.g., 30 minutes).

[0132] Also depicted in the graphical user interface 700 is a glucose time axis 730. The glucose time axis 730 is a graphic having a curve 733 that indicates the user's blood glucose readings over a time axis 737 from approximately 2:30 PM to a short time after 7 PM, such as approximately 7:05 PM in this example. The glucose time axis 730 has boundaries that represent a high blood glucose target set point boundary 732 (in this example, 180 mg / dL) and a low blood glucose target set point boundary 735 (in this example, 70 mg / dL), and a bolus indicator 731. The bolus indicator 731 includes a label that indicates the number of units of insulin delivered. In this example, the bolus indicator 731 indicates that a bolus of 3.5 units (U) was delivered at approximately 6 PM. The graphical user interface 700 also includes a color-coded time axis mode indicator 741 that indicates the mode of the drug delivery system during the time axis 737. The modes of the color coded timeline mode indicator 741 are color coded with a description displayed below the indicator 741.

[0133] FIG. 7B illustrates an example of the graphical user interface of FIG. 7A with descriptions showing drug delivery device modes and insulin usage for a drug delivery device according to the subject matter described herein.

[0134] Graphical user interface 701 of FIG. 7B includes elements from graphical user interface 700 of FIG. 7A that function similarly as described with reference to FIG. 7B, and therefore a detailed description of those elements will not be repeated.

[0135] In response to selection of the "View Description" soft button 740, the graphical user interface 701 may display a description 745 beneath a soft button 740A displaying "Hide Description." The description 745 may indicate different modes, such as automated mode 747 and automated mode only 748, which may be color coded. Additionally or alternatively, the description 745 may indicate when a threshold (both positive and negative) has been reached or exceeded, such as in the case of "Insulin Max Reached (Automated)" 749.

[0136] The automated mode limit 748 is a color coded label that spans the color coded timeline mode indicator 741 of FIG. 7A between approximately 3:45 PM and 4:15 PM. In one embodiment, the data visualization algorithm described with reference to other embodiments may be operable to identify when blood glucose measurements are missing during a period of time, such as gap 736. As described above with reference to FIG. 1, blood glucose measurements may be received from a continuous blood glucose monitor (CGM) at different time intervals during operation of the wearable drug delivery device. For example, some CGMs may output a signal including a blood glucose measurement every 5 minutes or less, e.g., every minute. There are various reasons why the data visualization application may not display a blood glucose measurement at a particular time. For example, the CGM may not be able to output a signal due to a bad reading or loss of connectivity, the controller may not be able to receive a signal from the CGM due to interference or is out of range, the signal is corrupted due to interference, etc. Also, the data visualization application (shown and described with other embodiments) may receive a subsequent blood glucose measurement that is much higher or lower than the immediately preceding blood glucose measurement, which is considered an outlier and not used. Whatever the reason for not receiving or using a blood glucose reading at the expected time, the data visualization algorithm is operable to indicate the missed blood glucose reading as a gap 736 in the curve 733 and also to indicate on the color coded timeline that the AID algorithm has entered automated only mode.

[0137] FIG. 7C illustrates an example of the graphical user interface of FIG. 7A with a pop-up window showing bolus delivery time, bolus amount, and estimated carbohydrates in accordance with the subject matter described herein.

[0138] The graphical user interface 703 includes a bolus indicator 731 having a label indicating the number of units of insulin delivered (i.e., 3.5 U) from approximately 4:30 to 4:40 PM. In response to selection of the bolus indicator 731, a pop-up window 534 may be displayed indicating the time the bolus was delivered (e.g., 1:22 PM), the number of carbohydrates (e.g., 25 U), and the amount of the total bolus dose (e.g., 3.5 U) delivered to offset the carbohydrates. The pop-up window 734 may be displayed for a predetermined period of time (e.g., 30 seconds, 1 minute, 3 minutes, etc.). Additionally or alternatively, the pop-up window 534 may be displayed until an interaction with the graphical user interface 703 occurs following selection of the bolus indicator 731.

[0139] FIG. 8A illustrates an example of a graphical user interface displaying low post-bolus events in accordance with the subject matter described herein.

[0140] The graphical user interface 800 may display information related to a low event after the user administered a bolus, called a "Post-bolus Low Event." The graphical user interface 800 may display a duration 802 of the post-bolus low event, which in this example shows a start time of the post-bolus low event at 3:35 PM, an end time of the post-bolus low event at 4:10 PM, and a date 804 when the post-bolus high event occurred. The bolus details 805 include information about the bolus, such as the time the bolus was delivered (e.g., 3:15 PM), the number of grams of carbohydrates (carbs) provided to the AID algorithm's bolus calculator (e.g., 45 grams), the most recent blood glucose reading (e.g., "110 mg / dL"), and the total number of units the bolus delivered (e.g., 3.5 U). The low event bolus delay indicator 806 indicates the amount of time after the bolus that the post-bolus low event occurred (in this case, 20 minutes). The low event details indicator 807 shows details of the post-bolus high event such as the start time of the post-bolus high event (i.e., 3:35 pm), the highest blood glucose reading during the high event (e.g., 110 mg / dL), and the duration of the post-bolus high event (e.g., 30 minutes).

[0141] Also displayed in the graphical user interface 800 is a glucose time axis 830. The glucose time axis 830 is a graphic having a curve 833 showing the user's blood glucose readings over a time axis 837 from approximately 12:30 PM to a short time after 5 PM, such as approximately 5:05:05 PM in this example. The glucose time axis 830 has boundaries representing a high target blood glucose set point boundary 832 (180 mg / dL in this example) and a low target blood glucose set point boundary 835 (70 mg / dL in this example), and a bolus indicator 831. The bolus indicator 831 includes a label indicating the number of units of insulin delivered. In this example, the bolus indicator 831 indicates that a bolus of 3.5 units (U) was delivered at approximately 3:15 PM. The graphical user interface 800 also includes a color-coded time axis mode indicator 841 indicating the mode of the drug delivery system during the time axis 837. The modes of the color coded timeline mode indicator 841 are color coded with a description displayed below the indicator 841.

[0142] FIG. 8B illustrates an example of the graphical user interface of FIG. 8A with descriptions showing drug delivery device modes and insulin usage for a drug delivery device according to the subject matter described herein.

[0143] Graphical user interface 801 of FIG. 8B includes elements from graphical user interface 800 of FIG. 8A that function similarly as described with reference to FIG. 8B, and therefore a detailed description of those elements will not be repeated.

[0144] In response to selection of the "View Description" soft button 840, the graphical user interface 801 may display a description 845 beneath a soft button 840A displaying "Hide Description." The description 845 may display different modes, such as automated mode 847 and automated mode only 848, which may be color coded. Additionally or alternatively, the description 845 may indicate when thresholds (both positive and negative) have been reached or exceeded, such as in the case of "Insulin Suspend (Automated)" 849.

[0145] Automated mode only 848 is a color coded label that spans the color coded timeline mode indicator 841 of FIG. 7A between approximately 1:45 PM and 2:15 PM. In one embodiment, the data visualization algorithm described with reference to other embodiments may be operable to identify when blood glucose readings are missing during a period of time such as gap 836. As discussed above with other embodiments showing gaps in blood glucose readings, the data visualization algorithm may be operable to show the missing blood glucose readings as gap 836 in curve 833 and also to indicate on the color coded timeline that the AID algorithm has entered automated mode only mode.

[0146] FIG. 8C illustrates an example of the graphical user interface of FIG. 8A with a pop-up window showing bolus delivery time, bolus amount, and estimated carbohydrates in accordance with the subject matter described herein.

[0147] The graphical user interface 803 includes a bolus indicator 831 having a label indicating the number of units of insulin delivered at 3:15 PM (i.e., 3.5 U). In response to selection of the bolus indicator 831, a pop-up window 834 may be displayed indicating the time the bolus was delivered (e.g., 1:22 PM), the number of carbohydrates (e.g., 25 U), and the amount of the total bolus dose delivered to offset the carbohydrates (e.g., 3.5 U). The pop-up window 834 may be displayed for a predetermined period of time (e.g., 30 seconds, 1 minute, 3 minutes, etc.). Alternatively or additionally, the pop-up window 834 may be displayed until an interaction with the graphical user interface 803 occurs following selection of the bolus indicator 831.

[0148] The graphical user interface 803 with the at least three high event patterns and at least two low event patterns entered may be replaced by a weekly summary graphical user interface that is displayed on the user device.

[0149] FIG. 9A illustrates an example of a graphical user interface that provides a daily summary over a period of time in accordance with the subject matter described herein.

[0150] The graphical user interface 900A may be a comprehensive summary of the user's diabetes treatment program, carbohydrate intake and blood glucose measurements over a period of time. Descriptions 902 indicate what each symbol indicates for each of the information for each day. The period may be 14 days, and each day of the period is displayed in a window that displays a timeline 904 of the user's blood glucose measurements and a timeline 906 of the user's diabetes treatment program, carbohydrate intake and mode. The timeline 906 of the user's diabetes treatment program, carbohydrate intake and mode may have a hierarchy of time-aligned information such as bolus doses, carbohydrate intake and operating mode of the drug delivery device during basal delivery. The graphical user interface 900A may display a total 908 of the total amount of insulin delivered by bolus (i.e., 29.8U), carbohydrates taken during the day (i.e., 215g) and the amount of drug delivered by basal delivery (i.e., 25.5U). The drug delivery device may have various operating modes, and the controller may set limits for drug delivery based on the user's blood glucose measurements, bolus delivered and carbohydrate information. The time axis 906 may display the respective operating modes and set limit values ​​of the drug delivery device during basal delivery in a color-coded format for more intuitive interpretation in accordance with principles of data visualization.

[0151] Note that the above information is provided when data is available. As shown for Tuesday's entry, a no data indicator 910 is displayed. An example of when data is not available is when the user's device (i.e., controller, wearable drug delivery device, or CGM) cannot connect to a network, etc.

[0152] Additionally, as discussed above, when there is a time zone change indicated by time zone indicator 912, the data visualization may be operable to decline to calculate whether a high or low event occurred and may indicate a gap 914 when the time zone change occurred. Thus, the data visualization in each timeline 906 for a particular day may have limited information, as indicated by 916, in each operational mode portion of the timeline.

[0153] FIG. 9B illustrates an example detailed graphical user interface display of an example day with explanations from the example daily summary graphical user interface of FIG. 9A in accordance with the subject matter described herein.

[0154] View 990 shows a day in the graphical user interface 900, which in this example is Monday. With reference to description 902, the different hierarchies of the timeline 906 (e.g., the user's diabetes treatment program, carbohydrate intake, and operating modes) are explained in more detail. First in time is an indication 921 that the drug delivery device has been changed. During the change, no blood glucose measurements were received or recorded, as indicated by the gap 922 in the glucose timeline 904. Next, an insulin delivery indication 931 provides an indication to the user that the maximum amount of insulin has been delivered, which also corresponds to a 1 U bolus at the same time. Next, an insulin delivery indication 933 indicates that the AID algorithm has paused insulin delivery for a period following the delivery of the bolus and consumption of the meal. The operating mode hierarchy of the timeline 906 indicates that the controller has implemented a manual mode (M), which corresponds to an extended bolus 945. The extended bolus dose is shown as 4 units.

[0155] Other summary pages may also be displayed. Figure 10A shows an example of a graphical user interface that provides a weekly summary based on time in range. The graphical user interface 1001 displays a horizontal time axis 1010 that provides a color-coded indication of the percentage of time the user stayed within the range of the hypoglycemia and hyperglycemia target sets (70-180 mg / dL in this example). If the user is within the range of the hypoglycemia and hyperglycemia target sets, this percentage of the summarized time (14 days in this example) is displayed in green.

[0156] Bars 1020 provide a quick reference indicating the hypoglycemic range (ie, 2%), in range (eg, 73%), and hyperglycemic range (eg, 25%).

[0157] The bolus bar 1030 of the graphical user interface 1000 shows the average bolus dose during four time periods: overnight (e.g., 2.75 U), morning (e.g., 10.4 U), afternoon (e.g., 7 U) and evening (e.g., 4.75 U), as well as additional information as described with reference to other figures.

[0158] Also displayed on the graphical user interface 1000 is a setting bar 1040. The setting bar 1040 shows the average settings for the time period in three setting categories: target glucose, correction factor, and insulin to carbohydrate (carb) ratio. The setting bar 1040 shows the time for which the settings for each of the target glucose, correction factor, and insulin to carbohydrate (carb) ratio are made. For example, the target glucose setting from 12:00 AM to about 5:00 AM is 120 mg / dL, the target glucose setting from about 5:00 AM to about 8:00 PM is 110 mg / dL, and the target glucose setting from about 8:00 PM to 12:00 PM is 120 mg / dL. Of course, other time ranges may be set. For example, the night range may be 9:00 PM to 6:00 AM, the morning range may be 6:00 AM to 2:00 PM, and the afternoon / evening range may be 2:00 PM to 9:00 PM. Additionally or alternatively, the target glucose setting, the correction factor setting, and / or the insulin setting for carbohydrate (carb) may be set to different values ​​or ranges of values. A correction factor, such as an insulin to carbohydrate ratio, is a ratio and is expressed in time segments in the same manner as the glucose target, as shown in FIG. 10A.

[0159] The graphical user interface 1000 also displays an insulin summary 1050, which provides delivered insulin information such as total daily dose (e.g., 48.1 U), broken down into units of insulin delivered by basal (e.g., 23.2 U) and units of insulin delivered by bolus (e.g., 24.9 U). Detailed information related to basal delivery is displayed such as the percentage of time the drug delivery device was controlled via automated mode, the percentage of time insulin delivery was reduced in anticipation of activity by the user, or the percentage of time limited mode was activated due to unavailable CGM data. Bolus delivery also has detailed information displayed such as the reason category for initiating bolus delivery, such as meal only, correction only, meal and correction, manual mode delivery.

[0160] FIG. 10B illustrates an example detailed graphical user interface display of a range of week hours from the example weekly summary graphical user interface of FIG. 10A in accordance with the subject matter described herein.

[0161] In view 1001 of graphical user interface 1000, horizontal time axis 1010 shows the percentage of time the user is in a low event (e.g., within a range of blood glucose measurements equal to between 54-69 mg / dL) in a lighter shade of red and another percentage of time the user is in a significant low event (e.g., below 54 mg / dL) in a darker shade of red. The user's high events are also displayed as percentages and color coded on horizontal time axis 1010. For example, when the user's blood glucose measurement is greater than the high blood glucose target set value, horizontal time axis 1010 displays a color coded percentage of when the blood glucose measurement is between 181-25-mg / dL, in this example, 20%. Horizontal time axis 1010 also displays when the blood glucose measurement is very high (i.e., greater than 250%). Horizontal time axis 1010 shows the user the color coded percentage of the user's blood glucose readings over the course of a summarized period. For example, the longer a particular portion of the color-coded horizontal time axis 1010 is, the greater the percentage of time the user spent in that particular range of the blood glucose spectrum (eg, 54 mg / dL - 250 mg / dL).

[0162] In addition to the bars 1020 providing a quick reference indicating the hypoglycemic range (i.e., 2%), in range (e.g., 73%), and hyperglycemic range (e.g., 25%), the bars 1020 also provide a percentage target for each range and the amount of time for each range to provide an indication of compliance with the user's diabetes treatment plan. The percentage target for each range is adjustable based on the user's diabetes treatment plan.

[0163] The view 1001 may provide additional information 1025 under the heading "Glucose Readings" to display information 1025 related to the user's blood glucose readings for the summarized time period, such as average glucose reading (and goal), glucose management index (GMI) (and goal), glucose variability (CV*) (and goal) and standard deviation.

[0164] Additional information 1025 of view 1001 may provide information related to the user's drug delivery device and CGM under the heading "Device Usage." For example, specific device model names may be listed, such as delivery device X (for drug delivery device) and sensor Y (for CGM). Summarized period statistics such as active pump time, CGM time connected, and average drug delivery device wear time may also be displayed.

[0165] FIG. 10C illustrates an example detailed graphical user interface view of the weekly bolus and insulin summary from the example weekly summary graphical user interface of FIG. 10A in accordance with the subject matter described herein.

[0166] Also shown are the amount of insulin delivered per bolus per day for each of the nighttime (e.g., average 0.2 times / day), morning (e.g., average 1.2 times / day), afternoon (e.g., average 2 times / day) and overnight (e.g., average 2 times / day).

[0167] The setting bar 1040 indicates the time for which the respective settings of the target glucose, correction factor and insulin to carbohydrate ratio are set. For example, the target glucose setting from 12:00 AM to about 5:00 AM is 120 mg / dL, the target glucose setting from about 5:00 AM to about 8:00 PM is 110 mg / dL, and the target glucose setting from about 8:00 PM to 12:00 PM is 120 mg / dL. Of course, other time ranges may be set. For example, the night range may be 9:00 PM to 6:00 AM, the morning range may be 6:00 AM to 2:00 PM, and the afternoon / evening range may be 2:00 PM to 9:00 PM. Additionally or alternatively, the target glucose settings may be set to different values ​​or ranges of values. For example, instead of 110 mg / dL or 120 mg / dL, the target glucose setting may be 105-115 mg / dL, 110-120 mg / dL, 100-120 mg / dL, etc. A correction factor, such as the insulin / carb ratio, is a ratio and is expressed in time segments, similar to the target glucose, as shown in FIG. 10A.

[0168] The insulin summary 1050 provides detailed insulin information related to the delivery of insulin to the user. The insulin summary 1050 display is a tree hierarchy of statistical day insulin delivery from total average insulin delivered each day and breakdown into basal / bolus splits. Part of the insulin summary 1050 includes information regarding basal delivery (i.e., basal breakdown), for example. Basal delivery information is displayed as the percentage of time the drug delivery device was controlled via automated mode, the percentage of time insulin delivery was reduced in anticipation of activity by the user, or the percentage of time limited mode was engaged because CGM data was not available. A basal breakdown of the average basal units delivered and the supported percentage of pump modes (e.g., automatic, hypoprotect (as a function), limited and manual delivery) may also be displayed.

[0169] The insulin summary 1050 also displays detailed information related to the bolus delivery (e.g., bolus breakdown), including reason categories that indicate what event initiated the bolus delivery, such as delivery of a bolus to address consumption of a meal only, a correction bolus to bring the user's blood glucose level back within range, a combination of a meal and correction, and a manual mode delivery. The bolus breakdown includes the average bolus delivery amount and a breakdown of the bolus type (e.g., meal, override, meal and correction, and manual).

[0170] Although insulin is often referred to in the above discussion as the therapeutic or liquid drug delivered by the wearable drug delivery device, insulin may be replaced by other drugs similar to insulin, combinations of drugs, or other drugs for other purposes, such as, for example, pharmaceutical and chemotherapy drugs which may include glucagon or glucagon-like peptides, pain medications such as opioids and narcotics, fertility medications and other drugs requiring careful monitoring and delivery.

[0171] 11-24 are diagrams illustrating decorative features of a graphical user interface. FIGS. 11-24 provide views of decorative features of a graphical user interface. For example, the exemplary graphical user interface depicted in FIG. 11 may display a summary of days in range. FIG. 12 illustrates a graphical user interface that may display headings for "Low Pattern" and "Afternoon Low Event." FIG. 13 illustrates a graphical user interface that may display headings for "High Pattern," "Evening High Event," and "Post-Bolus High Event." FIG. 14 illustrates a graphical user interface that may display headings for a summary of a user's glucose trends. FIG. 15 illustrates a graphical user interface that may display headings for "Evening High Event" and "Three High Events." FIG. 16 illustrates a graphical user interface that may display a heading for "Evening High Event." FIG. 17 illustrates a graphical user interface that may display headings for "Afternoon Low Event" and "Two Low Events." FIG. 18 illustrates a graphical user interface that displays a heading for "Afternoon Low Event." FIG. 19 shows a graphical user interface that may display a heading of "Post-Bolus High Events" and subheadings of "Bolus" and "High Events". FIG. 20 shows a graphical user interface that may display a heading of "Post-Bolus Low Events" and subheadings of "Bolus" and "Low Events". FIG. 21 shows a graphical user interface that may display a summary of the delivery of the bolus, carbohydrates (CARBS) and mode of the drug delivery device and the units of each of the bolus(es) and carbohydrates. FIG. 22 shows a graphical user interface that may display a summary of the bolus arranged as overnight average with units, AM average with units, PM average with units and overnight average with units. FIG. 23 shows a graphical user interface that may display a summary of the settings arranged as a 24-hour timeline with target glucose, correction factor and insulin to carbohydrate ratio.24 illustrates a graphical user interface that may display a basal and bolus insulin summary that displays an automatic mode subheading and a manual mode subheading under a basal heading. Borders of the graphical user interface are shown as solid lines, decorative features are shown as solid lines, and other features are shown as dashed lines, but may also be implemented as solid lines.

[0172] Various elements of a device, apparatus or system such as those described above with reference to the figures may include various hardware elements, software elements, or a combination of both. Examples of hardware elements may include structural members, logic devices, components, processors, microprocessors, circuits, processors, circuit elements (e.g., transistors, resistors, capacitors, inductors, etc.), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory units, logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (APIs), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.

[0173] Some examples of the disclosed apparatus or processes may be implemented using, for example, a storage medium, computer readable medium, or article of manufacture that may store instructions or sets of instructions that, when executed by a machine (i.e., a processor or controller), may cause the machine to perform methods and / or operations according to examples of the present disclosure. Such a machine may include, for example, any suitable processing platform, computing platform, computing device, processing device, computing system, processing system, computer, processor, etc., and may be implemented using any suitable combination of hardware and / or software. A computer readable medium or product may include, for example, any suitable type of memory unit, memory, memory article, memory medium, storage device, storage article, storage medium and / or storage device, such as memory (including non-transitory memory), removable or non-removable media, erasable or non-erasable media, writable or re-writable media, digital or analog media, hard disk, floppy disk, compact disk read only memory (CD-ROM), compact disk recordable (CD-R), compact disk rewriteable (CD-RW), optical disk, magnetic media, magneto-optical media, removable memory cards or disks, various types of digital versatile disks (DVDs), tapes, cassettes, etc. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, encrypted code, program code, etc., implemented using any suitable high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language. A non-transitory computer readable medium embodied with program code, when executing the program code, may cause a processor to perform functions as described herein.

[0174] Specific examples of the present disclosure have been described above. However, it is expressly pointed out that the present disclosure is not limited to these examples, but rather additions and modifications to those explicitly described herein are also intended to be included within the scope of the disclosed examples. Furthermore, it should be understood that the features of the various embodiments described herein are not mutually exclusive and may exist in various combinations and permutations even if such combinations or permutations are not expressly stated herein without departing from the spirit and scope of the disclosed embodiments. Indeed, variations, modifications, and other implementations of what is described herein will occur to those skilled in the art without departing from the spirit and scope of the disclosed embodiments. Thus, the disclosed embodiments are not defined solely by the illustrative description set forth above.

[0175] The program aspects of the present technology can be considered as a "product" or "article of manufacture" in the form of executable code and / or associated data typically carried on or embodied in some type of non-transitory machine-readable medium. The storage type medium includes any or all of the tangible memory or associated modules of a computer, processor, etc., such as various semiconductor memories, tape drives, disk drives, etc., which can provide non-transitory storage at any time for software programming. It is emphasized that the Summary of the Disclosure is provided to enable the reader to quickly grasp the nature of the technical disclosure. The Summary of the Disclosure is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the foregoing detailed description, various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, novel subject matter lies in less than all features of a single disclosed embodiment. Accordingly, the following claims are hereby incorporated into this specification, with each claim standing on its own as a separate embodiment. In the appended claims, the terms "having" and "in" are used as the plain-English equivalents of the respective terms "comprising" and "in." Moreover, the terms "first," "second," "third," etc. are used merely as labels and are not intended to impose numerical requirements on their objects.

[0176] The description of the foregoing embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims appended hereto. Future applications claiming priority to this application may claim the disclosed subject matter in different manners, and generally may include any set of one or more features as variously disclosed or otherwise illustrated herein.

Claims

1. When executing, Accessing blood glucose measurements and insulin data from memory, Blood glucose measurements exceeding the upper limit of the target blood glucose setting are identified as high-level events, and blood glucose measurements below the lower limit of the target blood glucose setting are identified as low-level events. Applying the high-event overlap rule set to the high-event events and applying the low-event overlap rule set to the low-event events, Based on applying the high-event overlap rule set to the high-event events and the low-event overlap rule set to the low-event events, overlapping high-events and overlapping low-events are identified for analysis. Identifying overlapping high-events within the set high-event overlap period and number of days as high-event patterns, Identifying overlapping low events within the set low event overlap period and number of days as low event patterns, Applying the respective pattern weights to each of the identified high events and each of the identified low events based on the criteria specific to the high events and the criteria specific to the low events, Adding the number of high-event patterns and another number of low-event patterns to the graphical user interface, A non-temporary, computer-readable medium that embodies programming instructions that cause a processor to execute.

2. When executing, When identifying blood glucose measurements exceeding the upper limit of the target blood glucose setting as high-risk events, A non-temporary computer-readable medium according to claim 1, which embodies a programming instruction that causes a processor to execute the task of obtaining the user's upper limit target blood glucose setting value from the user settings stored in the memory.

3. When executing, When identifying blood glucose measurements below the lower limit of the target blood glucose setting as low-level events, A non-temporary computer-readable medium according to claim 1, which embodies a programming instruction that causes a processor to execute the operation of obtaining the user's lower limit target blood glucose setting value from the user settings stored in the memory.

4. When executing, When generating the corresponding high-event pattern, A non-temporary computer-readable medium according to claim 1, which embodies a programming instruction causing a processor to perform a high-event overlap rule, which includes evaluating high events that overlap and span three days in accordance with a high-event duration rule.

5. When executing, When generating the corresponding low-event pattern, A non-temporary computer-readable medium according to claim 1, which embodies a programming instruction causing a processor to perform a low-event overlap rule, which includes evaluating low events that overlap and span three days in accordance with the low-event duration rule.

6. When executing, A non-temporary computer-readable medium according to any one of claims 1 to 5, which embodies a programming instruction that causes a processor to perform the task of obtaining blood glucose measurement values ​​and insulin data for one week from the aforementioned memory.

7. When executing, A non-temporary computer-readable medium according to claim 6, which embodies a programming instruction causing a processor to replace a graphical user interface with a weekly summary graphical user interface, in which at least three high-event patterns and at least two low-event patterns are added, based on weekly blood glucose measurement values ​​and insulin data from the memory.

8. When executing, Accessing blood glucose measurements and insulin data from memory, Blood glucose measurements exceeding the upper limit of the target blood glucose setting are identified as high-level events, and blood glucose measurements below the lower limit of the target blood glucose setting are identified as low-level events. Identifying high-event patterns in overlapping high-events and identifying low-event patterns in overlapping low-events, wherein the overlap is determined based on a time window. Applying a bolus event rule set to the identified overlapping high event patterns and identified overlapping low event patterns, Identifying bolus events for analysis corresponding to each of the identified high events and each of the identified low events, based on the application of the bolus event rule set to each of the identified low events and the identified overlapping low events, The identified bolus event is added to the corresponding identified high event or the corresponding identified low event in memory. The graphical user interface is to add the number of low-event patterns with bolus events and another number of the aforementioned high-event patterns with bolus events, A non-temporary, computer-readable medium that embodies programming instructions that cause a processor to execute.

9. When executing, Identifying high-event patterns in overlapping high-events, where the overlap is determined based on a time window, A non-temporary computer-readable medium according to claim 8, which embodies a programming instruction causing a processor to sum blood glucose measurements during each of the high-event durations and divide the sum by the total number of identified high events during the time window encompassing each of the high-event durations.

10. When executing, Identifying low-event patterns in overlapping low-events, where the overlap is determined based on a time window, A non-temporary computer-readable medium according to claim 8 or 9, which embodies a programming instruction causing a processor to sum blood glucose measurements during each of the low-event durations and divide the sum by the total number of identified low events during the time window encompassing each of the low-event durations.

11. A memory operable to store a user's continuous blood glucose monitoring data and data from the user's personal diabetes management device, wherein the user's continuous blood glucose monitoring data includes blood glucose measurements and the data from the user's personal diabetes management device includes insulin delivery data. A data analysis processor having a circuit capable of executing programming code stored in the memory, During a predetermined period, the blood glucose measurement values, insulin delivery data, and data from the user's personal diabetes management device are acquired. In normalized data, blood glucose measurements exceeding the upper limit of the target blood glucose setting are identified as high events, while blood glucose measurements below the lower limit of the target blood glucose setting are identified as low events. The high-event overlap rule set is applied to the high-event events, and the low-event overlap rule set is applied to the low-event events. Based on applying the high-event overlap rule set to the high-event events and the low-event overlap rule set to the low-event events, overlapping high-events and overlapping low-events are identified for analysis. Overlapping high-events within the set high-event overlap period and number of days are identified as high-event patterns. Overlapping low events within the set low event overlap period and number of days are identified as low event patterns. Based on the criteria specific to high events and the criteria specific to low events, the respective pattern weights are applied to each of the identified high events and each of the identified low events. A data analysis processor capable of adding the number of high-event patterns and another number of low-event patterns to a graphical user interface, A system equipped with these features.

12. When the data analysis processor identifies a blood glucose measurement exceeding the upper limit target blood glucose setting as a high event, The system according to claim 11, further capable of obtaining the user's upper limit target blood glucose setting value from the user settings stored in the memory.

13. When the data analysis processor identifies a blood glucose measurement below the lower limit target blood glucose setting as a low event, The system according to claim 11, further operable to obtain the user's lower limit target blood glucose setting value from the user settings stored in the memory.

14. The aforementioned data analysis processor generates a corresponding high-event pattern, The system according to claim 11, further operable to apply high-event overlap rules, which include evaluating high events that overlap and span three days in accordance with high-event duration rules.

15. The data analysis processor, when generating a corresponding low-event pattern, The system according to claim 11, further operable to apply low-event overlap rules, which include evaluating low events that overlap and span three days in accordance with low-event duration rules.

16. The aforementioned data analysis processor is The system according to claim 11, further operable to acquire a week's worth of blood glucose measurements and insulin data from the memory.

17. The aforementioned data analysis processor is The system according to claim 16, further operable to replace a graphical user interface with a weekly summary graphical user interface to which at least three high-event patterns and at least two low-event patterns have been added.

18. The data extraction, transformation, and loading circuit normalizes the user's continuous blood glucose monitoring data and data from the user's personal diabetes management device. Access the user's continuous blood glucose monitoring data and data from the user's personal diabetes management device. Blood glucose measurement data is extracted from the user's continuous blood glucose monitoring data and data from the user's personal diabetes management device. The system according to any one of claims 11 to 17, which is operable to format data in order to identify the high event pattern and the low event pattern.

Images