Systems and methods for cgm-based bolus calculator for display and for provision to medicament delivery devices

Abstract

A system and method for the safe and seamless setup and modification of bolus calculator parameters for a bolus calculator tool by a healthcare provider (HCP) are disclosed. In one embodiment, a method for enabling the setup of a bolus calculator by an HCP comprises the steps of: providing a server accessible by both the HCP and a patient; displaying or transmitting for display a rechargeable form containing one or more fields for inputting one or more bolus calculator parameters upon login by the HCP; receiving data corresponding to one or more bolus calculator parameters from the rechargeable form; and transmitting data based on the received data to a device associated with the patient upon login by the patient, wherein the transmitted data corresponds to one or more of the bolus calculator parameters in a format suitable for input into a bolus calculator.

Description

Technology Field

[0001] The present invention generally relates to the continuous monitoring of analyte values ​​received from an analyte sensor system. More specifically, the present invention relates to a system, method, apparatus, and device for a healthcare provider to be involved in the setup and optimization of a drug calculator and delivery device. Background Technology

[0002] Diabetes mellitus is a disorder in which the pancreas is unable to produce sufficient insulin (Type 1 or insulin-dependent) and / or insulin is ineffective (Type 2 or non-insulin-dependent). In a diabetic state, patients suffer from hyperglycemia, which causes physiological disturbances associated with the deterioration of small blood vessels (renal failure, skin ulcers, or hemorrhage into the vitreous humor of the eye). Hypoglycemic reactions (low blood sugar) can be induced by unintentional overdose of insulin, or may be accompanied by specific exercise or insufficient food intake following normal administration of insulin or glucose-lowering agents.

[0003] Typically, diabetic patients carry a self-monitoring blood glucose (SMBG) monitor, which generally requires an inconvenient finger-pricking method. Due to the lack of comfort and convenience, diabetic patients usually measure their glucose levels only two to four times a day. Unfortunately, these time intervals are too far apart, making it likely that diabetic patients will be alerted to hyperglycemia or hypoglycemia too late, which sometimes results in dangerous side effects. In fact, not only is it unlikely that diabetic patients will obtain SMBG values ​​in a timely manner, but due to the limitations of existing methods, they will also be unable to determine whether their blood glucose levels are rising (higher) or falling (lower).

[0004] Consequently, various non-invasive transdermal (e.g., transdermal) and / or implantable electrochemical sensors are being developed to continuously detect and / or quantify blood glucose values. US Patent Publication No. US-2005-0027463-A1 presents a technology for analyte sensors. Continuous glucose monitors are gaining popularity as an easy way to monitor glucose levels. In the past, patients would sample their blood glucose levels multiple times a day, such as at breakfast, lunch, and dinner. Levels could be measured by taking a small blood sample from the patient and measuring the glucose level using a test strip or a glucose meter. However, this technology has disadvantages because patients prefer not to need to take blood samples, and users do not know what their blood glucose levels are between samples throughout the day.

[0005] Night is a potentially dangerous time of day because a patient's glucose levels can drop to dangerous levels while sleeping. Consequently, continuous glucose monitors are gaining popularity by providing sensors that continuously measure a patient's glucose levels and wirelessly transmit the measured levels to a display. This allows the patient or their caregiver to monitor the patient's glucose levels throughout the day and even set alarms when glucose levels reach a preset level or experience a preset change.

[0006] Initially, continuous glucose monitors wirelessly transmit data related to glucose levels to a dedicated display. The dedicated display is a medical device designed to display glucose levels, trend patterns, and other user information. However, with the increasing popularity of smartphones and software applications (apps) running on them, some users prefer to avoid having to carry a dedicated display. Instead, some users prefer to monitor glucose levels using dedicated software apps running on mobile computing devices, such as smartphones, tablets, or wearable devices like smartwatches or smart glasses.

[0007] Systems and methods according to the present principle include methods for a user and a healthcare professional(s) (HCP) to communicate securely, generally over a wireless network, particularly when the HCP prescribes insulin to a patient as part of a bolus calculator parameter set-up or as part of a pump setup. For example, the systems and methods may provide a bolus calculator setup using secure transmission over a network that brings about the desired function, for example, a bolus calculator setup, where secure communication is established between the HCP and the user. The systems and methods generally use a ubiquitous smartphone by the user, and the systems and methods may use data determined by various sensors, including continuous glucose monitoring. The systems and methods generally provide analysis and calculations to provide calculated data to a drug delivery device to display as part of a bolus calculator and / or to allow administration by the user. Such drug delivery devices may include, for example, a pump, a pen, etc. In many embodiments, the calculation results of the bolus calculator may at least partially control a medical device, such as a drug delivery device like a pump or a pen.

[0008] The provided methods may be unique to the situations faced by different HCPs and may consider, for example, the amount of time spent with the patient, which may be short or long. Different HCPs may include, for example, endocrinologists, family physicians, certified diabetes educators, nurses, followers, and other users. Depending on the method, different amounts of information regarding the patient may be provided; for example, a follower may obtain glucose values, while an endocrinologist may obtain analyzed pattern graphs.

[0009] In addition, by automatically providing different amounts of information and data to different types of providers, the machines providing this data operate much more efficiently, and this factor can also have a significant impact on battery life, wear and tear, etc. Furthermore, the display of this data can be automatically configured to fit the available display screen size, and the user interface can be automatically changed to accommodate different amounts and types of data to be displayed.

[0010] This system and method are not only related to initial setup, but can also be used to update parameters for direct and automatic modification of bolus calculator parameters, transmit the updated parameters to the user, or allow the user to manually modify the parameters. In other embodiments, modifications may be suggested to be downloaded and automatically applied to the bolus calculator, but confirmation by the user may be required prior to the actual modification of the parameters.

[0011] Systems and methods according to the present principle generally do not merely review historical data retrospectively to determine the success or failure of a user's diabetes treatment. Using the described systems and methods, a "give and take" can be made between the user generating the data and the physician reviewing and analyzing the data in collaboration with the patient. In the same way, the physician can "hone in" the optimal set of parameters by providing more significant, meaningful, and frequent updates to the bolus calculator parameters, if necessary, and determine the optimal set of parameters for the patient's given situation, e.g., weekdays versus weekends. In this manner, systems and methods according to the present principle address the technical issues of user devices with suboptimal bolus calculator parameters and resolve these issues technically by enabling back-end-force communication, which has never been heard of before in this context.

[0012] In some cases, insurance may allow HCP to be reimbursed for the initial meeting and the setup of the bolus calculator, even if the setup was performed remotely. In the same way, transmitting an updated set of parameters along with optional HCP patient consultation may trigger other billing events. Parameter updates may originate from the user as well as from automated algorithms, which are expected to be the most common source of such updates. For example, if a user habitually takes one unit more than suggested by the bolus calculator and achieves a satisfactory result, the bolus calculator parameters may be automatically updated to increase the dosage. In some cases, notification of the proposed update may be sent to HCP for verification and approval.

[0013] In one technique, an HCP bolus calculator setup app may be provided to the HCP, for example, via an invitation link from the patient user (transmitted via text, email, etc., or via the technique described above in relation to the flowchart described below), and this provides an interface to be provided back to the patient user's device so that the HCP can set up specific bolus calculator parameters for the patient user and integrate them into the patient's bolus calculator. Using a system and method according to the present principle, a CGM-enabled bolus calculator may be provided. This provides a bolus calculator known by various CGM modalities, including glucose trends. The HCP can unlock the bolus calculator function and specify the calculator parameters. For example, when the CGM is connected to the pump, the bolus calculator function may be disabled so that the pump calculator takes precedence over the CGM bolus calculator. Meal inputs for the bolus calculator may be made "fuzzy" so that the user can more conveniently input small, average, or large meal sizes. Parameters for these different meal sizes may be defined by the HCP during setup. A third-party food database app can be used as input for a ballers calculator, the input can be validated by the user, and the user may be further provided with the ability to ignore such values. The CGM app can also calculate IOBs for MDI users within the context of the ballers calculator.

[0014] Generally, data from third-party apps may be verified and / or authenticated before use in the Bolus Calculator app. For example, values ​​may be 'grayed out' and not used in calculations until the user verifies their accuracy. The Bolus Calculator app or features may allow the user to input meal event data, for example, entered carbohydrates, and / or automatically pull meal event data from third-party applications, for example, via Apple HealthKit. In this way, for example, when a user accesses the Bolus Calculator, recently entered carbohydrates may be provided to them, and the user may choose to use this amount in the Bolus calculation or use a different value, for example, considering food they are about to eat. In some cases, the CGM app may not be able to verify the accuracy of carbohydrate estimates from other meal database applications and may inform the user of the risks during initial use.

[0015] In a first embodiment, a method is provided for a healthcare provider (HCP) to enable the setup of a bolus calculator, the method comprising: a) providing a server accessible by both the HCP and the patient; b) displaying or transmitting for display a fillable form containing one or more fields for inputting one or more bolus calculator parameters upon login by the HCP; c) receiving data corresponding to one or more bolus calculator parameters from the fillable form; and d) transmitting data based on the received data to a device associated with the patient upon login by the patient, wherein the transmitted data corresponds to one or more bolus calculator parameters in a format suitable for input into a bolus calculator.

[0016] An embodiment may include one or more of the following. The step of transmitting data to a device associated with a patient may include the step of transmitting data to an app associated with the bolus calculator. The app may be a continuous glucose monitoring (CGM) app, such as one running on a smartphone or a dedicated CGM device. The data transmission step may further include the step of encrypting the transmitted data with a patient encryption key. The method may further include the step of uploading the patient encryption key before encryption. The transmitted data may be a copy of the received data. The method may further include the step of receiving the transmitted data on a device associated with a patient and automatically modifying the bolus calculator parameters using the transmitted data. The method may further include the step of causing a display of an HCP account creation screen upon a login failure by the HCP. The method may further include the step of causing a display of a patient account creation screen upon a login failure by the patient. The method may further include the step of causing a display of a warning screen upon login by the patient, thereby allowing the patient to be warned about the bolus calculator setup without the involvement of the HCP. The above method may further include the step of retrieving one or more parameters related to the bolus calculator setup from a drug delivery device or from a user account associated with a drug delivery device when logging in by HCP.

[0017] A first part of the bolus calculator parameters may be from transmitted data, and a second part of the bolus calculator parameters may be from a drug delivery device or a user account associated with the drug delivery device. The method may further include the step of accessing a database of the drug delivery device and the step of generating a text version of the parameters according to the drug delivery device associated with the patient. The step of transmitting data to the patient may include the step of transmitting a text version of the parameters associated with the bolus calculator setup. Patient login may be enabled at least partially by a code, the code is entered by the patient, and the code is received by the patient from the HCP. The code may also be generated by the HCP when the HCP associates a new patient with an HCP user account. HCP login may be enabled at least partially by a code, the code is entered by the HCP, and the code is received by the HCP from the patient. The code may be generated by the patient when the patient associates the HCP with a patient user account. When generating the code, a time window may be instantiated, during which time the HCP can change the bolus calculator settings / parameters. The method may further include the step of receiving a confirmation message from the patient after displaying the data transmitted on a display associated with the patient, and upon receiving the confirmation message, transmitting the final data to the display associated with the patient, to the bolus calculator app, or to a CGM app including a bolus calculator function. The method may further include the step of receiving a modification message from the patient after displaying the data transmitted on a display associated with the patient, thereby allowing the patient to request modification of the HCP-inputted bolus calculator parameters. The method may further include the step of transmitting a notification regarding the requested modification to the HCP.When receiving confirmation of the requested modification from the HCP, the method may further include the step of transmitting the final data to a display associated with the patient or to a bolus calculator app.

[0018] The bolus calculator settings / parameters may include a basal rate and may also be limited by a guardrail or safety range. Messaging / email services may be accessed from the HCP to the patient or from the patient to the HCP when a change in bolus occurs. The method may further include the step of determining or detecting a bolus calculator parameter / setting change triggering event, and in response to the determination or detection, sending a notification regarding the event to the HCP. Multiple bolus calculator parameter / setting change triggering events may be determined or detected, and the method may further include the step of prioritizing or ranking the triggering events before sending the notification to the HCP. The method may further include the step of sending a subset of the prioritized or ranked events to the HCP. The bolus calculator parameter / setting change triggering event may include a detection pattern detected through the analysis of CGM traces. The pattern is treatable by changing the bolus calculator parameters / settings. The pattern may be, for example, one of a nocturnal low or a postprandial high. The bolus calculator parameter / setting change triggering event may include an atypical glucose response. The method may further include the steps of receiving a modification to the bolus calculator parameter / setting and transmitting the modification to a device associated with the patient. The modification may adjust the base rate or the bolus calculator parameter / setting.

[0019] The triggering event may include the detection of at least occasional departures of the delivered insulin bolus when compared to the calculated bolus value. The departures may have the same sign and value, and the departure values ​​may be within a common range. The data transmission step may include a step of transmitting using a Bluetooth communication protocol or a near field communication protocol. The method further includes a step of performing a bolus calculation based at least partially on the transmitted data. The method may further include a step of receiving additional data and a step of performing a bolus calculation based at least partially on the additional data. The additional data receiving step may include a step of receiving additional data from an external app or from user input. The additional data may be received from an external app, and the method may further include a step of authenticating or verifying the app or the additional data before use in the bolus calculator. The additional data may be received from an external app, and the method may further include a step of prompting the user for confirmation before using the additional data in the bolus calculator. The additional data may be received from user input, and the user input may be in a categorized or fuzzy form. The additional data reception step may include a step of receiving additional data from a continuous glucose monitoring system. The additional data may include trend data or glucose change rate data.

[0020] The above method may further include the step of transmitting transmitted data or data based on transmitted data to a drug delivery device. The drug delivery device may be a pump or pen or a bolus calculator app associated with a pump or pen. The bolus calculator parameters entered by the HCP may be specified for a time range within a day. The bolus calculator parameters entered by the HCP may be specified for weekdays versus weekends. The form may be displayed on the HCP along with pre-populated data. The pre-populated data may be obtained from user account data. The pre-populated data may be obtained from data associated with the drug delivery device. The above method may further include the step of receiving an edit to the pre-populated data, and the step of generating transmitted data based on the edited pre-populated data. The above method may further include the step of receiving transmitted data on a device associated with a patient and displaying an acknowledgment prompt on the user interface of the device, and the step of automatically modifying the bolus calculator parameters using the transmitted data when the acknowledgment prompt is accepted.

[0021] In a second embodiment, a continuous glucose monitoring method configured for secure communication between an HCP and a patient is provided, the method comprising: a. a step of receiving first data from a form on a web app, wherein the data relates to bolus calculator parameters and / or settings, the data is associated with a patient user account, and the session of the web app is associated with an HCP user account; b. a step of performing a first conversion of the received first data into second data, wherein the second data is in a form operable to be input into a bolus calculator app; c. a step of performing a second conversion of the second data into secure second data, wherein the secure second data can only be used by a device associated with the patient user account; and d. a step of transmitting the secure second data to the patient user account or making the secure second data accessible from the patient user account.

[0022] An embodiment may include one or more of the following. The second data may be in a form operable to be automatically transmitted to a storage device or memory on a device running the Bolus Calculator app. This device may be a smartphone or a dedicated device, and the Bolus Calculator app may be a standalone app or a Bolus Calculator function within a continuous glucose monitoring app. The second data may be in a form operable to be input by a user into a storage device or memory on a device running the Bolus Calculator app. This device may be a smartphone or a dedicated device, and the Bolus Calculator app may be a standalone app or a Bolus Calculator function within a continuous glucose monitoring app. The second conversion step may include an encryption step. The encryption step may encode the second data with a patient encryption key, and the patient encryption key is associated with a patient user account. The transmission step includes the step of transmitting the secured second data to a device associated with the patient user account, and this device may be configured to use the secured second data in the Bolus Calculator. The method may further include the step of displaying the secured second data on a device linked to the patient user account. The above method may further include the step of receiving confirmation or approval of the displayed secure second data from the patient. The above method may further include the step of receiving a request to modify the displayed secure second data from the patient. The above method may further include the step of transmitting the modification request to an HCP user account.

[0023] In a third embodiment, a continuous analyte monitoring method configured to be interoperable with one or more third-party applications is provided, the method comprising: a. a step of running a continuous glucose monitoring (CGM) app on a first device, wherein the CGM app communicates with a CGM sensor through a sensor electronics, and the sensor electronics are coupled to the sensor and transmit data to the first device; b. a step of receiving data from another app via an API in the CGM app, wherein the received data is operable to provide a bolus calculation to a user in a diabetic state, and the received data is operable to provide a bolus calculation when used in combination with data from the CGM sensor when providing a bolus calculation; and c. a step of attempting to authenticate the data before using the received data, and if the authentication is successful, using the received data in combination with the sensor data to provide a bolus calculation, and if the authentication is not successful, not using the received data to provide a bolus calculation.

[0024] An embodiment may include one or more of the following. The first device may be a smartphone or a dedicated continuous glucose monitor. The authentication attempt step may include a step of comparing the timestamp of the received data with the timestamp of the sensor data, or a step of comparing the timestamp of the received data with the time of receiving the data according to the clock of the first device. Another app may be an app running on the second device. The second device may be a drug delivery device including a pump or a pen. The second device may be a wearable fitness sensor. The authentication step may include a step of determining whether the application is a trusted app by comparing a certificate associated with the app with a list of trusted certificates stored on the first device. The received data may include exercise data or meal data. The received data may include population data from a database. The above method may further include the step of displaying the received data for verification by a user on the user interface of a first device before using the received data, and the step of using the received data in a bolus calculation upon successful verification. A continuous glucose monitoring app may include a bolus calculator function, and another app may be executed on a drug delivery device that includes a bolus calculator function, and the above method may further include the step of automatically disabling the bolus calculator function when the continuous glucose monitoring app detects that another app includes a bolus calculator function. Authentication may include the step of determining a first identification of a user associated with the continuous glucose monitoring app, the step of determining a second identification of a user associated with another app, and the step of determining whether the first and second identifications are associated with the same user.

[0025] In a fourth embodiment, an application configured to be executed on a mobile device is provided, said application comprises: a first input configured to receive signal data from a continuous indwelling analyte sensor and a transmitter; a second input configured to receive signal data corresponding to target patient data and / or patient population data; and a command configured to use the first and second inputs to calculate a bolus value, wherein the second input is used to provide settings and / or parameters for a bolus calculator, and the first input is used to provide a current patient analyte concentration value to be applied to a function that is at least partially determined by the settings and / or parameters to calculate the bolus value.

[0026] An embodiment may include one or more of the following. The application may further include one or more inputs to one or more third-party applications, and the command is also configured to calculate a bolus value based additionally on the inputs to the third-party applications. The application may further include commands for receiving signal data from a continuous indwelling analyte sensor and for calculating and displaying a clinical value of the analyte concentration. The application may further include commands for correcting the received signal data. The commands for correcting the received signal data may use the signal data alone or use the signal data together with other external data. The commands may also be configured to transmit the calculated bolus value to a drug delivery device. The commands may also be configured to stop the calculation of the bolus value when the mobile device communicates the signal data with a drug delivery device having a bolus calculator. The commands may also be configured to receive signal data corresponding to target patient data and / or patient population data in a secure manner from a healthcare worker server.

[0027] In a fifth embodiment, an application configured to be executed on a server is provided, said application comprising: first commands configured to receive data regarding a target user and set up a target user account; a first input configured to receive sensor data from a device associated with the target user; second commands configured to analyze data from the first input and determine whether bolus calculator parameters and / or settings on the target user device are optimal; and third commands configured to transmit a signal to a healthcare professional portal associated with the server or to the target user device and modify the parameters and / or settings if the parameters and / or settings on the target user device are not optimal.

[0028] An embodiment may include one or more of the following. The third commands may also be configured to display a prompt on the portal and receive one or more modified parameters and / or settings from a healthcare worker. The third commands may also be configured to encrypt or secure the modified parameters and / or settings before transmitting them to the target user device. The second commands may also be configured to determine whether the bolus calculator parameters and / or settings on the target user device are optimal by detecting whether a bolus calculator parameter / setting change triggering event has occurred.

[0029] In other embodiments and examples, the method features of the various embodiments are formulated in terms of a system, as in the various embodiments configured to perform the method features. Any feature of an embodiment of any of the first to fifth embodiments described above, which includes but is not limited to any of the first to fifth embodiments described above, is applicable to all other embodiments and examples identified herein that include but are not limited to any of the first to fifth embodiments described above. Additionally, any feature of an embodiment of any of the various embodiments described above, which includes but is not limited to any of the first to third embodiments described above, may be combined independently, either partially or wholly, with other embodiments described in any manner herein, for example, one, two, or three or more embodiments may be combined wholly or partially. Furthermore, any feature of an embodiment of any of the various embodiments described above, which includes but is not limited to any of the first to fifth embodiments described above, may be optional for other embodiments or examples. Any mode or embodiment of the method may be performed by a system or device of another mode or embodiment, and any mode or embodiment of the system or device may be configured to perform a method of another mode or embodiment that includes, but is not limited to, any embodiment of any one of the first to fifth modes described above. Brief explanation of the drawing

[0030] This patent or application file includes at least one drawing executed in color. A copy of this patent or patent application publication containing the color drawing(s) will be provided by the Patent Office upon request and payment of the necessary fees. Other aspects of the present disclosure will be more readily understood when considering the detailed description of the various disclosed embodiments set forth below in conjunction with the accompanying drawings. FIG. 1a illustrates an exemplary system aspect that may be used in connection with implementing an embodiment of the present disclosure. FIG. 1b illustrates an exemplary system aspect that may be used in connection with implementing an embodiment of the present disclosure. FIG. 2a is a perspective view of an exemplary enclosure that can be used in connection with implementing an embodiment of an analyte sensor system. FIG. 2b is a side view of an exemplary enclosure that can be used in connection with implementing an embodiment of an analyte sensor system. FIG. 3a illustrates an exemplary system aspect that can be used in connection with implementing an embodiment of the present disclosure. FIG. 3b illustrates an exemplary aspect of a system that may be used in connection with implementing an embodiment of the present disclosure. FIG. 4 illustrates a more detailed aspect of an exemplary system that can be used in connection with implementing an embodiment of the present disclosure. Figure 5 illustrates a flowchart of the implementation of a method according to the present principle. FIGS. 6a through 6c illustrate steps according to the present principle through which a bolus calculator application can be unlocked. FIGS. 7a through 7e illustrate flowcharts of other embodiments of the method according to the present principle. FIGS. 7f to 7l illustrate flowcharts of other embodiments of the method according to the present principle. FIGS. 7m to 7u illustrate flowcharts of other embodiments of the method according to the present principle. FIG. 8 illustrates a flowchart of another embodiment of the method according to the present principle. FIG. 9 illustrates a flowchart of another embodiment of the method according to the present principle. FIG. 10 illustrates an exemplary user flow of a bolus calculator according to the present principle. Figure 11 illustrates an embodiment of correcting bolus calculator parameters using trend adjustment. The drawings are described in more detail in the following description and embodiments and are provided merely for illustrative purposes and illustrate only ordinary or exemplary embodiments of the present disclosure. The drawings are not intended to limit or encompass the present disclosure in the exact form disclosed. It should also be understood that the present disclosure may be modified or altered and that the present disclosure may be limited only by the claims and their equivalents. Specific details for implementing the invention

[0031] In addition to continuous glucose monitors, another device used by diabetic patients is the bolus calculator (BC). This is a tool that helps patients determine how much insulin is needed to adequately manage glucose levels, particularly based on events such as meals, activity, and sleep. For example, a bolus calculator can determine a specific amount of insulin as a "bolus" to correct potentially high glucose levels after a meal. Determining the insulin dosage is an essential but complex task that diabetic patients must perform to accurately calculate the appropriate insulin dose and safely inject the calculated amount. Generally, a bolus calculator involves a three-part calculation based on insulin on board (IOB), carbohydrate intake, and correction factors. Automating the complex arithmetic used to calculate insulin dosage reduces the mental mathematical burden on patients, minimizes errors, and enables patients to achieve better glucose control.

[0032] However, current bolus calculators have drawbacks. For example, unlike pump users, patients undergoing multiple daily injection therapy (MDI) typically do not have access to FDA-approved bolus calculators. More specifically, while bolus calculators can be used with insulin pumps, there is generally a lack of available FDA-approved calculators for MDI patients using CGM-only system configurations or systems equipped with an insulin pen and CGM. Due to this lack of availability, MDI users often rely on qualitative bolus, such as estimating the dosage, rather than quantitatively determining the dose based on data. Furthermore, many MDI users generally do not consider or are unable to consider IOB when making dosage decisions.

[0033] Another downside is that there are many unapproved ballers calculator apps, but they have not actually received good reviews.

[0034] To provide safely used bolus calculators for both pump patients and MDI users, support and input from a Healthcare Professional (HCP) are essential, unless otherwise required. These HCPs may include, for example, endocrinologists, family physicians, internists, general practitioners, nurses, and certified diabetes educators. However, for certain types of HCPs, patient visit times are limited, and they may not have access to the resources to effectively set up the patient user's bolus calculator on patient devices, such as smartphones. Additionally, HCPs may find it inconvenient to use patient devices due to liability or other issues. As a result, many BCs are not properly set up.

[0035] A significant amount of prior art has been developed, particularly among pump manufacturers, in the context of bolus calculators, but generally relates to calculations and dosages based on SMBG measurements rather than continuous glucose monitoring measurements or many important characteristics and information derivable therefrom. Furthermore, pump setups differ from bolus calculator setups in many ways.

[0036] Embodiments of the present disclosure relate to systems, methods, and devices comprising enabling the setup of an HCP of a drug calculator and transmitting the results of such calculation to a drug delivery device. In various configurations described herein, the analyte data is glucose data generated by a glucose sensor system configured to be connected to a display device, etc. As described in detail herein, an implementation of an embodiment of the present disclosure can provide a safe and convenient setup of a drug calculator and a drug delivery device, including a bolus calculator and an insulin delivery device such as a pen and a pump. In particular, such an embodiment of the present disclosure relates to the setup of bolus calculator parameters by a physician, for example, transmitted to a patient, for example, their smartphone and pump. Systems and methods according to the present principle provide a convenient usage for both the patient and the HCP, ensuring use by both.

[0037] Systems and methods according to the present principle generally include methods for user and healthcare professional(s) to communicate securely via a wireless network and, in particular, methods for an HCP to prescribe insulin to a patient, i.e., as part of a bolus calculator parameter setup or as part of a pump setup. For example, the systems and methods may provide a bolus calculator setup using secure transmission over a network that brings about the desired function, for example, setting up a bolus calculator, where secure communication is established between the HCP and the user. The systems and methods generally use a ubiquitous smartphone by the user, and the systems and methods may use data determined by various sensors, including continuous glucose monitoring. The systems and methods generally provide analysis and calculation to provide calculated data to a drug delivery device to display as part of a bolus calculator and / or to allow administration by the user. Such drug delivery devices may include, for example, pumps, pens, etc.

[0038] The provided methods may be unique to the situations faced by different HCPs and may consider, for example, the amount of time spent with the patient, which may be short or long. Different HCPs may include, for example, endocrinologists, family physicians, certified diabetes educators, nurses, practitioners, and other users. Depending on the method, different amounts of information regarding the patient may be provided; for example, a practitioner may obtain glucose values, while an endocrinologist may obtain analyzed pattern graphs.

[0039] The system and method are not only related to the initial setup, but can also be used to update parameters for direct and automatic modification of bolus calculator parameters, transmit the updated parameters to the user, or allow the user to manually modify the parameters. In other embodiments, modifications may be suggested to be downloaded and automatically applied to the bolus calculator, but confirmation by the user may be required prior to the actual modification of the parameters.

[0040] Systems and methods based on the present principle generally do not merely review past data retrospectively to determine the success or failure of a user's diabetes treatment. Using the described systems and methods, a "give-and-take" can be made between the user generating the data and the physician reviewing and analyzing the data in collaboration with the patient. In the same way, the physician can "refine" the optimal set of parameters or determine the optimal set of parameters for a given patient situation, for example, weekdays versus weekends, by providing more significant, meaningful, and frequent updates to the bolus calculator parameters, if necessary.

[0041] In some cases, insurance may allow HCP to be reimbursed for the initial meeting and the setup of the bolus calculator, even if the setup was performed remotely. In the same way, transmitting an updated set of parameters along with optional HCP patient consultation may trigger other billing events. Parameter updates may originate from the user as well as from automated algorithms, which are expected to be the most common source of such updates. For example, if a user habitually takes one unit more than suggested by the bolus calculator and achieves a satisfactory result, the bolus calculator parameters may be automatically updated to increase the dosage. In some cases, notification of the proposed update may be sent to HCP for verification and approval.

[0042] In one technique, an HCP bolus calculator setup app may be provided to the HCP, for example, via an invitation link from the patient user (transmitted via text, email, etc., or via the technique described above in relation to the flowchart described below), and this provides an interface to be provided back to the patient user's device so that the HCP can set up specific bolus calculator parameters for the patient user and integrate them into the patient's bolus calculator. Using a system and method according to the present principle, a CGM-enabled bolus calculator may be provided. This provides a bolus calculator known by various CGM modalities, including glucose trends. The HCP can unlock the bolus calculator function and specify the calculator parameters. In some embodiments, for example, when the CGM is connected to the pump, the bolus calculator function may be disabled so that the pump calculator may take precedence over the CGM bolus calculator. The meal input of the bolus calculator may be made "fuzzy" so that the user can more conveniently input a small, average, or large meal size. Parameters for these different meal sizes can be defined by the HCP during setup. A third-party food database app can be used as input to the ballers calculator, the input can be validated by the user, and the user may be further provided with the ability to ignore such values. The CGM app can also calculate the IOB for the MDI user within the context of the ballers calculator.

[0043] Generally, data from third-party apps may be verified and / or authenticated before being used in the Bolus Calculator app. For example, values ​​may be 'grayed out' and not used in calculations until the user verifies their accuracy. The Bolus Calculator app or features may allow the user to input meal event data, for example, entered carbohydrates, and / or automatically pull meal event data from third-party applications, for example, via Apple HealthKit. In this way, for example, when a user accesses the Bolus Calculator, recently entered carbohydrates may be provided to them, and the user may choose to use this amount in the Bolus Calculator calculation or use a different value, for example, by considering food they are about to eat. In some cases, the CGM app may not be able to verify the accuracy of carbohydrate estimates from other meal database applications and may inform the user of this risk during initial use.

[0044] Details of some exemplary embodiments of the systems, methods, and apparatus of the present disclosure are described in this description and, in some cases, in other parts of the present disclosure. Other features, purposes, and benefits of the present disclosure will be apparent to those skilled in the art upon reviewing the present disclosure, description, drawings, embodiments, and claims. All such additional systems, methods, apparatus, features, and benefits are incorporated (expressly or by reference) into this description, are within the scope of the present disclosure, and are intended to be protected by one or more of the appended claims.

[0045] outline

[0046] In some embodiments, a system for continuous measurement of an analyte at a host is provided. The system may include a continuous analyte sensor configured to continuously measure the concentration of an analyte at a host, and a sensor electronic module physically connected to the continuous analyte sensor during sensor use. In certain embodiments, the sensor electronic module includes an electronic device configured to process a data stream associated with the analyte concentration measured by the continuous analyte sensor to generate sensor information, for example, including raw sensor data, converted sensor data, and / or any other sensor. The sensor electronic module may also be configured to generate sensor information customized for each display device so that different display devices can receive different sensor information.

[0047] As used herein, the term “analyte” is a broad term and is given a general and ordinary meaning to those skilled in the art (not limited to a special or customized meaning), and also means, but is not limited to, a substance or chemical component of a biological fluid (e.g., blood, bodily fluid, cerebrospinal fluid, lymph fluid, urine, sweat, saliva, etc.) that may be analyzed. Analytes may include naturally occurring substances, artificial substances, metabolites, and / or reaction products. In some embodiments, the analyte for measurement by the method or instrument is glucose. However, other analytes, including but not limited to the following, are likewise considered: carboxyprothrombin; acetoacetic acid; acetone; acetyl-core; acyl-carnitine; adenine phospho-ribosyl transferase; adenosine deaminase; albumin; alpha-fetoprotein; Amino Acid Profile (Arginine (Krebs Cycle); Histidine / Locaniic Acid, Homocysteine, Phenylalanine / Tyrosine; Tryptophan); Androstenedione; Antipyrine; Arbinitol Antioxidant; Arginase; Benzoelecgonine (Cocaine); Biotinidase; Biopterin; C-Reactive Protein; Carnitine; Carnosinase; CD4; Ceruloplasmin; Chenodeoxycholic Acid; Chloroquine; Cholesterol; Cholinesterase; Complex 1-β-hydroxycholic Acid; Cortisol; Creatine Kinase; Creatine Kinase MM Isozase; Cyclosporine A; d-Penicillamine; Di-Ethylchloroquine; Dehydroepiandrosterone Sulfate; DNA(acetyl polymorphism, alcohol dehydrogenase, alpha 1-antitrypsin, cystic fibrosis, Duchenne / Becker muscular dystrophy, glucose-6-phosphate dehydrogenase, hemoglobin A, hemoglobin S, hemoglobin C, hemoglobin D, hemoglobin E, hemoglobin F, D-Punjab, beta-thalasma, hepatitis B virus, HCMV, HIV-1, HTLV-1, Leber's hereditary optic neuropathy, MCAD, RNA, PKU, Plasmodium vivax, sex differentiation, 21-deoxycortisol); desbutylhalofantrine; dihydropteridine reductase;Diphtheria / tetanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin; esterase D; fatty acid / acylglycine; triglyceride; glycerin; free β-human chorionic gonadotropin; free erythrocyte porphyrin; free thyroxine (FT4); free tri-iodothyronine (FT3); fumaryl acetoacetase; galactose / gal-1-phosphate; galactose-1-phosphate uridyl transferase; gentamicin; glucose-6-phosphate dehydrogenase; glutathione; glutathione peroxidase; glycocholic acid; glycosylated hemoglobin; halopotinline; hemoglobin variant; hexosaminidase A; human erythrocyte carbonic anhydrase I; 17-alpha-hydroxyprogesterone; Hypoxanthine phosphoribosyl transferase; immunoreactive trypsin; ketone bodies; lactate; lead; lipoprotein((a), B / A-1,β); lysozyme; mefloquine; netilmycin; phenobarbiton; phenytoin; phytanic acid / frastanic acid; progesterone; prolactin; prolidease; purine nucleoside phosphorylase; quinine; inverse tri-iodothyronine (rT3); selenium; serum pancreatic lipase; cysomysin; somatomedin C; Specific antibodies (Adenovirus, Antinuclear antibody, Anti-zeta antibody, Arbovirus, Aujezky's disease virus, Dracunculus medenensis, Echinococcus granulosus, Enterova histolytica, Enterovirus, Giardia duodenalisa, Helicobacter pylori, Hepatitis B virus, Herpes virus, HIV-1, IgE (atopic disease), Influenza virus, Isoprene (2-methyl-1,3-butadiene), Visceral Leishmania, Leptospirosis, Measles / Mumps / Rubella, Leprosy bacteria, Mycoplasma pneumoniae, Myoglobin, Onchocerca pilosa, Parainfluenza virus, Plasmodium falciparum, Poliovirus, Pseudomonas aeruginosa, Respiratory syncytial virus, Rickettsia (Typhus), Schistosomiasis mansoni, Toxoplasma gondii, Trefenoma pallidum, Trip Panosoma cruzi / rangelii, vesicular variant virus, Ukulelia bancroft, flavivirus (e.g., deer tick, dengue fever, Powasen's fever, West Nile fever, yellow fever, or Zika virus);Specific antigens (Hepatitis B virus, HIV-1); succinylacetone; sulfadoxine; theophylline; thyroid-stimulating hormone (TSH); thyroxine (T4); thyroxine-binding globulin; trace elements; transferrin; UDP-galactose-4-epimerase; urea; uroporpyrinogen I synthase; vitamin A; leukocytes; and zinc protoporphyrin. Salts, sugars, proteins, fats, vitamins, and hormones that occur naturally in blood or interstitial fluid may also constitute the analytes in certain embodiments. The analytes may be naturally present in biological fluids, e.g., metabolites, hormones, antigens, antibodies, etc. Alternatively, the analytes may be introduced into the body or exogenously, e.g., imaging contrast agents, radioisotopes, chemical agents, fluorocarbon-based synthetic blood, or pharmaceuticals or pharmaceutical compositions, and include, but are not limited to: insulin; glucagon, ethanol; Cannabis (marijuana, tetrahydrocannabinol, hashish); inhalants (nitrous oxide, nitrite, butyl nitrite, chloro hydrocarbons, hydrocarbons); cocaine (foul cocaine); stimulants (amphetamine, methamphetamine, Ritalin, Silert, Preludin, Didrex, Freestate, Boranil, Sandrex, Plesin); depressants (tranquilizers such as barbiturates, methaqualone, Valium, Librium, Miltown, Serax, Ecuanil, and Tranzine); hallucinogens (phencyclidine, lysergic acid, mescaline, peyote, psilocybin); narcotics (heroin, codeine, morphine, opium, meperidine, Percoce, Percoden, Tursionex, fentanyl, Darvón, Talwin, Romotil); Synthetic drugs (analogous compounds of fentanyl, meperidine, amphetamine, methamphetamine, and phencyclidine, e.g., ecstasy); anabolic steroids;Nicotine. Metabolites of pharmaceuticals or pharmaceutical compositions are also considered as analytes. Analytes such as neurochemicals and other chemicals produced within the body may also be analyzed, for example: ascorbic acid, uric acid, dopamine, noradrenaline, 3-methoxycitamine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), 5-hydroxytryptamine (5HT), and 5-hydroxyindoleacetic acid (FHIAA), and intermediates of the citric acid cycle.;

[0048] alarm

[0049] In certain embodiments, one or more alarms are associated with a sensor electronic module. For example, each alarm may include one or more alarm states indicating when each alarm is triggered. For example, a hypoglycemia alarm may include an alarm state indicating a minimum glucose level. The alarm states may also be based on trending data and / or modified sensor data, such as sensor data from a number of different sensors (for example, the alarm may be based on sensor data from both a glucose sensor and a temperature sensor). For example, a hypoglycemia alarm may include an alarm state indicating a minimum required trend of the host's glucose level that must exist before triggering the alarm. As used herein, the term "trend" generally refers to data representing some attributes of data acquired over time, for example, calibrated or filtered data from a continuous glucose sensor. The trend may represent the amplitude, rate of change, acceleration, direction, etc. of data such as sensor data, including modified or raw sensor data.

[0050] In a specific embodiment, each alarm is associated with one or more actions to be performed in response to the triggering of the alarm. The alarm actions may include activating the alarm, such as, for example, displaying information on a display of the sensor electronic module or activating an audible or vibration alarm coupled to the sensor electronic module and / or transmitting data to one or more display devices outside the sensor electronic module. For any transmission action associated with the triggered alarm, one or more transmission options specify the content and / or format of the data to be transmitted, the device to which the data is transmitted, when the data is transmitted, and / or a communication protocol for data transmission. Additionally, the alarm may cause a bolus calculator parameter / setting modification trigger to be activated and a result signal to be generated and transmitted to an HCP server, as described in more detail below.

[0051] In a specific embodiment, a plurality of delivery operations (each having a delivery option) may be associated with a single alarm, so that displayable sensor information having different content and format is transmitted to each display device, for example, in response to the triggering of the single alarm. For example, a mobile phone may receive a data package containing minimal displayable sensor information (which may be specially formatted for a display on the mobile phone), while a desktop computer may receive a data package containing most (or all) displayable sensor information, and this information is generated by a sensor electronic module in response to the triggering of a common alarm. Advantageously, the sensor electronic module is configured not to rely on a single display device, but rather to communicate directly, systematically, simultaneously (e.g., via broadcast), regularly, periodically, randomly, on demand, in response to inquiries, based on an alarm or alarm, etc. with a plurality of different display devices.

[0052] In some embodiments, the clinical risk alert is provided with an alert state that combines an intelligent and dynamic estimation algorithm to estimate higher accuracy of existing or predicted risk, timeliness of imminent risk, avoidance of false alarms, and less discomfort to the patient. Generally, the clinical risk alert includes an intelligent and dynamic estimation algorithm that provides a more appropriate, clinically safe, and patient-friendly alarm based on analyte values, rates of change, acceleration, clinical risk, statistical probability, known physiological constraints, and / or individual physiological patterns. Reference [US Patent Publication No. 2007 / 0208246] is incorporated herein by reference in its entirety and describes some systems and methods associated with the clinical risk alert (or alarm) described herein. In some embodiments, the clinical risk alert may be triggered for a predetermined time period to allow the user to pay attention to their condition. Additionally, the clinical risk alert may be deactivated when leaving the clinical risk zone so as not to disturb the patient with repeated clinical alarms (e.g., visual, auditory, or vibration) when the patient's condition is improving. In some embodiments, dynamic and intelligent estimation determines the likelihood of a patient avoiding clinical risk based on analyte concentrations, rates of change, and dynamic and intelligent estimation algorithms of other modalities. If the likelihood of avoiding clinical risk is minimal or non-existent, a clinical risk alert will be triggered. However, if there is a likelihood of avoiding clinical risk, the system is configured to wait for a predetermined time period and re-analyze the likelihood of avoiding clinical risk. In some embodiments, when there is a likelihood of avoiding clinical risk, the system is also configured to provide goals, treatment recommendations, or other information that may help the patient avoid clinical risk in advance.

[0053] In some embodiments, the sensor electronic module is configured to search for one or more display devices within the communication range of the sensor electronic module and to wirelessly communicate sensor information (e.g., a data package including displayable sensor information, one or more alarm statuses and / or other alarm information). Accordingly, the display device is configured to display at least a portion of the sensor information and / or alert the host (and / or caregiver) when an alarm mechanism is located on the display device.

[0054] In some embodiments, the sensor electronic module is configured to provide one or more different alarms through the sensor electronic module and / or be initiated by one or more display devices through the transmission of a data package indicating the alarm (e.g., sequentially and / or simultaneously). In certain embodiments, the sensor electronic module merely provides a data field indicating that an alarm state is present, and the display device may decide to trigger the alarm when reading the data field indicating the presence of the alarm state. In some embodiments, the sensor electronic module determines one or more alarms to trigger based on one or more alarms being triggered. For example, if the alarm trigger indicates severe hypoglycemia, the sensor electronic module may perform a number of actions, such as activating an alarm on the sensor electronic module, transmitting a data package to a monitoring device indicating the activation of the alarm on the display, and transmitting the data package to a healthcare provider as a text message. For example, the text message may appear on a custom monitoring device, cell phone, pager device, etc., containing displayable sensor information indicating the host's status (e.g., "severe hypoglycemia").

[0055] In some embodiments, the sensor electronic module is configured to wait for a time period during which the host responds to a triggered alarm (e.g., by pressing or selecting a snooze and / or off function and / or button on the sensor electronic module and / or display device), and then to trigger additional alarms (e.g., in a stepwise manner) until one or more alarms are responded to. In some embodiments, the sensor electronic module is configured to transmit a control signal (e.g., a stop signal) to a medical device associated with an alarm state (e.g., hypoglycemia), such as an insulin pump, wherein the stop alarm triggers the cessation of insulin delivery through the pump.

[0056] In some embodiments, the sensor electronic module is configured to transmit alarm information in response to an inquiry (from a display device) directly, systematically, simultaneously (e.g., via broadcast), regularly, periodically, randomly, or on demand, based on an alarm or the like. In some embodiments, the system further includes a repeater that can increase the wireless communication distance of the sensor electronic module to, for example, 10, 20, 30, 50, 75, 100, 150, or 200 meters or more, and the repeater is configured to relay wireless communication from the sensor electronic module to a remotely located display device. The repeater may be useful to families with a child with diabetes. For example, it allows parents to carry the display device or place it in a fixed location, such as when parents sleep away from the child in a large house.

[0057] Display device

[0058] In some embodiments, the sensor electronic module is configured to search for and / or attempt wireless communication with a display device from a list of display devices. In some embodiments, the sensor electronic module is configured to search for and / or attempt wireless communication with a list of display devices in a predetermined and / or programmable order (e.g., graded and / or stepwise expansion), and, for example, if an attempt to communicate with and / or alarm an alarm with a first display device fails, to trigger an attempt to communicate with and / or alarm an alarm with a second display device. In an exemplary embodiment, the sensor electronic module is configured to sequentially search for and attempt to alarm an alarm with a host or medical provider using a list of display devices such as: (1) a default display device or a custom analyte monitoring device; (2) a mobile phone via auditory and / or visual methods, such as text messages sent to a host and / or medical provider, or voice messages sent to a host and / or medical provider and / or 911; (3) a tablet; (4) a smart watch or bracelet; and / or (5) smart glasses or other wearable display devices.

[0059] According to an embodiment, one or more display devices receiving a data package from a sensor electronic module are “dummy displays” that display displayable sensor information received from the sensor electronic module without additional processing (e.g., preliminary algorithm processing required for real-time display of sensor information). In some embodiments, the displayable sensor information includes converted sensor data that does not require processing by the display device prior to the display of the displayable sensor information. Some display devices may include software that includes display commands configured to enable the display of displayable sensor information (software programming including commands configured to display displayable sensor information and optionally query the sensor electronic module to obtain displayable sensor information). In some embodiments, the display device is programmed with display commands by a manufacturer and may include security and / or authentication to avoid plagiarism of the display device. In some embodiments, the display device is configured to display displayable sensor information through a downloadable program (e.g., JavaScript downloadable via the Internet), and any display device that supports the download of the program (e.g., any display device that supports Java applets) may be configured to display displayable sensor information (e.g., mobile phone, tablet, PDA, PC, etc.).

[0060] In some embodiments, a specific display device may communicate directly wirelessly with a sensor electronic module, but intermediate network hardware, firmware, and / or software may be included within the direct wireless communication. In some embodiments, a repeater (e.g., a Bluetooth repeater) may be used to retransmit transmitted displayable sensor information to a location further away than the immediate range of the sensor electronic module's telemetry module, and the repeater may communicate directly wirelessly when no substantial processing of the displayable sensor information occurs. In some embodiments, a receiver (e.g., a Bluetooth receiver) may be used to retransmit transmitted displayable sensor information onto a TV screen in a possible other format, such as a text message, and the receiver may communicate directly wirelessly when no substantial processing of the sensor information occurs. In certain embodiments, the sensor electronic module directly wirelessly transmits displayable sensor information to one or more display devices so that the displayable sensor information transmitted from the sensor electronic module is received by the display device without intermediate processing of the displayable sensor information.

[0061] In certain embodiments, one or more display devices include a built-in authentication mechanism for which authentication is required for communication between the sensor electronic module and the display device. In some embodiments, to authenticate data communication between the sensor electronic module and the display device, a try-and-response protocol, such as password authentication, is provided, in which the attempt is a request for a password and the valid response is the correct password, so that pairing of the sensor electronic module and the display device can be achieved by the user and / or the manufacturer via the password. This may also be referred to as bidirectional authentication in some cases.

[0062] In some embodiments, one or more display devices are configured to query a display electronic sensor module for displayable sensor information, and the display device acts as a master device that requests sensor information from a sensor electronic module (e.g., a slave device) on demand, for example, in response to a query. In some embodiments, the sensor electronic module is configured to transmit sensor information to one or more display devices periodically, systematically, regularly, and / or periodically (e.g., every 1, 2, 5, or 10 minutes or more). In some embodiments, the sensor electronic module is configured to transmit a data package associated with a triggered alarm (e.g., triggered by one or more alarm states). However, any combination of the data transmission states described above may be implemented by any combination of paired sensor electronic modules and display devices. For example, one or more display devices may be configured to query a sensor electronic module database and receive alarm information triggered by one or more alarm states that are satisfied. Additionally, the sensor electronic module may be configured to periodically transmit sensor information to one or more display devices (display devices identical or different from those described in the previous embodiment), and accordingly, the system may include display devices that function differently depending on how the sensor information is obtained.

[0063] In some embodiments, the display device is configured to query the data storage memory of the sensor electronic module for a specific type of data content, including a direct query of the database in the memory of the sensor electronic module and / or a request for a data content package configured or configurable therefrom; that is, based on the display device with which the sensor electronic module communicates, the data stored in the sensor electronic module is configurable, queryable, predetermined, and / or pre-packaged. In some additional or alternative embodiments, the sensor electronic module generates displayable sensor information based on knowledge of which display device receives a specific transmission. Additionally, some display devices may obtain calibration information and wirelessly transmit calibration information to the sensor electronic module, such as through manual input of calibration information, automatic transmission of calibration information, and / or through an integrated reference analysis monitor integrated into the display device. References [US Patent Publication Nos. [2006 / 0222566, 2007 / 0203966, 2007 / 0208245, and 2005 / 0154271] are all incorporated herein by reference in their entirety and describe systems and methods for providing an integrated reference analyte monitor integrated into a display device and / or other calibration methods that may be implemented in embodiments disclosed herein.

[0064] Generally, a plurality of display devices (e.g., customized analyte monitoring devices (which may also be referred to as analyte display devices), mobile phones, tablets, smartwatches, reference analyte monitors, drug delivery devices, medical devices, and personal computers) may be configured to communicate wirelessly with a sensor electronic module. The plurality of display devices may be configured to display at least some of the displayable sensor information wirelessly communicated from the sensor electronic module. The displayable sensor information may include sensor data such as raw data and / or modified sensor data, such as analyte concentration values, rate of change information, trend information, alarm information, sensor diagnostic information, and / or calibration information.

[0065] analyte sensor

[0066] Referring to FIG. 1a, in some embodiments, the analyte sensor (10) comprises a continuous analyte sensor, e.g., a subcutaneous, transdermal (e.g., transdermal) or intravascular device. In some embodiments, such a sensor or device may analyze a plurality of intermittent blood samples. Although the present disclosure includes embodiments of a glucose sensor, such embodiments may likewise be used for other analytes. The glucose sensor may use any glucose-measuring method including enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, ionophoretic, radiometric, immunochemical measurements, etc.

[0067] The glucose sensor may use any known method, including invasive, minimally invasive, and non-invasive sensing techniques (e.g., fluorescence monitoring), to provide a data stream representing glucose concentration within the host. The data stream is typically a raw data signal, which is converted into a corrected and / or filtered data stream used to provide glucose values ​​useful to a user, such as a patient or caregiver (e.g., parent, relative, guardian, teacher, doctor, nurse, or any other individual interested in the well-being of the host).

[0068] A glucose sensor can be any device capable of measuring glucose concentration. According to an exemplary embodiment described below, an insertable glucose sensor may be used. However, it should be understood that the device and method described herein may be applied to any device capable of detecting glucose concentration and providing an output signal indicating glucose concentration (e.g., in the form of analyte data).

[0069] In a specific embodiment, the analyte sensor (10) is an insertable glucose sensor as described with reference to [US Patent 6,001,067] and [US Patent Publication No. US-2005-0027463-A1]. In an embodiment, the analyte sensor (10) is a transdermal glucose sensor as described with reference to [US Patent Publication No. US-2006-0020187-A1]. In an embodiment, the analyte sensor (10) is [US Patent Publication No. US-2007-0027385-A1], [co-pending US Patent Publication No. US-2008-0119703-A1 filed October 4, 2006], and [US Patent Publication No. As described in [US-2008-0108942-A1 filed on March 26, 2007] and [US Patent Application No. US-2007-0197890-A1 filed on February 14, 2007], it is configured to be inserted into a host blood vessel or outside the body. In an embodiment, the continuous glucose sensor comprises, for example, a transdermal sensor as described in [US Patent 6,565,509 to Say et al.]. In an embodiment, the analyte sensor (10) is a continuous glucose sensor comprising, for example, a subcutaneous sensor as described by reference [US Patent 6,579,690 to Bonnecaze et al.] or [US Patent 6,484,046 to Say et al.]. In an embodiment, the continuous glucose sensor comprises a refillable subcutaneous sensor as described, for example, with reference to reference [US Patent 6,512,939 to Colvin et al.]. The continuous glucose sensor comprises, for example, reference [USIt may include an intravascular sensor as described with reference to Patent 6,477,395 to Schulman et al. The continuous glucose sensor may include, for example, an intravascular sensor as described with reference to US Patent 6,424,847 to Mastrototaro et al.

[0070] FIGS. 2a and 2b are a perspective view and a side view of an enclosure (200) that may be used in connection with implementing an embodiment of an analyte sensor system (8) according to a particular aspect of the present disclosure. In a particular embodiment, the enclosure (200) includes a mounting unit (214) and a sensor electronic module (12) attached thereto. The enclosure (200) is illustrated in a functional position that includes the mounting unit (214) and the sensor electronic module (12) which are coupled internally. In some embodiments, the mounting unit (214), also referred to as a housing or sensor pod, includes a base (234) configured to be fixed to the skin of a host or user. The base (234) may be formed of various hard or soft materials and may include a low profile to minimize protrusion of the device from the host during use. In some embodiments, the base (234) is formed at least partially from a flexible material, which can provide many advantages over other transdermal sensors that may unfortunately suffer from motion-related artifacts associated with the host's movement when the host is using the device. The mounting unit (214) and / or the sensor electronic module (12) may be positioned over the sensor insertion site to protect the site and / or provide a minimal footprint (use of the surface area of ​​the host's skin).

[0071] In some embodiments, a removable connection between the mounting unit (214) and the sensor electronic module (12) is provided to enable improved manufacturing capabilities, namely that the potentially relatively inexpensive mounting unit (214) can be discarded when the analyte sensor system (8) is modified or repaired, while the relatively more expensive sensor electronic module (12) can be reused in multiple sensor systems. In some embodiments, the sensor electronic module (12) consists of signal processing (programming) configured to filter, calibrate, and / or execute other algorithms useful for, for example, the calibration and / or display of sensor information. However, an integral (non-removable) sensor electronic module may be configured.

[0072] In some embodiments, the contact portion (238) is mounted on or within a subassembly hereinafter referred to as a contact subassembly (236) configured to be fitted into the base (234) of the mounting unit (214), and a hinge (248) that allows the contact subassembly (236) to pivot between a first position (for insertion) and a second position (for use) relative to the mounting unit (214). As used herein, the term “hinge” is a broad term and, in a general sense, includes but is not limited to referring to any various pivot, articulating, and any or hinge mechanisms such as adhesive hinges, sliding joints, etc.; the term hinge does not necessarily imply a fulcrum or fixed point where the joint occurs. In some embodiments, the contact portion (238) is formed from a conductive elastic material such as carbon black elastomer, from which the sensor (10) extends.

[0073] Referring further to FIGS. 2a and 2b, in a specific embodiment, the mounting unit (214) is provided with an adhesive pad (208) disposed on the back surface of the mounting unit and includes a releasable backing layer. Thus, by removing the backing layer and pressing at least a portion of the base (234) of the mounting unit (214) onto the host's skin, the mounting unit (214) is attached to the host's skin. Additionally or alternatively, the adhesive pad may be placed over part or all of the analyte sensor system (8) and / or sensor (10) after sensor insertion is completed to ensure adhesion and optionally ensure an airtight or waterproof seal around the wound exit-site (or sensor insertion site) (not shown). A suitable adhesive pad may be selected and designed to stretch, elongate, fit, and / or allow air to pass through the said area (e.g., the host's skin). The embodiment described with reference to FIGS. 2a and 2b is [US Patent No. [7,310,544] is described in more detail with reference, which is incorporated herein by reference in its entirety. The configuration and arrangement may provide water resistance, water resistance, and / or sealing properties associated with the mounting unit / sensor electronic module embodiments described herein.

[0074] Various methods and apparatus suitable for use in connection with aspects of some embodiments are disclosed in reference [US Patent Publication No. US-2009-0240120-A1], the entirety of which is incorporated herein by reference for all purposes.

[0075] Example configuration

[0076] Referring again to FIG. 1a, a system (100) that may be used in connection with implementing embodiments of an analyte sensor system is illustrated. In some cases, the system (100) may be used to implement various systems described herein. In embodiments, the system (100) includes an analyte sensor system (8) and display devices (110, 120, 130, and 140) according to specific embodiments of the present disclosure. In the illustrated embodiment, the analyte sensor system (8) includes a sensor electronic module (12) and a continuous analyte sensor (10) associated with the sensor electronic module (12). The sensor electronic module (12) may communicate wirelessly (e.g., directly or indirectly) with one or more display devices (110, 120, 130, and 140). In embodiments, the system (100) also includes a medical device (136) and a server system (134). The sensor electronic module (12) may also communicate wirelessly (e.g., directly or indirectly) with the medical device (136) and the server system (134). In some embodiments, the display device (110 to 140) may also communicate wirelessly with the server system (134) and / or the medical device (136).

[0077] In a specific embodiment, the sensor electronic module (12) includes electronic circuitry associated with measuring and processing continuous analyte sensor data, including a preliminary algorithm associated with processing and calibration of sensor data. The sensor electronic module (12) may be physically connected to the continuous analyte sensor (10) and may be attached integrally (immovably attached) or detachably to the continuous analyte sensor (10). The sensor electronic module (12) may include hardware, firmware, and / or software that enables the measurement of analyte levels through the glucose sensor. For example, the sensor electronic module (12) may include a potentiostat, a power supply for the sensor, other components useful for signal processing and data storage, and a telemetry module that transmits data from the sensor electronic module to one or more display devices. The electronic device may be attached to a printed circuit board (PCB), etc., and may take various forms. For example, the electronic device may take the form of an integrated circuit (IC), such as an application-specific integrated circuit (ASIC), a microcontroller, and / or a processor.

[0078] The sensor electronic module (12) may include a sensor electronic device configured to process sensor information, such as sensor data, and to generate converted sensor data and displayable sensor information. Examples of a system and method for processing sensor analyte data are described herein and in references [US Patent Nos. 7,310,544 and 6,931,327 and US Patent Publication Nos. [2005 / 0043598, 2007 / 0032706, 2007 / 0016381, 2008 / 0033254, 2005 / 0203360, 2005 / 0154271, 2005 / 0192557, 2006 / 0222566, 2007 / 0203966 and 2007 / 0208245] are described in more detail, the entire contents of which are incorporated herein by reference for all purposes.

[0079] Referring again to FIG. 1a, a display device (110, 120, 130 and / or 140) is configured to display (and / or alarm) displayable sensor information that can be transmitted by a sensor electronic module (12) (e.g., as a customized data package transmitted to the display device based on each preference). Each of the display devices (110, 120, 130, or 140) may include a display, such as a touch screen display (112, 122, 132 and / or 142), for displaying sensor information and / or analysis data to a user and / or receiving input from a user. For example, a graphical user interface may be provided to the user for this purpose. In some embodiments, the display device may include another type of user interface, such as a voice user interface, instead of or in addition to a touch screen display, for communicating sensor information to the user of the display device and / or receiving user input. In some embodiments, one, some, or all of the display devices are configured to display or communicate sensor information when communicated from a sensor electronic module (e.g., a data package transmitted to each display device) without any additional preliminary processing required for calibration and real-time display of sensor data.

[0080] The medical device (136) may be a passive device in an exemplary embodiment of the present disclosure. For example, the medical device (136) may be an insulin pump for injecting insulin into a user, as illustrated in FIG. 1b. For various reasons, it may be desirable for such an insulin pump to receive and track glucose values ​​transmitted from the analyte sensor system (8). One reason is to provide the insulin pump with the ability to stop or activate insulin injection when the glucose value is below a threshold. One solution that enables the passive device (e.g., medical device (136)) to receive analyte data (e.g., glucose values) without being coupled to the analyte sensor system (8) is to include the analyte data in an advertising message transmitted from the analyte sensor system (8). The data included in the advertising message may be encoded so that only a device having identification information associated with the analyte sensor system (8) can decode the analyte data. In some embodiments, the medical device (136) includes, for example, a sensor device (136b) that can be attached or worn by a user, and the sensor device (136b) communicates wired or wirelessly with a dedicated monitor or display device (136a) to process sensor data and / or display data from a sensor device (136a) and / or receive input for the operation of the sensor device and / or data processing.

[0081] Referring further to FIG. 1a, a plurality of display devices may include a custom display device specifically designed to display a specific type of displayable sensor information (e.g., level values ​​and arrows in some embodiments) associated with analysis data received from a sensor electronic module (12). An analysis display device (110) is an example of such a custom device. In some embodiments, one of the plurality of display devices is a smartphone, such as a mobile phone (120) based on Android, iPhone iOS, or another operating system, and is configured to display a graphic representation of continuous sensor data (e.g., including current and past data). Other display devices may include a tablet (130), a smart watch (140), a medical device (136) (e.g., an insulin delivery device or a blood glucose meter) and / or other portable devices such as a desktop or laptop computer.

[0082] Because different display devices provide different user interfaces, the content of the data package (e.g., amount of data to be displayed, format and / or type, alarms, etc.) can be customized for each specific display device (e.g., programmed differently by the manufacturer and / or end user). Accordingly, in the embodiment of FIG. 1a, a plurality of different display devices can communicate directly wirelessly with a sensor electronic module (e.g., an on-skin sensor electronic module (12) physically connected to a continuous analyte sensor (10)) during a sensor session, thereby enabling a plurality of different types and / or levels of display and / or functions associated with displayable sensor information, which are described in more detail elsewhere in this specification.

[0083] As further illustrated in FIG. 1a, the system (100) may also include a wireless access point (WAP) (138) that can be used to combine one or more of an analyte sensor system (8), a plurality of display devices, a server system (134), and a medical device (136). For example, the WAP (138) may provide Wi-Fi and / or cellular access within the system (100). Near-field communication (NFC) may also be used between the devices of the system (100). The server system (134) may be used to collect analyte data from the analyte sensor system (8) and / or a plurality of display devices, for example, to perform analysis thereon and to generate a universal or individualized model for glucose levels and profiles. One embodiment of the server system (134) may be used to receive bolus calculator trigger events from a user mobile device and / or to determine this from the received user sensor signal data.

[0084] Now, referring to FIG. 3a, a system (300) is illustrated. The system (300) may be used in connection with implementing embodiments of the disclosed system, method, and apparatus. For example, the various components described below in FIG. 3a may be used to provide wireless communication of glucose data between an analyte sensor system and a plurality of display devices, medical devices, servers, etc., as illustrated in FIG. 1a, for example.

[0085] As illustrated in FIG. 3a, the system (300) may include an analyte sensor system (308) and one or more display devices (310). Additionally, in the illustrated embodiment, the system (300) includes a server system (334), and the server system (334) includes a server (334a) coupled to a processor (334c) and a storage device (334b). The analyte sensor system (308) may be coupled to the display device (310) and / or the server system (334) via a communication medium (305) to communicate sensor data that may be used, for example, to determine whether bolus calculator parameters or settings require modification.

[0086] As described in detail in this specification, the analyte sensor system (308) and the display device (310) may exchange messages through a communication medium (305), and the communication medium (305) may also be used to transmit analyte data to the display device (310) and / or the server system (334). As mentioned above, the display device (310) may include various electronic computing devices such as, for example, smartphones, tablets, laptops, wearable devices, etc. The display device (310) may also include an analyte display device (110) and a medical device (136). Here, it should be noted that the GUI of the display device (310) may perform functions such as accepting user input and displaying menus as well as information derived from the analyte data. The GUI may be various operating systems known in the prior art, such as, for example, iOS, Android, Windows Mobile, Windows, Mac OS, Chrome OS, Linux, Unix, game platform OS (e.g., Xbox, PlayStation, Wii), etc. In various embodiments, the communication medium (305) may be based on one or more wireless communication protocols such as Bluetooth, Bluetooth Low Energy (BLE), Zigbee, Wi-Fi, 802.11 protocol, infrared (IR), radio frequency (RF), 2G, 3G, 4G, etc., and / or wired protocols and media.

[0087] In various embodiments, elements of the system (300) may be used to perform various processes described herein and / or to perform various operations described herein in connection with one or more disclosed systems and methods. When studying the present disclosure, those skilled in the art will recognize that the system (300) may include a plurality of analyte sensor systems, communication media (305) and / or server systems (334).

[0088] As mentioned, the communication medium (305) may be used to connect or enable communication between an analysis sensor system (308), a display device (310), and / or a server system (334) or to a network, and the communication medium (305) may be implemented in various forms. For example, the communication medium (305) may include internet access such as a local area network (LAN), a wide area network (WAN), a fiber optic network, the internet over a power line, a wired connection (e.g., a bus), or any other type of network access. The communication medium (305) may be implemented using any combination of routers, cables, modems, switches, fiber optics, wires, radios (e.g., microwave / RF links). Additionally, the communication medium (305) may be implemented using various wireless standards such as Bluetooth®, BLE, Wi-Fi, 3GPP standards (e.g., 2G GSM / GPRS / EDGE, 3G UMTS / CDMA2000, or 4G LTE / LTE-U). When reading the present disclosure, those skilled in the art will recognize other methods of implementing a communication medium (305) for communication purposes.

[0089] The server (334a) may receive, collect, or monitor information including analyte data and related information from the analyte sensor system (308) and / or the display device (310), such as an input received in connection with an analyte monitoring application running on the analyte sensor system or the display device (310) or an input responding to analyte data. In this case, the server (334a) may be configured to receive such information via a communication medium (305). This information may be stored in a storage device (334b) and processed by a processor (334c). For example, the processor (334c) may include an analysis engine capable of performing analysis on the information collected and received by the server (334a) via the communication medium (305). In embodiments, the server (334a), the storage device (334b), and / or the processor (334c) may be implemented as a distributed computing network such as a Hadoop® network or as a relational database, etc.

[0090] The server (334a) may include, for example, an internet server, a router, a desktop or laptop computer, a smartphone, a tablet, a processor, a module, etc., and may be implemented in various forms including, for example, an integrated circuit or a group thereof, a printed circuit board or a group thereof, or a discrete housing / package / rack or a number of these. In embodiments, the server (334a) enables communication to be performed at least partially through a communication medium (305). Such communication includes transmission and / or messaging (e.g., advertisements, commands or other messaging) and analysis data. For example, the server (334a) may process and exchange messages between the analysis sensor system (308) and the display device (310) with respect to frequency band, transmission timing, security, alarms, etc. The server (334a) may update information stored on the analysis sensor system (308) and / or the display device (310) by, for example, by transmitting an application. The server (334a) can transmit / receive information to / from the analyte sensor system (308) and / or display device (310) in real-time or sporadically. Additionally, the server (334a) can implement cloud computing functions for the analyte sensor system (308) and / or display device (310).

[0091] FIG. 3b illustrates a system (302) comprising an example of additional aspects of the present disclosure that may be used in connection with implementing an analyte sensor system. As illustrated, the system (302) may include an analyte sensor system (308). As illustrated, the analyte sensor system (308) may include an analyte sensor (375) (e.g., may also be indicated by the number (10) in FIG. 1a) coupled to a sensor measurement circuit (370) for processing and managing sensor data. The sensor measurement circuit (370) may be coupled to a processor / microprocessor (380) (e.g., may be part of item (12) in FIG. 1a). In some embodiments, the processor (380) may perform some or all of the functions of the sensor measurement circuit (370) for obtaining and processing sensor measurements from the sensor (375). The processor (380) may also be coupled to a radio unit or transceiver (320) (e.g., may be part of item (12) in FIG. 1a) for receiving requests and commands from an external device, such as a display device (310), which can be used to transmit sensor data and display or provide sensor data (or analyte data) to a user. As used herein, the terms “radio unit” and “transceiver” are used interchangeably and generally refer to a device capable of transmitting and receiving data wirelessly. The analyte sensor system (308) may further include a storage device (365) (e.g., may be part of item (12) in FIG. 1a) for storing and tracking sensor data and a real-time clock (RTC) (380) (e.g., may be part of item (12) in FIG. 1a).

[0092] As mentioned above, a wireless communication protocol may be used to transmit and receive data between an analyte sensor system (308) and a display device (310) via a communication medium (305). Such a wireless protocol may be designed for use in a wireless network optimized for periodic and small-scale data transmission (which may be transmitted at low speeds if necessary) to and from multiple devices in a short distance (e.g., a Personal Area Network (PAN)). For example, one such protocol may be optimized for periodic data transmission in which a transceiver may be configured to transmit data for a short interval and then enter a low-power mode for a long interval. The protocol may have low overhead requirements for normal data transmission and initial communication channel setup to reduce power consumption (e.g., by reducing overhead). In some embodiments, burst broadcasting methods (e.g., unidirectional communication) may be used. This may allow periodic transmission that consumes little power by eliminating the overhead required for acknowledgment signals.

[0093] Protocols can also be configured to establish communication channels with multiple devices while implementing interference avoidance schemes. In some embodiments, the protocol may use an adaptive isochronous network topology that defines various time slots and frequency bands for communication with multiple devices. Thus, the protocol can modify the transmission window and frequency in response to interference and support communication with multiple devices. Accordingly, the wireless protocol may use Time and Frequency Division Multiplexing (TDMA) based schemes. The wireless protocol may also use Direct Sequence Spread Spectrum (DSSS) and Frequency-Hopping Spread Spectrum schemes. Various network topologies may be used to support short-range and / or low-power wireless communication, such as peer-to-peer, start, tree, or mesh network topologies like Wi-Fi, Bluetooth, and Bluetooth Low Energy (BLE). The wireless protocol may operate in various frequency bands, such as the open ISM band at 2.4 GHz. Additionally, to reduce power consumption, the wireless protocol may adaptively configure the data rate based on power consumption.

[0094] consumption

[0095] Referring further to FIG. 3b, the system (302) may include a display device (310) that is communicably coupled to an analyte sensor system (308) via a communication medium (305). In the illustrated embodiment, the display device (310) includes a connection interface (315) (which includes a transceiver (320)), a storage device (325) (which stores an analyte sensor application (330) and / or additional applications), a processor / microprocessor (335), a graphical user interface (GUI) (340) provided using a display (345) of the display device (310), and a real-time clock (RTC) (350). A bus (not shown herein) may be used to interconnect various elements of the display device (310) and to transmit data between these elements.

[0096] The display device (310) may be used to provide sensor information or analyte data to a user for alarms and may include a processor / microprocessor (335) for processing and managing sensor data. The display device (310) may include a display (345), a storage device (325), an analyte sensor application (330), and a real-time clock (350) for displaying, storing, and tracking sensor data. The display device (310) may further include a radio unit or transceiver (320) coupled to other elements of the display device (310) via a connection interface (315) and / or a bus. The transceiver (320) may be used to receive sensor data and transmit requests, commands, and / or data to the analyte sensor system (308). The transceiver (320) may also use a communication protocol. The storage device (325) may also be used to store an operating system for the display device (310) and / or a custom (e.g., dedicated) application designed for wireless data communication between the transceiver and the display device (310). The storage device (325) may be a single memory device or a multi-memory device and may be volatile or non-volatile memory for storing data and / or commands for software programs and applications. Commands may be executed by a processor (335) to control and manage the transceiver (320).

[0097] In some embodiments, when a standardized communication protocol is used, commercially available transceiver circuits may be used that incorporate processing circuits for handling low-level data communication functions, such as data encoding, transmission frequencies, and the management of handshake protocols. In these embodiments, the processor (335, 380) does not need to manage these activities, but rather provides the desired data values ​​for transmission, manages high-level functions such as powering on or off, and sets the speed at which the message is transmitted. Commands and data values ​​for performing these high-level functions may be provided to the transceiver circuit via data buses and transmission protocols established by the manufacturer of the transceiver (320, 360).

[0098] Components of the analyte sensor system (308) need to be replaced periodically. For example, the analyte sensor system (308) may include an insertable sensor (375) and a battery (not shown) that can be attached to a sensor electronic module comprising a sensor measurement circuit (370), a processor (380), a storage device (365), and a transceiver (360). The sensor (375) may require periodic replacement (e.g., every 7 to 30 days). The sensor electronic module may be configured to remain powered and active for a much longer period than the sensor (375) (e.g., for 3 to 6 months or more) until the battery needs to be replaced. Replacing these components can be difficult and may require the assistance of skilled personnel. Reducing the need to replace these components, particularly the battery, significantly improves the convenience and cost of using the analyte sensor system (308), including for the user. In some embodiments, when the sensor electronic module is first used (or in some cases when the battery is replaced and reactivated), it may be connected to the sensor (375) and a sensor session may be established. As further described below, when the module is first used or reactivated (e.g., when the battery is replaced), there may be a process for initially establishing communication between the display device (310) and the sensor electronic module. Once the display device (310) and the sensor electronic module establish communication, the display device (310) and the sensor electronic module may communicate periodically and / or continuously for the lifespan of multiple sensors (375), for example, until the battery needs to be replaced. Whenever a sensor (375) is replaced, a new sensor session may be established. A new sensor session may be initiated through a process completed using the display device (310), and the process may be triggered by a notification of the new sensor through communication between the sensor electronic module and the display device (310) that may continue across the sensor sessions.

[0099] The analyte sensor system (308) typically collects analyte data from the sensor (375) and transmits it to the display device (310). Data points regarding analyte values ​​may be collected and transmitted over the lifespan of the sensor (375) (e.g., in the range of 1 day to 30 days or more). New measurements may be transmitted frequently enough to adequately monitor glucose levels. Instead of the transmission and reception circuits of the analyte sensor system (308) and the display device (310) communicating continuously, the analyte sensor system (308) and the display device (310) may establish a communication channel between them regularly and / or periodically. Thus, the analyte sensor system (308) may, in some cases, communicate with the display device (310) (e.g., a portable computing device, a medical device, or a dedicated device) via wireless transmission at predetermined time intervals. The duration of the predetermined time interval may be selected to be sufficiently long so that the analyte sensor system (308) does not consume too much power by transmitting data more frequently than necessary, but transmits it sufficiently frequently to provide real-time sensor information (e.g., measured glucose values ​​or analyte data) to the display device (310) for output to the user (e.g., via the display (345)). In some embodiments, the predetermined time interval is every 5 minutes, but it can be seen that this time interval can be changed to any desired time length.

[0100] Referring further to 3b, as illustrated, the connection interface (315) interfaces the display device (310) to the communication medium (305), so that the display device (310) can be coupled to the analyte sensor system (308) for communication via the communication medium (305). The transceiver (320) of the connection interface (315) may include a plurality of transceiver modules capable of operating for different wireless standards. The transceiver (320) may be used to receive analyte data and associated commands and messages from the analyte sensor system (308). Additionally, the connection interface (315) may, in some cases, include additional components for controlling wireless and / or wired connections, such as baseband and / or Ethernet modems, audio / video codecs, etc.

[0101] The storage device (325) may include volatile memory (e.g., RAM) and / or non-volatile memory (e.g., flash storage), and may include any of EPROM, EEPROM, and cache, or a combination or variation thereof. In various embodiments, the storage device (325) may store user input data collected by the display device (310) and / or other data (e.g., input from other users collected through the analyte sensor application (330)). The storage device (325) may also be used to store the amount of analyte data received from the analyte sensor system (308) for subsequent retrieval and use, for example, to determine trends and trigger alarms. Additionally, the storage device (325) may store an analyte sensor application (330) that receives input (e.g., by conventional hard / soft keys or a touch screen, voice detection or other input mechanism) when executed using the processor (335), and enables the user to interact with the analyte data and related content through the GUI (340), which will be described in more detail in the specification.

[0102] In various embodiments, a user may interact with an analyte sensor application (330) through a GUI (340) that may be provided by a display (345) of a display device (310). For example, the display (345) may be a touch screen display that accepts various hand gestures as input. The application (330) may process and / or provide analyte-related data received by the display device (310) according to various operations described herein, and may provide such data through the display (345). Additionally, the application (330) may be used to acquire, access, display, control, and / or interface with analyte data and related messaging and processes associated with the analyte sensor system (308), as described in more detail herein.

[0103] The application (330) may be downloaded, installed, and initially configured / set up on the display device (310). For example, the display device (310) may obtain the application (330) from a server system (334) or from another source accessed via a communication medium (e.g., communication medium (305)), such as an application store. After installation and setup, the application (330) may be used to access and / or interface with analyte data (e.g., stored locally on the server system (334), from the storage device (325), or from the analyte sensor system (308). As an example, the application (330) may provide a menu containing various controls or commands that can be executed in relation to the operation of the analyte sensor system (308) and one or more display devices (310). The application (330) may also be used to interface with or control another display device (310) to transmit or make available the analyte data, for example, by directly receiving / transmitting the analyte data to the other display device (310) and / or transmitting commands to the connected analyte sensor system (308) and the other display device (310), which will be described herein. In some embodiments, the application (330) may interact with other application(s) of the display device to retrieve or provide related data, for example, other health data.

[0104] As becomes clear from the description of the various functions in this specification (e.g., in relation to the disclosed method), the analyte sensor application (330) may include various code / function modules, such as a display module, a menu module, a list module, etc. These modules may be implemented individually or in combination. Each module may include a computer-readable medium where computer-executable code is stored therein, and the code may be operably coupled to and / or executed by a processor (335) (e.g., may include circuits for such execution) to perform specific functions (e.g., as described in this specification in relation to various operations and flowcharts, etc.) in relation to interfacing with analyte data and performing related operations. As further described below, the display module may provide various screens to the user (e.g., via the display (345)), and the screens include a graphical representation of information provided by the application (330). In another embodiment, the application (330) may be used to display to the user an environment for viewing and interacting with various display devices that may be connected to the analyte sensor system (308) as well as the analyte sensor system (308) itself. The sensor application (330) may include a native application modified with a software design kit (e.g., depending on the operating system) to perform the functions / features described herein.

[0105] Referring again to FIG. 3b, the display device (310) may include a processor (335). The processor (335) may include a processor sub-module that interfaces with and / or controls other elements of the display device (310), for example, a connection interface (315), an application (330), a GUI (340), a display (345), an RTC (350), etc., and includes an application processor. The processor (335) may include a controller and / or microcontroller that provides various controls related to device management (e.g., interface with buttons and switches), such as a list of available or previously paired devices, information related to measurements, information related to network status (e.g., link quality, etc.), and information related to the timing, type, and / or structure of messaging exchanged between the analysis sensor system (308) and the display device (310). In addition, the controller may include various controls related to the collection of user inputs, such as the analysis data, as well as user fingerprints (e.g., used to grant user access to data containing analysis data or for authorization / encryption of data).

[0106] The processor (335) may include circuits such as logic circuits, memory, battery and power circuits, and other circuit drivers for peripheral components and audio components. The processor (335) and any of its sub-processors may include logic circuits for receiving, processing, and / or storing data received and / or input to the display device (310), and data transmitted or conveyed by the display device (310). The processor (335) may be coupled to the display (345) as well as to the connection interface (315) and the storage device (325) (including the application (330)) by a bus. Thus, the processor (335) may perform various functions by receiving and processing electrical signals generated by each of these elements. For example, the processor (335) may access stored content from the storage device (325) at the direction of the application (330) and process the stored content for display and / or output by the display (345). Additionally, the processor (335) can process stored content to be transmitted to another display device (310), an analysis sensor system (308), or a server system (334) via the connection interface (315) and the communication medium (305). The display device (310) may include other peripheral components not shown in detail in FIG. 3b.

[0107] In another embodiment, the processor (335) may also acquire, detect, calculate, and / or store data input by a user via the display (345) or GUI (340) or data received from the analyte sensor system (308) (e.g., analyte sensor data or related messaging) for a certain period of time. The processor (335) may use this input to measure the user's physical and / or mental response to the data and / or other factors (e.g., time, location, etc.). In various embodiments, the user's response or other factors may indicate a preference regarding the use of a specific display device (310) under specific conditions and / or the use of a specific connection / transmission method under various conditions, which will be described in more detail in the specification.

[0108] On this occasion, it should be noted that identical-name elements between the display device (310) and the analyte sensor system (308) may include similar features, structures, and / or functions. Accordingly, with respect to these elements, the description of the display device (310) above may be applied to the analyte sensor system (308) in some cases.

[0109] CGM-based bolus calculation

[0110] As noted above, it is generally important to obtain HCP inputs for parameters used in related (and sometimes connected) devices, such as bolus calculators as well as drug delivery devices. Generally, when an HCP communicates with a patient via a wired or wireless network, specific safety and security features must be provided to ensure that the prescription is delivered to the correct patient and that the prescription of any given patient remains confidential.

[0111] Desirable and / or useful features for the system in which the HCP is involved in the bolus calculator setup include an encrypted system, such as an encrypted email system that allows back-and-forth communication between the HCP and the patient for the communication of bolus calculator parameters containing data files containing the encrypted system. It is also important to allow and enable integration into electronic medical records (EMR). Furthermore, it is important to enable multi-point verification so that the HCP can work with accurate patient files.

[0112] Generally, patient reports, such as a PDF of a 14-day report, can be uploaded directly to the EMR and configured to be printable for review by the HCP. By utilizing signal communication enabled as described in more detail below, the HCP can determine whether the patient maintains a high state or experiences a hypoglycemic event. The patient can choose whether to take medication. The home screen of the patient device displays trends, blood glucose values, whether the patient is within a range, high and low threshold events (usually set by the HCP) with date / time stamps, such as meals, exercise, sleep, statistics, comparisons between one day and another, etc. Based on what is visible on their home screen, the patient can use the system to easily identify "cause-and-effect" relationships on their own, thereby enabling the patient to determine for themselves how their blood glucose is being affected.

[0113] The reports provided to the HCP may include average blood glucose, average Alc, frequency of hypoglycemic events, ratios of time within and out of range (including whether time outside the range is higher or lower than the target range), results overlaid on top of each other to illustrate trends, and indications such as posts related to nutrition, stress, activity, exercise, sleep, disease, and infection. Electronic reports containing various levels of detail regarding the aforementioned aspects can be exported to the HCP’s patient EMR, for example, in PDF format. Since these reports are generally available to the HCP immediately after reviewing the same content with the patient, information may be grouped within the report to be highlighted. For example, the most critical information for making decisions about the patient may be placed in or highlighted within the report for immediate availability.

[0114] Returning to the secure communication of BC / drug delivery parameters, it is important not only to facilitate the communication of initial parameters but also to facilitate the updating of the bolus calculator and drug delivery parameters, which are determined by the system and transmitted to the patient's bolus calculator, and which correspond to the patient's dose-response metrics evaluated after the initial setup and / or previous updates. In many embodiments, systems and methods according to the present principle utilize specific inputs, such as CGM data, which were not available in previous bolus calculator and pump setup routines. Specific third-party data may also be used for the bolus calculator setup. Finally, where available, insulin data may also be used depending on the implementation.

[0115] A system and method according to the present principle provides software, hardware, algorithms, and workflow processes for HCP to safely and efficiently set up a personalized bolus calculator, particularly a CGM system. The disclosed system and method provides an intelligent and efficient method for the initial setup of bolus calculator parameters for a bolus calculator tool by HCP, including, for example, setting up the total number of carbohydrates for basic meals such as small / medium / large breakfast, lunch, or dinner. The disclosed system and method also provides a method for HCP to initially set parameters such as the insulin-to-carbohydrate ratio (ICR), glucose target and threshold, and insulin action time, so as to safely enable the operation of the bolus calculator by the patient / user. The bolus calculator app (or CGM app with a bolus calculator tool) provides a warning in the bolus calculator menu prior to the initial setup to inform the user of the risks and risk factors associated with setting up the bolus calculator without the assistance of HCP, for example, without implementing the HCP setup method. The disclosed system and method also provide a bolus calculator tool that can be implemented through software such as a feature of a dedicated continuous glucose monitoring application, but can also operate as a standalone application integrated with a dedicated CGM application. In one exemplary embodiment, it was found useful to operate the bolus calculator as a function provided as part of a CGM app. The bolus calculator tool is generally known by CGM trend parameters to calculate and determine insulin bolus.

[0116] In this regard, it should be noted that it is generally safer for patients to make decisions regarding CGM use with the help of a bolus calculator that considers trend information, such as that available through CGM. Currently, however, the challenge is to make safe bolus calculators available to patients, as they are generally limited to pump users and do not include trend adjustments. Since it takes only a few minutes for a physician to access a website and handle the unlock mechanism while making an appointment, they may choose not to use a patient's bolus calculator at all if the setup process is too difficult. Currently, instead of a safe but difficult-to-access, properly configured bolus calculator, there are many unapproved, FDA-unapproved bolus calculator apps available for patients to choose from that are immature, prone to errors due to a lack of software validation.

[0117] As described further below, a specific embodiment of the system and method according to the present principle also enables secure handling of configuration / parameter / setting files for a bolus calculator. Additionally, a specific embodiment provides a method for integrating a bolus calculator app or function with a third-party application so that the bolus calculator function becomes more known by data received by the third-party application.

[0118] In the following description regarding the HCP setup of the bolus calculator / drug delivery parameters, it should be noted that the HCP may attempt to manually input parameters into the user's device, e.g., a smartphone. However, such non-automatic data entry raises concerns, including the HCP's responsibility, the extremely limited time the HCP typically spends with the patient, and the lack of data measured by CGM during the short time the HCP spends with the patient; this last aspect results in the HCP generally lacking information based on the proposed set of parameters. Since these various technical barriers prevent manual HCP input, they highlight the importance of automated methods to transmit HCP knowledge to the user's bolus calculator and / or drug delivery system, and such automated methods give rise to other requirements, including security and privacy. These other requirements give rise to new potential efficiencies in the system, including the use of a cloud server communicating with the HCP portal and a cloud server communicating with the app on the patient's device.

[0119] FIG. 4 schematically illustrates a system (400) for achieving the present principle in one embodiment. A mobile device (402) is illustrated, and in many cases, the mobile device is a user / patient's smartphone, but it may also be a dedicated device. The mobile device (402) includes a processor (404) for providing a computational and analytical mode. A CGM application (406) is generally located within the mobile device (402) and is downloadable from a server, such as an Android or Apple App Store, and the CGM application (406) is generally instantiated by commands residing on non-transient media within the mobile device (402). For example, flash memory or other storage device (416) may be used, and the CGM app is loaded into RAM memory upon execution. A drug delivery app (410) is also illustrated and may include (or be implemented by) a bolus calculator (412). The drug delivery app uses data from the CGM app (406) and other data (described below) to provide a bolus calculator function, as well as, in some embodiments, a signal to drive a pump or other drug delivery device (428). The signal may be provided via an API (414) and may be transmitted to a pump, or other drug delivery device including an MDI device, such as an insulin pen.

[0120] The CGM app may be part of the drug delivery app or vice versa, or it may be separate but communicated via an appropriate API.

[0121] Data may be received from one or more third-party apps (418) (such as being measured by a sensor and stored and / or processed by a third-party app), and the data is loaded into memory for processing by a processor (404) as part of a bolus calculator or drug delivery calculation. These third-party apps may include apps that track nutrition, fitness, activity, sleep, meals, heart rate, stress, etc. Thus, these apps may receive data from sensors including a heart rate sensor, a skin conductivity sensor, a user input device including a camera and a keyboard / touch screen, an accelerometer, a GPS, a location information device and a location tracking sensor including an app.

[0122] In addition to through a third-party app, data may be received from a mobile device (402) via a data port (420), and the data port (420) may serve as an input port for data (or non-sensor data) from a sensor (426). The data port (420) includes one or more ports for receiving signals via Bluetooth®, Near Field Communication (NFC), USB, and a dedicated interface.

[0123] The mobile device (402) may include a display (408) that can serve as a user interface implemented by a touch screen. Data may be received from the mobile device (402) via the cellular data port (422) and / or Wi-Fi data port (424) as well as via the port (420) described below.

[0124] A mobile device (402) communicates with an HCP server (430), which may be a cloud-based server that the HCP accesses, for example, via an HCP user account session. The HCP server (430) generally includes a patient database (432) and an HCP portal (436). The HCP portal (436) can access the patient database (432) and can more securely receive a list of patients through a filter (434) based on HCP identification. Other aspects of HCP identification and filtering are described later. One or more HCP client devices can access the HCP server (430) through the HCP portal (436). Two HCP client devices: an HCP client device (438), such as a PC, tablet, or phablet, and an HCP mobile device (440) are illustrated in FIG. 4.

[0125] In one system and method according to the present principle, an application may be configured to run on a user mobile device. The application may include a first input configured to receive signal data from a continuous indwelling analyte sensor and a transmitter. A second input configured to receive signal data corresponding to target patient data and / or patient population data may also be used. The application may also include a command configured to use the first and second inputs to calculate a bolus value, wherein the second input is used to provide settings and / or parameters for a bolus calculator, and the first input is used to provide a current patient analyte concentration value to be applied to a function at least partially determined by the settings and / or parameters to calculate the bolus value.

[0126] Third-party apps may have their own inputs, and the application may receive signal data from a continuous indwelling analyte sensor and further include commands to calculate and display clinical values ​​of analyte concentrations, for example, through various calibration routines. The commands may also be configured to transmit the calculated bolus values ​​to a drug delivery device.

[0127] A system and method according to the present principle also consider an application configured to run on a server. This server application may include a first command configured to receive data regarding a target user and to set up a target user account. The first input may be configured to receive sensor data from a device associated with the target user. A second command may be used to determine whether the bolus calculator parameters and / or settings on the target user device are optimal by analyzing data from the first input and, for example, determining whether a bolus calculator measurement / setting change triggering event has occurred. If the settings are not optimal, one or more commands, for example, a third command, may be configured to transmit a signal to a healthcare worker portal associated with the server or to the target user device to cause a modification of the parameters and / or settings.

[0128] FIG. 5 illustrates a flowchart (500) of a first embodiment of a system and method that involves at least partially the HCP in the setup of a user’s bolus calculator. A particular advantage of the method of FIG. 5 is that the HCP does not need to have any knowledge of the specifics of the specific user device.

[0129] In the first step, the ballers calculator is initially locked by the application (step 502). Patients can invite HCP to their account (step 504). Such invitations can be sent via the cloud server noted above. HCP creates an account on the cloud server, for example, if a web account has not yet been created, and that account is linked to the patient (step 506). Generally, HCP only needs to create one web account, which can be linked to multiple patients.

[0130] This step provides strict enforcement that the HCP must be involved in the setup. While this is a particularly safe implementation, it places a greater burden on the HCP and may be unsatisfactory to users who are already trained in bolus calculator setup.

[0131] When both the patient and the HCP are connected via the cloud server, the HCP can fill out a form for the patient, and the form includes settings / parameters for the bolus calculator (step 508). Once the form is completed, the bolus calculator app receives a file from the cloud server containing appropriate parameters generated from the form (step 510). Alternatively, the HCP can email the form to the patient (step 514). For example, parameters can be stored in the form, and the data file may contain form information protected by a passcode. Once the passcode is entered, the patient can access the parameters, open the bolus calculator app, and manually set up the bolus calculator app with the data from the form (step 516). Alternatively, the app can read the file and automatically complete the bolus calculator setup (step 512). In the latter case, the bolus calculator app is unlocked upon receiving parameters from the HCP, making setup easier and eliminating transcription errors. However, patients may forget about potential training on manual setup and, in some cases, may pose a higher cybersecurity risk.

[0132] In a different embodiment, the app may not be locked, but the bolus calculator may provide the patient with an initial warning message regarding the risks of the bolus calculator set up without HCP involvement (step 518). In this method, the patient may email the setup form to the HCP, and in some cases, it may be sent from the app itself (step 520). Then, the HCP fills out the setup form for the patient (step 522), and the HCP sends the form back to the patient (step 524). As before, the patient manually sets up the bolus calculator using the data from the form (step 516). Variations from other embodiments, including the setup parameters being automatically entered into the bolus calculator app (or a suitably configured function within the CGM app), may also be seen in this specification.

[0133] Variations will be understood, and variations may provide simpler or more complex setup options.

[0134] For example, referring to FIGS. 6a through 6c, for a particularly simple setup method without an unlock step, the user can open the bolus calculator menu on their app. The bolus calculator menu may inform the user that it is not safe to set up the bolus calculator without the assistance of the HCP. The user may then click on "Understand" and be granted access to the app. The system may display a screen showing the location of the clinician's website, which further includes a setup worksheet and user instructions. The user may be advised to print the worksheet for their next visit to the HCP. The user may also be provided with an available button that reads "Ready to set up bolus calculator." Similarly, the HCP may provide a website describing the bolus calculator, which includes setup information such as a setup worksheet and setup instructions. Returning to the app, the user can click "Ready to set up bolus calculator." The user may see an additional confirmation screen asking whether they have worked with HCP to obtain setup parameters. If they click "I understand," the user can enter the setup wizard for the bolus calculator and transfer settings from the worksheet.

[0135] As another example regarding a simple unlock method, one might open the Bolus Calculator menu within the app and see a message stating that it is unsafe to set up and use the Bolus Calculator without the assistance of an HCP. However, a field may be provided where the HCP can enter an unlock code. On the website, the HCP knows that a patient is setting up the Bolus Calculator and can enter the desired data to set up a new patient. The HCP can enter their name and National Provided Identifier (NPI) number. The server can verify that the NPI number has the correct number of digits (e.g., 10) and is complete (other verifications may be performed). The HCP may need to click on a legal statement of authentication, such as "I certify that I am a healthcare professional authorized to provide healthcare services to patients." Upon presenting the authentication, the HCP may be redirected to a page where worksheets and user commands are set up, and may be instructed to print the set-up worksheet. The HCP can click a button to obtain a unique one-time unlock code for the patient, and there may be a location on the set-up worksheet to enter the code.

[0136] In the app, the user or HCP enters a one-time unlock code and waits for server verification of its validity. If the code is determined to be valid, the user / HCP can enter the setup wizard of the ballous calculator and transcribe the settings from the worksheet provided by the HCP.

[0137] In the above system and method, novice users are prevented from unsafely setting up bolus calculator parameters without assistance from HCP. If the user actively proceeds with the setup, they are well aware of and decide to use the CGM bolus calculator unsafely. Since individual CGM users still have to manually enter their setup parameters, they could not be deceived by someone pretending to be a doctor; they would have to pretend to be a doctor themselves.

[0138] We will now describe several more detailed methods for providing HCP setup.

[0139] Referring to FIGS. 7a through 7e, the HCP setup of the bolus calculator is described, and the bolus calculator is provided as part of the CGM app. In this embodiment, the HCP requests access to the patient's account, and the HCP obtains a user ID from the patient. A form containing setup parameters is completed online and transmitted digitally to the patient. In summary, the HCP sets up an account for the bolus calculator, and such access and setup typically require authentication, such as an NPI code and / or secondary verification. The HCP requests access to the user account. When the patient accepts the HCP permission request, the HCP sets up the appropriate parameters. The HCP verifies the parameters and patient information and transmits the file containing the parameters to the CGM app. The patient and the CGM app receive the update, and the parameters are accepted in the GCM app.

[0140] More specifically, the physician may initiate the process from the sign-up screen (step 701). If the user is not an HCP, they generally cannot perform this step, so a message indicating that they cannot continue may be displayed (step 702). In response to the sign-up inquiry (step 703), if the HCP indicates that they have not yet signed up, they may be prompted to enter an NPI code (step 704) and receive various types of additional verification (step 705). If they are found to be an HCP (step 706), they may proceed to create a username (step 707) and password (step 708). Otherwise, a message indicating that they cannot continue may be displayed (step 702).

[0141] If the HCP continues, they may be prompted to enter their email (step 709) and start setting up the bolus calculator for the new patient (step 710). If the HCP has already signed up, they may simply enter their login credentials (step 711).

[0142] A system and method according to the present principle may prompt the HCP to indicate whether the HCP is setting up a bolus calculator for a new patient (step 710). If so, the HCP may move to the "Add New Patient" point. Otherwise, the system may display an already added patient (step 712), and the HCP may be prompted to see the settings for an already added patient, for example, a patient for whom a bolus calculator can already be enabled (step 713). In this case, the HCP may select the patient (step 714).

[0143] The patient may prompt the HCP or the system may simply indicate whether the bolus calculator is operational or set up (step 715). If so, the patient's bolus calculator settings may be displayed (step 716), and if necessary, missing settings may be highlighted. The HCP may choose to edit the settings (step 717), and if desired, parameters may be edited. Editing may occur within "guard rails" (step 718). For example, limits or ranges that the HCP can input as parameters may be set. These "guard rails" may be determined based on the patient's weight, medical history, age, BMI, etc.

[0144] These parameters may be verified by the HCP before being transmitted to the patient (step 719). If the HCP does not verify the edited parameters, the HCP may re-edit them (step 718). If the HCP verifies the parameters, the HCP may be notified that the updated settings will be transmitted to the patient (step 720). In this case, the patient bolus calculator settings may be displayed with a "WAITING FOR PATIENT" indication for the system to accept the change (step 721).

[0145] After that, the patient may choose whether to accept the change (step 722). If so, the edited bolus calculator settings may be displayed on the HCP (step 716). If the patient does not accept the change, the patient may be asked if they want the proposed change to the edited parameters (step 723). If the patient does not resend the proposed change, the HCP may be notified that the patient rejected the change and did not resend the proposed change (step 724). Again, with the display of the patient bolus calculator settings (no change), the process may resume at step (716).

[0146] However, if the patient resends the proposed change, the HCP may be notified that the patient has rejected the change and resent the proposed change (step 726). The HCP may be urged to approve the proposed change (step 727). If the HCP does not accept the proposed change, the HCP may be provided with a screen for editing parameters, for example, within a guardrail (step 718). However, if the HCP approves the proposed change, the HCP may be provided with a notification screen stating that the approved settings will be updated on the patient's bolus calculator (step 728). The patient may be notified that the proposed change has been accepted and the bolus calculator has been updated (step 729).

[0147] Returning to step (710), when the HCP sets up a bolus calculator for a new patient, the HCP may be provided with a screen prompting whether a patient ID is required (step 730). The HCP may be prompted whether it has a patient ID (step 731). Otherwise, the HCP may request the ID from the patient, for example, via email, text, a CGM app, or other messaging service (step 732). Once the patient ID is obtained, the HCP may enter the patient ID (step 733). Various information to accurately identify the patient, including the patient's name and date of birth, may be used and displayed so that the HCP can verify the patient's identity (step 734), so that the setup can be confirmed to be for the correct patient.

[0148] After that, HCP may be prompted to determine whether the correct patient is displayed and identified (step 735). Using the displayed information, if HCP determines that the correct patient has not been identified, the process may be restarted at step (730). However, if the correct patient is identified, HCP may add the patient (step 736).

[0149] The HCP may be prompted to determine whether the patient is a pump user (step 737). If so, specific bolus calculator parameters may be pre-filled based on the pump bolus calculator settings (step 738). Again, missing settings may be highlighted for HCP input, in which case the HCP may provide the missing settings or edit the pre-filled settings (step 739). In this case, the HCP may be asked to confirm the transmission of the settings to the patient (step 740). If the HCP confirms that the settings can be transmitted, the flow may proceed from step (720). If the HCP does not confirm that the settings can be transmitted to the patient, the system may display pre-filled settings that can be edited (step 741). The HCP may be prompted to edit the pre-filled settings (step 742), and if they choose to do so, parameters may be edited, for example, within a guardrail (step 718), and the flow may proceed from step (718). If HCP decides not to edit the default settings in step (742), the flow can proceed in step (740).

[0150] Returning to step (737), if the patient is not a pump user, the HCP may be prompted to enable / set up the patient's bolus calculator (step 743). If they do not want to do so at this point, the flow may be passed to the patient's display that has already been added (step 712). If, in step (743), the HCP wants to enable / set up the patient's bolus calculator, the flow may be passed to the display of pre-filled settings that can be edited (step 741).

[0151] In all these cases, values ​​can be pre-filled to reduce the burden of data entry and to pre-select the rationale, and both the rationale and the settings can be transmitted to the user. The rationale can be used to advise the user on why a specific setting was selected.

[0152] In the embodiment described above, the HCP can enable defining a safety range for parameter values ​​for individual patients rather than a safety range inherent to the device, and these values ​​provide a better bolus calculator setting than the device-based setting. Individual patient parameters can be set, and the patient can also be trained to have the ability to modify these values ​​later.

[0153] Specific advantages of the methods in Figures 7a through 7e include reducing or eliminating transcription errors by simply entering HCP values. Additionally, HCP is generally always associated with the setup. A disadvantage is that the patient is not always involved with the bolus parameters during the HCP conversation. Furthermore, while bolus values ​​can be used in the cloud, various safety and security measures may be taken. Additionally, although there is a possibility that HCP may select an incorrect patient, this risk can be mitigated through patient verification over the phone as well as the use of identification data such as name and date of birth.

[0154] For specific uses, specific bolus calculator parameters / values ​​or ranges of such values ​​may be pre-approved for direct import. In relevant implementations, values ​​authorized for use with the bolus calculator may be entered, while unauthorized values ​​are rejected. If the user has a pump already set up, the pump's bolus calculator values ​​may be entered. For example, when the HCP sets up the appropriate parameters, values ​​may be automatically entered into the HCP server. Missing fields may be highlighted so that the HCP can enter them manually. The HCP or the user may optionally adjust trend-related parameters independently. For example, the calculated trend does not necessarily need to be linked to the pump's bolus calculator, but may be linked to the trend measured and determined by the CGM app.

[0155] In another embodiment, as illustrated in FIGS. 7f through 7h, the ballers calculator parameters can be automatically set up by the HCP. Specifically, in the first step, the HCP can access the web application home page (step 745). The HCP can activate or press an appropriate button for HCP setup (step 746). The HCP may be prompted to determine whether they are actually the HCP (step 747). An appropriate authentication procedure, such as in FIGS. 7a through 7e, may be performed. If the HCP cannot be properly authenticated, control may be returned to the web application's homepage (step 745). Assuming the HCP is properly authenticated in step (747), a legal statement may be displayed (step 748), and the HCP may be prompted to determine whether they agree to the app's actions, e.g., ballers calculator setup (step 749). If they do not agree, control may be returned to step (745). If the HCP agrees, they may be prompted to enter their name (step 751) and NPI number (step 752). The system may check whether the NPI is valid (step 753). If the NPI is valid, control may be transferred from the patient to the step of entering the code (step 754). If the NPI is invalid, an error message may be displayed (step 755), and control may be transferred back to entering the name (step 751).

[0156] The code from the patient may be as described below, for example, a one-time code valid for a limited period that allows the HCP to access the patient file and provide bolus calculator adjustments. Since the patient code may be entered first, the HCP does not enter the bolus calculator settings unless there is anything associated with the patient. The validity of the code may be checked (step 756). If the code is invalid, an error message may be displayed (step 757), and the HCP may be prompted to re-enter the code (step 754). However, if the code is valid, the patient's name may be displayed, the name belongs to the code, and the code is keyed off (step 757).

[0157] The HCP may be prompted to determine whether the correct patient file is in progress (step 758). If not, control may be passed to step (754). If the correct patient file is in progress, the HCP may be prompted to enter the patient settings (step 756). Details regarding the entry of specific patient settings can be seen in other flowcharts, including FIGS. 7a through 7e. The HCP may be prompted to verify the settings (step 757) and to determine whether the settings are ready to be sent to the patient (step 758). If the settings are not ready to be sent to the patient, the flow may proceed back to step (756) and the patient settings may be re-entered. When the settings are ready to be sent to the patient, the HCP may be prompted to determine whether they wish to save or print the settings file, for example, as a PDF (step 759). If they choose to save the settings file, the settings file may be saved (step 760). If they choose to print the setup file, the settings file may be printed (step 761). If neither of the two is selected, HCP may be prompted to confirm that the file will not be saved or printed (step 762). If HCP does not confirm so, the flow can proceed back to step (759). If HCP confirms, the flow can return to the display of the HCP web application home page (step 763).

[0158] FIGS. 7i through 7l illustrate different flowcharts that can be used to enable the HCP to participate in the bolus calculator setup. In the first step, the HCP accesses an application, such as a web application or the home page of a website (step 764). While the nature of the web application may vary, the basic requirement is that the HCP and the user must be able to access it, for example, to obtain parameters to manually input into the bolus calculator or to download parameters directly into the bolus calculator. In the case of the HCP, the HCP can press, select, or activate a button representing the HCP bolus calculator setup (step 765). The system may ask if the user is the HCP (step 766). Otherwise, the HCP can return to the homepage (step 764).

[0159] If the user indicates that they are an HCP, the flow may be passed to, for example, an optional display of a legal statement (step 767). The legal statement may indicate various conditions and disclaimers regarding the use of the website when entering bolus calculator parameters. The HCP may be prompted to indicate whether they agree (step 768). If the HCP does not agree, the flow may be passed back to the home page (step 764). However, if the HCP indicates agreement, the HCP may be prompted to enter their name (step 769) as well as other information, for example, an NPI number (step 771) (step 769). The system and method may verify whether the entered NPI number is a valid NPI number (step 772). If the number is not a valid NPI number, an error message may be displayed (step 770), and the flow may be passed back to the information input screen(s) of step (769 and / or 771).

[0160] Once a valid NPI number is entered, the flow can be passed to initiate a series of prompts for patient information. For example, if the patient has provided access to the EMR using a code, the HCP may be prompted to enter the code from the patient (step 773). If the code is entered from the patient, any settings entered by the HCP will be automatically assigned to the correct patient, acting as a security measure. Additionally, if the code is entered from the patient, specific patient parameters may be pre-filled (if known), which can limit the data entry burden on the HCP.

[0161] The code entered by the HCP can be verified for validity. If the code is invalid, an error message may be displayed (step 774). The flow may be returned to the "enter code" screen (step 773) for the HCP to re-enter a different code. If it is determined that the code is valid, the patient's name may be displayed (step 776). A feedback step may be implemented, where the HCP is prompted to determine whether the correct patient file is being worked on (step 777). This provides confirmation that the HCP will set up parameters for the correct patient. If patient information corresponding to a patient for whom the HCP does not intend to enter settings is displayed, the flow may be returned to the "enter code" screen for the HCP to re-enter a new code (step 773). However, if the correct patient appears in step (777), the HCP can enter the patient settings (step 778). Details of the patient setting input are described in the flowchart above. The HCP may be prompted to verify the entered settings (step 779).

[0162] After that, the HCP may be prompted to determine whether the settings are ready to be transmitted to the patient (step 780). Otherwise, the flow may be returned to the input of the patient settings screen (step 778). If the HCP indicates that the settings are ready to be transmitted to the patient (as part of step (780)), the patient settings may optionally be displayed in a form (step 781). In any case, the patient settings may be transmitted to the patient.

[0163] Afterward, the HCP may be prompted to perform various actions, including saving the settings to a file, printing the settings to, for example, a PDF, or closing the web application (step 783). In one case, the HCP chooses to save the settings as a file (step 784). In another case, the HCP may choose to print the file (step 785). Note that these steps may be performed immediately from step (782), that is, the step following the HCP notification. In some cases, such options may be provided to the HCP before or instead of the HCP notification, or before or instead of displaying the patient settings in a form (step 781).

[0164] If HCP selects to exit, the system may ask HCP whether he has already saved or printed the settings (step 786), and if not, HCP may be asked to confirm that he does not want to save or print (step 787). If he does not want to save or print, or if HCP has already saved or printed the settings, the flow may be passed to the display of the HCP web application homepage (step 788). If HCP does not confirm that he does not want to save / print, the flow may be passed back to the notification step (step 782).

[0165] In another embodiment, as illustrated by the flowchart (775) in FIGS. 7m to FIGS. 7u, a process is illustrated with additional details regarding the setup of patient parameters for a bolus calculator.

[0166] In the first part, the "all day setting" is set up.

[0167] Step 1 is for the HCP to enter the patient code (Step 790). The method by which the HCP receives the code may be as described in the previous flowchart. An all-day setup may be displayed (Step 791). The HCP may be prompted to enter the method best suited for tracking a specific patient's meals, for example, by exchange, carbohydrates, etc. (Step 792). In one case, the HCP selects by exchange (Step 793). In another case, the HCP selects by carbohydrates (Step 794).

[0168] The HCP may be prompted to set a meal size carbohydrate / exchange preset (step 795). If so, the HCP may be prompted to select the number of carbohydrate / exchanges for the small meal size preset (step 796), the number of carbohydrate / exchanges for the medium meal size preset (step 797), and the number of carbohydrate / exchanges for the large meal size preset (step 798). The HCP may also select the active insulin time (step 799) and select the maximum bolus size (step 801).

[0169] Subsequently, the HCP can select whether the bolus calculation should be adjusted for the determined glucose trend (step 802). This parameter is typically specific to continuous glucose monitoring and can determine the direction and magnitude of the trend arrow. If the HCP indicates that trend arrow adjustment is not necessary, trend arrow adjustment cannot be performed (step 803). If a trend arrow is used, the system can enable trend adjustment (step 804). Subsequently, the HCP may be prompted to confirm their selection (step 805).

[0170] Various time settings may appear by the doctor and are indicated here as the first option and the second option.

[0171] In the first option, the time setting period is prompted (step 806). For example, the HCP may indicate a night time period from 11 PM to 7 AM. The HCP may enter the carbohydrate ratio (step 807), correction factor (step 808), target range (step 811), etc. The HCP may be prompted to confirm the settings (step 812). Afterward, the HCP may be prompted to create settings for another time period (step 813). If they do not select one, the flow may proceed to the step of sending the settings to the patient for review (step 833). If the HCP chooses to create settings for another time period, a new start time may be selected (step 814), and default settings from the previous period may be displayed (step 819). The default settings may be adjusted, but otherwise, they are used as default values ​​(step 820). If adjustments are made by HCP (step 821), adjustments may be made to the carbohydrate ratio (step 822), correction factor (step 823), or target range (step 831). As before, HCP may be prompted to check the settings (step 830).

[0172] The HCP may be given the option to create settings for a different time period (step 832). If they choose, the flow may be passed to step (814). If they do not choose, the settings may be sent to the patient (step 833). The step of sending the settings to the patient and requesting a patient response may be as described above.

[0173] In the second option, the initial display may be a display of a specific time period, for example, a "morning" setting (step 809). To this end, the HCP may set the parameters described above, including a carbohydrate ratio (step 810), a correction factor (step 815), and a target range (step 816). The HCP may be prompted to confirm these "morning" settings (step 817).

[0174] Similarly, other time period settings may appear as a display of a specific time period, e.g., a "noon" setting. The setting may default to the "morning" setting but may be conveniently adjusted. Thus, HCP may be prompted to decide whether they wish to adjust the setting from the default value (step 824). If they do not choose, the noon setting may be confirmed (step 826). However, if HCP chooses to adjust from the default as part of step (824), any default setting may be adjusted, including adjustment of the carbohydrate ratio (step 827), adjustment of the correction factor (step 828), and / or adjustment of the target range (step 829) (step 825).

[0175] Following the confirmation step (826), a display of the "dinner" setting may be provided (step 834). Again, the default may be the previously entered noon setting. The HCP may be prompted to decide whether they wish to adjust the setting from the default values ​​(step 835). If they do not choose, the dinner setting may be confirmed (step 839). However, if the HCP chooses to adjust from the default values ​​as part of step (835), any default setting may be adjusted, including adjustment of the carbohydrate ratio (step 837), adjustment of the correction factor (step 838), and / or adjustment of the target range (step 840) (step 836).

[0176] Following the confirmation step (839), a display of the "night" setting may be provided (step 841). Again, the default may be the previously entered evening setting. The HCP may be prompted to decide whether they wish to adjust the setting from the default values ​​(step 842). If they do not choose, the night setting may be confirmed (step 846). However, if the HCP chooses to adjust from the default as part of step (842), any default setting may be adjusted, including adjustment of the carbohydrate ratio (step 843), adjustment of the correction factor (step 845), and / or adjustment of the target range (step 847) (step 844).

[0177] After that, confirmed settings for various time periods can be transmitted to the patient (step 848). The patient receives the settings and can automatically download the settings to the bolus calculator, manually enter the displayed settings, request a patient response, or perform other patient interactions.

[0178] Specific variations of HCP setup - Initial setup and / or updates

[0179] Variations of the above HCP setup system and method according to the present principle will also be understood. Such variations include preparation for updating the HCP of already set parameters.

[0180] FIG. 8 is a flowchart (800) illustrating a method for updating bolus calculator parameters. In one embodiment, the patient can enable modification of the bolus calculator by generating a one-time upload code and transmitting the code to the HCP.

[0181] More specifically, the necessity or requirement for modifying the bolus calculator can be determined (step 851) and the patient can be notified as such (step 853). For example, pattern recognition or other techniques may be used to determine whether the patient deviates from the target range by an undesirable amount of time, e.g., an undesirable time ratio, even with the current set of bolus calculator parameters. In a specific embodiment, if the patient deviates from the target range by a ratio (or other measure) greater than a predetermined threshold reference amount, the patient may be notified that a change in the bolus calculator parameters is warranted or desirable. Notification may be made by an HCP action or may occur automatically, such as through previously notified pattern determination, recognition of atypical signal responses, and behavior. Subsequently, the patient may generate a one-time code (in the same manner as described above) and transmit it to the HCP (step 855). In particular, notifying the patient may provide a link to a URL / URI where the patient can generate the code. Alternatively, the patient may generate it by accessing a desktop application or a smartphone app (which may also be used to receive the notification). The code may be in various forms, including QR codes, barcodes, etc. In one embodiment, the code is simply a generated alphanumeric string that is entered by the HCP on the HCP portal to allow access to and modification of the user's bolus calculator parameters. The code may be of various types, but generally a one-time code is used, so that the code is entered once to allow the HCP to modify the bolus calculator parameters and the code no longer operates after a specified time interval; if additional modification of the bolus calculator parameters is required, a new one-time code must be generated. Each one-time code may operate to allow modification for a specified time interval, e.g., 10 minutes, 30 minutes, 1 hour, etc.That is, HCP may be provided with a time-limited window for updating or pushing changes to such ballous calculator settings.

[0182] The HCP may enter a one-time code into the system, and temporary access to the user's current bolus calculator settings may be granted by configuring / modifying a set of bolus calculator parameter settings transmitted to the bolus calculator, for example, in real-time or for installation (step 857). Exemplary values ​​that may be modified include, for example, the insulin-to-carbohydrate ratio, the duration of insulin action, and the patient's correction factor. While such codes may be used with the HCP account, using these codes may also prevent the HCP from setting up and accessing the account. Code generation and subsequent parameter modification may be performed during a telephone consultation, and such consultation may generate an event eligible for insurance claim (step 859).

[0183] Benefits of some embodiments include the elimination of the need for password and database access setup for each HCP. Updates can be pushed immediately, and the HCP can view the current real-time app settings and potentially discuss them with the patient. Two-way security is provided, and it is HIPAA compliant. Additionally, a simple report, identical to the evidence of contact, can be generated for billing purposes.

[0184] In many of the embodiments described above, the HCP can initiate the setup, set up the patient account online, and configure thresholds and other custom settings. The HCP can then send an invitation to the patient, thereby eliminating the need for the patient to enter settings and access physician recommendations. In specific variations of these implementations, once the patient accepts the invitation and starts a sensor session, the HCP can receive electronic information, such as data from the patient. Additionally, in some embodiments, the patient can grant the HCP permission to view patient data automatically or after clicking a button in the app. In this way, the HCP can automatically access such data, and the patient is no longer burdened with sending an invitation to the HCP. This data may be transmitted to an EMR or other electronic records or databases.

[0185] Specific functions that the HCP can set up are described below. In one embodiment, the CGM app is set up as a bolus calculator tool for an MDI user using a CGM-only system configuration. However, some or all features may be adopted for non-MDI CGM systems, e.g., for a user with a CGM and an insulin pump.

[0186] In one embodiment, a bolus calculator tool uses user input of insulin dosage to determine various factors useful for calculating bolus, such as IOB. Such user input is typically required in such systems, for example, for MDI users, because, unlike in the case of a connected pump, the ability to automatically input such parameters is generally limited. However, in some cases, data is available from the insulin pen via Bluetooth (or other communication protocols and technologies), so separate user input is not required.

[0187] In this embodiment (and other cases), the insulin dosage recommendation of the bolus calculator may be accepted or modified, and data regarding such recommendation, whether accepted or rejected or rejected, and subsequent glucose response data may be used to inform future IOB decisions.

[0188] To input such data, the user can input it by using the event input feature of the CGM app, such as logging insulin boluses as "events." In some implementations, during initial setup, the user may be warned that the bolus calculator relies on insulin bolus inputs for accurate estimation of IOBs, and that failing to input this information or entering inaccurate information poses a risk of dangerous insulin recommended doses.

[0189] For non-MDI users, for example, users of interactive CGM-insulin delivery system configurations or arrangements, the CGM app bolus calculator may provide different recommended amounts than the insulin pump's bolus calculator. These differences may arise from differences in settings, differences in IOB calculations, the use (or non-use) of glucose trend information, and other related factors. And, as with MDI users, CGM app users may be provided with a warning message during the initial setup of the bolus calculator tool to inform the user of these potential differences between the bolus calculator tool and the bolus calculator associated with the insulin delivery device.

[0190] For example, in a connected pump system configuration where the insulin app provides its own bolus calculator, the CGM app bolus calculator may be disabled or unavailable to avoid user confusion, particularly if the bolus calculator associated with the insulin delivery device is "trusted" and authenticated. In this case, if the user enables the bolus calculator option in the CGM app, the user may be provided with the bolus calculator in the insulin app associated with the insulin delivery device. Generally, such communication between apps via a properly configured API typically invokes security considerations to ensure that data received by the apps is accurate, reliable, and associated with the correct patient.

[0191] Various parameters that can be set up are described below. In one embodiment, the HCP can set up a preset meal bolus. In one embodiment, the preset meal bolus provides "fuzzy" meal input to the bolus calculator. The CGM app can provide a preset meal bolus based on multiple factors, including the user's typical intake values ​​for breakfast, lunch, dinner, and / or snacks. This may be particularly useful for users who do not want a high carbohydrate content but consistently eat similar amounts of food every day. For example, the HCP may consult with the patient to determine that the patient's meals can be entered into the smart device as input, and for the user's convenience and due to the user's consistency regarding such meals, they can be entered more easily within categories such as small, medium, or large, or as fuzzy, and additional categorization (or "fuzzifications") correspond, for example, to the relative amounts of carbohydrates / fat / protein. If the user knows the amount of carbohydrates or other such data, similar data can be entered as "crisp." The type of calculation or calculation reliability performed by the bolus calculator may be based at least in part on whether the user provides accurate or crisp data, approximate data, fuzzy or categorized data, etc. For example, if the user enters "3 carb units" versus "big meal," the calculation may differ.

[0192] HCP can provide preset meal boluses during initial setup and subsequently modify these values ​​according to an update routine. The bolus calculator then recommends an insulin bolus with glucose correction, trend adjustment, and IOB.

[0193] In another variation, the HCP can use the EMR system to provide a default rate to the CGM app. More specifically, the HCP can input a recommended default rate into the EMR system, and the EMR system can transmit the recommended default rate to the patient's CGM app, for example, which includes a bolus calculator tool. An appropriate API can be configured to allow communication between the EMR system and the CGM app. The patient can view the recommendations and confirm or reject the settings. In some cases, a comment field may be provided to explain why the patient is taking a specific action, or for the HCP to explain why the change is being suggested. On the HCP's side, the HCP can see whether the patient has confirmed or rejected the default change.

[0194] In the same or similar manner, data discussed with the HCP at the appointment can be entered into the data profile via an appropriate UI and transmitted to the CGM app using appropriate security procedures. In some cases, the "data profile" may be the aforementioned EMR system, and in other cases, it may be another application that may or may not communicate with the patient's EMR.

[0195] In another variation, Near Field Communication (NFC) may be used to communicate data, such as settings and configuration parameters, to a patient's mobile device, such as a smartphone. More specifically, the NFC of the mobile phone can be used to scan the transmitter, which automatically causes the mobile phone and the transmitter to set up the system, such as downloading a CGM app on the phone (from the transmitter), pairing the phone and the transmitter, and, in some embodiments, initiating sensor startup. Such a system and method according to the present principle eliminates the step of having to enter a code, and the "cost" is that the devices must be in close proximity to each other. However, a significant advantage is that the devices cannot be easily hacked from a distance.

[0196] More specifically, in this embodiment, the transmitter itself can store applications for various devices, e.g., iOS and Android, and during the pairing process, the transmitter can directly transmit the application to the paired smartphone. This is useful for actual app downloads that often require a strong data connection, which can be particularly difficult or a challenge in certain situations, and the ability of a patient to access a hospital or doctor's Wi-Fi network due to privacy concerns can also be a challenge. Therefore, if pairing is initiated by a technology such as NFC and the application is transmitted in the same manner, this provides a significant advantage to the user. Additionally, the application can be updated using NSF, or the application can be updated when the user is near a strong Wi-Fi connection.

[0197] Systems and methods according to the present principle may be related to the initial setup of a bolus calculator app or function as well as its updates, for example, based on subsequent learned data regarding the patient and / or sensor, that is, data learned following the initialization of the sensor session. This may be particularly important as sensor sessions generally become longer and patients use the sensor less than before.

[0198] In one embodiment, referring to the flowchart (850) of FIG. 9, the HCP and the user may communicate for the initial setup of the bolus calculator (step 902). Such setup may occur in the manner described above, for example, through a cloud server, a peer-to-peer system, etc. Then, the system may determine whether the bolus calculator parameters are near-optimal or can be improved (step 904). This determination may be made in several ways. For example, the system may determine whether the user frequently or always changes the bolus calculator calculations (step 906). For example, the user may continuously add units to all boluses. If it is determined that the user's glucose response has delivered too much insulin, this is automatically flagged and can be used as a point of discussion for the next visit between the user and the HCP. However, if the user maintains glucose levels within the target range by doing so, this may indicate that changes to the bolus calculator parameters are needed.

[0199] In another embodiment, the system can automatically determine post-event pattern quantification (step 908). In this embodiment, the system can review past data to determine whether there are patterns that can be processed by changing the bolus calculator parameters. In this regard, it should be noted that some patterns can be processed in this way and others cannot. If a pattern that can be processed is identified, appropriate changed bolus calculator parameters can be determined and transmitted to the user's bolus calculator app.

[0200] More generally, the system can determine a bolus calculator triggering event (step 912). More specifically, the system can detect an event or a series of events that can be advantageously and effectively processed by changing the bolus calculator parameters. If the system can uniquely determine such a triggered and proposed modification solution, this can be proposed as a potential change to the bolus calculator parameters or settings. In some cases, a unique and clear solution cannot be calculated immediately, but a qualitative direction for parameter modification can be determined. For example, it can be determined that the bolus calculated with the current parameters is generally too small. In this case, it can be determined that the parameters should be changed to increase the amount of bolus.

[0201] However, it is determined that the bolus calculator parameters / settings may be determined to be near-optimal, more optimal, or improved (step 914). As indicated above, when considering the currently available data, in some cases the direction and magnitude of change may be determined, but in other cases only the qualitative direction of change may be determined. In some cases the qualitative magnitude of the change in bolus calculator parameters / settings may be determined, but in other cases, using more data may determine the quantitative magnitude of the change.

[0202] If a potential modification is determined, for example, qualitatively or quantitatively, the user and / or HCP is notified that the modification should actually be attempted or is given an opportunity to confirm this (step 916). Upon confirmation, the modified parameter can be entered into the bolus calculator app or function (step 918).

[0203] Keep in mind that any number of known data (including inferred amounts such as data patterns) may potentially be "mined" for data that may be useful for modifying the settings of a bolus calculator and / or the control of a drug delivery device.

[0204] For example, in the determination of step (906) above, the system may detect a pattern in which the user continuously delivers a bolus different from that calculated by the bolus calculator. In this embodiment, it is particularly important to notify the user of changes to the bolus calculator settings because without such notification, too much insulin may be delivered by the system. Detection of such user deviation from the calculated value may be achieved by analyzing periodic, occasional, habitual, frequent, constant, or regular deviations from the calculated value, where the deviation is, for example, of approximately the same size and sign within a range. For example, the user may occasionally or frequently deviate from the calculated bolus value by +1 unit, -1 unit, etc.

[0205] In response to the detection and notification of a bolus calculator triggering event, the HCP may take various actions. One action is to modify the bolus calculator settings / parameters and send them back to the patient. The steps of this method may include the specific steps described above in relation to FIG. 8 and include the HCP receiving a one-time code that allows for the creation of the patient and the modification of the bolus calculator parameters. Alternatively, if a sufficiently encrypted and / or secure communication channel exists between the HCP portal and the patient's bolus calculator, the HCP may modify the parameters without a one-time code. Since most users generally wish to approve the modification of the bolus calculator, it is expected that the bolus calculator app (or CGM app with bolus calculator functionality) may be configured to prompt the patient for approval before actually modifying the bolus calculator parameters, even if the parameters have already been downloaded to the device. Another action is to provide a notification to the insurance company that a consultation has occurred and a billing event may occur. In this measure, if a consultation takes place between the patient and the HCP, billing events can be configured according to the consultation, and billing for these events can be facilitated or made more convenient by automatically notifying the payer, such as an insurance company. The consultation can be configured in several forms, including: (1) detection of BC triggering events; (2) notification to the patient; (3) generation of the patient's code and transmission to the HCP; (4) use of the HCP's code upon modification; and (5) patient approval for the modification and installation of modified parameters for the ballus calculator app / function.Other forms in which consultation may be taken include: (1) detection of BC triggering events; (2) HCP initiation of notification to the patient; (3) patient's approval of potential modifications and transmission of approval to HCP; (4) HCP modification of BC parameters and / or transmission of the modifications to the bolus calculator in a secure and / or encrypted manner; and (5) patient approval of the modification and installation of the modified parameters for the bolus calculator app / function. Other methods will also be understood. In all these cases, the manner in which consultation is performed—that is, the use of efficiency and other benefits obtained through the use of systems and methods according to the present principles—can provide significant health benefits to the patient because it is determined that modifications are necessary and should be made more quickly. This can also provide significant technical advantages, as the transmission of short messages between the patient device and the HCP device provides distributed processing and / or peer-to-peer communication, allowing modifications to be made without, for example, the need for the patient to take a smartphone to the doctor's office and access a hospital computer, etc.

[0206] Another measure is to notify the patient that a doctor's appointment may be required. In this embodiment, automatic notification may be made to the payer. This type of measure may generally be taken when a doctor feels that an office consultation is necessary or desirable.

[0207] Another measure is to potentially notify the patient to take measures that do not involve medications, for example, to increase sleep or exercise. However, a commonality in such measures is that modifications to such parameters or settings allow for the correction of defects in the bolus calculator parameters / settings, at least partially. For example, rather than the pattern of the user encountering nighttime lows being detected; the system determines that the pattern of nighttime lows can be corrected by the parameters or settings of the bolus calculator.

[0208] To accommodate the busy schedules of most HCPs, potential bolus calculator modifications to settings / parameters may be grouped so that HCPs receive grouped sets for specific patients periodically, for example, only once a week. Additionally, or alternatively, potential modifications may be prioritized or ranked so that the most important ones are processed first. For example, a specific number of points may be assigned to actions (dosage-related) taken by a patient that result in an undesirable reaction, and when the point threshold level is reached based on the total number or cycle, actions exceeding the threshold may be flagged for physician review.

[0209] In a specific embodiment, the automatic review may include having the system review the patient's meals, based on the event of the meal occurring rather than a time-based system. A time period after the meal, e.g., 4 hours, can determine whether the patient is within a desired target range or a higher or lower range. If the patient is not within the range for a specific threshold number of days during the week, it may be desirable to make a change. For example, if the patient is not within the range for 5 out of 7 days, a change may be requested. These and other methods can be used to determine the result or satisfactory (or unsatisfactory) characteristics of the bolus calculator parameter / setting set.

[0210] In another variation, parameters / settings of different groups may be appropriately discovered or specific events may be processed at different time zones, and the settings and parameters may be modified according to system knowledge regarding whether such events or time zones are current. For example, refer to FIGS. 7m through 7u.

[0211] Generally, the system and method use historical data containing inferred quantities, such as patterns, to provide real-time current suggestions or changes to the parameters or settings of a bolus calculator. The decision regarding the change or modification is at least partially automatic, but the implementation of the change itself can be verified by the patient, the HCP, or both.

[0212] Bolus Calculator Example

[0213] The bolus calculator is an important tool for users to manage diabetes. It makes mathematics significantly easier for patients and is less susceptible to human error. Currently, bolus calculators are generally only available with insulin pumps.

[0214] An exemplary calculation might be as follows. In the equation operating for the bolus calculator, the appropriate insulin bolus may be equal to the sum of the correction factor, the current carbohydrate-related factor, and the IOB-related factor. Carbohydrate "coverage" is generally equal to the number of carbohydrates divided by the ICR, and the correction is equal to the target value divided by the correction factor subtracted from the current glucose value. In one estimate, the trend adjustment is equal to the rate of glucose change multiplied by the time period, e.g., 20 minutes, and divided by the correction factor. Essentially, the correction and trend adjustment are equivalent to predicting what the glucose level will be at 20 minutes from the current time, assuming the current rate of change is constant, and correcting based on future glucose levels.

[0215] In an exemplary calculation without trend adjustment, blood glucose may be 165; the target value may be 100; the carbohydrate count may be 45; the ISF may be 1:35; and the insulin-to-carbohydrate ratio (ICR) may be 1:12. The last bolus taken may be 3 units 3 hours prior. For certain types of insulin, the insulin-to-acting interval (DIA) may be 4 hours. The adjustment is 165 to 100 or 65. An ISF of 65 provides 1.86 units. The carbohydrate value is 45 carbohydrates, and with an insulin-to-carbohydrate ratio of 1:12, it becomes 3.75 units. The IOB is 3 units, and if it acts for 4 hours, 0.75 units remain. Therefore, the total dose is equal to 1.86 + 3.75 - 0.75 or 4.86 units. The Bolus calculator, which utilizes CGM functionality, is significantly more accurate because it determines the amount of insulin required for correction using current CGM glucose values ​​and trends. Trend information proved to be particularly important and was shown to yield much superior results compared to when trends are unexplained.

[0216] The bolus calculator mentioned above may be an integrated feature of the CGM app or a separate app that communicates with the CGM app, and can determine the insulin dosage using both the current CGM glucose value and the trend. An exemplary user flow of the bolus calculator is illustrated in FIG. 10. As can be seen, the user may choose to always enter the meter glucose value instead of the CGM value, especially when the CGM value is unavailable. Additionally, trend adjustment is included to consider where the glucose is heading at the time of the insulin bolus, which can affect where the glucose stabilizes relative to the target after a meal. Trend adjustment can be calculated by multiplying the current rate of change (mg / dL / min) by a time factor (e.g., 20 minutes) and dividing by a patient-specific adjustment factor (mg / dL / units). In one embodiment, the trend adjustment corrects for the expected glucose change within the next 20 minutes.

[0217] More specifically, an exemplary calculation using trend adjustment is illustrated in FIG. 11. Trend adjustment is equal to the rate of change in glucose multiplied by the corresponding time period, i.e., the time to achieve the target, e.g., 20 minutes, and divided by a correction factor. Essentially, correction and trend adjustment are equivalent to predicting what the glucose level will be at 20 minutes from now, assuming the current rate of change is constant, and correcting based on the future glucose level.

[0218] Figure 11 also illustrates an exemplary graphical representation of trend adjustment, namely, a graphical representation of the case where a trend is considered in the bolus calculation. Trend adjustment can be turned off in the bolus calculator settings, but it can also be turned on by default. Generally, if trend data is not available in the CGM app, trend adjustment will not be performed.

[0219] The correction factor is typically a patient-specific value estimated with the help of the patient's doctor. The correction factor can vary throughout the day and change over time. It represents the decrease in glucose resulting from taking 1 unit of insulin. Therefore, if a patient's blood glucose level is 200 and they take 1 unit of insulin, the blood glucose drops to 120, and consequently, the correction factor is 80.

[0220] Like correction factors, ICR is patient-specific and can vary over time throughout the day depending on physiology. Most patients make three estimates for breakfast, lunch, and dinner. What this parameter should reflect is the number of carbohydrates equivalent to one unit of insulin. Therefore, if a patient's ICR is 15, it means that consuming 15g of carbohydrates and taking one unit of insulin will eventually result in blood glucose returning to its current value after the insulin action time—for example, about four hours—is over.

[0221] In a specific implementation of the bolus calculator function, during real-time use of the bolus calculator, the user can view their last insulin dose, which can be updated if inaccurate.

[0222] For MDI users, a bolus calculation relating the Intravenous Bolus (IOB)—the amount of rapid-acting insulin still active in the user's body several hours after administration—can be calculated from insulin event inputs generated by such users. The bolus calculator can also account for the Insulin Action Time (IAT), which is the total time that insulin remains active in the user's system after the bolus. IAT varies by person and situation. For shorthand purposes, a linear IOB curve is easy for patients to understand, but a curved IOB curve is closer to the pharmacokinetic action of insulin. Recent studies suggest that using a log-normal distribution as the insulin action profile yields even more accurate results. IOB can follow a cumulative distribution function, and the remainder of IOB at any given time point can be determined from the cumulative distribution function of the log-normal distribution, i.e., IOB = 1 - CDF. Since the log-normal distribution generally has very long tails, the IOB does not drop to zero at the end of the insulin action time but generally maintains a certain level, for example, 19%. Users can subtract linear adjustments at all points to adjust for the IOB to drop smoothly to zero at the time of insulin action, as they generally expect not to activate insulin in their system after the insulin action time has ended. The top equation in Fig. 11 illustrates such subtraction of the IOB. When performing trend adjustments, adjustments are generally not made when the trend is flat, and adjustments may be limited to provide maximum trend adjustment; for example, no additional adjustments may be made for predicted rises or falls of 60 mg / dL or more (at a rate of 3 mg / dL / min).

[0223] The benefits of using trend adjustments are varied. For example, most users have a "blind spot" approximately two hours after a meal, during which carbohydrates and insulin are active in their systems. During this period, it is generally best to include additional carbohydrates but not apply corrections. The Pump Bolus calculator subtracts IOB only from the correction portion and not from the carbohydrate portion, but this has the effect of recommending too much insulin for meals outside the blind spot.

[0224] Therefore, when the bolus is calculated within the last 2 hours, i.e., in the post-meal blind spot, the carbohydrate coverage is calculated, but the corrected bolus or trend adjustment is not calculated. The IOB is subtracted from the carbohydrate coverage if the predicted glucose is below the target range, for example, if the current glucose value is 80 and the rate is -2 mg / dL / min.

[0225] According to the study, incorporating trend information into the bolus calculator resulted in increased time being achieved within the target range and reduced hypoglycemia compared to cases without trend adjustments.

[0226] Transmission details

[0227] The transmission of bolus calculator settings and parameters can be performed from the HCP to the patient's CGM app (and thus the bolus calculator app / function) via the cloud, for example, through the use of real-time services that can be implemented in the cloud. Such services may include real-time event reporting, which can be extended to include not only event reporting but also the transmission of bolus calculator settings and parameters (in the reverse direction). Some continuous data paths may be used, while others are temporary.

[0228] In one variation, a performer, e.g., a parent, may notify a sharer, e.g., a child, when bolusing, and may also know whether the child has bolused a calculated amount or a different amount. This may allow for future discussion, potential modification of the bolus calculator, and / or the establishment of confidence in the performance of the bolus calculator. For example, when calculating a bolus value, a message may be sent to one or more performers via text message, an app, etc. This may indicate to the performer that the patient is bolusing or has already bolused, provided such data is available. If the bolus calculation is performed on a monitoring device, e.g., a drug delivery device communicating with a smartphone, the smartphone function may serve as a leverage to provide a message to one or more performers based on actions occurring on the drug delivery device. For example, if the drug delivery device is used to deliver a bolus of insulin to a user, the smartphone may be used to send a message to the performer.

[0229] In a more detailed embodiment, bolus information may be transmitted to the practitioner, and if available, the effect of the bolus may be transmitted likewise. For example, bolus information may be transmitted at the time of delivery. Additionally, several hours after the bolus is delivered, the bolus information may be repeated along with a chart showing the patient's subsequent glucose values. In this way, the effect of the bolus can be shown and reviewed by the practitioner. In some cases, more summary information than the chart, such as a display of the time rate within the target range, may be provided.

[0230] In another embodiment, if the performer wishes to review transmitted data and communicate potential modifications to the bolus calculator parameters, a function may be provided for the performer to send a suggestion to the patient. Alternatively, the performer may send a notification of potential bolus calculator modifications directly to the HCP. This function may be particularly useful when one HCP communicates a suggestion to another HCP.

[0231] As another advantage, if the practitioner reviews the transmitted data, for example using a different bolus calculator method, and finds that the patient is spending significantly more time within the target range than before, practitioner confidence in the bolus calculator will increase, leading to further increases in usage and the associated health benefits.

[0232] Further details regarding message transmission for the purpose of sharing and execution can be found in references [US Patent Publication Nos. 2014 / 0184422 and 2014 / 0187889], all of which are incorporated herein by reference in their entirety and describe a system and method for remote monitoring of analyte measurements that can be implemented together with embodiments disclosed herein.

[0233] Such systems and methods can also provide notification from HCP to HCP. In one embodiment, an endocrinologist may be aware of general practice prescribed by a physician, including bolus calculator settings, and in the same way, a certified diabetes educator may be aware of a patient under protection. Other HCPs associated with the user may be similarly notified, and the transmitted data may be specific to and tailored to the relevant HCP in content, format, or both.

[0234] The use of an HCP-related server in setting bolus calculator parameters offers certain advantages. For example, the server can provide messaging / email services to the HCP and provide them back to the patient. Messaging / email can be triggered, for example, by changes to the bolus and potential modifications.

[0235] As a specific embodiment, notifications, e.g., alerts, may be set up to notify the HCP regarding the patient's glucose levels, particularly in response to insulin administration based on the use of the bolus calculator. Such alerts may include cases where the patient's glucose levels fall outside a specific range, particularly when close to a bolus event. Based on the alerts, the HCP may verify patient data via a share-like system and modify / update the bolus calculator settings. As mentioned above, when the HCP modifies the bolus calculator settings, the system may configure a file to be transmitted via the cloud in an encrypted manner to a mobile device running the bolus calculator app. A report may be generated in response, and such a report is appropriately formatted for the recipient and transmitted to the recipient in a secure manner.

[0236] For ease of explanation and example, in some examples, detailed descriptions describe exemplary systems and methods in the context of a continuous glucose monitoring environment; however, the scope of the invention is not limited to that specific environment, and those skilled in the art should understand that the systems and methods described herein may be implemented in various forms. Accordingly, any structural and / or functional details disclosed herein should not be construed as limiting the systems and methods, but rather are provided as attributes of representative embodiments and / or arrangements to instruct those skilled in the art in one or more ways to implement the systems and methods that may be advantageous in other contexts.

[0237] For example, without limitation, the described monitoring system and method may include a sensor that measures the concentration of one or more analytes (e.g., glucose, lactate, potassium, pH, cholesterol, isoprene and / or hemoglobin) and / or other blood or body fluid components of or associated with the host and / or other party.

[0238] For example, without limitation, embodiments of the monitoring system and method described herein may include finger-blood sampling, blood analyzer test strips, non-invasive sensors, wearable monitors (e.g., smart bracelets, smart watches, smart rings, smart necklaces or pendants, exercise monitors, fitness monitors, health and / or medical monitors, clip-on monitors, etc.), adhesive sensors, smart textiles and / or garments containing sensors, shoe inserts and / or insoles containing sensors, transdermal (i.e., transdermal) sensors, and / or swallowable, inhalable, or implantable sensors.

[0239] In some embodiments, without limitation, the monitoring system and method may include inertial measuring instruments including accelerometers, gyroscopes, magnetometers and / or barometers; motion, altitude, position and / or position sensors; biometric sensors; optical sensors including, for example, optical heart rate monitors, photoelectronic pulse meters (PPG) / pulse oxygen meters, fluoroscopic monitors and cameras; wearable electrodes; electrocardiogram (EKG or ECG), electroencephalogram (EEG) and / or electromyogram (EMG) sensors; chemical sensors; flexible sensors for measuring, for example, stretch, displacement, pressure, weight, or impact; galvanometer sensors, capacitive sensors, electric field sensors, temperature / heat sensors, microphones, vibration sensors, ultrasonic sensors, piezoelectric / piezoresistive sensors, and / or transducers for measuring information of or related to a host and / or other party, and other sensors instead of or in addition to the sensors described herein.

[0240] In this document, the terms “computer program medium,” “computer usable medium,” “computer readable medium,” and variations thereof are generally used to refer to ephemeral or non-ephemeral media, such as main memory, storage unit interfaces, removable storage media, and / or channels. These and various other forms of computer program mediums or computer usable / readable media may be associated with delivering one or more sequences of one or more instructions to a processing device for execution. Such instructions implemented on the medium may generally be referred to as “computer program code,” “computer program product,” or “instructions” (which may be grouped in the form of a computer program or other groupings). When executed, these instructions may enable or be connected to a computing module or its processor to perform the features or functions of the present disclosure as disclosed herein.

[0241] Various embodiments have been described with reference to their specific exemplary features. However, it will be apparent that various changes and modifications may be made without departing from the broader spirit and scope of the various embodiments described in the appended claims. Accordingly, the specification and drawings should be regarded as exemplary rather than restrictive.

[0242] Although various exemplary embodiments and embodiments have been described above, it should be understood that the various features, aspects, and functions described in one or more individual embodiments are not limited to the applicability to the specific embodiments described and may be applied to one or more other embodiments of the present invention, either alone or in various combinations, regardless of whether such embodiments are described or whether such features are provided as part of the described embodiments. Accordingly, the breadth and scope of this application should not be limited by any of the exemplary embodiments described above.

[0243] Terms, phrases, and variations used in this application shall be interpreted as open rather than restrictive, unless otherwise expressly stated. For example, the term "including" shall be read to mean "including, without limitation," etc.; the term "example" is used in the discussion to provide an exemplary example of an item, rather than a comprehensive or restrictive list of items; the indefinite article (“a” or “an”) shall be read to mean "at least one," "one or more," etc.; adjectives such as "conventional," "traditional," "normal," "standard," "known," and terms of similar meaning shall not be interpreted as restricting items described for a given time period or items available for a given time period, but instead shall be read to encompass conventional, traditional, normal, or standard technology that may be available or known at any time, present or in the future. Likewise, when this document refers to technology that is obvious or known to a person skilled in the art, such technology includes technology that is obvious or known to a person skilled in the art at any time, present or in the future.

[0244] In some cases, the presence of extended words and phrases, such as “one or more,” “at least,” “but not limited to,” or other similar expressions, should not be interpreted to mean that the narrower case is intended or required in the absence of such extended phrases. The use of the term “module” does not imply that all components or functions described or claimed as part of a module are organized into a common package. In practice, regardless of control logic or other components, some or all of the various components of a module may be combined into a single package or maintained individually, or may be distributed across multiple groupings or packages or multiple locations.

[0245] Furthermore, the various embodiments described herein are described with reference to exemplary block diagrams, flowcharts, and other drawings. As will be apparent to those skilled in the art after reading this document, the illustrated embodiments and various alternatives thereof may be implemented without being limited to the illustrated embodiments. For example, block diagrams and accompanying descriptions should not be interpreted as mandating a specific architecture or configuration.

[0246] Implementations of the subject matter and functional operations described in this patent document may be implemented in various systems, digital electronic circuits, or computer software, firmware, or hardware, or in combinations of one or more of these, including structures and structural equivalents disclosed herein. Implementations of the subject matter described herein may be implemented as one or more computer program products, namely, as one or more modules of computer program instructions encoded on a tangible and non-transient computer-readable medium to be executed by the operation of a data processing apparatus or to control such operation. The computer-readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of a material that affects machine-readable radio signals, or a combination of one or more of these. The term "data processing apparatus" includes, for example, a programmable processor, a computer, or any device, apparatus, and machine for processing data, including a plurality of processors or computers. In addition to hardware, this apparatus may include code that creates an execution environment for the said computer program, for example, processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of these.

[0247] A computer program (also known as a program, software, software application, script, or code) may be written in any form of programming language, including compiled or interpreted languages, and may be distributed in any form, including a standalone program or modules, components, subroutines, or other units suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored as part of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), as a single file dedicated to the program, or as multiple coordination files (e.g., files storing one or more modules, subprograms, or parts of code). A computer program may be distributed to run on a single computer or at a single site, or on multiple computers distributed across multiple sites and interconnected by a communication network.

[0248] The processes and logic flows described in this specification may be performed by one or more programmable processors that execute one or more computer programs to perform functions by manipulating input data and generating outputs. The processes and logic flows may also be performed by special-purpose logic circuits such as field programmable gate arrays (FPGAs) or application-specific integrated circuits (ASICs), and the device may also be implemented by said special-purpose logic circuits.

[0249] Processors suitable for the execution of computer programs include, for example, general-purpose and special-purpose microprocessors and any one or more processors of any type of digital computer. Generally, the processor will receive instructions and data from read-only memory or random access memory, or both. Essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, the computer will also include one or more mass storage devices for storing data, operably coupled to receive, transmit to, or both transmit data from, for example, magnetic, magneto-optical, or optical disks. However, the computer does not need to have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices. The processor and memory may be supplemented by or contained therein by special-purpose logic circuits.

[0250] Although this patent document contains many details, they should not be interpreted as limitations on the scope of any invention or claimable, but rather as descriptions of features that may be specific to specific embodiments of a particular invention. Specific features described in this patent document in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, while features may be described above as functioning in a specific combination and even initially claimed as such, one or more features from the claimed combination may, in some cases, be removed from that combination, and the claimed combination may relate to a sub-combination or a variation of a sub-combination.

[0251] Similarly, although operations are depicted in a specific order in the drawings, this should not be understood as requiring that such operations be performed in the specific order depicted or in sequential order, or that all depicted operations be performed, in order to achieve the desired result. Furthermore, the separation of various system components in the embodiments disclosed in this patent document should not be understood as requiring such separation in all embodiments.

[0252] Only a few embodiments and examples are described, and other implementations, improvements, and variations may be made based on what is described and illustrated in this patent document.

Claims

Claim 1 An application executable on a server and stored on a computing-readable medium, comprising: first commands configured to receive data regarding a target user and set up a target user account; a first input configured to receive sensor data from a device associated with said target user; second commands configured to analyze data from said first input and determine whether a bolus calculator parameter on a device associated with said target user can be improved; and third commands configured to transmit a signal to a healthcare professional portal associated with said server or to a device associated with said target user and modify said parameter if said parameter on a device associated with said target user can be improved, and said second commands are also configured to determine whether a bolus calculator parameter on a device associated with said target user can be improved by detecting whether a change triggering event of the bolus calculator parameter has occurred, and said triggering event is a detection pattern detected through analysis of CGM traces - said pattern is treatable by changing the bolus calculator parameter or settings -; An application stored on a computer-readable medium, comprising the detection of departures of the delivered insulin bolus when compared to a calculated bolus value. Claim 2 In claim 1, the third commands are also an application stored on a computing readable medium configured to display a prompt on a portal and receive one or more parameters modified by a healthcare worker. Claim 3 In claim 2, the third commands are also configured to encrypt or secure the modified parameters before transmitting them to a device associated with the target user, an application stored on a computing readable medium. Claim 4 delete

Images