Patent Description:
Diabetes mellitus is a chronic metabolic disorder caused by the inability of a person's pancreas to produce sufficient amounts of the hormone insulin such that the person's metabolism is unable to provide for the proper absorption of sugar and starch. The inability to absorb those carbohydrates sometimes leads to hyperglycemia, i.e., the presence of an excessive amount of glucose within the blood plasma. Hyperglycemia has been associated with a variety of serious symptoms and life threatening long-term complications such as dehydration, ketoacidosis, diabetic coma, cardiovascular diseases, chronic renal failure, retinal damage and nerve damages with the risk of amputation of extremities.

Because healing is not yet possible, a permanent therapy is necessary which maintains a proper blood glucose level within normal limits. Maintaining a proper glucose level is achieved by regularly supplying insulin to a person with diabetes (PWD). Maintaining a proper blood glucose level creates a significant cognitive burden for a PWD and affects many aspects of the PWD's life. For example, the cognitive burden on a PWD can be attributed to, among other things, tracking meals and constant check-ins and minor course corrections of blood glucose levels. The adjustments of blood glucose levels by a PWD can include taking insulin, tracking insulin dosing and glucose, deciding how much insulin to take, how often to take it and how to time insulin doses in relation to meals and/or glucose fluctuations. These factors make up just a portion of the significant cognitive burden of a PWD.

From the moment a PWD wakes up to the moment they go to bed, a PWD is constantly checking their blood glucose level, considering the amount and type of food they have and will eat, considering how much active insulin is still in their body, trying to anticipate future insulin requirements, checking and rechecking their supplies, and confirming that their equipment is still working.

Insulin-based management of diabetes requires significant attention to detail throughout the day. Even with careful planning and self-monitoring, a PWD may skip doses, double dose, or dose the wrong amount and/or type of insulin. As mentioned already, insufficient insulin can result in hyperglycemia, and too much insulin can result in hypoglycemia, which can result in clumsiness, trouble talking, confusion, loss of consciousness, seizures, or death.

Document <CIT> discloses receiving and storing data indicative of a user's blood glucose levels, i.e. therapy data associated with insulin based management of the user's diabetes, identification of a retrospective time period of and based on the user's blood glucose levels for said time period the determination whether the user missed a bolus or not, i.e. a classification (bolus missed or not), and according labeling of the time period, i.e. storing information whether a bolus was missed during said time period or not. It does not disclose a trained missed-bolus classifier based on training data and feature sets, wherein the training data comprises positive class training data formed from positive chunked data and negative class training data formed from negative chunked data, and wherein the feature sets comprises aggregated feature set values for the positive class training data formed from feature values for positive class chunked data and aggregated feature set values for the negative class training data formed from feature values for negative class chunked data.

While this disclosure concludes with claims particularly pointing out and distinctly claiming specific embodiments, various features and advantages of embodiments within the scope of this disclosure may be more readily ascertained from the following description when read in conjunction with the accompanying drawings, in which:.

The following description provides specific details to provide a thorough description of various embodiments of the invention. However, one of ordinary skill in the art will understand that the disclosed embodiments may be practiced without using these specific details. Indeed, the disclosed embodiments may be practiced in conjunction with conventional systems and methods used in the industry. In addition, only those elements helpful to understand and enable one of ordinary skill in the art to practice the disclosed embodiments are described in detail. One of ordinary skill in the art will recognize that some elements not described herein but, using various conventional method components and acts, would be in accord with the embodiments of this disclosure.

The following description may include examples to help enable one of ordinary skill in the art to practice the disclosed embodiments. The use of the terms "exemplary," "by example," "for example," "e.g.," and "such as" means that the related description is explanatory. The use of such terms is not intended to limit the scope of an embodiment or this disclosure to the specified components, steps, features, functions, arrangement of components, or the like. Moreover, the use of such terms does not indicate or imply that the related description comprises, or is, a preferred embodiment.

Any drawings accompanying this disclosure are for illustrative purposes only, and no scale is intended unless specifically indicated. Elements common among figures may retain the same numerical designation; however, the similarity in numbering does not mean that the structures or components are necessarily identical in size, composition, configuration, or any other property.

It will be readily understood that the components of the embodiments as generally described herein and illustrated in the drawing could be arranged and designed in a wide variety of different configurations. Thus, the following description of various embodiments is not intended to limit the scope of the present disclosure, but is merely representative of various embodiments. While the various aspects of the embodiments may be presented in drawings, the drawings are not necessarily drawn to scale unless specifically indicated.

As noted, above, specific implementations shown and described are only examples and should not be construed as the only way to implement the present disclosure unless specified otherwise herein. Elements, circuits, and functions may be shown in block diagram form in order not to obscure the present disclosure in unnecessary detail. Block definitions and partitioning of logic between various blocks is/are examples of a specific implementation. It will be readily apparent to one of ordinary skill in the art that the present disclosure may be practiced by numerous other partitioning solutions. For the most part, details concerning timing considerations and the like have been omitted where such details are not necessary to obtain a complete understanding of the present disclosure and are within the abilities of persons of ordinary skill in the relevant art.

Many of the functional units described in this specification may be illustrated, described or labeled as logic, modules, engines, threads, or other segregations of programming code, to more particularly emphasize their implementation independence in accomplishing the features, functions, tasks or steps that are generally described herein. The various illustrative logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be at least partially implemented or performed with a general purpose processor, a special purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.

The functional units may be implemented using software or firmware, stored on a computer-readable storage medium, in system memory, or a combination thereof for execution by various types of processors. Some examples of languages that may be used to write the software include, but are not limited to, an extensible markup language, C, C++, JAVA, MATLAB, MINITAB, EXPRESS, DRAKON, DYNA, PYTHON, MOOSE, and RUBY. The software programs may be further translated into machine language or virtual machine instructions and stored in a program file in that form. The program file may then be stored on or in one or more of the articles of manufacture. Although enabling software might be "written on" a disc, "embodied in" an integrated circuit, "carried over" a communications circuit, "stored in" a memory chip, or "loaded in" a cache memory, it will be appreciated that, for the purposes of this application, the software is referred to simply as being "in" or "on" the computer readable medium. Thus, the terms "in" or "on" are intended to encompass the above mentioned and all equivalent and possible ways in which software can be associated with a computer readable medium.

In the case of a general-purpose computer, these logic and modules may be embodied in software classes and applications executed by processor cores, and while the modules are executing the general-purpose computer may be thought of as a special purpose computer or a specific purpose computer. The logic and modules may also relate to specific purpose hardware, including the firmware and machine code, controlling its operation. An identified module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as a thread, object, procedure, or function. Nevertheless, the executable code of an identified module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the module and achieve the stated purpose for the module.

A module of executable code may comprise a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several storage or memory devices. The operational data may be collected as a single data set or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. Where a module or portions of a module are implemented in software, the software portions are stored on one or more physical devices, which are referred to herein as computer-readable media.

In some embodiments, the software portions are stored in a non-transitory state such that the software portions or representations thereof, persist in the same physical location for a period of time. Additionally, in some embodiments, the software portions are stored on one or more non-transitory storage mediums, which include hardware elements capable of storing non-transitory states and/or signals representative of the software portions, even though other portions of the non-transitory storage mediums may be capable of altering and/or transmitting the signals. Examples of non-transitory storage mediums are flash memory and certain types of random-access memory (RAM). Another example of a non-transitory storage medium includes a read-only memory (ROM) which can store signals and/or states representative of the software portions for a period of time. However, the ability to store the signals and/or states is not diminished by further functionality of transmitting signals that are the same as, or representative of, the stored signals and/or states. For example, a processor may access the ROM to obtain signals that are representative of the stored signals and/or states to execute the corresponding software instructions.

A processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. A general-purpose computer including a processor is considered a special-purpose computer when the general-purpose computer is configured to execute computing instructions (e.g., software code) related to embodiments of the present disclosure.

The embodiments disclosed herein may be described in terms of a process that is depicted as a flowchart, a flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe operational acts as a sequential process, many of these acts can be performed in another sequence, in parallel, or substantially concurrently. In addition, the order of the acts may be rearranged. A process may correspond to a method, a thread, a function, a procedure, a subroutine, a subprogram, etc. Furthermore, the methods disclosed herein may be implemented in hardware, software, or both. If implemented in software, the functions may be stored or transmitted as one or more instructions or code on computer-readable media.

Various embodiments described herein may be described as implemented in or by a "computer," "computing system," or a "computing platform," which are to be understood to include at least one non-transitory computer-readable medium and at least one processing unit. In general, the storage medium will store, at one time or another, at least portions of an executable program code, and a processor(s) will execute one or more of the instructions included in that executable program code.

It will be appreciated that the term "executable program code" and the term "software" mean substantially the same thing for the purposes of this description. It is not necessary to the practice of the various embodiments described herein that the storage medium and the processing unit be physically located in the same place. That is to say, it is foreseen that the processor and the memory might be distributed among physical pieces of equipment or even in geographically distinct locations. One of ordinary skill in the art will appreciate that "media," "medium," "storage medium," "computer-readable media," or "computer-readable medium" as used herein, may include a diskette, a magnetic tape, a digital tape, a compact disc, an integrated circuit, a ROM, a CD, DVD, Blu-Ray, a cartridge, flash memory, a PROM, a RAM, a memory stick or card, or any other non-destructive storage medium useable by computers, including those that are re-writable.

Disclosed embodiments may be performed, in whole or in part, in cloud computing, client-server, or other networked environments, or any combination thereof. One or more components of such systems (e.g., a computing platform) may be located in a singular "cloud" or network, or spread among many clouds or networks. End-user knowledge of a physical location and/or configuration of components of a computing platform is not required. Moreover, components of such systems may be operatively linked via one or more electronic communication links. Such electronic communication links may be established, at least in part, via a network such as the Internet and/or other networks. It will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes embodiments in which servers, clients, computing platforms, and/or external resources may be operatively linked via some other communication media.

Users may interact with the computing platforms described herein by way of graphical user interfaces (GUIs) on a display and input devices such as touchscreens, keyboards, a computer mouse, touchpads, buttons, switches, jumpers, and the like. A GUI may include a console and/or dashboard and a user may interact with the GUI and, in turn, underlying software applications.

Any reference to an element herein using a designation such as "first," "second," and so forth does not limit the quantity or order of those elements, unless such limitation is explicitly stated. Rather, these designations may be used herein as a convenient method of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements may be employed there or that the first element must precede the second element in some manner. In addition, unless stated otherwise, a set of elements may comprise one or more elements.

As used herein, the term "substantially" about a given parameter, property, or condition means and includes, to a degree, that one of ordinary skill in the art would understand that the given parameter, property, or condition is met with a small degree of variance, such as, for example, within acceptable manufacturing tolerances. By way of example, depending on the parameter, property, or condition that is substantially met, the parameter, property, or condition may be at least <NUM>% met, at least <NUM>% met, or even at least <NUM>% met.

When a bolus dose (the terms "bolus dose" and "bolus dose of insulin" are used interchangeably in this disclosure) is missed, a PWD is at risk for elevated blood glucose and hyperglycemia. Moreover, in order to administer a late bolus dose, a PWD should consider that some glucose may already have been acted on by existing insulin in their body. If the PWD administers the same amount as the original bolus dose, some of the insulin may be active in the body for a long time. If the catchup bolus dose is large enough, there is a risk of causing hypoglycemia, either from that dose or a later dose due to insulin stacking. So, a PWD carries the cognitive burden of remembering to administer a bolus dose, and if they forget, the additional cognitive burden of a more difficult calculation for a catchup bolus dose.

Bolus calculators (typically a worksheet or software application) can relieve some of the cognitive burden and, in theory, reduce risks associated with incorrectly calculating a catch-up bolus dose of insulin. However, bolus calculators are not always accurate, and PWDs and their caregivers do not always provide correct data. So, bolus calculators can provide a false sense of security that results in relaxed vigilance and more missed bolus doses.

If a health care provider (HCP) is aware that their patient frequently misses bolus-doses then the HCP can take corrective action or initiate corrective action by their patient. For example, an HCP can educate a patient about risks associated with missed bolus doses, propose habits and strategies for remembering to timely administer a bolus dose, increase the amount of long acting (LA) insulin a PWD administers each day, and even change the PWDs insulin delivery mechanism (e.g., from an insulin pen to an insulin pump with continuous glucose monitor).

The inventors of this disclosure appreciate a need for detection of missed bolus doses. In particular, a need for detecting, retrospectively, that a bolus dose or bolus doses were missed, and in some implementations the frequency at which bolus doses were missed.

In this disclosure, the terms "retrospective" and "retrospectively" have the same meanings as commonly understood by one of ordinary skill in the technical art to which this disclosure belongs.

In this disclosure, the term "insulin therapy" means insulin-based management of diabetes. Unless otherwise indicated, when "therapy" is used herein it should be understood to mean "insulin therapy. " For example, "therapy data" should be understood to mean "insulin therapy data" and "therapy management system" should be understood to mean "insulin therapy management system.

Some disclosed embodiments relate, generally, to performing a process for detecting a missed-bolus dose using therapy data, the therapy data being associated with an insulin-based management of a person's diabetes over a period of time. In one embodiment, a retrospective time period is identified during (i.e., within) a period of time of the insulin therapy to which the therapy data relates. As a non-limiting example, a retrospective time period may be defined by a timestamp or series of timestamps that are within the retrospective time period. A classifier assigns a label to the retrospective timestamp as either detecting or not detecting a missed-bolus event. In one embodiment, a classifier is a trained model (i.e., obtained using machine learning techniques).

<FIG> shows a computing platform <NUM> for detecting a missed bolus event, in accordance with disclosed embodiments. In disclosed embodiments, computing platform <NUM> is, or is operative to be executed as, a data processing system, and more specifically, as a data processing system for performing retrospective missed-bolus detection. Computing platform <NUM> may include data store <NUM> and processor(s) <NUM>. Data store <NUM> may include therapy data <NUM>. Therapy data <NUM> is data related to insulin therapy of one or more persons. In the embodiment shown in <FIG>, therapy data <NUM> includes insulin dosing data <NUM>, meal data <NUM>, and blood glucose data <NUM>. Alternatively or additionally, therapy data <NUM> may include exercise data, sleep data, and/or physiological parameters of a patient (e.g., an insulin sensitivity factor or insulin-to-carbohydrate ratio).

Blood glucose data <NUM> may include data about blood glucose in a human body at one or more times. Blood glucose data <NUM> may include measurements of blood glucose levels, for example, raw blood glucose measurements, blood glucose estimates based on blood glucose measurements, and/or aggregations of the same (e.g., averages, trends and/or metrics). Blood glucose data <NUM> may include date and time (e.g., a timestamp), and a value for each blood glucose measurement. In disclosed embodiments, any suitable glucose sensor may provide blood glucose data <NUM>, for example, a continuous glucose monitor (CGM), a flash glucose monitor, a blood glucose meter (BGM). In the case of CGMs and flash glucose monitors, they may be configured to provide blood glucose data <NUM> based on interstitial fluid glucose levels of a person, which may be correlated to blood glucose levels. A BGM may be configured to provide blood glucose data based on a blood sample. Accordingly, the term "blood glucose" is not limited herein to using just blood glucose data, values, levels etc., but is also intended to include interstitial fluid glucose levels, intermediate measurements, and legal equivalents thereof.

Insulin dosing data <NUM> may include dosing event data. Dosing event data may include data about insulin dosing actions at one or more times and may include, for example, a dosing time or time range, type of insulin (e.g., LA insulin and rapid acting (RA) insulin) dosed, brand of insulin, and/or amount of dosed insulin. In some embodiments, dosing event data may include an indication of a dosing mechanism, for example, injection pen, inhaler, or infusion pump. In some embodiments, dosing event data may include an indication of whether dosing event data, in part or in whole, is based on an actual dosing action (e.g., detecting insulin delivery, for example, based on a manual action of a pump or a control signal configured to cause insulin delivery), user tracking of dosing actions (e.g., a PWD or caregiver enters a dose using a therapy application executing on a mobile device), or inferred dosing actions (e.g., from capping/uncapping of an injection pen).

Processor(s) <NUM> may be configured to execute a number of engines for performing disclosed embodiments. In the embodiment shown in <FIG>, processor(s) <NUM> includes trained missed-bolus classifier engine <NUM>, math engine <NUM>, and reporting engine <NUM>.

Trained missed-bolus classifier engine <NUM> may be configured, generally, to process therapy data <NUM> or part(s) of therapy data <NUM>, and detect one or more missed boluses. In one embodiment, a retrospective time period may be defined (e.g., as a setting), and a part of therapy data <NUM> processed by the trained missed-bolus classifier engine <NUM> may correspond to the retrospective time period. In one embodiment, trained missed-bolus classifier engine <NUM> may be a binary classifier, that is, return one of two results, a first result corresponding to "missed bolus detected" and a second result corresponding to "no missed bolus detected. " Trained missed-bolus classifier engine <NUM> may assign only one label to each retrospective timestamp, for example, "missed bolus detected" and "no missed bolus detected.

In disclosed embodiments, trained missed-bolus classifier engine <NUM> may be trained using one or more supervised and/or unsupervised learning techniques, including those described in more detail in this disclosure.

Math engine <NUM> may be configured to perform various statistical calculations using therapy data <NUM> and results provided by trained missed-bolus classifier engine <NUM>. In various embodiments, statistical calculations may include, for example, frequency calculations, confidence calculations, probability calculations, and more.

Reporting engine <NUM> may be configured, generally, to generate one or more reports <NUM> responsive to trained missed-bolus classifier engine <NUM> and/or math engine <NUM>. Reports <NUM> may include descriptions of retrospective studies performed at computing platform <NUM> as more fully described with reference to <FIG> and <FIG>, and may include, for example, patient identifiers, descriptions of retrospective time periods, assigned class labels, the class labels and more.

<FIG> shows a flowchart of a process <NUM> for detecting a missed bolus, in accordance with one or more embodiments. Process <NUM> may be performed for example, in whole or in part, by embodiments disclosed herein, including by computing platform <NUM>. In operation <NUM>, process <NUM> receives therapy data associated with an insulin-based management of a person's diabetes over a period of time. In operation <NUM>, process <NUM> identifies a retrospective time period during the period of time. In one embodiment, the retrospective time period may be identified based on a setting associated with performing process <NUM>. For example, a user may set one or more retrospective time periods, including the retrospective time period used in operation <NUM> prior to the current instance of performing process <NUM>. In operation <NUM>, process <NUM> performs a missed-bolus classification process on a part of the therapy data that corresponds to the retrospective time period. In operation <NUM>, process <NUM> obtains a classification result responsive to the performed missed-bolus classification process. In one embodiment, a classification result may be binary, e.g., "missed bolus detected" or "no missed bolus detected. " In one embodiment, a classification result may be indicative of a number of missed-bolus doses detected in the retrospective time period. In operation <NUM>, process <NUM> assigns a label to the retrospective time period responsive to the classification result, e.g., "missed bolus detected" or "no missed bolus detected. " In operation <NUM>, process <NUM> calculates a missed-bolus frequency metric responsive to the classification result for the retrospective period of time and one or more classification results for one or more other retrospective periods of time.

Some embodiments relate, generally, to reporting of missed boluses detected in accordance with disclosed embodiments. <FIG> and <FIG> show report <NUM> and report <NUM>, respectively, which are examples of reports that may be created by computing platform <NUM> of <FIG> for retrospective studies. In one embodiment, report <NUM> and/or report <NUM> may be a computer file including one or more of the fields shown in <FIG> and <FIG>, respectively. In one embodiment, report <NUM> and report <NUM> may include an electronic document in a human-readable form, a machine-readable form, or both human-readable and machine-readable forms. In disclosed embodiments, a "computer file" refers to a computer resource for recording data discretely in a computer storage device and to a stream of data received on a tangible computer medium. In disclosed embodiments, "data" refers to both data and information.

Turning to <FIG>, report <NUM> includes a list <NUM> of retrospective studies included in report <NUM>. In this example, there are entries for three studies associated with a person identified at identifier <NUM>. Entry <NUM> for the first study includes a date range <NUM> and a label <NUM>. The other entries have the same elements. Date range <NUM> corresponds to a retrospective time period processed by trained missed-bolus classifier engine <NUM>. Label <NUM> corresponds to a label assigned by trained missed-bolus classifier engine <NUM> to the retrospective timestamps corresponding to date range <NUM>.

For each entry, additional data may be provided. In this example, for entry <NUM>, additional data <NUM> is provided in report <NUM>. Additional data <NUM> includes fields for number of missed boluses detected <NUM>, overall confidence level <NUM>, dates detected <NUM>, and confidence levels <NUM> for dates detected <NUM>. Number of missed boluses detected <NUM> describes the overall number of missed bolus doses that were detected by trained missed-bolus classifier engine <NUM> for date range <NUM>. Overall confidence level <NUM> describes a calculated confidence level that the overall number of missed bolus doses that were detected were true missed bolus doses. Dates detected <NUM> is a list of dates for which at least one missed bolus was detected by trained missed-bolus classifier engine <NUM>. In one embodiment, a number of missed bolus doses for each date may be included for each date in dates detected <NUM>. Confidence levels <NUM> describes calculated confidence levels for each respective date in dates detected <NUM>. Additionally or alternatively, overall confidence level <NUM> and confidence levels <NUM> may indicate confidence that trained missed-bolus classifier engine <NUM> detected all missed-boluses.

For entry <NUM>, additional data <NUM> is provided in report <NUM>. In this example, no missed bolus was detected in the study corresponding to entry <NUM>, so additional data <NUM> includes fields for no missed bolus detected <NUM>. Additional data <NUM> also includes an overall confidence level <NUM> that describes a calculated confidence level that there were no true missed bolus doses in the date range <NUM>.

In some embodiments, supporting data may be provided for any of the data in additional data <NUM> and/or additional data <NUM>. Supporting data for additional data <NUM> and additional data <NUM> may be included in more detail <NUM> and more detail <NUM>, respectively.

Turning to <FIG>, data in report <NUM> may be created in addition to, or alternatively to, that in report <NUM>. In the embodiment shown in <FIG>, report <NUM> includes fields for data about a patient for which trained missed-bolus classifier engine <NUM> performed retrospective missed-bolus detection in accordance with disclosed embodiments. Report <NUM> includes fields for: person identifier <NUM>, number of studies performed <NUM>, and dates ranges <NUM> for which studies were performed. Report <NUM> also includes fields for overall statistics <NUM> and person insights <NUM>.

Overall statistics <NUM> are statistical observations related to missed-bolus detection for the person identified in person identifier <NUM>. In the embodiment shown in <FIG>, overall statistics <NUM> includes fields for number of missed boluses detected <NUM> and overall confidence levels <NUM> that the number of missed boluses detected <NUM> correspond to true missed boluses. Additionally or alternatively, confidence levels <NUM> may indicate confidence that trained missed-bolus classifier engine <NUM> detected all missed boluses.

Person insights <NUM> are observations about predicted behaviors related to missed-bolus dosing of a person associated with person identifier <NUM>. In the embodiment shown in <FIG>, person insights <NUM> includes fields for overall probability this patient will miss a bolus dose <NUM> and probability of a missed bolus within specific time ranges <NUM>. Overall probability this patient will miss a bolus dose <NUM> is a probability that a person associated with person identifier <NUM> will miss a bolus dose during insulin therapy. Probability of a missed bolus within specific time ranges <NUM> includes probabilities that a person associated with person identifier <NUM> will miss a bolus dose during insulin therapy within a specific time range. In the embodiment shown in <FIG>, probabilities are provided for time ranges of a day <NUM>, a week <NUM> two weeks <NUM>, and four weeks <NUM>. Fields for supporting data related to data in report <NUM> may be included, such as more detail <NUM>.

Any suitable technique used by one of ordinary skill in the art in the field of data science to calculate and/or express probabilities may be used with disclosed embodiments.

Some embodiments relate, generally, to insulin therapy systems and elements thereof that incorporate systems, methods and devices for missed-bolus detection. <FIG> shows a system <NUM> for insulin therapy, in accordance with disclosed embodiments. In the embodiment shown in <FIG>, data processing system <NUM>, clinical decision support system <NUM>, and therapy management system <NUM> are computing platforms configured, generally, to provide various services related to insulin therapy, in whole or in part, to each other and to HCP systems <NUM> and patient systems <NUM>. HCP systems <NUM> may include, for example, portals, dashboards, electronic medical record systems, computing platforms executing the same, and more.

In disclosed embodiments, therapy management system <NUM> may be one or more computing platforms configured to receive and store therapy data (such as therapy data <NUM> in <FIG>) and physiological parameters about patients, issue alarms and alerts, and manage therapy settings for insulin delivery systems - all related to insulin-based management of a PWD's diabetes.

In disclosed embodiments, clinical decision support system <NUM> may be one or more computing platform configured as a health data technology system for assisting HCPs with clinical decision-making tasks, and more specifically in this example, assist HCPs with clinical decision-making tasks related to a PWD's insulin therapy. In disclosed embodiments, clinical decision support system <NUM> is configured to assist with insulin-based management of diabetes, and automatically analyzes therapy data <NUM> (<FIG>), identifies clinically relevant patterns in a PWD's therapy from therapy data <NUM>, and provides data and recommendations to HCP systems <NUM> based on those patterns. A goal of embodiments of clinical decision support system <NUM> is to improve outcomes for PWDs by facilitating communication of clinically relevant "insights" about a PWD's insulin-based therapy to patient systems <NUM> and/or HCP systems <NUM> as well as by facilitating communication of therapy related advice from HCP systems <NUM> to patient systems <NUM>.

In disclosed embodiments, data processing system <NUM> may be one or more computing platforms configured to process therapy data <NUM> (<FIG>) stored at, or received from, therapy management systems <NUM> and/or clinical decision support system <NUM>. In one embodiment, data processing system <NUM> may, among other things, include one or more elements of computing platform <NUM> (<FIG>), including trained missed-bolus classifier engine <NUM>. In this manner, data processing system <NUM> may be configured to perform missed-bolus detection for therapy management system <NUM> and/or clinical decision support system <NUM>.

By way of example, data processing system <NUM> may perform missed-bolus detection on therapy data <NUM> (<FIG>) stored at clinical decision support system <NUM> and provide one or more reports <NUM> (<FIG>) detailing one or more labeled retrospective time periods, as well as one or more metrics for frequency of missed bolus doses. Clinical decision support system <NUM> may use the data in reports <NUM> to trigger insights and/or recommendations that it sends to HCP systems <NUM>. Upon HCP system <NUM> accessing messages from clinical decision support system <NUM>, data from reports <NUM> may be included in such message or accessible by HCP systems <NUM>. For example, HCP systems <NUM> requests data to support an insight or recommendation described in a message.

<FIG> shows a functional block diagram of a system <NUM> for training a missed-bolus classifier (such as trained missed-bolus classifier engine <NUM> in <FIG>) using machine learning techniques, in accordance with disclosed embodiments.

In a contemplated operation, supervised learning engine <NUM> trains trained classifier <NUM> using training data <NUM> and sets of engineered features (i.e., feature sets <NUM>) selected for model training purposes. In one embodiment, trained classifier <NUM> is a function or algorithm that detects missed bolus doses. An initial "best guess" may be used for trained classifier <NUM> which is then continually improved by supervised learning engine <NUM>. In disclosed embodiments, trained classifier <NUM> and supervised learning engine <NUM> may implement any suitable supervised learning algorithms and ensemble methods thereof for performing embodiments of the disclosure, including, for example, a logistic regression classifier, a decision tree classifier, an extra tree classifier, an isolation forest classifier, a random forest classifier, and/or a boosting classifiers. Disclosed embodiments may also implement supervised learning algorithm(s) that do not use feature selection, including, for example, one class support vector machine (SVM) without feature selection, and logistic regression without feature selection.

In one embodiment, training data <NUM> is labeled therapy data associated with one or more PWDs. PWDs may be chosen so they are representative of a desired domain of PWD physiologies, eating behaviors, exercise behaviors, sleeping behaviors, diurnal profile variation, and more.

In disclosed embodiments, feature sets <NUM> are sub-sets of features engineered (i.e., formed) in the training data <NUM> and used by supervised learning engine <NUM> to train any classifier. In one embodiment, feature sets <NUM> are created using a feature selection process for selecting a subset of features included in a feature domain created using feature engineering techniques. Features in a feature domain may include, for example, one or more of the features identified in Table <NUM>, below:.

Feature sets <NUM> may be selected from the feature domain using any suitable feature selection technique or combination of techniques for trying features in the feature domain and identifying important features, including, for example, sequential forward feature selection, sequential backward elimination, and tree-based feature selection algorithms.

Labeled test data <NUM> is test data <NUM> classified and labeled by a trained classifier <NUM> during successive iterations of system <NUM>. In one embodiment, the rule for a missed bolus may be a clinically relevant rule (e.g., commonly accepted rule for a "missed bolus" used by HCPs). In one embodiment, the rule is that a bolus is missed where there is not a bolus within substantially <NUM> minutes of a meal. In another embodiment, the rule is that a bolus is missed where there is not a bolus within a predetermined period of time (e.g., <NUM> minutes, <NUM> minutes, <NUM> minutes) after a recommendation to dose a bolus of insulin is presented to a user, for example, by a therapy management system or therapy management application.

In one embodiment, binary labels (e.g., <NUM> and <NUM>, or -<NUM> and <NUM>) are used to indicate whether a rule was satisfied.

Labelled test data <NUM> is the "true" or "target" labels for test data <NUM>. Stated another way, it is the labeling result that is the target for trained classifier <NUM>. Predictive ability analyzer <NUM> can assess the predictive ability of trained classifier <NUM> by comparing the labels of the labelled test data <NUM> that were predicted by the classifier to the true labels in the target classified test data. Any suitable technique for calculating and/or assessing validity of a model may be used by predictive ability analyzer <NUM>, including for example, precision, recall, number of detected events versus number of true events, confusion matrix, area-under-the-free-curve (AUC), and/or receiver operating characteristics (ROC) curve. Techniques such as grid search combined with cross validation, and N-fold cross-validation can be used for hyper parameter tuning of a classifier.

Feature selection <NUM> receives assessment results from predictive ability analyzer <NUM> and, in response, changes feature sets <NUM> to attempt to improve accuracy and/or attempt to simplify feature sets <NUM>. As non-limiting examples, changes to feature sets <NUM> may include, changing weighting for features of feature sets <NUM>, adding features to feature sets <NUM> to attempt to improve accuracy of predictions, removing unnecessary features from feature sets <NUM>, and combinations thereof.

Feature engineering <NUM> receives assessment results from predictive ability analyzer <NUM> and, in some cases, performs feature engineering techniques to extract new features from test data <NUM> and add those features to engineered features <NUM>. These new features may be used in the feature selection process by feature selection <NUM>.

In one embodiment, system <NUM> may include simulation engine <NUM> configured to generate simulation data <NUM> from which training data <NUM> and test data <NUM> may be obtained. Simulation engine <NUM> may be configured to simulate insulin therapy scenarios for a variety of PWDs. PWD profiles are created that represent a cross-section of PWDs in terms of characteristics such as physiology (e.g., age, weight, height, complicating health conditions, diurnal profile variation, etc.), lifestyle (e.g., eating behaviors, exercise behaviors, sleeping behaviors, etc.), socio-economic factors (e.g., income, race, geographic location, marriage status, child status, etc.), differences in how PWDs measure and track meal intake, and differences in the operation and quality of insulin delivery systems and components the PWDs use. In one embodiment, simulation engine <NUM> is configured to model for missing therapy data due to, for example, lost components, failure to input therapy related data, failure to wear a glucose monitor, and lost Bluetooth connection.

<FIG> shows a flowchart for a process <NUM> for training a missed-bolus classifier, in accordance with disclosed embodiments. Process <NUM> may be performed, in whole or in part, by embodiments disclosed herein, including by one or more components of system <NUM>.

In operation <NUM>, process <NUM> simulates insulin-based management of diabetes. In operation <NUM>, process <NUM> obtains training data and test data responsive to the simulations performed in operation <NUM>. In one embodiment, pre-processing of simulation data obtained from operation <NUM> may be performed to obtain the training data and test data including the feature sets. In operation <NUM>, process <NUM> trains a number of missed-bolus classifiers using the training data. In operation <NUM>, process <NUM> uses the test data to determine a predictive ability for each of the number of missed-bolus classifiers trained in operation <NUM>. In operation <NUM>, process <NUM> selects a trained missed-bolus classifier corresponding to a highest predictive ability of the predictive abilities determined in operation <NUM>. The trained missed-bolus classifier selected in operation <NUM> may be used as a trained missed-bolus classifier.

Notably, disclosed embodiments, in whole or in part, may be performed as a series of discrete operations, performed iteratively or reclusively such that the method converges on a final result, or combinations thereof.

In some embodiments, system <NUM> and process <NUM> may be used to train a late bolus classifier for performing retrospective late-bolus classification of insulin therapy data, in addition or alternatively, to training a missed-bolus classifier. In one embodiment, a rule for a late bolus may be defined as a bolus dose of insulin was administered after a pre-determined first time threshold and before a pre-determined second time threshold. As an example, a rule for late bolus detection may be that a bolus dose of insulin was administered more than <NUM> minutes after a meal or after a bolus recommendation but less than <NUM> minutes after a meal or a bolus recommendation.

In one embodiment, late-bolus classifiers and missed-bolus classifiers may both be used to classify insulin therapy data, and label data as including a missed-bolus event and/or a late-bolus event.

In some embodiments, a rule for missed bolus or late bolus may use a time when blood glucose levels trend lower to detect administration of a bolus dose of insulin. In other words, a decreasing blood glucose level that is indicative of insulin action by the user's body may be used to detect a bolus dose of insulin. A rate of decrease over a period of time that is greater than a rate threshold, or a total decrease of blood glucose level over a period of time that exceeds a total decrease threshold, may be used to determine a time when a bolus dose of insulin was administered in embodiments of this disclosure. A bolus dose may be detected based on a rate of decrease of blood glucose levels or total decrease in blood glucoses, or, alternatively, a bolus may be detected based on either of those in conjunction with a previously recommended dose or meal.

Several non-limiting examples are provided for operation of a missed-bolus classifier and late-bolus classifier in conjunction. The rule used by the late bolus classifier can take into account a time period <NUM>-<NUM> minutes after a recommendation or meal. The rule used by the missed-bolus classifier can take into account a time period <NUM> minutes or more after a recommendation or meal.

As a non-limiting example, if a bolus dose is recommended at 3PM and a blood glucose trends lower at <NUM>:<NUM>, then a late bolus may be detected because <NUM> minutes is greater than <NUM> minutes but less than <NUM> minutes. As another non-limiting example, if a meal is input by a user at 3PM and a blood glucose trends higher at 4PM, then a missed bolus may be detected because <NUM> minutes is more than <NUM> minutes.

In one embodiment, the time of a meal may be based on blood glucose levels. More specifically, a time of a meal may be based on when blood glucose levels change by an amount or rise at a rate that is indicative of meal intake. As a non-limiting example, a user may input a meal at 3PM, blood glucose levels may rise at a rate that is greater than a pre-determined rate at <NUM>:<NUM>, and then blood glucose trends lower at 4PM. In this example, a late bolus may be detected because <NUM> minutes is less than <NUM> minutes.

In embodiments described herein, trends may be based on one or more of a rate of decrease of blood glucose levels, based on a rate at which an increase in blood glucose levels is slowing, measurements of insulin on board, and combinations thereof.

Notably, statistics about missed-bolus detection and late-bolus detection described herein may be reported - e.g., in reports <NUM> of <FIG>. For example, a probability that a user will bolus late or miss a bolus may be reported. A clinical decision support (CDS) system, such as CDS system <NUM> (<FIG>), may detect that those probabilities exceed a certain threshold and generate a behavioral intervention or action for a patient. As a non-limiting example, a CDS may detect that a user is consistently in the missed and/or late bolus category and recommend to an HCP that the patient be educated about blood glucose levels responses to meal intake and/or insulin in case the patient does not understand when bolus doses should be administered.

Some disclosed embodiments relate, generally, to obtaining training data and test data, such as training data <NUM> and test data <NUM> (<FIG>), from simulation data such as simulation data <NUM>. <FIG> shows a functional block diagram of a data journey <NUM>, for creating training data from simulation data, in accordance with disclosed embodiments. Each stage of data journey <NUM> is shown as an operational block that describes at least some notable intermediate data elements of data journey <NUM>.

In operational block <NUM>, training simulation data <NUM> is obtained by selecting part of simulation data (such as simulation data <NUM> in <FIG>)) to be training simulation data <NUM>. In one embodiment, <NUM> days' worth of simulated data is obtained and the first <NUM> days of simulation data is selected to be training simulation data <NUM> and the last <NUM> days of simulation data is selected to be test simulation data.

In operational block <NUM>, each missed bolus event is flagged in the training simulation data <NUM> to obtain flagged data <NUM>. Notably, each true missed bolus in the simulation data <NUM> is known for each PWD that was part of a simulation.

In operational block <NUM>, feature engineering techniques are used on flagged data <NUM> to obtain feature set <NUM>. More specifically, feature engineering techniques are used to form features in flagged data <NUM> to obtain the feature set <NUM>.

In operational block <NUM>, feature set <NUM> is chunked to obtain positive chunked data <NUM> and negative chunked data <NUM>. In various embodiments, a chunk of data is data that is relevant to a class (here a positive class or negative class), and a chunk of data may itself be formed by aggregating sub-units of data. Positive chunked data <NUM> are chunks of data associated with a positive class (i.e., there is a missed bolus event detected). In one embodiment, positive chunked data <NUM> may be obtained by aggregating feature set <NUM> (here, training data) corresponding to the next <NUM> minutes' worth of observations after each missed bolus event. Further, a <NUM> minute chunk of therapy data may be formed of therapy data corresponding to <NUM> instances of consecutive <NUM> minute observations.

Negative chunked data <NUM> are chunks of data associated with a negative class (i.e., no missed bolus event detected). In one embodiment, negative chunked data <NUM> may be obtained by aggregating training data corresponding to a <NUM> minutes' worth of observations where (<NUM>) the observations in the <NUM> minutes are consecutive in timestamps; (<NUM>) chunks of chunked data <NUM> do not intersect (i.e., the intersection of chunks of chunked data <NUM> is empty); and (<NUM>) no chunks of chunked data <NUM> and chunks of chunked data <NUM> intersect (i.e., the intersection of chunks of chunked data <NUM> and chunked data <NUM> is empty). In one embodiment, available chunks of data are randomly selected to form chunked data <NUM> and/or chunked data <NUM>. In one embodiment, a number of chunks selected for chunked data <NUM> is substantially the same as the number of chunks selected for chunked data <NUM>.

Feature values <NUM> for positive chunked data <NUM> and feature values <NUM> for negative chunked data <NUM> are obtained for chunks of chunked data <NUM> and chunks of chunked data <NUM>, respectively, in operational block <NUM>. In various embodiments, feature values may be calculated for a chunk of data or one or more smaller observational units of a chunk of data. For example, feature values may be calculated using therapy data for each of the <NUM> minute observational units that form a <NUM> minute chunk of therapy data.

In operational block <NUM>, positive class data <NUM> and negative class data <NUM> are obtained, and more specifically, are constructed from chunks of chunked data <NUM> and chunks of chunked data <NUM>, respectively. In one embodiment, each positive class data <NUM> is formed by labeling the constituent chunks of data of chunked data <NUM> with a positive class identifier (e.g., "true" or " <NUM>") and copying the labeled chunks of data into positive class data <NUM>. Similarly, in one embodiment, each negative class data <NUM> is formed by labeling the constituent chunks of data of chunked data <NUM> with a negative class identifier (e.g., "false" or "<NUM>") and copying the labeled chunks of data to negative class data <NUM>.

In operational block <NUM>, aggregated feature set values <NUM> for positive class data <NUM> and aggregated feature set values <NUM> for negative class data <NUM> are obtained. In one embodiment, aggregated feature set values <NUM> for positive class data <NUM> and aggregated feature set values <NUM> for negative class data <NUM> are formed by aggregating feature values <NUM> for positive chunked data <NUM> and feature values <NUM> for negative chunked data <NUM>, respectively, on a feature by feature basis into a single value for the chunk. In various embodiments, any suitable statistical method for aggregating may be used, including, for example, one or more of mean, median, a commercially available aggregate function (e.g., first value).

In various embodiments, training data, such as training data <NUM> (<FIG>), may be obtained by combining positive class data <NUM> and negative class data <NUM>.

In one embodiment, training data obtained as a result of data journey <NUM> may be characterized as balanced training data, i.e., having a substantially equal number of observations from both classes (i.e., "detected missed bolus" and "no detected missed bolus"). Since the probability of a missed bolus event is lower than the probability of no missed-bolus event, the observations in simulation data <NUM> (<FIG>) should (in theory) be imbalanced, more specifically, the negative observations should outweigh the positive observations. So, when obtaining balanced training data, a majority of negative observations may not be considered, and so there is potential for data loss. In one embodiment, any impact of data loss is alleviated by using ensemble or bagging techniques.

In disclosed embodiments, test data, such as test data <NUM> (<FIG>), may be obtained in a manner similar to data journey <NUM> described above, except that the entire set of test simulation data may be chunked. Test data may be imbalanced (i.e., does not have to be balanced). So, in one embodiment, chunks may be formed by applying a rolling window to test simulation data. For example, <NUM> minute chunks may be formed by travelling across an entire test simulation data in <NUM> minute by <NUM> minute observational units, person by person. Features may be formed for each rolling window by aggregating values using suitable statistical methods similar to training data as described above.

In some cases, there may not be enough consecutive observational sub-units available to form a full chunk of data. Using the example of a <NUM> minute chunk of data formed of <NUM>-minute observational units, after a missed bolus event there may be <NUM> of the <NUM>-minute observational units and <NUM> discontinuities (e.g., gaps between observations). So, in one embodiment, a chunk of data is discarded if fewer than a predetermined number of consecutive observational units is available. Each chunk may be assigned a label with an appropriate class identifier to indicate that it is associated with a missed bolus or no missed bolus. In one embodiment, a chunk of data may be assigned a positive class label if any missed bolus event is within plus-minus <NUM> minutes of a chunk start time, and assigned a negative class label if otherwise.

While embodiments have been described herein with respect to missed-bolus detection and/or late bolus detection, one of ordinary skill in the art would understand that embodiments are equally applicable to missed or late meal detection. For example, detecting a missed and/or late meal after exercise, sleep, and/or a recommendation that a user eat, which could lead to hypoglycemia.

Claim 1:
A computer-implemented method of detecting a missed-bolus dose, comprising:
receiving therapy data associated with an insulin-based management of a person's diabetes over a period of time (<NUM>);
identifying a retrospective time period of the period of time (<NUM>);
performing, using a trained missed-bolus classifier, a trained missed-bolus classification process on a part of the therapy data that corresponds to the retrospective time period (<NUM>), wherein the trained missed-bolus classifier (<NUM>) is based on training data and feature sets, wherein the training data comprises positive class training data (<NUM>) formed from positive chunked data (<NUM>) and negative class training data (<NUM>) formed from negative chunked data (<NUM>), and wherein the feature sets comprises aggregated feature set values for the positive class training data (<NUM>) formed from feature values for positive class chunked data (<NUM>) and aggregated feature set values for the negative class training data (<NUM>) formed from feature values for negative class chunked data (<NUM>);
obtaining a classification result responsive to the performed trained missed-bolus classification process (<NUM>); and
assigning a label to the retrospective time period responsive to the classification result (<NUM>).