Patent Description:
Management of chronic illness, like diabetes, involves collecting and analyzing large amounts of data. Such data may be acquired from medical devices, personal healthcare devices, patient recorded information, and test results. For people with diabetes, successful management requires monitoring one's blood glucose level. As a tool for understanding changes in one's blood glucose level, a patient may access and run a variety of reports which aggregate and present diagnostic data over preset time periods, such as days, weeks, or even months. However, interfaces are needed to alert and inform a healthcare provider or a person suffering diabetes of possible harmful changes in the patient's blood glucose level.

<CIT> discloses systems and methods for detecting and reporting patterns in blood glucose measurements. The pattern data can be based on detecting frequency and severity of measurement data in clinically risky ranges, wherein data can be evaluated by using weight factors.

<CIT> discloses methods to evaluate continuous glucose monitoring (CGM) data and insulin delivery data to generate projected alarms related to a projected glucose levels. Profiles of CGM data are created for use in tuning patient-specific insulin data, such at basal rate, carb ratio, and insulin sensitivity. Patterns in the data profiles are determined to recommend changes to patient-specific insulin data.

<CIT> discloses a blood glucose (bG) measurement engine to selectively measure bG levels in blood samples input to a handheld diabetes management device during a certain period of days during which the patient input at least two blood samples. A value is calculated based on the bG levels of blood samples input during the period, and based on the value, the patient is classified as having a first, second, or third risk of being hypoglycemic in the future.

<CIT> discloses methods and apparatuses for determination and application of a unidimensional metric for assessing a patient's glycemic health. In one particular implementation, a computed metric may be used to balance short-term and long-term risks associated with a particular therapy. In another implementation, a computed unidimensional metric may be used to balance risks of hyperglycemia and hypoglycemia.

A computer implemented method for prioritizing patients associated with a healthcare provider according to the independent claim <NUM> is provided. Embodiments are set out in dependent claims.

The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations.

The present disclosure will now be described more fully with reference to the accompanying drawings.

With reference to <FIG>, a diabetes management system (DMS) <NUM> may be housed in one or more servers and includes software tools that enable users to manage diabetes. A user, such as a person suffering from diabetes (i.e., patient) and/or the healthcare provider for the patient, may access the software tools supported by the diabetes management system <NUM> by way of a computing device <NUM>. For example, the diabetes management system <NUM> and the computing device <NUM> may exchange information via a communication link to a communication network <NUM>, such as the Internet. The computing device <NUM> may include: a laptop; a portable computing device, such as a smartphone and/or tablet having a diabetes management application residing in and executed by the portable computing device; a medical device, such as blood glucose meter; and/or other suitable device that exchanges and processes information.

Using the computing device <NUM>, the healthcare provider (i.e., HCP) may create a user account and register with the diabetes management system <NUM> as a healthcare provider member. For example, through a user interface supported by the diabetes management system <NUM>, the healthcare provider may create a profile that is stored by the diabetes management system <NUM>. The profile may include information for identifying the healthcare provider and information regarding patients associated with the healthcare provider.

Similarly, the patient may establish a user account and register as a client member with the diabetes management system <NUM>. As an example, through a user interface supported by the diabetes management system <NUM>, the patient creates a profile that is stored by the diabetes management system <NUM>. Once registered, the patient may have access to tools supported by the diabetes management system <NUM>, such as a bolus calculator and a logbook for storing blood glucose (bG) measurements. The bG measurement may include a numerical measurement, a unit of measurement (e.g., mg/dl), a timestamp, and a comment (e.g. before breakfast or after exercise). The bG measurement may be entered manually by the patient by way of a user interface on computing device <NUM> or may be transmitted by a glucose measurement device to the DMS <NUM>.

The patient may also authorize one or more healthcare providers registered with the diabetes management system <NUM> to access information related to the patient. For example the patient may send an invitation to a selected healthcare provider member to link with the patient. Once the selected healthcare provider member accepts the patient's invitation, the healthcare provider may view information related to the patient, such as bG measurements. Alternately, the healthcare provider may send an invitation to the patient to link with the healthcare provider. Once the patient accepts the healthcare provider's invitation, the healthcare provider may view information related to the patient, such as bG measurements.

The diabetes management system <NUM> enables the patient and the healthcare provider to monitor the patient's bG measurements. For instance, the diabetes management system <NUM> includes a glucose alert detection module <NUM> and a patient prioritization module <NUM>. The glucose alert detection module <NUM> may be used by the patient and/or the healthcare provider for monitoring a glucose condition of the patient and for notifying the patient and/or healthcare provider of an alert status regarding the patient's blood glucose level. The patient prioritization module <NUM> may be used by the healthcare provider to sort and prioritize multiple patients associated with the healthcare provider based on the alert status for each of the patients.

The glucose alert detection module <NUM> analyzes the patient's bG measurements to determine a glucose condition for a specified enquiry period and to generate an alert status for a patient summary interface. As an example, <FIG> illustrates a patient summary interface <NUM> that is generated by the diabetes management system <NUM>. The patient summary interface <NUM> includes a menu section <NUM>, a title bar <NUM>, an enquiry period selection section <NUM>, a display selection bar <NUM>, a glucose synopsis bar <NUM>, an alert status section <NUM>, and a digest section <NUM>.

The menu section <NUM> displays drop down menus and tabs accessible by the user and may be continuously displayed by the diabetes management system <NUM>. The title bar <NUM> display contextual information regarding the interface currently being displayed. For example, in <FIG>, the title bar <NUM> identifies the interface <NUM> as the "Patient Summary.

The enquiry period selection section <NUM> displays data input interfaces that enable the user to input or select the enquiry period. The enquiry period is a time period for which the glucose condition is analyzed. The enquiry period selection section <NUM> may include a drop down menu for displaying preset time periods (e.g., "<NUM> Weeks" in <FIG>) and text input interfaces for inputting specified dates that define the enquiry period (e.g., "<NUM>/<NUM>/<NUM>" and "<NUM>/<NUM>/<NUM>" in <FIG>). The enquiry period may be configured to span a minimum or maximum time period. For example, the user may be able to set a time period between <NUM> to <NUM> weeks or <NUM>-days to <NUM> weeks or other suitable time period. The enquiry period selection section may be referred to as a first section of the patient summary interface <NUM>.

The display selection bar <NUM> includes a drop down menu that lists various graphs that may be displayed in the digest section. For example, the user may select the standard day graph from the drop down menu in order to view the graph in the digest section <NUM> or unselects the graph to remove it from the digest section <NUM>.

The glucose synopsis bar <NUM> displays textual information that provides a summary of the patent's bG level during the enquiry period. For example, the glucose synopsis bar <NUM> may include information indicative of an average bG, average number of bG tests, number of hypoglycemic occurrences. While <FIG> illustrates specific information displayed in the glucose synopsis bar <NUM>, other suitable glucose information may be displayed, such as number of hyperglycemic occurrences, and is not limited to the information illustrated.

The alert status section <NUM> displays textual information regarding one or more glucose conditions analyzed with respect to the enquiry period and an alert status for the patient based on the glucose conditions. As described in detail below, the one or more glucose conditions is indicative of a bG level of the patient and may include: hypoglycemia frequency, hypoglycemia risk, hyperglycemia frequency, hyperglycemia risk, and/or blood glucose variability.

The digest section <NUM> of the patient summary interface <NUM> displays information indicative of the patient's bG measurements during the enquiry period. For example, <FIG> illustrates a graph <NUM> that conveys the patient's bG measurements for the enquiry period. The digest section <NUM> may also include information regarding different activities that may affect the patient's bG measurement such as insulin dosage, meal time, calorie consumption, etc. The digest section <NUM> may also be referred to as a second section of the patient summary interface <NUM>.

The glucose alert detection module <NUM> determines the glucose conditions based on bG measurements taken during the enquiry period and determines a state of the glucose condition based on an alert threshold. The state of the glucose condition is determined as: HIGH, LOW, or not available due to insufficient data. A HIGH state indicates that the glucose condition is excessive or, in other words, over or outside of an acceptable range. A LOW state indicates that the glucose condition is normal or, in other words, within the acceptable range. The state of the glucose condition may include other states and is not limited to "HIGH", "LOW', and "Insufficient Data".

In some embodiments, the alert status section <NUM> may only be displayed by the diabetes management system <NUM> when the glucose alert detection module <NUM> determines that at least one of the glucose conditions is outside an acceptable range (i.e., HIGH). For example, <FIG> illustrates a situation in which the state of the bG hypoglycemia frequency (i.e., "Hypo Frequency") is HIGH for the enquiry period. The alert status section <NUM> is located between the enquiry period selection section <NUM> and the digest section <NUM> of the patient summary interface <NUM>. The alert status section <NUM> may also display textual information regarding the state of the other glucose conditions (e.g., "Hypo risk", "Hyper Frequency", and "Variability").

The glucose alert detection module <NUM> may be configured to determine the glucose conditions periodically, when a new bG measurement is received, or when the user activates a particular user interface, such as the patient summary interface <NUM>. For each of the glucose conditions, the glucose alert detection module <NUM> stores at least one glucose threshold and an alert threshold. The glucose threshold assess whether a given bG level is within a desirable range. The alert threshold determines the state of the glucose condition or, in other words, whether the glucose condition is within an acceptable range.

By way of example, when the glucose condition is a bG hypoglycemia frequency, the glucose alert detection module <NUM> determines the total number of occurrences in which the patient's bG measurement is below a bG hypo-target threshold. More particularly, the glucose alert detection module <NUM> compares a given bG measurement to the bG hypo-target threshold (e.g., <NUM>/dL or other suitable threshold). The bG hypo-target threshold may be set by the user or by the diabetes management system <NUM>. If the given bG measurement is less than or equal to the bG hypo-target threshold, the glucose alert detection module <NUM> determines the occurrence of a hypoglycemic condition. If the given bG measurement is greater than the bG hypo-target threshold, the glucose alert detection module <NUM> determines the patient is not hypoglycemic. The glucose alert detection module <NUM> performs the comparison for each bG measurement taken in the enquiry period, which are stored in the diabetes management system <NUM>.

The glucose alert detection module <NUM> then determines the total number of hypoglycemic occurrences for the enquiry period. The state of the hypoglycemia frequency may be determined based on the total number of hypo-occurrences and/or by a hypo-occurrence percentage. For the hypo-occurrence percentage, the glucose alert detection module <NUM> divides the total number of hypoglycemic occurrences by the total number of bG measurements taken during the enquiry period, and multiplies the ratio by <NUM>.

To determine the state of the hypoglycemia frequency for the patient, the glucose alert detection module <NUM> compares the total hypo-occurrences and/or the hypo-occurrence percentage to respective alert thresholds. For example, the hypo-occurrence percentage is compared to an occurrence percentage alert threshold and the total hypo-occurrences is compared to an occurrence number threshold. If the hypo-occurrence percentage is greater than or equal to the occurrence percentage threshold, the hypoglycemia frequency is considered over an acceptable range and the state of the hypoglycemia frequency is determined as HIGH. If the hypo-occurrence percentage is less than the occurrence percentage threshold, the hypoglycemia frequency is considered within the acceptable range and the state of the hypoglycemia frequency is determined as LOW. Similarly, if the total hypo-occurrences is greater than or equal to the occurrence number threshold, the state of the hypoglycemia frequency is determined as HIGH, and if the total hypo-occurrences is less than the occurrence number threshold, the state of the hypoglycemia frequency is determined as LOW. The glucose alert detection module <NUM> issues an alert for the hypoglycemia frequency when at least one of the hypo-occurrence percentage or the total hypo-occurrences are determined as HIGH. It is envisioned that alerts may be further delineate by visual indicators, for example a red arrow may be placed adjacent to the glucose condition determined to be HIGH (i.e., hypofrequency in <FIG>); whereas, an indicia adjacent to a glucose condition determined to be LOW or INSUFF DATA may be greyed out. Other types of delineations are contemplated by this disclosure.

<FIG> illustrates a flowchart of an example glucose alert determination routine performed by the diabetes management system <NUM>. At <NUM>, the routine determines whether an enquiry period is received. The enquiry period may be set by the user via the patient summary interface <NUM> or the initial enquiry period may be set by the diabetes management system <NUM> (e.g., two weeks). At <NUM>, the glucose measurements taken during the enquiry period is acquired from the database of the diabetes management system <NUM>.

At <NUM>, the routine determines the glucose conditions using the bG measurements and determines the state of each of the glucose conditions based on an alert threshold for respective glucose condition. For example, <FIG> illustrate exemplary set of guidelines that may be executed by the diabetes management system <NUM> for determining the glucose condition and determining the state of the glucose condition. While specific guidelines are illustrated for determining the hypoglycemia frequency, the hypoglycemia risk, the hyperglycemia frequency, the hyperglycemia risk, and/or the blood glucose variability, other guidelines and/or standards may be used to determine these glucose conditions.

At <NUM>, the routine determines whether the state for any one of the glucose conditions is determined as HIGH or, in other words, over an acceptable range. If one of the glucose conditions is HIGH, the routine, at <NUM>, determines that an alert should be issued and outputs, at <NUM>, alert status information for the patient summary interface <NUM>. The alert status information may include information identifying each of the glucose conditions and the status for each of the glucose conditions. When the alert is to be issued, the diabetes management system <NUM> displays the alert status section <NUM> in the patient summary interface <NUM>.

If none of the glucose conditions have a HIGH state, the routine, at <NUM>, determines no alert needs to be issued and the routine ends. Since there is no alert, the diabetes management system <NUM> does not display the alert status section <NUM> in the patient summary interface <NUM>. In other embodiments, if no alerts need to be issued, the diabetes management system <NUM> may still opt to display the alert status section <NUM> in the patient summary interface <NUM>. In this case, indicia adjacent each glucose condition is greyed out.

The glucose condition includes: the hypoglycemia frequency, hypoglycemia risk (LGBI), hyperglycemia frequency, hyperglycemia risk (HBGI), and blood glucose variability. However, other parameters that indicate the level or trend of the bG level may be used and is not limited to the glucose conditions described herein.

The alert threshold, which is used for determining the state of the glucose condition for the patient, may be predetermined and fixed or may be adjustable by the user. For example, <FIG> indicate whether the alert threshold for a respective glucose condition is fixed or adjustable. With reference to <FIG>, the user may change an adjustable alert threshold by way of an alert setting interface <NUM>. The alert setting interface <NUM> defines the different glucose conditions and the respective alert threshold. As illustrated, an alert threshold that may be adjusted is provided with an input text interface <NUM> (e.g., alert thresholds for hypo-frequency, hyper-frequency, and variability), and an alert threshold that is fixed includes textual information <NUM> to indicate the threshold (e.g., alert threshold for hypo-risk and hyper risk).

The patient and the healthcare provider may both change the alert thresholds for their respective profiles. That is, in the example embodiment, the healthcare provider may not change the alert threshold for the patient, but may be able to recommend a new threshold by notifying the patient by way of, for example, an electronic message or phone call. In another example embodiment, the alert threshold set by healthcare provider may supersede an alert threshold set by the patient.

The healthcare provider may view the patient summary interface <NUM> or another interface that conveys similar information for a given patient. The healthcare provider may be linked with multiple patients via the diabetes management system <NUM>. Accordingly, each patient may have different alert statuses due to one or more HIGH state glucose conditions. The patient prioritization module <NUM> sorts and prioritizes the healthcare provider's patients based on the alert status of each of the patient. As an example, <FIG> illustrates a healthcare provider (HCP) welcome interface <NUM> that includes a prioritized list <NUM> of patients determined by the patient prioritization module <NUM>.

The patient prioritization module <NUM> utilizes an alert sort algorithm for prioritizing the patients based on the alerts status. Specifically, the alert sort algorithm pre-assigns a weight factor for each glucose condition and for each possible state of a given glucose condition. As an example, <FIG> illustrates a condition weight table that lists the assigned weight for each glucose condition and <FIG> illustrates a state weight table that lists the assigned weight for each state. In the example embodiment, the glucose conditions are weighted such that the hypoglycemia frequency is assigned the highest weight followed by the hypoglycemia risk, then the hyperglycemia frequency/risk, and then the variability. With regard to the states, the HIGH state is given the highest weight followed by the LOW state and then the insufficient data.

<FIG> illustrates a condition-state weight table that provides an effective weight for a particular glucose condition and state combination. The effective weight is equal to the weight factor for the glucose condition multiplied by the weight factor for the state. For example, a hypoglycemia frequency having a HIGH state has an effective weight equal to <NUM>,<NUM> (i.e., <NUM> X <NUM>,<NUM>=<NUM>,<NUM>).

To prioritize the patients, the patient prioritization module <NUM> determines a total alert weight. Specifically, using the state determined for each glucose condition by the glucose prioritization module <NUM>, the patient prioritization module <NUM> determines the effective weight for each glucose condition and sums the effective weight to determine the total alert weight for the patient. As an example, if the glucose prioritization module <NUM> determines that the hyperglycemia frequency is HIGH, the hyperglycemia risk is LOW, the hypoglycemia frequency and risk are LOW, and the variability is LOW, the patient prioritization module <NUM> determines the effective weights as: Hyper-Freq = <NUM>, Hyper-risk = <NUM>, Hypo-Freq = <NUM>, Hypo-Risk = <NUM>, and Variability = <NUM>. The total alert weight for the patient is determined as the sum of the effective weights, which is equal <NUM>,<NUM>. The patient prioritization module <NUM> determines the total alert weight for each patient associated with the healthcare provider.

Based on the total alert weight for each of the patients, the patient prioritization module sorts the patients into different groups based on the total alert weight. For example, <FIG> illustrates a group criteria table that identifies multiple groups (Groups <NUM>-<NUM>) and ranks each of the groups such that Group <NUM> > Group <NUM> >. > Group <NUM>. The group criteria table also provides the minimum and maximum alert weights for each group. Accordingly, based on the total alert weight for a given patient, the patient prioritization module <NUM> sorts the patients into one of the six groups. For example, the patient having a total alert weight of <NUM>,<NUM> is sorted into Group <NUM>.

The patient prioritization module <NUM> then displays the patients such that the patients sorted in Group <NUM> are listed first, followed by the patients in Group <NUM>, then Group <NUM>, then Group <NUM>, then Group <NUM>, and finally Group <NUM>. If there are multiple patients in each group, the patient prioritization module <NUM> may list the patients from highest to lowest total alert weight, and if two patients have the same total alert weight the patient prioritization module <NUM> may list the patients in alphabetical order.

Once sorted and prioritized, the diabetes management system <NUM> displays the list on the HCP welcome interface <NUM> as the prioritized list <NUM>. The prioritized list <NUM> may also display an alert summary section <NUM> for each of the patient's. The alert summary <NUM> is indicative of the information provided in the alert status section <NUM> of the patient summary interface <NUM> if available.

<FIG> illustrates a flowchart of a prioritization routine performed by the diabetes management system <NUM>. At <NUM>, the routine determines the total alert weight for each patient based on the state determined for each glucose condition and predefined weight factors. For example, the effective weight for each glucose condition is determined based on the predefined weight factors, and the effective weights for all of the glucose conditions is summed together to generate the total alert weight. At <NUM>, the routine sorts the patients based on the total alert weight. In the example embodiment, the patients are sorted into one of six groups. However, different number of groups may be defined and should not be limited to six predefined groups. Finally, at <NUM>, the routine organizes and lists the patients based on the group, then the total weight factor for the patient, and then last name of the patient.

Spatial and functional relationships between elements (for example, between modules) are described using various terms, including "connected," "engaged," "interfaced," and "coupled. " Unless explicitly described as being "direct," when a relationship between first and second elements is described in the above disclosure, that relationship encompasses a direct relationship where no other intervening elements are present between the first and second elements, and also an indirect relationship where one or more intervening elements are present (either spatially or functionally) between the first and second elements. As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A OR B OR C), using a non-exclusive logical OR, and should not be construed to mean "at least one of A, at least one of B, and at least one of C.

In this application, including the definitions below, the term 'module' or the term 'controller' may be replaced with the term 'circuit. ' The term 'module' may refer to, be part of, or include processor hardware (shared, dedicated, or group) that executes code and memory hardware (shared, dedicated, or group) that stores code executed by the processor hardware.

Shared processor hardware encompasses a single microprocessor that executes some or all code from multiple modules. Group processor hardware encompasses a microprocessor that, in combination with additional microprocessors, executes some or all code from one or more modules. References to multiple microprocessors encompass multiple microprocessors on discrete dies, multiple microprocessors on a single die, multiple cores of a single microprocessor, multiple threads of a single microprocessor, or a combination of the above.

Shared memory hardware encompasses a single memory device that stores some or all code from multiple modules. Group memory hardware encompasses a memory device that, in combination with other memory devices, stores some or all code from one or more modules.

The term memory hardware is a subset of the term computer-readable medium. The term computer-readable medium, as used herein, does not encompass transitory electrical or electromagnetic signals propagating through a medium (such as on a carrier wave); the term computer-readable medium is therefore considered tangible and non-transitory. Non-limiting examples of a non-transitory computer-readable medium are nonvolatile memory devices (such as a flash memory device, an erasable programmable read-only memory device, or a mask read-only memory device), volatile memory devices (such as a static random access memory device or a dynamic random access memory device), magnetic storage media (such as an analog or digital magnetic tape or a hard disk drive), and optical storage media (such as a CD, a DVD, or a Blu-ray Disc).

The apparatuses and methods described in this application may be partially or fully implemented by a special purpose computer created by configuring a general purpose computer to execute one or more particular functions embodied in computer programs. The functional blocks and flowchart elements described above serve as software specifications, which can be translated into the computer programs by the routine work of a skilled technician or programmer.

The computer programs include processor-executable instructions that are stored on at least one non-transitory computer-readable medium. The computer programs may also include or rely on stored data. The computer programs may encompass a basic input/output system (BIOS) that interacts with hardware of the special purpose computer, device drivers that interact with particular devices of the special purpose computer, one or more operating systems, user applications, background services, background applications, etc..

Claim 1:
A computer implemented method for prioritizing patients associated with a healthcare provider, comprising:
- determining, by a diabetes management system, one or more glucose conditions for each patient in a plurality of patients associated with the healthcare provider, wherein each of the one or more glucose conditions is indicative of a glucose level of the patient and is assigned a condition weight, wherein the one or more glucose conditions are selected from a group consisting of a hypoglycemic condition, a hyperglycemic condition and a variability condition;
- determining, by the diabetes management system, a state for each glucose condition associated with a given patient using an alert threshold,
wherein:
- the state for a given glucose condition is selected from a group consisting of a HIGH state, a LOW state, and an unavailable state,
- the LOW state indicates that the glucose condition is within an acceptable range,
- the HIGH state indicates that the glucose condition is outside the acceptable range, and
- the unavailable state indicates insufficient data is available in the enquiry period to determine the state of the glucose condition,
- each state is assigned a state weight, the alert threshold is indicative of an acceptable range for the glucose condition, and the determination of a state is made for each patient in the plurality of patients;
- determining, by the diabetes management system, a total alert value for each patient in the plurality of patients by summing together the product of the condition weight and the state weight for each of glucose condition associated with a given patient; and
- displaying, by the diabetes management system, a listing of the patients on a display of a computing device, where the patients are arranged in accordance with the total alert value, wherein the patients in the listing of the patients are arranged in descending order in accordance with the total alert value.