US20240029853A1 - Managing Insulin Administration - Google Patents

Abstract

A method includes obtaining blood glucose measurements and blood glucose times of a patient from a blood glucose meter and executing a patient management program configured to display on a screen a graphical user interface having a trend window of the blood glucose measurements on the time line. The patient management program is configured to receive, in the trend window magnifying inputs for a magnification window superimposed on a segment of the timeline to specify a date range for a magnified window. The patient management program is further configured to display the magnified window including the blood glucose measurements of the patient from the specified date range and display a first information window including quantitative information associated with the blood glucose measurements from the specified date range.

Description

CROSS REFERENCE TO RELATED APPLICATIONS
• This U.S. patent application is a continuation of, and claims priority under 35 U.S.C. § 120 from, U.S. patent application Ser. No. 29/788,571, filed on Jun. 24, 2021, which is a continuation of U.S. patent application Ser. No. 15/610,187, filed on May 31, 2017, which claims priority under 35 U.S.C. § 119(e) to U.S. Provisional Application 62/346,874, filed on Jun. 7, 2016. The disclosures of these prior applications are considered part of the disclosure of this application and are hereby incorporated by reference in their entirety.
TECHNICAL FIELD
• This disclosure relates to a system for managing insulin administration or insulin dosing.
BACKGROUND
• Managing diabetes requires calculating insulin doses for maintaining blood glucose measurements within desired ranges. Managing diabetes requires calculating insulin doses for maintaining blood glucose measurements within desired ranges. Manual calculation may not be accurate due to human error, which can lead to patient safety issues. Different institutions use multiple and sometimes conflicting protocols to manually calculate an insulin dosage. Moreover, the diabetic population includes many young children or elderly persons whom have difficulty understanding calculations for insulin doses.
SUMMARY
• One aspect of the disclosure provides a method for managing insulin administration or insulin dosing. The method includes obtaining, at data processing hardware, blood glucose measurements of a patient and blood glucose times associated with a time of measuring each blood glucose measurement from a blood glucose meter associated with the patient, and executing, at the data processing hardware, a patient management program configured to display on a screen in communication with the data processing hardware a graphical user interface having a trend window of the blood glucose measurements on a timeline. The patient management program is configured to receive, in the trend window, magnifying inputs from a medical professional for a magnification window superimposed on a segment of the timeline to specify a date range for a magnified window and display, in the graphical user interface, the magnified window including the blood glucose measurements of the patient from the specified date range. The blood glucose measurements of the magnified window include interactive points within associated ones of scheduled blood glucose time intervals based on the blood glucose times. The patient management program is also configured to display, in the graphical user interface, a first information window including quantitative information associated with the blood glucose measurements from the specified date range.
• Implementations of the disclosure may include one or more of the following optional features. In some implementations, the patient management program is configured to superimpose, in the graphical user interface, a first line on the magnified window representing an upper blood glucose limit of a target blood glucose range and superimpose, in the graphical user interface, a second line on the magnified window representing a lower blood glucose limit of the target blood glucose range. The interactive points associated with the blood glucose measurements within the target blood glucose range may display as a first representation, the interactive points associated with the blood glucose measurements greater than the upper blood glucose limit display as a second representation, and the interactive points associated with the blood glucose measurements less than the lower blood glucose limit display as a third representation or the second representation.
• In some examples, the patient management program is configured to, in response to receiving the magnifying inputs, determine a representative average blood glucose value for each of the scheduled blood glucose time intervals and superimpose, in the graphical user interface, an average blood glucose graphic on the magnified window based on the representative average blood glucose values for the scheduled blood glucose time intervals. The patient management program may also be configured to receive, in the magnified window, filtering inputs from the medical professional to define a specified time range for the magnified window, query memory hardware in communication with the data processing hardware to obtain quantitative information related to the blood glucose measurements within the specified time range of the magnified window, and display, in the graphical user interface, a second information window including the quantitative information related to the blood glucose measurements within the specified time range of the magnified window. The interactive points associated with the blood glucose measurements within the specified time range of the magnified window may display as a first representation and the blood glucose measurements outside the specified time range of the magnified window display as a second representation different from the first representation.
• In some implementations, the patient management program may receive the filtering inputs from the medical professional when the medial professional manipulates a first interactive cursor superimposed on the magnified window to set a lower time limit for the specified time range of the magnified window and/or manipulates a second graphical cursor superimposed on the magnified window to set an upper time limit for the specified time range of the magnified window. The patient management program may also be configured to, in response to the medical professional selecting one of the interactive points on the magnified window: illuminate the selected interactive point of the magnified window; query memory hardware in communication with the data processing hardware to obtain quantitative information related to the blood glucose measurement associated with the selected interactive point; and display a pop-up window including the quantitative information related to the blood glucose measurement associated with the selected interactive point.
• The quantitative information may include at least one of an average blood glucose value, an aggregated blood glucose value for each of the scheduled blood glucose time intervals, a hemoglobin A1c value, an average number of blood glucose measurements per day, an average total daily dose of insulin, or average doses of insulin injected by the patient during each of the scheduled blood glucose time intervals. Obtaining the blood glucose measurements of the patient may include receiving, at the data processing hardware, the blood glucose measurements of the patient and the blood glucose times from a patient device in communication with the data processing hardware and the blood glucose meter.
• Another aspect of the disclosure provides a second method for managing insulin administration or insulin dosing. The method includes obtaining, at data processing hardware, blood glucose measurements of a patient and blood glucose times associated with a time of measuring each blood glucose measurement from a blood glucose meter associated with the patient and executing, at the data processing hardware, a patient management program configured to display on a screen in communication with the data processing hardware a graphical user interface having a trend window of the blood glucose measurements on a timeline. The patient management program is configured to receive, in the trend window, magnifying inputs from a medical professional for a magnification window superimposed on a segment of the timeline to specify a date range for a magnified window and display, in the graphical user interface, the magnified window including the blood glucose measurements of the patient from the specified date range. The blood glucose measurements of the magnified window includes a blood glucose plot extending through each date of the specified date range. The patient management program is also configured to display, in the graphical user interface, a first information window including quantitative information associated with the blood glucose measurements from the specified date range.
• This aspect may include one or more of the following optional features. In some implementations, the patient management program is configured to, in response to receiving the magnifying inputs determine an estimated hemoglobin A1c value for each date of the specified date range and superimpose, in the graphical user interface, an average hemoglobin A1c graphic on the magnified window based on the estimated hemoglobin A1c values of the specified date range. The patient management program may also be configured to, in response to receiving the magnifying inputs: determine a daily average blood glucose value for each date of the specified date range; and superimpose, in the graphical user interface, an average blood glucose graphic on the magnified window based on the daily average blood glucose values for the specified date range.
• In some examples, the patient management program is configured to: in response to receiving the magnifying inputs: query memory hardware in communication with the data processing hardware to obtain doses of insulin administered by the patient for each date of the specified date range; and superimpose, in the graphical user interface, a plot of the doses of insulin administered by the patient for each date of the specified date range on the magnified window. The patient management program may also be configured to display, in the graphical user interface, a communication window including a history of communications with the patient. The patient management program may further be configured to display, in the graphical user interface, a monitoring window including a list of patients under the supervision of the medical professional. In some implementations, the patient management program is configured to: determine an alert condition for one of the patients when a most recent blood glucose measurement of the patient is less than a hypoglycemia blood glucose threshold or greater than a hyperglycemia blood glucose threshold; and superimpose, in the graphical user interface, an alert graphic on the monitoring window proximate to the patient associated with the alert condition. The alert graphic includes a value of the most recent blood glucose measurement associated with the alert condition.
• Yet another aspect of the disclosure provides a third method for managing insulin administration or insulin dosing. The method includes receiving, at data processing hardware, a current blood glucose measurement of a patient from a patient device. The patient device executes an insulin management program configured to: display, on a patient screen of the patient device, a blood glucose input field; receive, at the blood glucose input field, the current blood glucose measurement; and transmit the current blood glucose measurement and a blood glucose time associated with a time of measuring the current blood glucose measurement to the data processing hardware. In response to receiving the current blood glucose measurement, the method includes obtaining, by the data processing hardware, blood glucose parameters associated with the patient from memory hardware in communication with the data processing hardware. The blood glucose parameters include a hypoglycemia blood glucose value, a target blood glucose value greater than the hypoglycemia blood glucose value, and a correction factor. The method also includes comparing, by the data processing hardware, the current blood glucose measurement to the blood glucose parameters. When the current blood glucose measurement is less than the hypoglycemia blood glucose value, the method includes transmitting a low blood glucose alert notification from the data processing hardware to the patient device. The low blood glucose alert notification, when received by the patient device, causes the insulin management program to render a hypoglycemia view on the patient screen. The hypoglycemia view displays: hypoglycemia patient instructions to treat a hypoglycemia episode associated with the current blood glucose measurement; a countdown timer indicating a remaining amount of time until the patient is instructed to attain a subsequent blood glucose measurement; and one or more patient-selectable hypoglycemia buttons each indicating respective ones of potential causes for the hypoglycemia episode.
• This aspect may include one or more of the following optional features. In some implementations, prior to receiving the current blood glucose measurement, the method includes determining, by the data processing hardware, whether a current time is within a scheduled blood glucose time interval requiring the current blood glucose measurement. When the current time is within the scheduled blood glucose time interval requiring the current blood glucose measurement, the method may include transmitting a blood glucose request notification from the data processing hardware to the patient device during the scheduled blood glucose time interval. The blood glucose request notification, when received by the patient device, may cause the insulin management program to display the blood glucose request notification on the patient screen. The blood glucose request notification may instruct the patient to attain the current blood glucose measurement. The blood glucose request notification may include an interactive graphic or user-selectable link and the insulin management program may be configured to display the blood glucose input field on the patient screen in response to the patient selecting the blood glucose request notification.
• In some examples, the insulin management program executing on the patient device is configured to display a patient-selectable meal type button on the patient screen indicating a meal type when the patient is consuming a meal based on the blood glucose time. Selecting the meal type button by the patient may cause the insulin management program to prompt the patient to input a meal size for the meal type and transmit the input meal size to the data processing hardware. The patient device may also be configured to display a patient-selectable non-meal button on the patient screen indicating that the current blood glucose measurement is dissociated from the meal type indicated by the patient-selectable meal type button. Selecting the non-meal button by the patient may cause the insulin management program to prompt the patient to input a rational for obtaining the current blood glucose measurement and transmit the input rational to the data processing hardware. The insulin management program may display the blood glucose input field, the patient-selectable meal type button, and the patient-selectable non-meal button in a common view on the patient screen. The meal type may include at least one of a pre-breakfast blood glucose measurement, a pre-lunch blood glucose measurement, a pre-dinner blood glucose measurement, or a bedtime blood glucose measurement. The pre-breakfast, pre-lunch, pre-dinner, and bedtime blood glucose measurements may be scheduled in a daily repetitive rotational order.
• When the current blood glucose measurement is greater than the target blood glucose value, the method may include determining, by the data processing hardware, a correction dose for the patient based on a function of the current blood glucose measurement, the target blood glucose value, and the correction factor. The method may also include transmitting the correction dose for the patient from the data processing hardware to the patient device. The correction dose when received by the patient device, may cause the insulin management program to display a value of the correction dose on the patient screen.
• After receiving the current blood glucose measurement of the patient, the method may include obtaining, by the data processing hardware, a meal type for the patient based on the blood glucose time associated with the time of measuring the current blood glucose measurement and receiving a meal size for the meal type at the data processing hardware from the patient device. The patient device may receive the meal size at a meal size input displayed by the insulin management program on the patient screen. The method may also include determining, by the data processing hardware, a recommended meal bolus for the patient based on the meal size and the meal type and transmitting the recommended meal bolus from the data processing hardware to the patient device. The recommended meal bolus, when received by the patient device, may cause the insulin management program to display on the patient screen: a value of the recommended meal bolus; a recommended total dosage of insulin for the patient based on a sum of the values of the recommended meal bolus and the correction dose; and a patient-selectable change dosage button enabling the patient to change the recommended total dosage of insulin when the patient selects the patient-selectable change dosage button.
• In some examples, the patient inputs the meal size to the patient device by selecting one of multiple meal size buttons displayed on the patient screen, each meal size button corresponding to a respective meal size associated with the meal type. The patient may input the meal size to the patient device by inputting a number of carb exchanges associated with the meal type. The patient may input the meal size to the patient device by inputting an amount of carbohydrates associated with the meal type.
• The details of one or more implementations of the disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will be apparent from the description and drawings, and from the claims.
DESCRIPTION OF DRAWINGS
• FIG.1 is a schematic view of an exemplary system for monitoring blood glucose levels of a patient.
• FIG.2 is a schematic view of an exemplary program for managing the blood glucose level of a patient.
• FIGS.3A and3B are schematic views of exemplary components of the system ofFIG.1.
• FIGS.4A-4C are schematic views of example graphical user interfaces displaying blood glucose data for a patient.
• FIGS.5A and5B are schematic views of example graphical user interfaces displaying insulin dosing information for a patient.
• FIGS.6A-6C are schematic views of example graphical user interfaces for logging blood glucose measurements.
• FIGS.7A-7D are schematic views of example graphical user interfaces for determining a meal bolus for a patient.
• FIGS.8A and8B are schematic views of example graphical user interfaces for determining a meal bolus for a patient.
• FIGS.9A and9B are schematic views of example graphical user interfaces prompting a patient to provide a rational for obtaining a blood glucose measurement not associated with a scheduled meal type.
• FIGS.10A-10C are schematic views of example graphical user interfaces displaying a hypoglycemic view when a patient's blood glucose is less than a hypoglycemic blood glucose value.
• FIGS.11A-11E are schematic views of example graphical user interfaces displaying a timeline of blood glucose measurements for a patient.
• FIG.12 is a schematic view of an example graphical user interface displaying a dashboard of a list of patients under the supervision of a healthcare professional.
• Like reference symbols in the various drawings indicate like elements.
DETAILED DESCRIPTION
• Persons with diabetes must manage their blood glucose level within desired ranges, typically by using multiple daily injections (MDI) therapy that includes injection doses of long-acting (basal) insulin, bolus insulin at meals and correction bolus injections during other periods of hyperglycemia. Insulin doses must be individualized for each patient. Too much insulin can cause hypoglycemia, coma, and death; too little insulin can cause hyperglycemia and other complications. Providers often use a variety of methods to adjust a patient's insulin dose: some may use formulas of their own; some may use paper protocols that are complex and difficult for the patients to follow, leading to a high incidence of human error; and some may use heuristic methods. Moreover, patients must periodically make clinical visits to adjust their treatment plan based on historical blood glucose information since their last visit. Therefore, it is desirable to have a clinical support system100 (FIG.1) that remotely monitors a patient's blood glucose level and enables healthcare providers to communicate treatment plans, or modifications thereto, to their patients on a day-by-day basis.
• Referring toFIG.1, in some implementations, a clinicaldecision support system100 analyzes inputted patient condition parameters for one ormore patients10 and calculates a personalized dose of insulin to bring and maintain each patient's blood glucose level into a target blood glucose range BG_TR. As used herein, thepatient10 refers to an outpatient that may be located at some remote location, such as the patient's residence or place of employment. As used herein, the term “clinical” may refer to a hospital call center. Thesystem100 may monitor the glucose levels of apatient10 and calculate a recommended subcutaneous insulin dose to bring the patient's blood glucose into the preferred target range BG_TRover a recommended period of time. Moreover, thesystem100 provides notifications to the patient10 that include hypoglycemia patient instructions to bring the patient's blood glucose into the target range BG_TRwhen the patient's blood glucose is below a hypoglycemia blood glucose value and blood glucose request notifications requesting the patient10 to attain a blood glucose measurement during a scheduled blood glucose time interval as indicated by the patient condition parameters input to thesystem10. A qualified and trained healthcare professional (HCP) may use thesystem100 along with clinical reasoning to determine the proper dosing administered to apatient10. Therefore, thesystem100 is a glycemic management tool for evaluation of a patient's current and cumulative blood glucose value BG while taking into consideration the patient's information such as age, weight, and height. Thesystem100 may also consider other information such as carbohydrate content of meals, insulin doses being administered to thepatient10, e.g., long-acting insulin doses for basal insulin and rapid-acting insulin doses for meal boluses and correction boluses. Based on those measurements (that may be stored innon-transitory memory24,114,144), thesystem100 recommends a subcutaneous basal and bolus insulin dosing recommendation or prescribed dose to adjust and maintain the blood glucose level towards a configurable (based on the patient's information) physician's determined blood glucose target range BG_TR. Thesystem100 also considers a patient's insulin sensitivity or improved glycemic management and outcomes. Thesystem100 may take into account pertinent patient information such as demographics and previous results, leading to a more efficient use of healthcare resources. Finally, thesystem100 provides a reporting platform for reporting the recommendations or prescribed dose(s) to theuser40 and thepatient10. In addition, thesystem100 provides faster, more reliable, and more efficient insulin administration than a human monitoring the insulin administration. Thesystem100 reduces the probability of human error and insures consistent treatment, due to the system's capability of storing and tracking the patient's blood glucose levels BG, which may be used for statistical studies. Thesystem100 provides a meal-by-meal adjustment of Meal Boluses without carbohydrate counting, by providing a dedicated subprogram that adjusts meal boluses based on the immediately preceding meal bolus and the BG that followed it. Thesystem100 provides a meal-by-meal adjustment of Meal Boluses with carbohydrate counting by providing a dedicated subprogram that adjusts meal boluses based a Carbohydrate-to-Insulin Ratio (CIR) that is adjusted at each meal, based on the CIR used at the immediately preceding meal bolus and the BG that followed it.
• Thesystem100 may also enable theHCP40, or multiple HCPs, to view blood glucose measurements and doses of insulin for one ormore patients10. For instance, the HCP may view a trend window of blood glucose measurements on a timeline and interactively specify date ranges over the timeline to view at least the blood glucose measurements for a givenpatient10 during the specified date ranges. Additionally, thesystem100 may alert theHCP40 when apatient10 under the HCP's40 care has a low blood glucose measurement or has not entered his/her blood glucose measurement during a scheduled blood glucose time interval as indicated by the patient condition parameters input to thesystem100. For example, thesystem100 may alert theHCP40 when a lunchtime blood glucose measurement has not been received from one of the patients. Thereafter, theHCP40 may send a blood glucose request notification requesting the patient10 to attain the lunchtime blood glucose measurement. Alternatively, thesystem100 may automatically send the blood glucose request notification when the lunchtime blood glucose measurement has not been received.
• Hyperglycemia is a condition that exists when blood sugars are too high. While hyperglycemia is typically associated with diabetes, this condition can exist in many patients who do not have diabetes, yet have elevated blood sugar levels caused by trauma or stress from surgery and other complications from hospital procedures. Insulin therapy is used to bring blood sugar levels back into a normal range.
• Hypoglycemia may occur at any time when a patient's blood glucose level is below a preferred target. Appropriate management of blood glucose levels for critically ill patients reduces co-morbidities and is associated with a decrease in infection rates, length of hospital stay, and death. The treatment of hyperglycemia may differ depending on whether or not a patient has been diagnosed withType1 diabetes mellitus,Type2 diabetes mellitus, gestational diabetes mellitus, or non-diabetic stress hyperglycemia. The blood glucose target range BG_TRis defined by a lower limit, i.e., a low target B GIRL and an upper limit, i.e., a high target BGTRH.
• Diabetes Mellitus has been treated for many years with insulin. Some recurring terms and phrases are described below:
• Injection: Administering insulin by means of manual syringe or an insulin “pen,” with a portable syringe named for its resemblance to the familiar writing implement.
• Infusion: Administering insulin in a continuous manner by means of an insulin pump forsubcutaneous insulin apparatus123acapable of continuous administration.
• Basal-Bolus Therapy: Basal-bolus therapy is a term that collectively refers to any insulin regimen involving basal insulin and boluses of insulin.
• Basal Insulin: Insulin that is intended to metabolize the glucose released by a patient's the liver during a fasting state. Basal insulin is administered in such a way that it maintains a background level of insulin in the patient's blood, which is generally steady but may be varied in a programmed manner by aninsulin pump123a. Basal insulin is a slow, relatively continuous supply of insulin throughout the day and night that provides the low, but present, insulin concentration necessary to balance glucose consumption (glucose uptake and oxidation) and glucose production (glucogenolysis and gluconeogenesis). A patient's Basal insulin needs are usually about 10 to 15 mU/kg/hr and account for 30% to 50% of the total daily insulin needs; however, considerable variation occurs based on thepatient10.
• Bolus Insulin: Insulin that is administered in discrete doses. There are two main types of boluses, Meal Bolus and Correction Bolus.
• Meal Bolus: Taken just before a meal in an amount which is proportional to the anticipated immediate effect of carbohydrates in the meal entering the blood directly from the digestive system. The amounts of the Meal Boluses may be determined and prescribed by aphysician40 for each meal during the day, i.e., breakfast, lunch, and dinner. Alternatively, the Meal Bolus may be calculated in an amount generally proportional to the number of grams of carbohydrates in the meal. The amount of the Meal Bolus is calculated using a proportionality constant, which is a personalized number called the Carbohydrate-to-Insulin Ratio (CIR) and calculated as follows:
• 
  Meal Insulin Bolus={grams of carbohydrates in the meal}/CIR  (1)
• Correction Bolus CB: Injected immediately after a blood glucose measurement; the amount of the correction bolus is proportional to the error in the BG (i.e., the bolus is proportional to the difference between the blood glucose measurement BG and the patient's personalized Target blood glucose BG_Target). The proportionality constant is a personalized number called the Correction Factor, CF. The Correction Bolus is calculated as follows:
• 
  CB=(BG−BG_Target)/CF  (2)
• A Correction Bolus CB is generally administered in a fasting state, after the previously consumed meal has been digested. This often coincides with the time just before the next meal.
• In some implementations, blood glucose measurements BG are aggregated using an exponentially-weighted moving average EMAt as a function for each modal day's time interval BG. The EMAt is calculated as follows:
• 
  EMA_t=α(BG_t)+(1−α)EMA_t-1,  (3)
• 
  wherein:
• 
  α=2/(n+1),
• wherein n is the number of equivalent days averaged. In other embodiments, an arithmetic moving average is utilized that calculates the sum of all BG values in n days divided by a total count (n) of all values associated with the arithmetic average.
• There are several kinds of Basal-Bolus insulin therapy including Insulin Pump therapy and Multiple Dose Injection therapy:
• Insulin Pump Therapy: An insulin pump123ais a medical device used for the administration of insulin in the treatment of diabetes mellitus, also known as continuous subcutaneous insulin infusion therapy. The device includes: a pump, a disposable reservoir for insulin, and a disposable infusion set. Thepump123ais an alternative to multiple daily injections of insulin by insulin syringe or an insulin pen and allows for intensive insulin therapy when used in conjunction with blood glucose monitoring and carbohydrate counting. The insulin pump123ais a battery-powered device about the size of a pager. It contains a cartridge of insulin, and it pumps the insulin into the patient via an “infusion set”, which is a small plastic needle or “canula” fitted with an adhesive patch. Only rapid-acting insulin is used.
• Multiple Dose Injection (MDI): MDI involves the subcutaneous manual injection of insulin several times per day using syringes or insulin pens123b. Meal insulin is supplied by injection of rapid-acting insulin before each meal in an amount proportional to the meal. Basal insulin is provided as a once, twice, or three time daily injection of a dose of long-acting insulin. Other dosage frequencies may be available. Advances continue to be made in developing different types of insulin, many of which are used to great advantage with MDI regimens:
• Long-acting insulins are non-peaking and can be injected as infrequently as once per day. These insulins are widely used for Basal Insulin. They are administered in dosages that make them appropriate for the fasting state of the patient, in which the blood glucose is replenished by the liver to maintain a steady minimum blood glucose level.
• Rapid-acting insulins act on a time scale shorter than natural insulin. They are appropriate for boluses.
• Thesystem100 is configured to facilitate real-time communication between the patient10 and theHCP40 by evaluating a blood glucose level and nutritional intake of the patient10 to provide the patient10 with a recommended treatment plan for maintaining the patient's blood glucose level within the blood glucose target range BG_TR. For instance, based on the evaluation and analysis of the data, thesystem100 calculates an insulin dose, which is administered to the patient10 to bring and maintain the blood glucose level of the patient10 into the blood glucose target range BG R. Thesystem100 may be applied to various devices, including, but not limited to, subcutaneous insulin infusion pumps123a, insulin pens123b,glucometers124, continuous glucose monitoring systems, and glucose sensors.
• In some examples the clinicaldecision support system100 includes anetwork20, apatient device110, adosing controller160, aservice provider130, an HCPmedical record system140, and ameter manufacturer provider190. Thepatient device110 may include, but is not limited to,desktop computers110aor portableelectronic device110b(e.g., cellular phone, smartphone, smartwatch, personal digital assistant, barcode reader, personal computer, or a wireless pad) or any other electronic device capable of sending and receiving information via thenetwork20. In some implementations, one or more of the patient'sglucometer124, insulin pump123a, orinsulin pen123bare capable of sending and receiving information via thenetwork20.
• Thepatient device110a,110b, includesdata processing hardware112a,112b(e.g., a computing device that executes instructions), andnon-transitory memory114a,114band adisplay116a,116b(e.g., touch display or non-touch display) in communication with thedata processor112. Thedata processing hardware112 may execute apatient management program200 that allows the patient10 to input blood glucose measurements to thepatient device110 and transmit the blood glucose measurement over thenetwork20 to at least one of thedosing controller160, theservice provider130, the health care providermedical record system140, or themeter manufacturer provider190. In some implementations, thepatient management program200 is configured to graphically display (e.g., via a graphical user interface (GUI) on thedisplay116a,116) a recommended treatment on thepatient device110 for managing the patient's blood glucose level. In some examples, thepatient device110 includes akeyboard119,speakers122, microphones, mouse, and a camera.
• Theglucometer124, insulin pump123a, andinsulin pen123bassociated with the patient10 include adata processor112c(e.g., a computing device that executes instructions), andnon-transitory memory114cand adisplay116c(e.g., touch display or non-touch display in communication with thedata processor112c.
• Themeter manufacturer provider190 may include may include adata processor192 in communication withnon-transitory memory194. Thedata processor192 may execute aproprietary download program196 for downloading blood glucose BG data from thememory114cof the patient'sglucometer124. In some implementations, theproprietary download program196 is associated with thepatient management program200 and implemented on the HCP's140computing device142 or the patient's10device110afor downloading the BG data frommemory114c. In some examples, thedownload program196 exports a BG data file for storage in thenon-transitory memory24,114,144. Thedata processor192 may further execute a web-basedapplication198 for receiving and formatting BG data transmitted from one or more of the patient'sdevices110a,110b,124,123a,123band storing the BG data innon-transitory memory24,114,144.
• Theservice provider130 may include adata processor132 in communication withnon-transitory memory134. Theservice provider130 provides the patient10 and/or theHCP40 with the patient management program200 (e.g., a mobile application, a web-site application, or a downloadable program that includes a set of instructions) executable on aprocessor112,132,142 of thedosing controller160 and accessible through thenetwork20 via thepatient device110 and/or the health care provider electronicmedical record systems140. In some examples, thepatient management program200 is accessible through thenetwork20 via the portable blood glucose measurement devices124 (e.g., glucose meter or glucometer) orportable administration devices123a,123b.
• In some implementations, the HCPmedical record system140 is located at a doctor's office,clinic42, or a facility administered by a hospital (such as a hospital call center)) and includesdata processing hardware142, anon-transitory memory144, and a display146 (e.g., touch display or non-touch display). Thenon-transitory memory144 and thedisplay146 are in communication with thedata processing hardware142. Thedata processing hardware142 may execute thepatient management program200 for allowing theHCP40 to graphically view the patient's blood glucose measurements on thedisplay146 and provide a recommended treatment to thepatient10. In some examples, the HCP electronicmedical system140 includes akeyboard148 in communication with thedata processor142 to allow a user (e.g., the HCP40) to input data, such aspatient information208a(FIG.2). Thenon-transitory memory144 maintains patient records capable of being retrieved, viewed, and, in some examples, modified and updated by authorized hospital personal using thepatient management program200 and displaying on thedisplay146.
• Thedosing controller160 is in communication with theglucometer124,insulin administration device123a,123band includes acomputing device112,132,142 andnon-transitory memory114,134,144 in communication with thecomputing device112,132,142. Thedosing controller160 executes thepatient management program200. Thedosing controller160 stores patient related information obtained from thepatient device110, theglucometer124, and or the HCPmedical record system140 to determine insulin doses and dosing parameters based on the received blood glucose measurement BG.
• As used herein, thepatient management program200 may refer to computer software that causes acomputing device112,132 to perform a task. In some examples, thepatient management program200 may be referred to as an “application,” an “app,” or a “program.” Programs can be executed on a variety of computing devices, including mobile computing devices such as smart phones, tablets, and wearable computing devices (e.g., headsets and/or watches). Programs can also be executed on other types of computing devices having other form factors, such as laptop computers, desktop computers, or other consumer electronic devices. In some examples, programs may be installed on a computing device prior to a user/patient purchasing the device. In other examples, the patient/user may download and install applications on the computing device after purchasing the device.
• The administration device123 may include theinsulin pump123aor thepen123b. The administration device123 is in communication with theglucometer124 and includes acomputing device112 and non-transitory memory114 in communication with thecomputing device112. The administration device123 includes a doser in communication with theadministration computing device112 for administering insulin to the patient. For instance, theinsulin pump123aincludes an infusion set including a tube in fluid communication with an insulin reservoir and a cannula inserted into the patient's10 body and secured via an adhesive patch. Thepen123bincludes a needle for insertion into thepatients10 for administering insulin from an insulin cartridge. The administration device123 may receive and execute subcutaneous insulin treatment program selected by and transmitted from thedosing controller160. Theadministration devices123a,123bmay be “smart” administration devices capable of communicating with thedosing controller160 to populate recommended doses of insulin for administering to thepatient10. For instance, units for the doses of insulin may be automatically set or dialed in by theadministration device123a,123band administered to thepatient10.
• Thenetwork20 may include any type of network that allows sending and receiving communication signals, such as a wireless telecommunication network, a cellular telephone network, a time division multiple access (TDMA) network, a code division multiple access (CDMA) network, Global system for mobile communications (GSM), a third generation (3G) network, fourth generation (4G) network, a satellite communications network, and other communication networks. Thenetwork20 may include one or more of a Wide Area Network (WAN), a Local Area Network (LAN), and a Personal Area Network (PAN). In some examples, thenetwork20 includes a combination of data networks, telecommunication networks, and a combination of data and telecommunication networks. Thepatient device110, theservice provider130, and the hospital electronicmedical record system140 communicate with each other by sending and receiving signals (wired or wireless) via thenetwork20. In some examples, thenetwork20 provides access to cloud computing resources, which may be elastic/on-demand computing and/orstorage resources24 available over thenetwork20. The term cloud′ services generally refers to a service performed not locally on a user's device, but rather delivered from one or more remote devices accessible via one ormore networks20.
• Thepatient management program200 implement analarm system120 that alerts auser40 at the clinic42 (or hospital call center) when the patient's blood glucose level BG is outside the target range BG_TR. Thealarm system120 may produce an audible sound viaspeaker122 in the form of a beep or some like audio sounding mechanism. For instance, thealarm system120 may produce an audible sound via aspeaker122 of themobile device110b. In some examples, thealarm system120 displays a warning message or other type of indication on the display116 of thepatient device110 to provide a warning message. Thealarm system120 may also send the audible and/or visual notification via thenetwork20 to the clinic system140 (or any other remote station) for display on thedisplay146 of theclinic system140 or played throughspeakers152 of theclinic system140.
• Referring toFIG.2, theprogram200 receives parameters (e.g., patient condition parameters) inputted via theclient device110, theservice provider130, and/or theclinic system140, analyzes the inputted parameters, and determines a personalized dose of insulin to bring and maintain a patient's blood glucose level BG into a preferred target range BG_TRfor thepatient management program200. The patient management program may refer to a subcutaneous (SubQ)outpatient program200 orinsulin treatment program200 for treating adiabetic outpatient10 remotely by sending/receiving communications through thenetwork20.
• Theprogram200 prompts auser40 to inputpatient information208aatblock208. Theuser40 may input thepatient information208a, for example, via theuser device140 or via the health care providermedical record systems140 located at a clinic42 (or a doctor's office or HCP). Theuser40 may input newpatient information208aand theprogram200 may retrieve thepatient information208afrom thenon-transitory memory144 of the clinic's electronicmedical system140 or the non-transitory memory114 of the patient device110 (e.g., where thepatient information208awas previously entered and stored). Thepatient information208amay include, but is not limited to, a patient's name, a patient's identification number (ID), a patient's height, weight, date of birth, diabetes history, physician name, emergency contact, hospital unit, diagnosis, gender, room number, and any other relevant information.
• Theprogram200 flows to block216, where theuser40 enters patientsubcutaneous information216a(e.g., blood glucose parameters), such as bolus insulin type, target range, target BG value, hypoglycemia BG value, hyperglycemia BG value, correction factor (CF), basal insulin type and frequency of distribution (e.g., 1 dose per day, 2 doses per day, 3 doses per day, etc.), patient diabetes status, subcutaneous type ordered for the patient (e.g., Basal/Bolus and correction) that is intended for patients on a consistent carbohydrate diet, frequency of patient blood glucose measurements, or any other relevant information. In some implementations, the patientsubcutaneous information216ais prepopulated with default parameters, which may be adjusted or modified. When theuser40 enters the patientsubcutaneous information216a, the user selects theprogram200 to execute atblock226. The patientsubcutaneous information216amay further include a total daily dosage (TDD) calculated following a period on Intravenous Insulin in accordance with equation:
• 
  TDD=QuickTransitionConstant*M_Trans  (4A)
• where QuickTransitionConstant is usually equal to 1000, and M_Transis the patient's multiplier at the time of initiation of the SubQ transition process. In other implementations, the TDD is calculated by a statistical correlation of TDD as a function of body weight. The following equation is the correlation used:
• 
  TDD=0.5*Weight(kg)  (4B)
• In other implementations, the patient's total daily dose TDD is calculated in accordance with the following equation:
• 
  TDD=(BG_Target−K)*(M_Trans)*24  (4C)
• where M_Transis the patient's multiplier at the time of initiation of the SubQ transition process.
• In some implementations, theuser40 selects to initiate thepatient management program200 executing on thedosing controller160 to provide recommended insulin dosing (bolus/basal) for a patient10 to apatient device110 associated with thepatient10. Theuser40 may configure thepatient management program200 by selecting thepatient device110 used by thepatient10. Selection ofblock110aindicates information for the patient'sdesktop computer110a, including communication capabilities with other devices and/or thenetwork20. Selection ofblock110bindicates information for the patient's10smartphone110b, tablet or smart watch, including communication capabilities with theglucometer124 and/or theinsulin administration devices123a,123b, As used herein, a smartwatch or tablet can similarly be used to implement the same functionality as thesmartphone110bdescribed herein. For instance, thesmartphone110bmay communicate with theglucometer124 via Bluetooth or other connection to download BG data from thememory114cof the glucometer, and transmit the downloaded BG data through thenetwork20. In other examples, thesmartphone110bmay receive recommended insulin doses over thenetwork20 from thedosing controller160 and provide the recommended insulin doses to theglucometer124 and/orinsulin administration device123a,123b. Theuser40 may also select to execute thepatient management program200 on theuser device142 to receive blood glucose measurements and/or administered doses of inulin from the patient device. For instance, selection ofblock142 indicates information for theuser device142.
• FIGS.3A and3B areschematic views300a,300bof exemplary components of the system ofFIG.1. Referring toFIG.3A, in some implementations, thecomputing device112bof thesmart phone110bexecutes the patient management program200 (e.g., insulin management program) for communicating with thedosing controller160 such that information can be communicated over thenetwork20 between thedosing controller160 and thesmart phone110b. For example, thesmart phone110bmay transmitblood glucose data302 and a dose of insulin administered by the patient10 (e.g., dose administered304) to thedosing controller160 and stored within thememory hardware134,144. TheBG data302 includes aBG measurement127 and a BG time associated with a time of measuring each blood glucose measurement. In some examples, thedosing controller160 executing on theuser device132,142 transmits recommendeddosing information306 to thesmart phone110bbased on the obtained blood glucose data and dose administered304 by thepatient10. Thedosing information306 may include dosing parameters such as, but is not limited to: TargetBG, Correction Factor (CF), CIR for all day, CIR's for each meal, Recommended Breakfast Bolus, Recommended Lunch Bolus, Recommended Dinner Bolus, Recommended Basal doses, number of Basal doses per day, and Basal dose scheduled times. The dosing parameters may be adjusted automatically or manually initiated by theuser40 orpatient10. Thedosing controller160 may additionally transmit one ormore notifications308 to thesmart phone110bthat causes thesmart phone110bto graphically display content associated with eachnotification308 on thedisplay116b.
• Thepatient devices110 may use a variety ofdifferent operating systems202. In examples where thepatient device110 is thesmart phone110b, thesmart phone110bmay operate using an OS such as ANDROID® by Google, Inc., IOSO by Apple, Inc., or WINDOWS PHONE® by Microsoft Corporation. In an example where theuser device102 is a laptop or desktop computing device, theuser device102 may use an OS such as MICROSOFT WINDOWS® by Microsoft Corporation, MAC OS® by Apple, Inc., or LINUX® (LINUX® is the registered trademark of Linus Torvalds in the U.S. and other countries). Thepatient devices110 may also interact with thedosing controller160 using other operating systems.
• Thepatient management program200 enables thepatient device110 to interface with thedosing controller160 executing on theuser device142 or thecomputing device132 of theservice provider130. In some examples, thepatient management program200 is associated with an application dedicated to interfacing with thedosing controller160 via thenetwork20. In other examples, thepatient management program200 is associated with a more general application, such as a web browser application. In any case, thepatient management program200 executing on thecomputing device112 of thepatient device110 for communicating with thedosing controller160 includes a graphical user interface that displays a bloodglucose input field310 on the display116 for receiving a current blood glucose measurement input by the patient using a touchscreen, physical keyboard, a speech-to-text program, or other form of user input available on thepatient device110. Additionally or alternatively, thepatient management program200 may enable the patient device110 (e.g.,smart phone110b) to communicate with theglucometer124 for obtaining blood glucose measurements. For instance, theglucometer124 andsmart phone110bmay communicate via Bluetooth, infrared, cable, or any other communications. In some examples, theglucometer124 communicates with adata translator125, and thedata translator125 provides the blood glucose measurements from theglucometer124 to thesmart phone110b. The GUI may display the blood glucose measurements communicated from theglucometer124 ortranslator125.
• In some implementations, thesmart phone110brenders the BG measurement upon thedisplay116band transmits the BG data including the BG measurement and the BG time to thedosing controller160 via thenetwork20. In response to receiving the BG data from thesmart phone110b, thedosing controller160 executing on thecomputing device132,142 may calculate a correction bolus (CB) using EQ. 2 based upon the current correction factor (CF) and Target BG stored within thememory24,134,144. The CF and Target BG may be provided when a previous dosing parameter adjustment was transmitted to thesmart phone110bfrom thedosing controller160. Thereafter, thedosing controller160 transmits the CB within the recommendeddosing information306 to thesmart phone110b, and upon receiving the recommendeddosing information306, thepatient management program200 executing on thesmart phone110bcauses thesmart phone110bto display the recommendeddosing information306 upon thedisplay116b.
• In some examples, the GUI of thepatient management program200 provides a mealtype selection box312 that enables the patient10 to select a meal type associated with the BG measurement and the BG time and transmits the selected meal type in theBG data302 to thedosing controller160 via thenetwork20. For instance, the meal type for a given BG measurement may include at least one of a pre-breakfast blood glucose measurement, a pre-lunch blood glucose measurement, a pre-dinner blood glucose measurement, or a bedtime blood glucose measurement. In some implementations, thedosing controller160 determines a recommended meal bolus based on the meal type selected by thepatient10 and transmits the recommended meal bolus in the recommendeddosing information306 to thesmart phone110bvia thenetwork20. For instance, the recommendeddosing information306 displayed upon the display116 of thesmart phone110bmay include the CB (e.g., Correction1 u), the meal bolus (e.g., Lunch bolus6 u), and a total recommended dose (e.g.,7 u) based on a sum of the CB and the meal bolus.
• In some implementations, the insulin administration device123 associated with thepatient10 includes asmart pump123aor asmart pen123bthat is capable of communicating (e.g., syncing) with apatient device110 such as asmart phone110b. In the example shown, thesmart pen123bcommunicates with thesmart phone110bvia Bluetooth, however, other wireless or wired communications are possible. In some examples, thesmart pen123bautomatically dials in the total bolus for the doser223bto administer. In some examples, thesmart pen123breceives a recommended total bolus dose from thesmart phone110bbased on the recommendeddosing information306 transmitted from thecomputing device142 of thedosing controller160 via thenetwork20. In some examples, upon administration of an insulin dose by thesmart pen123b, thesmart pen123btransmits the value of the administered dose to thesmart phone110bfor storage withinmemory114aalong with the associated BG measurement. In other examples, the patient10 uses the GUI of thepatient management program200 to input the value of the dose administered304. Thesmart phone110bmay transmit the dose administered304 to thecomputing device132,142 of thedosing controller160 via the network for storage within thememory hardware134,144.
• Referring toFIG.3B, in some implementations, theuser device142 of theclinic system140 executes thepatient management program200 for communicating with thedosing controller160 such that information can be communicated over the network between thedosing controller160 and theuser device142. For example, theuser device142 may receive theBG data302 and the dose administered304 from thedosing controller160 via thenetwork20. In some examples, thecomputing device112 of thepatient device110 executes thedosing controller160 and transmits theBG data302 and/or the dose administered304 directly to theuser device142. In other examples, thedosing controller160 executes on thecomputing device132 of theservice provider130 such that thecomputing device132 receives theBG data302 and/or the dose administered304 from thepatient device110 and provides theBG data302 and/or the dose administered304 to theuser device142.
• Theuser device142 may transmit updates to the recommendeddosing information306 to thedosing controller160 via thenetwork20 and/or transmit the one ormore notifications308 to thedosing controller160 for display on atarget patient device110. For example,notifications308 can include a low bloodglucose alert notification308 when a patient's current BG measurement is less than a hypoglycemia blood glucose value (e.g., obtained frommemory hardware20,134,144) or a bloodglucose request notification308 when a current time is within a scheduled blood glucose time interval for the patient10 that requires a current BG measurement.
• In some implementations, thepatient management program200 is configured to display on thedisplay screen146 in communication with the user device142 a GUI having historical blood glucose anddosing information320 for one ormore patients10. The historical blood glucose anddosing information320 may include a trend window1102 (FIGS.11A-11E) of obtained BG measurements on a timeline. In some examples, thepatient management program200 is configured to receive magnifying inputs in thetrend window1102 from a user40 (e.g. HCP) for a magnification window1104 (FIGS.11A-11E) superimposed on a segment of the timeline to specify a date range for a magnified window1106 (FIGS.11A-11E). Here, the GUI of thepatient management program200 may display the magnifiedwindow1106 including the BG measurements of the patient10 from the specified date range.
• FIGS.4A-4C show schematic views400a-cof example GUIs of thepatient management program200 displayed on the display116 of thepatient device110 for viewing historical blood glucose and dosing data for apatient10. Referring toFIG.4A, the example GUI displays averageBG value information402, averagehemoglobin A1c information412,treatment adherence information422, andinsulin information432.
• The averageBG value information402 includes a last month'saverage BG value404, a current week'saverage BG value406, and a trending graphic408 indicating a magnitude that the current week'saverage BG value406 increases or decreases from last month'saverage BG value404. TheBG value information402 may also display aBG value goal410 indicating the target BG value for thepatient10. The blood glucose parameters (e.g.,SubQ parameters216a) for the patient10 may include theBG value goal410 for access by thepatient management program200. TheBG value information402 may also include educational information related to the correlation between maintaining blood glucose levels and health of the patient. For example, the education information may state that “Lowering your blood sugar will help you feel better and have more energy in the short run, and lower your chances of eye, kidney, liver, and heart disease in the long run.”
• Theaverage A1c information412 includes a last month'saverage A1c value414, a current week'saverage A1c value416, and a trending graphic418 indicating a magnitude that the current week'saverage A1c value416 increases or decreases from last month'saverage A1c value414. TheA1c information412 may also display anA1c value goal420 for the patient which may be obtained from theSubQ parameters216ainput to thesystem100 by theHCP40 and accessible by thepatient management program200. TheA1c value information412 may also include educational information related to the correlation between lower A1c values and health of thepatient10. For example, the education information may state that “Less than a 1 percentage point drop in A1C can lead to 45% decreased risk of death from cardiovascular disease.
• Theadherence information422 is associated with a number of times per day (e.g., a number of readings per day) thepatient10 checks/measures his or her blood glucose level using theglucometer124. Theadherence information422 includes a last month's average number of readings perday424, a current week's average number of readings perday426, and a trending graphic428 indicating a magnitude that the current week's average number of readings perday426 increases or decreases from last month's average number of readings perday424. Theadherence information422 may also display anadherence goal430 indicating a target number of times the patient10 should measure/check his or her blood sugar. Theadherence information422 may also include education information related to the correlation between increasing the number of blood glucose readings per day and managing blood glucose values. For example, the education information may state that “Checking your blood sugar regularly will help us prescribe the right dosage for you. Sticking with this insulin regimen will help you tightly control your blood sugar and feel better.”
• Theinsulin information432 may display an insulin dosing regimen for the patient10 as prescribed by the HCP. For instance, the insulin dosing regimen may include a daily schedule of basal and meal doses thepatient10 is prescribed to administer each day. The insulin dosing regimen may correspond to theinsulin dosing information306 thedosing controller160 transmits to thepatient device110 based on theBG Data302 thedosing controller160 obtains from thepatient device110, as set forth above with respect toFIG.3A. For example, thedosing controller160 may automatically adjust the patient's10 insulin dosing regimen during predetermined intervals (e.g., daily, weekly, every two weeks, etc.) based on theBG data302 obtained from thepatient device110. Similarly, theHCP40 may analyze the patient's10BG data302 over a specified time range and adjust the patient's10 insulin dosing regimen accordingly.FIG.4A shows the GUI of thepatient management program200 displaying a chart of a daily frequency of insulin distribution (e.g., 4 doses per day) and a number of units administered by thepatient10 for each dose. For example, thepatient10 may be prescribed a frequency of insulin distribution (e.g., as indicated in thepatient SubQ information216a) that includes a basal dose in the morning and breakfast, lunch, and dinner meal boluses. Theinsulin information432 may also display an insulin type and frequency of distribution for the patient's long-acting basal insulin (e.g., Lantus, lx/day) along with an insulin type for the patient's short acting bolus insulin (e.g., Humalog, Meal-dosing, carb grams). In some configurations, the GUI of thepatient management program200 includes a “Request New Dose” patient-selectable link434 that allows the patient10 to request a new dose of insulin from thedosing controller160 when thepatient10 selects the Request New Dose patient-selectable link434. Accordingly, thedosing controller160 may calculate a new insulin dosing regimen for the patient10 in response to the patient selecting the “Request New Dose” user-selectable link434 displayed by the GUI of thepatient management program200 on the display116 of thepatient device110.
• Referring toFIG.4B, the example GUI displays a blood glucose screen providing the patient'sBG data302 based on the BG measurements and BG times obtained by theglucometer124 and provided to thepatient device110 and/ordosing controller160. In some implementations, thepatient management program200 determines a representative average BG value for each scheduled blood glucose time interval for the patient during a specified time range. In these implementations, the GUI of thepatient management program200 displays a representative averageBG value graph440 indicating the representative average BG value for each of the scheduled blood glucose time intervals during the specified time range. For example,FIG.4B shows thegraph440 including the representative average BG value determined by thepatient management program200 for each one of Breakfast, Lunch, Dinner, and Bedtime scheduled blood glucose time intervals during a current week. Thegraph440 may graphically display the representative average BG value for each BG time interval (e.g.,201 for Breakfast;165 for Lunch;198 for Dinner;215 for Bedtime) and aprofile line442 extending through each value. Thegraph440 may also provide the target BG range444 (e.g., “Goal 70-100”) for thepatient10. In some examples, theprofile line442 includes different representations based on the representative average BG value. For instance, theprofile line442 may change color for representative average BG values outside thetarget BG range444. For instance,FIG.4B shows theprofile line442 including a different color for the representative average BG value of 165 during lunch than the higher representative average BG values of 201, 198, and 215 for the respective ones of Breakfast, Dinner, and Bedtime. In some implementations, thegraph440 graphically displays low BG measurements (e.g., BG measurements less than the hypoglycemia blood glucose value) as well as high BG measurements (e.g., BG measurements greater than the hyperglycemia blood glucose value).
• In some implementations, the GUI of thepatient management program200 also graphically displaysdaily BG data446 for the patient10 indicating the patient's BG measurement obtained by the patient's10glucometer124, the BG time for each BG measurement, and the BG time interval for each BG measurement. For example, the GUI may display thedaily BG data446 for a current day (e.g. Today) and include BG values for BG time intervals of Before Breakfast, After Breakfast, After Lunch After Dinner, and Bedtime. The GUI may display the BG measurements as different representations based on the value for each BG measurement. For example, the value of each BG measurement displayed may be color coordinated based upon a range of BG values the corresponding BG measurement falls into. Moreover, the daily BG data445 may also provide an upward arrow next to BG measurements that exceed an upper limit of the BG target range or a downward arrow next to BG measurements that are less than a lower limit of the BG target range.
• Referring toFIG.4C, the example GUI displays an insulin dosing screen indicating the number of units of insulin administered by the patient10 during each scheduled time interval. In some examples, the administration device123 communicates the number of doses administered by the patient10 to thepatient device110 and thepatient device110 transmits the dose administered304 (FIG.3A) to thedosing controller160. In other examples, thepatient management program200 enables the patient to input the number of doses administered by the patient10 directly to thepatient device110. Accordingly, the GUI of thepatient management program200 displays aninsulin dosing graph450 indicating a number of units of insulin administered by thepatient10 for each scheduled time interval during a specified time range. For example,FIG.4C shows thegraph450 including abasal profile line452, a breakfastbolus profile line454, a lunchbolus profile line454, and a dinnerbolus profile line456. Here, each profile line452-458 indicates the number of units of insulin administered by the patient during each day during the specified time range (e.g., This Week).
• In some implementations, the GUI of thepatient management program200 also graphically displays dailyinsulin dosing data460 for the patient10 including the number of units of insulin for each scheduled dose, a time interval for each scheduled dose, and a time for each scheduled dose administered by thepatient10. For example, the GUI may display the dailyinsulin dosing data460 for a current day (e.g., Today) and include a number of units of insulin for scheduled doses of Fasting (70 units), Breakfast (17 units), Lunch (26 units), and Dinner (17 units). Theinsulin dosing data460 may include the type of insulin for each scheduled dose. For instance,FIG.4C shows theinsulin dosing data460 indicating the insulin type for the Fasting interval is Lantus (e.g., long-acting basal) while the insulin type for the Breakfast, Lunch, and Dinner intervals is Humalog (e.g., short-acting bolus). Theinsulin dosing data460 also indicates when a scheduled dose is skipped by the patient when thedosing controller160 fails to receive the dose administered302 from the patient device. For example, theinsulin dosing data460 ofFIG.4C indicates that the scheduled dose for Dinner is skipped.
• FIGS.5A and5B showschematic views500a,500bof example GUIs of thepatient management program200 displayed on the display116 of thepatient device110 for viewing and confirming a recommended insulin dosing regimen for thepatient10. TheHCP40 may prescribe the recommended insulin dosing regimen for the patient10 based upon theBG data302 associated with thepatient10. TheHCP40 and/or thedosing controller160 may adjust the recommended insulin dosing regimen in real-time using one or more BG measurements for the patient10 obtained by the dosing controller. Similarly, theHCP40 and/or thedosing controller160 may adjust or update the recommended insulin dosing regimen during predetermined intervals (e.g., daily, every 3 days, weekly, every two weeks, etc.).FIG.5A shows the GUI of thepatient management program200 displaying a newinsulin dosage notification308 on the display116 of the patient device110 (e.g.,smart phone110b) that notifies the patient10 when a new recommended insulin dosing regimen is ready for the patient10 to view and confirm. For example, in response to receiving a notification308 (FIG.3A) from the dosing controller160 (e.g.,user device142 or computing device132) via thenetwork20, the patient management program executing on thecomputing device112 may cause thepatient device110 to display the new insulindosage regimen notification308 on the display116. In some examples, the new insulindosage regimen notification308 includes a user selectable link associated with data, such that when thepatient10 selects thelink308, thepatient management program200 causes thepatient device110 to display an insulin dosing regimen screen providing the new insulin dosage regimen for the patient.
• FIG.5B shows the GUI of thepatient management program200 displaying the insulin dosing regimen screen in response to the patient selecting the user selectable link associated with the newinsulin dosage notification308 ofFIG.5A. The insulin dosing regimen screen displays the newinsulin dosing regimen510 for the patient indicating a daily frequency of distribution and a number of units of insulin for each insulin dose of the distribution. For example, the newinsulin dosing regimen510 of FIG. includes 4 doses of insulin per day for morning basal (e.g., 70 units of Lantus), breakfast bolus (e.g., 18 units of Humalog), lunch bolus (e.g., 26 units of Humalog), and dinner bolus (e.g., 17 units of Humalog). Thepatient management program200 may render the newinsulin dosing regimen510 on the display116 in the form of a message or communication from theHCP40 that includes anext update message512 and apersonal message514 for the patient10 associated with the newinsulin dosing regimen510. For example,FIG.5B shows thepersonal message514 stating “I raised your lunch bolus to see if we can get those midday high BGs down. How does this sound?” In some implementations, the GUI of thepatient management program200 displays a Confirm Dose user-selectable link516 that enables the patient10 to confirm the newinsulin dosing regimen510 when thepatient10 selects the Confirm Dose user-selectable link516. Accordingly, theuser device142 associated with theHCP40 may receive a message through thenetwork20 from thepatient device110 indicating thepatient10 has confirmed the newinsulin dosing regimen510 in response to the patient10 selecting the Confirm Dose user-selectable link. The GUI of thepatient management program200 may also display a Confirm & Ask user-selectable link518 that enables the patient10 to inquire theHCP40 about the newinsulin dosing regimen510 when thepatient10 selects the Confirm & Ask user-selectable link518. By selecting, the Confirm & Ask user-selectable link518, thepatient management program200 may cause thepatient device110 to display a text box for the patient10 to input textual message for theHCP40 to answer and/or cause thepatient device110 to initiate a phone call with theHCP40 when thepatient device110 is capable of voice calls.
• FIGS.6A-6C show schematic views600a-cof example GUIs of thepatient management program200 displayed on the display116 of thepatient device110 for logging BG measurements measured by the patient's10glucometer124. TheSubQ information216ainput to thepatient management program200 may include scheduled BG time intervals each indicating a time interval requiring a BG measurement for thepatient10. For example, the scheduled BG time intervals may include a pre-breakfast BG measurement, a pre-lunch BG measurement, a pre-dinner BG measurement, and/or a bedtime BG measurement. In some implementations, thedosing controller160 determines whether a current time is within one of the scheduled BG time intervals requiring a BG measurement, and when the current time is within one of the scheduled BG time intervals and the corresponding BG measurement has not been received, thedosing controller160 transmits a bloodglucose request notification308 to thepatient device110 during the scheduled BG time interval. For example, theuser device142 may implement thedosing controller160 and transmit the bloodglucose request notification308 to thesmart phone110bassociated with the patient10 during the scheduled BG time interval, as shown inFIG.3A. When the patient device110 (e.g.,smart phone110bofFIG.3A) receives the bloodglucose request notification308 from thedosing controller160, thepatient management program200 executing on thecomputing device112 of the patient device displays the bloodglucose request notification308 on the display116 (e.g., patient screen).
• FIG.6A shows the GUI of the patient management program displaying the bloodglucose request notification308 instructing the patient to attain a current blood glucose measurement for the scheduled Lunch BG time interval. In some examples, the bloodglucose request notification308 includes a user-selectable link associated with data, such that when thepatient10 selects thelink308, thepatient management program200 causes thepatient device110 to advance to a patient screen for inputting the current blood glucose measurement for the scheduled BG time interval.
• FIG.6B shows the GUI of thepatient management program200 displaying a BG input field602 (e.g., “BG input box”) enabling the patient10 to input the current BG measurement for the scheduled BG time interval. Thepatient management program200 may display atouchscreen keypad604 for use by the patient10 to input the current BG measurement. Alternatively, thepatient10 may input the current BG measurement to theBG input field602 using thekeyboard119 and/or via speech recognition techniques. Thepatient management program200 may display theBG input field602 andtouchscreen keypad604 in response to the patient selecting the user-selectable link associated with the bloodglucose request notification308 displayed by the example GUI ofFIG.6A or the patient10 may navigate to the example GUI ofFIG.6B when the patient10 desires to enter a BG measurement. In other examples, theglucometer124 automatically transmits a current BG measurement to thepatient device110 to cause the patient management program to render the received BG measurement in the BG input filed602 without requiring input by thepatient10.
• FIG.6C shows the current BG measurement (e.g., 321 mg/dl) input to theBG input field602 and the GUI of thepatient management program200 displaying user-selectable link606,608 that enables the patient10 to log the current BG measurement as corresponding to the scheduled BG time interval (e.g. “At Lunch”) when thepatient10 selects the user-selectable link606 or as not corresponding to the scheduled BG time interval (e.g., “Not at Lunch”) when thepatient10 selects the user-selectable link608. In response to the patient10 selecting the user-selectable link606 to log the current BG measurement as corresponding to a scheduled BG time interval, thepatient management program200 may cause thepatient device110 to display the example GUIs ofFIGS.7A-7D or the example GUIs ofFIGS.8A and8B for calculating a meal bolus for the patient10 associated with the scheduled BG time interval. As used herein, the user-selectable link606 may correspond to a patient-selectablemeal type button606 indicating a meal type (e.g., Lunch) when the patient is consuming a meal based on the BG time associated with the current BG measurement input to theBG input field602. Conversely, in response to the patient10 selecting the user-selectable link608 to log the current BG measurement as not corresponding to a scheduled BG time interval, thepatient management program200 may cause thepatient device100 to display the example GUIs ofFIGS.9A and9B for requesting the patient10 to provide rational for checking/measuring the current BG measurement and/or calculate a correction dose if necessary based on the current BG measurement.
• The GUI ofFIGS.6B and6C may correspond to a patient log screen showing a log of BG measurements, corresponding BG times, and/or doses of insulin administered by the patient10 in addition to theBG input field602. For instance, during a scheduled Fasting BG time interval, the patient10 logged a BG measurement equal to 215 mg/dl and administered 70 units of Lantus insulin for the patient's basal dose. Similarly, during a scheduled Breakfast BG time interval, the patient10 logged a BG measurement equal to 256 mg/dl and administered 20 units of Humalog insulin for the patient's breakfast bolus. The patient's breakfast bolus may include a sum of a correction bolus and a meal bolus.
• FIGS.7A-7D show schematic views700a-dof example GUIs of thepatient management program200 displayed on the display116 of thepatient device110 for calculating a meal bolus for the patient10 associated with the scheduled BG time interval when thepatient10 selects the meal type button606 (e.g., user-selectable link606). Thepatient management program200 may augment an area of the GUI including themeal type button606 when the patient selects themeal type button606 and prompt the patient to input a meal size for the meal type associated with the selectedmeal type button606. For example, the example GUI ofFIGS.7A and7B highlights an area around themeal type button606 indicating thepatient10 is consuming or about to consume Lunch. Themeal type button606 may correspond to breakfast or dinner in other examples.
• FIG.7A shows the GUI rendering ameal size window710 for the selected meal type (e.g., Lunch) that requests the patient10 to input the meal size for the selected meal type. In some examples, themeal size window710 includes user-selectable links712,714,716 each including a respective image that corresponds to a size of the patient's meal. Each user-selectable link712,714,716 may be referred to as a patient-selectable meal size button indicating a respective meal size associated with the selected meal type. For instance, themeal size button712 corresponds to a small meal size, themeal size button714 corresponds to a medium meal size, and themeal size button716 corresponds to a large meal size. Accordingly, the GUI of thepatient management program200 enables the patient10 to select one of themeal size buttons712,714,716 to input the meal size for the meal type and cause the patient device to transmit the input meal size to thedosing controller160. Thedosing controller160 may execute on any of thecomputing devices112,132,142.
• The example GUI ofFIG.7A also renders a recommendedinsulin dose window720 for the selected meal type which provides a correction bolus graphic722 indicating a value of the correction dose for the patient10 to administer. Thedosing controller160 may determine the correction bolus using Eq. 2 based on the current BG measurement input to theBG input field602 and provide the correction bolus to thepatient device110 in the recommendeddosing information306 transmitted to thepatient device110. For instance, the correction bolus graphic722 in the example ofFIG.7A includes a correction bolus equal to 10 units.
• FIG.7B shows thepatient management program200 augmenting an area of the GUI including themeal size button712,714,716 selected by thepatient10. For example, the GUI highlights an area around themeal size button714 indicating a “medium” meal size associated with the selected meal type (e.g., Lunch). Thepatient management program200 may cause thepatient device110 to transmit the input meal size to thedosing controller160 in response to the patient10 selecting appropriatemeal size button712,714,716. Thereafter, thedosing controller160 determines a recommended meal bolus for the patient10 based on the meal size and meal type selected by the patient10 (e.g., by selectingbuttons606 and714) and transmits the recommended meal bolus to thepatient device110. For instance, thedosing controller160 may transmit the recommended meal bolus in the recommendeddosing information306 to thepatient device110 via thenetwork20. In some examples, in response to receiving the recommended meal bolus (e.g., contained in the recommended dosing information306) at thepatient device110, thepatient management program200 causes the recommendedinsulin dose window720 displayed by the GUI to provide a meal bolus graphic724 indicating a value of the meal bolus (e.g., Lunch meal bolus) for the patient10 to administer. For instance, the meal bolus graphic724 in the example ofFIG.7B includes a Lunch meal bolus equal to 17 units.
• Upon displaying the values for the correction bolus and meal bolus in corresponding ones of the correction bolus graphic722 and the meal bolus graphic724, the GUI of thepatient management program200 displays a recommended total dosage of insulin for the patient based on a sum of the values of the recommended meal bolus and the correction dose.FIG.7B shows the GUI displaying a patient-selectabletotal dosage button730 that instructs the patient to administer the recommended total dosage of insulin (e.g., 27 units of Humalog based on the sum of the correction bolus and the meal bolus) and enables the patient10 to confirm the recommended total dosage of insulin by selecting thetotal dosage button730. Here, thepatient management program200 causes thepatient device110 to transmit the recommended total dosage of insulin as the dose administered304 to thedosing controller160 so that the total dosage of insulin for the selected meal type (e.g., Lunch) is logged and stored within thememory hardware24,114,134,144. Conversely, the GUI also displays a patient-selectablechange dosage button732 that permits the patient to change the value of the total dosage of insulin recommended by the dosing controller when thepatient10 selects thechange dosage button732.
• The example GUI ofFIG.7C renders a changedosage input field734 that enables the patient10 to change the recommended total dosage of insulin by inputting a new value in the changedosage input field734 in response to the patient10 selecting thechange dosage button732 in the example GUI ofFIG.7B. Moreover, thepatient management program200 may display atouchscreen key pad740 for use by the patient10 to input the new value in the changedosage input field734. Alternatively, thepatient10 may input the new value to the changedosage input field734 using thekeyboard119 and/or via speech recognition techniques.
• Referring toFIG.7D, in some implementations, the GUI of thepatient management program200 renders a change dosagerational window750 in response to the new value input to the changedosage input field734. The change dosagerational window750 prompts the patient10 to provide rational as to why thepatient10 has changed the recommended total dosage of insulin. For example, the change dosagerational window750 may include one or more patient-selectable links752,754,756,758,760 each including link data (e.g., text and/or images) associated with a corresponding rational for changing the recommended total dosage of insulin. For instance, patient selectable link752 indicates thepatient10 is exercising, patient-selectable link754 indicates thepatient10 is currently having insulin issues, patient-selectable link756 indicates thepatient10 has a recent illness, patient-selectable link758 indicates the patient10 consumed less food than indicated by the meal size input, and patient-selectable link760 indicates the patient10 consumed more food than indicated by the meal size input. The patient management program may also augment an area of the GUI including the patient-selectable link752-760 selected by thepatient10. For example, the GUI highlights an area around the patient-selectable link758 indicating the patient's rational for changing the total dosage of insulin is due to the patient consuming less food than previously indicated by the meal size input. Thepatient management program200 may also display a rational text box for permitting the patient10 to input the rational for changing the recommended dosage of insulin if none of the links752-760 describe the rational for changing the dose.
• FIG.7D also shows the GUI displaying a patient-selectable total changeddosage button766 that instructs the patient to administer the new dosage of insulin (e.g., units of Humalog based on the new value input to the change dosage input field734) and enables the patient10 to confirm the new dosage of insulin by selecting the changeddosage button766. Here, thepatient management program200 causes thepatient device110 to transmit the new value for the total dosage of insulin as the dose administered304 to thedosing controller160 so that the new total dosage of insulin for the selected meal type (e.g., Lunch) is logged and stored within thememory hardware24,114,134,144. Conversely, the GUI also displays a patient-selectable canceleddosage button732 that permits the patient to cancel the new value input to the changedosage input field734.
• In some implementations, rather than the patient inputting the meal size to thepatient device110 by selecting one of the multiplemeal size buttons712,714,716 displayed on the patient screen as set forth above with respect toFIGS.7A and7B, thepatient10 inputs the meal size by inputting a number of carbohydrate exchanges associated with the meal type. As used herein, one carbohydrate exchange refers to 15 grams of carbohydrate. For instance, a piece of bread generally contains 15 grams of carbohydrate and therefore corresponds to one carbohydrate exchange.FIG.8A provides aschematic view800aof an example GUI of thepatient management program200 rendering acarbohydrate exchange window810 for the selected meal type (e.g., Lunch) that prompts the patient10 to input the meal size for the selected meal by inputting the number of carbohydrate exchanges thepatient10 is consuming or about to consume. In some examples, thecarbohydrate exchange window810 includes user-selectable links812,814,816,818,820 each including a respective image that corresponds to a type of carbohydrate exchange for the patient's meal. Thelink812 is associated with a Milk carbohydrate exchange, thelink814 is associated with a Fruit carbohydrate exchange, thelink816 is associated with a Starch carbohydrate exchange, thelink818 is associated with a Vegetable carbohydrate exchange, and thelink820 is associated with a Sweet carbohydrate exchange. Moreover, each user-selectable link812-820 may include a patient-selectable positive (“+”) button for inputting a carbohydrate exchange each time thepatient10 selects the positive (“+”) button and a patient-selectable negative (“—”) button for removing a carbohydrate exchange each time thepatient10 selects the negative (“—”) button. For instance, thepatient10 may select the positive (“+”) button for thelink814 when patient consumes a banana and an apple for the selected meal type (e.g., lunch). Thedosing controller160 may obtain an insulin to carbohydrate ratio from the patient'sSubQ information216astored within thememory hardware24,134,144 for calculating a recommended meal bolus for the patient10 in response to the number of carbohydrate exchanges input by thepatient10 via thecarbohydrate exchange window810.
• In another implementation, thepatient10 inputs the meal size for the selected meal type by inputting a total number of carbohydrates the patient10 consumed.FIG.8B provides aschematic view800bof an example GUI of thepatient management program200 rendering acarbohydrate input window850 for the selected meal type (e.g., Lunch) that prompts the patient10 to input the meal size for the selected meal by inputting the number of carbohydrates thepatient10 is consuming or about to consume. In some examples, thecarbohydrate input window850 provides acarbohydrate input field852 that enables the patient10 to input the number of carbohydrates for the selected meal type. In these examples, the example GUI may provide a touch screen keypad for inputting the number carbohydrates or the patient10 may input the number of carbohydrates to thecarbohydrate input field852 using thekeyboard119 and/or via speech recognition.
• The example GUIs ofFIGS.8A and8B may render the recommendedinsulin dose window720 providing the correction bolus graphic722 and the meal bolus graphic724, the patient-selectabletotal dosage button730 for allowing the patient10 to view and confirm the recommended total dosage of insulin, and the patient-selectablechange dosage button732 for allowing the patient10 to change the recommended total dosage of insulin by inputting a new value when thechange dosage button732 is selected.
• FIGS.9A and9B provideschematic views900a,900bof example GUIs of thepatient management program200 displayed on the display116 of thepatient device110 for prompting the patient10 to input a rational for obtaining the current BG measurement when thepatient10 selects the non-meal button608 (e.g., user-selectable link606). As set forth above, thenon-meal button608 indicates that the current BG measurement input to theBG input field602 is dissociated from the meal type indicated by the patient-selectable meal type button. For instance,FIGS.9A and9B show thenon-meal button608 indicating that the current BG measurement equal to 321 mg/dl in theBG input field602 is dissociated from the Lunch meal type indicated by the selectablemeal type button606. Thepatient management program200 may augment an area of the GUI including thenon-meal button608 when the patient selects thenon-meal button608 and prompt the patient to input the rational for obtaining the current BG measurement. For example, the example GUIs ofFIGS.9A and9B highlight an area around thenon-meal button608 when selected by thepatient10.
• FIG.9A shows the GUI renderingrational window910 that requests the patient10 to input the rational for obtaining the current BG measurement that is dissociated from a meal type. In some examples, therational window910 includes patient-selectablerational boxes912,914,916,918,918,920 each describing a respective rational/reasoning for obtaining the current BG measurement and enabling the patient10 to log the rational when the corresponding one of the rational boxes912-920 is selected by thepatient10. For instance, thepatient10 may tap the rational box912-920 that most accurately describes the patient's rational for obtaining the current BG measurement. In some examples, the GUI of thepatient management program200 augments the rational box912-920 selected by thepatient10.FIG.9B shows the GUI augmenting therational box920 selected by the patient10 indicating that the patient was being precautious and/or curious. The example GUI ofFIG.9B also provides a patient-selectable Done button930, that when selected by thepatient10, causes thepatient device110 to transmit the selected rational input by the patient10 to thedosing controller160 for storage within thememory hardware24,134,144.
• FIGS.10A-10C show schematic views1000a-cof example GUIs of thepatient management program200 displayed on the display116 of thepatient device110 that render a hypoglycemia view. In some implementations, when the current BG measurement input to theBG input field602 ofFIGS.6A and6B is less than a hypoglycemia blood glucose value, thedosing controller160 transmits a low bloodglucose alert notification308 to thepatient device110 that causes thepatient management program200 to render the hypoglycemia view on the patient display116. The hypoglycemia view may include analert window1002 that provides a value of the current BG measurement and the BG time associated with the current BG measurement. Thealert window1002 also provides acountdown timer1004 indicating a remaining amount of time until thepatient10 is requested to re-test his or her blood glucose using theglucometer124. The example GUI ofFIG.10A shows the current BG measurement equal to 56 mg/dl and the BG time equal to 11:32 am while thecountdown timer1004 indicates 13 minutes remaining until the patient10 needs to re-test his or her blood glucose. Thecountdown timer1004 initializes at 15 minutes in some examples.
• In some examples, the hypoglycemia view displayed by the example GUI of thepatient management program200 displayshypoglycemia patient instructions1006 for treating the hypoglycemia episode associated with the current BG measurement. For instance,FIG.10A shows thehypoglycemia patient instructions1006 stating (1) “Call 911 if you have blurred vision, fruity breath, or are vomiting;” (2) “Eat 15 g of carbohydrates orDrink 4 oz of juice,” and (3) “Check your blood sugar again every 15 mins until above 70.”
• Additionally, the hypoglycemia view displayed by the example GUI may display patient-selectable Retest nowbutton1008 and/or a patient-selectableCall doctor button1010. For example, when the patient selects the Retest nowbutton1008, thepatient management program200 may prompt the patient10 to retest his or her blood glucose measurement at the present moment. For instance,FIG.10B shows thealert window1002 providing aBG input box1012 in place of thecountdown timer1004 in response to the patient10 selecting the Retest nowbutton1008. In other examples, thepatient management program200 provides theBG input box1012 in response to thecountdown timer1004 lapsing. In some examples, thepatient management program200 displays atouchscreen keypad1004 for use by the patient10 to input a subsequent BG measurement into theBG input box1012. Alternatively, thepatient10 may input the subsequent BG measurement to theBG input box1012 using thekeyboard119 and/or via speech recognition techniques. In some implementations, thepatient management program200 causes thepatient device110 to initiate a voice call with theHCP40 when the patient selects theCall doctor button1010.
• In some examples, thepatient management program200 augments thealert window1002 of the displayed hypoglycemia view when the subsequent BG measurement input to theBG input box1006 is greater than the hypoglycemia blood glucose value. For instance, the example GUI ofFIG.10C shows thepatient management program200 providing an exclamation graphic indicating the value of the subsequent BG measurement equal to 76 mg/dl is greater than the hypoglycemia blood glucose value. Here, thealert window1002 of the displayed hypoglycemia view may also provide a notification informing the patient10 that the patient's blood glucose back to normal. In some implementations, thepatient management program200 causes thepatient device110 to inform theuser device142 associated with theHCP40 of the patient's hypoglycemia episode. Thepatient management program200 may also prompt the patient10 to optionally input a cause associated with the hypoglycemia episode by displaying a hypoglycemia cause window1020 (FIG.10C) when the subsequent BG measurement input to theBG input box1006 is greater than the hypoglycemia blood glucose value.
• Referring to the example GUI ofFIG.10C, thehypoglycemia cause window1020 may include one or more patient-selectable links1022,1024,1026,1028,1030 each including link data (e.g., text and/or images) associated with a corresponding cause for the recent hypoglycemia episode. Patient-selectable link1022 indicates the cause of the hypoglycemia episode was due to exercise, patient-selectable link1024 indicates the cause of the hypoglycemia episode was due to insulin issues, patient-selectable link1026 indicates the patient10 the cause of the hypoglycemia episode was due to a recent illness, patient-selectable link1028 indicates the cause of the hypoglycemia episode was due to the patient10 consuming less food than indicated by the meal size input, and patient-selectable link1030 indicates the cause of the hypoglycemia episode was due to the patient10 consuming more food than indicated by the meal size input. Thehypoglycemia cause window1020 may also render ahypoglycemia cause box1032 that enables the patient10 to input a cause of the most recent hypoglycemia episode when none of the patient-selectable link1022-1030 displayed by the GUI adequately describe the cause of the episode.
• Additionally, the hypoglycemia view displayed by the example GUI may display a patient-selectable Return toactivities button1034 and/or the patient-selectableCall doctor button1010. For example, when the patient selects the Return toactivities button1034, thepatient management program200 may thepatient device110 to exit the hypoglycemia view.
• Referring toFIGS.11A-11E, in some implementations, theuser device142 of theclinic system140 executes the patient management program configured to display on a screen (e.g., display146) in communication with the user device142 a GUI1100,1100a-dhaving thetrend window1102 of BG measurements on a timeline. For instance, theuser device142 may obtain the BG measurements of apatient10 and BG times associated with the time of measuring each BG measurement from theglucometer124 associated with thepatient10. Here, thepatient10 refers to one of one or more patients theHCP40 associated with theuser device142 is treating remotely via communications through thenetwork20 and in association with thedosing controller160.
• In some examples, thepatient management program200 executing on theuser device142 is configured to receive magnifying inputs from theHCP40 in thetrend window1102 for amagnification window1104 superimposed on a segment of the timeline to specify a date range for a magnifiedwindow1106,1106a-e. Here, the HCP (e.g. user) may apply the magnifying inputs in thetrend window1102 to set a start date and an end date for the specified date range. For instance, a start dategraphical point1105 and an end dategraphical point1107 may be superimposed on thetrend window1102 to define themagnification window1104 and may be manipulated by the HCP40 (e.g., touched, or clicked on) to slide thepoints1105 and/or1107, and therefore stretch or shorten themagnification window1104, to set the specified date range. The examples ofFIGS.11A-11E show themagnification window1104 defining a start date of “18 February” and an end date of “Today” for the magnifiedwindow1106. Once the date range for the magnifiedwindow1106 is set, thepatient management program200 is configured to display the magnifiedwindow1106 in the GUI1100. In some implementations, the magnified window includes the BG measurements of the patient10 from the specified date range. Moreover, the GUI1100 of thepatient management program200 may also display one or more information windows1108a-deach including respective quantitative information associated with the BG measurements from the specified date range.
• In some implementations, the quantitative information of each information window1108a-dmay be displayed in the GUI1100 in the form of a user-selectable link each including link data, i.e., text and/or an image that describes the corresponding quantitative information associated with the BG measurements from the specified date range. In the examples ofFIGS.11A-11E, each of the information windows1108a-dare associated with data, such that when theHCP40 selects the window1108a-d, thepatient management program200 displays the corresponding quantitative information in the magnifiedwindow1106. The example GUIs1100 show afirst information window1108aincluding quantitative information related to a number of BG measurements (e.g., BG readings) of the patient10 per day for the specified date range, asecond information window1108bincluding quantitative information related to an average daily BG measurement for the specified date range, athird information window1108cincluding quantitative information related to an average A1c value for the specified date range, and afourth information window1108dincluding quantitative information related to insulin dosing information for the specified date range. Here, the insulin dosing information may include an average total daily dosage of insulin, insulin adherence, and/or average doses of insulin injected by the patient during each of the patient's scheduled BG time intervals.
• Referring toFIG.11A, the example GUI1100aof thepatient management program200 displayspatient information1120 for the patient10 associated with the displayedtrend window1102 of BG measurements. For instance thepatient information1120 includes information such as the patient's name, age, height, weight, and contact information. Thepatient information1120 may also indicate any alerts associated with the patient, such as recent hypoglycemic episodes and a cause for the hypoglycemic episode. For instance, thepatient management program200 may render an alert graphic1127 in thepatient information1120 indicating the recent hypoglycemic episode in response to the patient10 selecting one of the patient-selectable links1022,1024,1026,1028,1030 in thehypoglycemia cause window1020 displayed on the patient's display116 ofFIG.10C.
• Thepatient management program200 may also allow theHCP40 to search for other patients theHCP40 treats by entering a name in aname search box1122. Moreover, thepatient management program200 may display an alert list1124 of patients under the supervision of theHCP40 that have recent alert conditions. For instance, the alert list1124 may provide a list of patient names, a type of alert condition, and a time of the alert condition. The alert list1124 may augment alerts that have been resolved by rendering a graphic in an area near the resolved patient's name. Additionally, thepatient management program200 may superimpose an alert graphic1127 in the GUI1100aproximate to the patient associated with the alert condition. The alert graphic1127 may include a value of the most recent blood glucose measurement associated with the alert condition. The alerts may include, but are not limited to, hypoglycemic episodes, hyperglycemic episodes, and no BG measurements received. The alert list1124 allows theHCP40 to efficiently review patient's requiring attention by prioritizing the patient's in the alert list1124 by severity. Additionally or alternatively, thepatient management program200 may display anupdate list1126 of patients requiring treatment updates (e.g., new recommended insulin dosing regimens). Thepatient management program200 is configured to display thetrend window1102 of BG measurements for different patients by selecting the patients from either of thelists1124 or1126 or patients entered in thename search box1122. The alert list1124 and theupdate list1126 may collectively provide amonitoring window1125 ofpatients10 under the supervision of theHCP40 that may require attention due to an alert condition or in need of a new recommended insulin dosing regimen soon.
• In some implementations, thepatient management program200 is further configured to display acommunication window1128 in the GUI1100a. Here, thecommunication window1128 may show a history of communications (e.g., text messages, emails, video conferences, phone calls, etc.) between theHCP40 and thepatient10. Thecommunication window1128 may be substantially similar to the example GUI displayed on thepatient device110 ofFIG.5B.
• With continued reference toFIG.11A, the BG measurements of the magnified window1106aincludeinteractive points1140 and1130,1130a-cwithin associated ones of scheduled blood glucose time intervals based on the blood glucose times. Here, the blood glucose time intervals may correspond to fasting, pre-breakfast, pre-lunch, pre-dinner, and bedtime. More particularly, thepatient management program200 renders theinteractive points1130,1140 in the magnified window1106ain response to the patient selecting thefirst information window1108aincluding quantitative information related to the number of BG measurements (e.g., BG readings) of the patient10 per day for the specified date range. Thepatient management program200 may highlight, or otherwise augment, an area of the GUI1100aaround thefirst information window1108ato indicate that the magnified window1106ais associated with the HCP's selection of thefirst information window1108a. Theinteractive points1140 are “unfilled” and correspond to BG measurements thedosing controller160 will not use for calculating the next recommended insulin dosing regimen for the patient. On the other hand, the interactive points1130 are “filled” and correspond to BG measurements thedosing controller160 will use for calculating the next recommended insulin dosing regimen for thepatient10.
• In response to receiving the magnifying inputs for themagnification window1104, thepatient management program200 may determine a representative average BG value for each of the scheduled BG time intervals and superimpose an average BG graphic1134 on the magnified window1106abased on the representative average blood glucose values for the scheduled BG time intervals. The average BG graphic1134 in the example ofFIG.11A reveals that the patient's average BG measurements are higher during the bedtime BG time interval than during the lunch and breakfast BG time intervals.
• In some implementations, the patient management program superimposes afirst line1131 on the magnified window1106arepresenting an upper BG limit (e.g. 180 mg/dl) of the target BG range and asecond line1132 on the magnified window1106arepresenting a lower BG limit (e.g., 70 mg/dl) of the target BG range. In some examples, the upper and lower BG limits of the target BG range are obtained from thepatient SubQ information216astored in thememory hardware24,134,144. In some scenarios, theinteractive points1130aassociated with the BG measurements within the target BG range display as a first representation, theinteractive points1130bassociated with the BG measurements greater than the upper BG limit (e.g., first line1131) display as a second representation, and theinteractive points1130cassociated with the BG measurements less than the lower BG limit (e.g., second line1132) display as a third representation or the second representation.
• In some examples, thepatient management program200 aggregates the BG measurements greater than the upper BG limit (e.g., first line1131) into a first hyperglycemia range, a second hyperglycemia range, and a third hyperglycemia range. The first hyperglycemia range may include BG measurements greater than 180 mg/dl and less than or equal to 250 mg/dl, the second hyperglycemia range may include BG measurements greater than 250 mg/dl and less than 300 mg/dl, and the third hyperglycemia range may include BG measurements greater than 300 mg/dl. Moreover, thepatient management program200 may assign a percentage of distribution based on the number of BG measurements less than the lower BG limit (e.g., second line1132), the number of BG measurements within the BG target range (e.g., between the first andsecond lines1131 and1132), and the number of BG measurements within each of the first hyperglycemia range, the second hyperglycemia range, and the first hyperglycemia range. The example ofFIG.11A shows that 3% of the BG measurements are less than the lower BG limit, 9% of the BG measurements are within the BG target range, 88% of the BG measurements are within the first hyperglycemia range, 50% of the BG measurements are within the second hyperglycemia range, and 38% of the BG measurements are within the third hyperglycemia range.
• In some implementations, theinteractive points1130,1140 associated with the BG measurements are patient-selectable such that, in response to theHCP40 selecting (e.g., touching, hovering a cursor over, or clicking on) one of theinteractive points1130,1140 on the magnified window1106a, thepatient management program200 may obtain quantitative information related to the BG measurement associated with the selectedinteractive point1130,1140. In these implementations, thepatient management program200 may illuminate the selectedinteractive point1130,1140, query thememory hardware24,134,144 to obtain the quantitative information related to the BG measurement, and display a pop-upwindow1150 including the obtained quantitative information for theHCP40 to view. For instance, theHCP40 may be curious about one of the patient's BG measurements that is below the lower BG limit, and may select (e.g., touch, hover, or click on) the correspondinginteractive point1130cto prompt the patient management program to obtain the quantitative information for display in the pop-upwindow1150.FIG.11A shows the pop-upwindow1150 indicating that the patient's BG value was equal to 48 mg/dl on February 22 at 8:52 pm after the patient consumed dinner. The quantitative information in the pop-upwindow1150 may include other information such as, but not limited to, a dosage of insulin administered by the patient before obtaining the BG measurement, a meal size of the meal occurring before the BG measurement, and/or whether thepatient10 was exercising.
• Referring toFIG.11B, in some implementations, thepatient management program200 is configured to receive filtering inputs in the magnified window1106bfrom theHCP40 to define a specified time range for the magnified window1106b. In some examples, theprogram200 receives the filter inputs when theHCP40 manipulates a first interactive cursor1161 superimposed on the magnified window to set a lower time limit for the specified time range. Additionally or alternatively, theprogram200 receives the filter inputs when theHCP40 manipulates a secondinteractive cursor1162 superimposed on the magnified window to set an upper time limit for the specified time range. For instance, the first interactive cursor1161 in the example ofFIG.11B indicates the lower time limit equal to 8:30 am while the secondinteractive cursor1162 indicates the upper time limit equal to 7:30 μm. Thepatient management program200 may prompt theHCP40 to confirm a new specified time range for the magnified window1106bby selecting a FilterData Again button1164 that causes thepatient management program200 to filter the BG measurements that fall within the specified time range for the magnified window1106b. Here, thepatient management program200 queries thememory hardware24,134,144 to obtain quantitative information related to the BG measurements within the specified time range of the magnified window and displays an information window including the quantitative information related to the BG measurements within the specified time range of the magnified window1106b. Conversely, theprogram200 may allow theHCP40 to cancel the new specified time range by selecting an Undo Adjustments button1166 so that no filtering is performed. In some examples, the interactive points1130 associated with the BG measurements within the specified time range (e.g., between cursors1161 and1162) display as a representation that is different than a representation for the BG measurements outside the specified time range (e.g., occurring before the lower time limit or occurring after the upper time limit).
• In some implementations, in response to receiving the magnifyinginputs1105,1107 for themagnification window1104 superimposed on the segment of thetimeline1102 to specify the date range for the magnifiedwindow1106, thepatient management program200 determines a daily average BG value for each date of the specified date range. For example, thesecond information window1108bmay be associated with the daily average BG value for each date of the specified date range. The example GUI1100cofFIG.11C shows thepatient management program200 superimposing an average BG graphic1170 on the magnified window1106cbased on the daily average blood glucose values for the specified date range. Thepatient management program200 may superimpose the average BG graphic on the magnified window1106cresponse to the patient selecting thesecond information window1108b. In some examples, thepatient management program200 displays ablood glucose plot1172 on the magnified window1106cfor each BG measurement from the specified date range. Here, the plot extends through each date of the specified date range based on each BG measurement value and corresponding BG time.
• Referring toFIG.11D, thepatient management program200 may determine an estimated hemoglobin A1c value for each date of the specified date range and superimpose an average hemoglobin A1c graphic1180 on the magnified window1106dbased on the estimated hemoglobin A1c values of the specified date range. Thepatient management program200 may also superimpose apoint1182 corresponding to an actual hemoglobin A1c value for the patient10 on the magnified window1106d.
• Referring toFIG.11E, in some implementations, thepatient management program200 is configured to query thememory hardware24,134,144 to obtain doses of insulin administered by thepatient10 for each date of the specified date range and superimpose aplot1190 of doses of insulin administered by thepatient10 for each date of the specified date range on the magnifiedwindow1106e. Theplot1190 may include a total daily dose (TDD) of insulin for each date based on the number of units of insulin administered by the patient throughout the day during scheduled intervals. For instance,patient management program200 may displaydosage graphics1192,1194,1196,1198 indicating the number of units of insulin administered by the patient10 during respective ones of basal dose, breakfast bolus dose, lunch bolus dose, and dinner bolus dose. In some implementations, each dosage graphic1192,1194,1196,1198 is interactive such that, in response to theHCP40 selecting e.g., touching, hovering a cursor over, or clicking on) one of thegraphics1192,1194,1196,1198 on the magnifiedwindow1106e, thepatient management program200 displays a pop-upwindow1195 including detailed information related to the dosage of insulin associated with the selected dosage graphic1192,1194,1196,1198. For example,FIG.11E shows the pop-upwindow1195 providing information related to the patient's breakfast bolus such as the BG measurement, the number of carbohydrates consumed, the meal bolus, the correction bolus, and the insulin to carbohydrate ratio for the patient.
• Referring toFIG.12A, in some implementations, theuser device142 of theclinic system140 executes the patient management program configured to display apatient dashboard GUI1200 having alist1202 ofpatients10 under the supervision of theHCP40. Thepatient list1202 may provide patient information for each patient10 such as name, date of birth (DOB), clinic, A1C value, average BG measurement value, TDD, when a next update is due (e.g., Update), and any pending alert conditions (e.g., Alert). Thepatient management program200 may display the patient information as data including text and/or images. For example, image plots for the patients' A1C and average BG measurement values may be displayed to reveal a trend for the corresponding data. The alert conditions may include hypoglycemia events such as when a patient had a recent blood glucose measurement that was less than a hypoglycemia blood glucose value, hyperglycemia events such as when a patient had a recent blood glucose measurement that was greater than a hyperglycemia blood glucose measurement, and no BG data conditions such as when apatient10 has failed to log BG measurements during scheduled time intervals.
• In some examples, thepatient dashboard GUI1200 ofFIG.12 also displayspatient profile cards1204,1204a-cfor each patient10 flagged as having a recent alert condition and therefore requiring review by theHCP40. Thepatient profile cards1204 may be displayed horizontally and include pertinent patient information such as name, contact information, when next update is due, average A1c value, average BG value and the corresponding alert condition. The patient profile cards may be sorted and arranged together based on the alert condition.FIG.12 shows patient profile cards1204aand1204beach associated with a patient who had a hypoglycemic event (e.g., “Low BGs”) while patient profile card1204cis associated with a patient who has not reported any BG data. Thepatient management program200 may display a Send Reminder button1220 in the patient profile card1204cassociated with the patient who has not reported any BG data. In some examples, thepatient management program200 causes theuser device142 to transmit the blood glucose request notification308 (FIG.3B) to auser device110 associated with the patient10 who has not reported any BG data when theHCP40 selects the Send Reminder button1220.
• Navigation buttons1206 and1208 may allow theHCP40 to scroll horizontally to view anypatient profile cards1204 not currently displayed. Moreover, a name search filed1210 may allow theHCP40 to input a name of apatient10 under the supervision of theHCP40. Thepatient management system200 may allow theHCP40 to filter patients by clinic or by a specific clinician.
• Various implementations of the systems and techniques described here can be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and/or combinations thereof. These various implementations can include implementation in one or more computer programs that are executable and/or interpretable on a programmable system including at least one programmable processor, which may be special or general purpose, coupled to receive data and instructions from, and to transmit data and instructions to, a storage system, at least one input device, and at least one output device.
• These computer programs (also known as programs, software, software applications or code) include machine instructions for a programmable processor and can be implemented in a high-level procedural and/or object-oriented programming language, and/or in assembly/machine language. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, apparatus and/or device (e.g., magnetic discs, optical disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions and/or data to a programmable processor, including a machine-readable medium that receives machine instructions as a machine-readable signal. The term “machine-readable signal” refers to any signal used to provide machine instructions and/or data to a programmable processor.
• Implementations of the subject matter and the functional operations described in this specification can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Moreover, subject matter described in this specification can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter affecting a machine-readable propagated signal, or a combination of one or more of them. The terms “data processing apparatus”, “computing device” and “computing processor” encompass all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus can include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus.
• A computer program (also known as an application, program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
• The processes and logic flows described in this specification can be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
• Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read only memory or a random access memory or both. The essential elements of a computer are a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer can be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.
• To provide for interaction with a user, one or more aspects of the disclosure can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touch screen for displaying information to the user and optionally a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; for example, by sending web pages to a web browser on a user's client device in response to requests received from the web browser.
• One or more aspects of the disclosure can be implemented in a computing system that includes a backend component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a frontend component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).
• The computing system can include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some implementations, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.
• While this specification contains many specifics, these should not be construed as limitations on the scope of the disclosure or of what may be claimed, but rather as descriptions of features specific to particular implementations of the disclosure. Certain features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.
• Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multi-tasking and parallel processing may be advantageous. Moreover, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.
• A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. Accordingly, other implementations are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results.

Claims (20)

What is claimed is:

1. A computer-implemented method executing on data processing hardware that causes the data processing hardware to perform operations comprising:

obtaining glucose measurements of a patient and glucose times associated with a time of measuring each glucose measurement from a glucose sensor associated with the patient; and

executing a patient management program configured to display on a screen in communication with the data processing hardware a graphical user interface having a trend window of the blood glucose measurements on a timeline, wherein the patient management program is configured to:

receive, in the graphical user interface, a user input indication from a medical professional to specify a date range;

display, in the graphical user interface, the trend window including the glucose measurements of the patient from the specified date range; and

display, in the graphical user interface, a first information graphic including quantitative information associated with an average number of times the patient checks the glucose measurements measured from the glucose sensor per day within the specified date range.

2. The computer-implemented method ofclaim 1, wherein the operations further comprise:

receiving insulin dosing parameters for the patient input by a healthcare provider; and

transmitting the insulin dosing parameters to a patient device associated with the patient.

3. The computer-implemented method ofclaim 2, wherein the insulin dosing parameters for the patient comprise a carbohydrate-to-insulin ratio for the patient.

4. The computer-implemented method ofclaim 2, wherein the insulin dosing parameters for the patient comprise a correction factor for the patient.

5. The computer-implemented method ofclaim 2, wherein the insulin dosing parameters for the patient comprise a target glucose range for the patient.

6. The computer-implemented method ofclaim 1, wherein the operations further comprise:

receiving, from a patient device associated with the patient, a message directed toward a healthcare provider of the patient, the message comprising an inquiry related to insulin dosing parameters for the patient; and

displaying the message on the screen.

7. The computer-implemented method ofclaim 1, wherein the operations further comprise determining, based on the glucose measurements of the patient from the specified date range, an estimated hemoglobin A1c value for the patient.

8. The computer-implemented method ofclaim 7, wherein the operations further comprise displaying, in the graphical user interface, a second information graphic including quantitative information associated with the estimated hemoglobin A1c for the patient.

9. The computer-implemented method ofclaim 1, wherein the operations further comprise determining, based on the glucose measurements of the patient from the specified date range, an average glucose measurement value for the specified date range.

10. The computer-implemented method ofclaim 9, wherein the operations further comprise displaying, in the graphical user interface, a second information graphic including quantitative information associated with the average glucose measurement value for the specified date range.

11. A system comprising:

data processing hardware; and

memory hardware in communication with the data processing hardware, the memory hardware storing instructions that when executed on the data processing hardware cause the data processing hardware to perform operations comprising:

obtaining glucose measurements of a patient and glucose times associated with a time of measuring each glucose measurement from a glucose sensor associated with the patient; and

executing a patient management program configured to display on a screen in communication with the data processing hardware a graphical user interface having a trend window of the blood glucose measurements on a timeline, wherein the patient management program is configured to:

receive, in the graphical user interface, a user input indication from a medical professional to specify a date range;

display, in the graphical user interface, the trend window including the glucose measurements of the patient from the specified date range; and

display, in the graphical user interface, a first information graphic including quantitative information associated with an average number of times the patient checks the glucose measurements measured from the glucose sensor per day within the specified date range.

12. The system ofclaim 11, wherein the operations further comprise:

receiving insulin dosing parameters for the patient input by a healthcare provider; and

transmitting the insulin dosing parameters to a patient device associated with the patient.

13. The system ofclaim 12, wherein the insulin dosing parameters for the patient comprise a carbohydrate-to-insulin ratio for the patient.

14. The system ofclaim 12, wherein the insulin dosing parameters for the patient comprise a correction factor for the patient.

15. The system ofclaim 12, wherein the insulin dosing parameters for the patient comprise a target glucose range for the patient.

16. The system ofclaim 11, wherein the operations further comprise:

receiving, from a patient device associated with the patient, a message directed toward a healthcare provider of the patient, the message comprising an inquiry related to insulin dosing parameters for the patient; and

displaying the message on the screen.

17. The system ofclaim 11, wherein the operations further comprise determining, based on the glucose measurements of the patient from the specified date range, an estimated hemoglobin A1c value for the patient.

18. The system ofclaim 17, wherein the operations further comprise displaying, in the graphical user interface, a second information graphic including quantitative information associated with the estimated hemoglobin A1c for the patient.

9. The system ofclaim 11, wherein the operations further comprise determining, based on the glucose measurements of the patient from the specified date range, an average glucose measurement value for the specified date range.

20. The system ofclaim 11, wherein the operations further comprise displaying, in the graphical user interface, a second information graphic including quantitative information associated with the average glucose measurement value for the specified date range.

Images