User Interface for Continuous Glucose Monitoring

Abstract

To provide a method for presenting glucose level data.SOLUTION: Glucose data for a patient may be received. Current glucose level and rate of change of the current glucose level may be determined based on the received glucose data. A first interface may be displayed on a screen of a device. The first interface may include a unitary icon. The unitary icon may display the current glucose level and visualization of the rate of change. Related apparatuses, systems, techniques, and articles are also described.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Incorporation by Interaction of Related Applications Any claim of priority or any amendment thereto identified in the application data sheet is incorporated herein by reference under 37 CFR 1.57. This application claims the benefit of U.S. Provisional Application No. 62 / 067,303, filed Oct. 22, 2014. The foregoing application is incorporated herein by reference in its entirety and is hereby expressly made a part hereof.

[0002] The present disclosure generally relates to the presentation of glucose data on a computing device, and more particularly to the presentation of a patient's glucose data in a manner that provides an at-a-glance view of the current and predicted states.

Background Art

[0003] Type 1 diabetes is a disorder in which the pancreas is unable to produce sufficient insulin. In a diabetic state, a person suffering from hyperglycemia may experience a series of physiological side effects associated with the deterioration of small blood vessels. These side effects can include, for example, kidney failure, skin ulcers, or bleeding into the vitreous of the eye. Hypoglycemic reactions such as hypoglycemic events can be caused by inadvertent over-administration of insulin or after normal dosing of insulin or glucose-lowering agents. In severe hypoglycemic reactions, there can be a high risk of headache, seizures, loss of consciousness, and coma.

[0004] A person with diabetes may carry a self-monitoring blood glucose (SMBG) monitor, which typically requires the user to prick their finger to measure their glucose level. Due to the inconvenience associated with traditional finger-pricking methods, diabetic patients tend not to perform SMBG measurements in a timely manner, and as a result, they may not be aware of whether their blood glucose levels indicate a dangerous situation.

[0005] For this reason, various non-invasive, transdermal (e.g., percutaneous), and / or implantable electrochemical sensors have been developed to detect and / or quantify blood glucose levels. These devices generally transmit raw or minimally processed data for subsequent analysis on a remote device. The remote device may have a display that presents information to the user having the sensor. In some systems, the patient may check their glucose level on a portable computing device. It is difficult to present this information unobtrusively and reliably. SUMMARY OF THE INVENTION MEANS FOR SOLVING THE PROBLEM

[0006] A method and apparatus for presenting glucose level data are provided, including a computer program product.

[0007] In one aspect, glucose data is received for a patient. A current glucose level and a rate of change of the current glucose level are determined based on the received glucose data. A first interface is displayed on the screen of the device. The first interface includes a unitary icon. The unitary icon displays a visualization of the current glucose level and the rate of change.

[0008] The above method, apparatus, and computer program product may further include one or more of the following features in some implementations.

[0009] The rate of change may be based at least on the current glucose level and a second value. The second value may represent the patient's glucose level at a second time preceding the time associated with the current glucose level.

[0010] The visualization of the rate of change may include one or more arrows facing a first direction. The first direction may represent whether the current glucose level is increasing, decreasing, or stable. The visualization of the rate of change may change by varying the first direction of at least one or more of the arrows.

[0011] One or more arrows facing the first direction may have a first indication direction of 0° when the rate of change is increasing, a second indication direction of 180° when the rate of change is decreasing, or a third indication direction of 90° when the rate of change is stable.

[0012] The number of one or more arrows may be selected based on the magnitude of the rate of change.

[0013] The unitary icon may possess a background color based at least on the current glucose level.

[0014] The background color may be a first color when the current glucose level is associated with a high glucose level, a second color when the current glucose level is associated with a target glucose level, or a third color when the current glucose level is associated with a low glucose level.

[0015] The first interface may further include a graph that displays a plurality of glucose levels over a predetermined period. The plurality of glucose levels may include a plurality of data points representing the current glucose level and one or more past values.

[0016] The graph may be divided into one or more of a first band associated with a high glucose level, a second band associated with a target glucose level, and a third band associated with a low glucose level. The first band, the second band, and the third band may be different colors.

[0017] The current glucose level may be displayed on the far right of the graph in the current band. The current band may include the first band, the second band, or the third band. The color of the current band may match the background color of the unitary icon.

[0018] The plurality of data points may include at least a first data point type and a second data point type. The current glucose level may be displayed on a graph using the first data point type. One or more past values may be displayed on a graph using the second data point type.

[0019] The first data point type may be a first circle with a black border and a white background. The second data point type may be a second circle with a black border and a black background.

[0020] The plurality of data points may further include a third data point type representing an event. The event may be associated with the most recent one of the plurality of data points.

[0021] The third data point type may be a shape surrounding the first data point type or the second data point type.

[0022] An explanation of the event may be displayed on the first interface when the third data point type is selected.

[0023] When the screen rotates, a second interface may be displayed. The second interface may include a landscape view of the graph in the first user interface over a period selected by the user. The period selected by the user may be 1 hour, 3 hours, 6 hours, 12 hours, or 24 hours.

[0024] A small icon may be displayed on the second interface when one of the plurality of data points is selected. The small icon may display the glucose level associated with the selected data point. The small icon may further include a background color based on the value of the selected data point relative to one or more thresholds.

[0025] The first interface may further include a second icon indicating whether the mute switch on the device is active.

[0026] The first interface may further include a third icon indicating whether a calibration measurement is required.

[0027] The first interface may further include a fourth icon that enables the input of one or more events when the fourth icon is selected. The one or more events may be associated with one or more of food intake, beverage intake, exercise, and drug administration.

[0028] The first interface may further include a fifth icon indicating whether remote monitoring is active, inactive, or experiencing an error.

[0029] The current glucose level may be shared with one or more remote monitors approved by the patient when remote monitoring is active. Remote monitoring may experience an error when the device cannot connect to one or more remote monitors approved by the patient.

[0030] The fifth icon may have a first color when remote monitoring is inactive. The fifth icon may have one or more colors when remote monitoring is active. The one or more colors may be different from the first color. The fifth icon may have a badge when remote monitoring is experiencing an error.

[0031] The unitary icon may include a circular shape with one or more arrows that rotate around the perimeter of the circular shape based on the rate of change of the current glucose level.

[0032] The current glucose level may be displayed inside the circular shape.

[0033] In another aspect, access is made to the patient's current glucose level and the rate of change of the current glucose level. A clinical risk for the patient is determined. A first interface is displayed on the device screen. The first interface includes a visualization of the clinical risk and a unitary icon. The unitary icon displays a visualization of the current glucose level and the rate of change.

[0034] The methods, apparatuses, and computer program products described above may further include one or more of the following features in some implementations.

[0035] Determining the clinical risk may be based on the current glucose level and the rate of change. The clinical risk may be related to an estimated glucose level.

[0036] The rate of change may be based on at least the current glucose level and a second value. The second value may represent the patient's glucose level at a second time. The second time may precede the time associated with the current glucose level.

[0037] The clinical risk may be high when one or more of the following conditions are met: the current glucose level exceeds a first threshold and the rate of change is increasing; the current glucose level exceeds a first threshold and the rate of change is stable; the current glucose level is below a second threshold and the rate of change is decreasing; the current glucose level is below a second threshold and the rate of change is stable.

[0038] The clinical risk may be low when one or more of the following conditions are met: the current glucose level exceeds a first threshold and the rate of change is decreasing; the current glucose level is below a second threshold and the rate of change is increasing; the current glucose level is between a first threshold and a second threshold and the rate of change is stable.

[0039] Visualization of clinical risk may include coloring the device screen with a first color when the clinical risk is high. Visualization of clinical risk may include coloring the device screen with a second color when the clinical risk is low.

[0040] Visualization of clinical risk may include incorporating a color gradient into the background of a unitary icon. The color gradient may include multiple colors. The multiple colors may be arranged in a pattern that illustrates clinical risk.

[0041] Visualization of clinical risk may include displaying an estimated glucose level on a second unitary icon.

[0042] Visualization of the rate of change may include one or more arrows facing a first direction. The first direction may indicate whether the current glucose level is increasing, decreasing, or stable.

[0043] One or more arrows facing the first direction may have a first indication direction of 0° when the rate of change is increasing, a second indication direction of 180° when the rate of change is decreasing, or a third indication direction of 90° when the rate of change is stable.

[0044] The number of one or more arrows may be selected based on the magnitude of the rate of change.

[0045] Visualization of clinical risk may include blinking one or more arrows.

[0046] Visualization of clinical risk may include enlarging one or more arrows.

[0047] Visualization of clinical risk may include coloring one or more arrows and the background of the unitary icon with different colors.

[0048] Determining clinical risk can be further based on one or more events. The one or more events can be related to one or more of food intake, beverage intake, exercise, and drug administration.

[0049] One or more of the current glucose level and rate of change may be displayed on the locked screen when the device is locked.

[0050] In a further aspect, an application is executed to generate one or more warnings on the device related to the patient's glucose level. Executing includes accessing the patient's current glucose level. Executing also includes accessing one or more conditions related to the one or more warnings. The one or more conditions define a relationship between the current glucose level and one or more thresholds. Executing further includes determining whether the one or more conditions are met. Executing also includes generating one or more warnings when the one or more conditions are met. The one or more warnings generated are based on one or more of the state of the device and the state of the application.

[0051] The above methods, devices, and computer program products may further include one or more of the following features in some implementations.

[0052] The state of the device may include one or more of a locked state, an unlocked state, a muted state, and an unmuted state. The state of the application may include an active state or a stopped state.

[0053] The application may be in an active state when the application is displayed in the foreground of the device screen. The application may be in a stopped state when the application is displayed in the background of the device screen.

[0054] One or more warnings may include one or more non - auditory warnings when the device is in a silent state. The one or more non - auditory warnings may include one or more of vibration or visualization displayed on the screen of the device. The visualization may include a blinking screen or a shaded screen.

[0055] One or more warnings may include one or more local notifications displayed on the screen of the locked device when the device is in a locked state. The one or more local notifications may display an identifier associated with the one or more warnings.

[0056] The one or more local notifications may further display the current glucose level and a trend arrow representing the rate of change of the current glucose level.

[0057] One or more warnings may include one or more banners when the device is in an unlocked state and the application is in a stopped state. The one or more banners may display an identifier associated with the one or more warnings on the screen of the device for a predetermined period.

[0058] One or more warnings may further include one or more auditory warnings.

[0059] One or more warnings may be regenerated at a predetermined frequency until one or more acknowledgments of the warnings are received or when one or more conditions are no longer met.

[0060] One or more warnings may include a low - urgency warning, a low warning, a high warning, a rising - rate warning, a falling - rate warning, or a no - data warning.

[0061] The low - urgency warning may not be changeable in some cases.

[0062] One or more thresholds associated with one or more warnings may be adjusted over a predetermined period. By adjusting, one or more conditions of one or more warnings may be satisfied more frequently than if the adjustment were not made. The adjustment may be made during the night mode.

[0063] In yet another aspect, one or more warnings regarding a patient's glucose level are maintained. One or more warnings are generated when one or more conditions are satisfied. One or more conditions define a relationship between the patient's current glucose level and one or more thresholds. It is detected whether a silencing function on a first device is active. Generation of one or more warnings is modified based on the detection.

[0064] The methods, apparatuses, and computer program products described above may further include one or more of the following features in some implementations.

[0065] The patient may be notified using one or more notifications that a silencing switch is active. The notification may be based on the detection.

[0066] An image may be displayed on the screen of the first device. The image may indicate that the silencing function is active on the first device. A message may be displayed on the screen. The message may indicate that the silencing function is active on the first device. An email may be sent to the patient. The email may indicate that the silencing function is active on the first device.

[0067] One or more vibratory warnings may be generated until recognition of one or more notifications is received.

[0068] A message may be sent to a second device. The message may cause the second device to notify one or more remote monitors of the patient that the silencing function is active on the first device.

[0069] Modifying may include initiating communication with one or more remote monitors of a patient. The communication may indicate that one or more conditions of one or more alerts are met. The communication may include one or more of a phone call, a text message, and an email.

[0070] Modifying may include sending a message to a second device. The message may indicate that one or more conditions of one or more alerts on the first device are met, and may cause one or more alerts to be generated on the second device.

[0071] Modifying may include adjusting one or more thresholds. By adjusting, one or more conditions of one or more alerts may be met more frequently than if the adjustment were not made. Adjusting one or more thresholds may be done over a predetermined period.

[0072] A message may be sent to a pump that is communicating with the first device. The message may cause the pump to interrupt the delivery of medication to the patient.

[0073] In another aspect, an application is executed on a first device for monitoring a patient's glucose level. It is determined whether the application on the first device has stopped execution. A notification is generated based on the determination. The notification indicates that the application has stopped execution.

[0074] The above method, apparatus, and computer program product may, in some implementations, further include one or more of the following features.

[0075] The notification may be generated before the application stops execution and may indicate that the application has ended.

[0076] The notification may be generated locally on the first device.

[0077] A message can be sent to a second device. The message may cause the second device to notify one or more remote monitors of the patient that the application has stopped running.

[0078] The application can start when receiving communication from a third device. The communication can be related to the operation of the application. The first device and the third device may be paired using a Bluetooth® connection.

[0079] An alarm may be set on the first device. The alarm can be configured to start at a predetermined time. The alarm can be reset on the first device before the alarm starts by extending the predetermined time. Determining whether the application has stopped running can be based on the start of the alarm.

[0080] A notification can be generated when receiving a message indicating that the application has failed to communicate with the second device during a predetermined period.

[0081] Determining can include determining whether the battery of the first device has sufficient power to continue operating the first device during a predetermined period.

[0082] It should be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and not restrictive. Additional features and / or variations may be provided in addition to those shown herein. For example, the implementations described herein may be directed to various combinations and sub - combinations of the disclosed features, and / or combinations and sub - combinations of several additional features disclosed hereinafter in the detailed description.

[0083] This patent or application file includes drawings created in at least one color. Copies of this patent or patent application publication that include color drawings (s) will be provided by the Patent Office upon request and payment of the necessary fees.

[0084] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate certain aspects of the subject matter disclosed herein and, together with the description, help explain some of the principles associated with the subject matter disclosed herein.

Brief Description of the Drawings

[0085]

Figure 1

Figure 2A

Figure 2B

Figure 3A

Figure 3B

Figure 3C

Figure 3D

Figure 3E

Figure 3F

Figure 3G

Figure 3H

Figure 3I

Figure 3J

Figure 4A

Figure 4B

Figure 5A

Figure 5B

Figure 5C

Figure 5D

Figure 6A

Figure 6B

Figure 6C

Figure 7A

Figure 7B

Figure 7C

Figure 7D

Figure 7E

Figure 8A

Figure 8B

Figure 8C

Figure 8D

Figure 9A

Figure 9B

Figure 10A

Figure 10B

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16A

Figure 16B

Figure 16C

Figure 17

Figure 18

Figure 19

Figure 20

Best Mode for Carrying Out the Invention

[0086] Like reference numerals are used to refer to the same or similar elements in the drawings.

[0087] A continuous glucose monitoring system can closely monitor a patient's glucose level at frequent intervals. By increasing the frequency of glucose level measurements and transmitting these measurements to the patient, the patient can prevent long periods of high glucose levels that can damage tissues over time and prevent or shorten periods of dangerously low glucose levels. The continuous glucose monitoring system may have a dedicated display device such as a receiver. The patient or a remote monitor can use this receiver to view the patient's glucose level and receive warnings when the patient's glucose level becomes high or low. Since the patient may find it cumbersome to carry a separate glucose monitoring device, it may be advantageous to incorporate the receiver's functionality into a multifunctional computing device such as a smartphone or other portable device.

[0088] FIG. 1 depicts an exemplary system that includes a continuous analyte sensor system (e.g., a continuous glucose meter) 8. The continuous analyte sensor system 8 can include a sensor electronics module 12 and a continuous analyte sensor 10 connected to a patient 100. The system can include other devices and / or sensors such as a pharmaceutical delivery pump 2 and a blood glucose meter 4. The continuous analyte sensor 10 may be physically connected to the sensor electronics module 12, integral with (e.g., non-removably attached to) the continuous analyte sensor 10, or removably attachable thereto. The sensor electronics module 12, the pharmaceutical delivery pump 2, and / or the blood glucose meter 4 can be coupled to one or more devices such as display devices 14, 16, 18, and 20.

[0089] FIG. 1 is for illustrative purposes only, and it should be understood that the system may include other components. For example, the system may further include a gastric pacemaker that communicates with a continuous analyte sensor system 8 and a pharmaceutical delivery pump 2. The components of the system may communicate with each other to trigger the gastric pacemaker to perform pacing in order to facilitate the processing of the patient's food / drink. By way of illustration, the continuous glucose sensor system 8 may trigger a message to the gastric pacemaker to initiate pacing when a hyperglycemic event is detected by the system, and to stop pacing when the measured glucose level is below or within a predetermined threshold(s).

[0090] The system may also communicate with other devices in some implementations. For example, the system may communicate with the electronics of an automobile. The display of the automobile electronics may be used as a display device to display and / or alert the user of the glucose level measured by the analyte sensor system 8. Further, the automobile electronics may facilitate the operation of the automobile according to the glucose level measured by the analyte sensor system. For example, the automobile electronics may disable the ignition if the glucose level is too low, or may pull the automobile over to a stop if the automobile includes autonomous driving capabilities.

[0091] In some exemplary implementations, the system may include a cloud-based analyte processor 114 configured to analyze analyte data (and / or other patient-related data) provided from a sensor system 8 and other devices such as display devices 14, 16, 18, and 20, etc., associated with a host (also referred to as a patient) via a network 120 (e.g., via wired, wireless, or a combination thereof). The cloud-based analyte processor 114 may be configured to generate reports that provide high-level information such as statistics regarding the analyte measured over a particular time frame.

[0092] In some exemplary implementations, the sensor electronics module 12 may include electronic circuitry related to measurement and processing data generated by a continuous analyte sensor (e.g., a continuous glucose meter) 10. The generated continuous sensor data may also include algorithms that can be used to process and calibrate the continuous sensor data, although these algorithms may also be provided in other ways. The sensor electronics module 12 may include hardware, firmware, software, or a combination thereof to provide measurements of analyte levels via a continuous analyte sensor such as a continuous glucose sensor.

[0093] The sensor electronics module 12 may be coupled to one or more devices such as display devices 14, 16, 18, and / or 20 (e.g., wirelessly, etc.). The display devices 14, 16, 18, and / or 20 may be configured to present (and / or notify of) information such as sensor information transmitted by the sensor electronics module 12 for display on the display devices 14, 16, 18, and / or 20. In some implementations, the display devices 14, 16, 18, and / or 20 may implement algorithms performed by the sensor electronics module 12.

[0094] The display devices may include a relatively small key fob-like display device 14, a relatively large portable display device 16, a mobile phone (e.g., a smartphone, tablet, etc.) 18, a computer 20, and / or at least any other user device configured to present information (e.g., pharmaceutical delivery information, individual self-monitoring glucose readings, heart rate monitor, calorie intake monitor, etc.).

[0095] In some exemplary implementations, the relatively small key fob-like display device 14 may include a wristwatch, a belt, a necklace, a pendant, part of a jewelry item, an adhesive patch, a pager, a key fob, a plastic card (e.g., a credit card), an identification (ID) card, and the like. This small display device 14 may include a relatively small display (e.g., smaller than a large display device) and may be configured to display certain types of displayable sensor information, such as numbers and arrows.

[0096] In some exemplary implementations, the relatively large portable display device 16 may include a portable receiver device, a palmtop computer, and the like. This large display device may include a relatively large display (e.g., larger than a small display device), which may be configured to display a graphic representation of continuous sensor data, including information such as current and past sensor data output by the sensor system 8.

[0097] In some exemplary implementations, the continuous analyte sensor (e.g., a continuous glucose meter) 10 includes a sensor for detecting and / or measuring an analyte, and the continuous analyte sensor 10 may be configured to continuously detect and / or measure the analyte as a non-invasive device, a subcutaneous device, a transdermal device, and / or an intravascular device. In some exemplary implementations, the continuous analyte sensor 10 can analyze multiple intermittent blood samples, although other analytes can be used as well.

[0098] In some exemplary implementations, the continuous analyte sensor 10 may comprise a glucose sensor configured to measure in vivo glucose using one or more measurement techniques, such as enzymatic, chemical, physical, electrochemistry, spectrophotometric, polarimetric, calorimetric, electrophoretic, radiometric, immunochemical, etc. In implementations where the continuous analyte sensor 10 includes a glucose sensor, the glucose sensor may comprise any device capable of measuring the concentration of glucose, and may use various techniques, including invasive, minimally invasive, and non-invasive sensing techniques (e.g., fluorescence monitoring), to measure glucose and provide data indicative of the glucose concentration in the patient 100, such as a data stream. The data stream may be the raw data signal, which is converted into a calibrated and / or filtered data stream that is used to provide glucose values to a user, such as a patient or a remote monitor (e.g., a parent, relative, caregiver, teacher, physician, nurse, or any other individual interested in the patient's health). Further, the continuous analyte sensor 10 may be implemented as at least one of the following types of sensors: an implantable glucose sensor, a transcutaneous glucose sensor implanted in the host's blood vessel or outside the body, a subcutaneous sensor, a refillable subcutaneous sensor, an intravascular sensor, and a non-invasive analyte sensor.

[0099] The description herein refers to some implementations that include the continuous analyte sensor 10 with a glucose sensor, but the continuous analyte sensor 10 may similarly include other types of analyte sensors. Further, some implementations refer to the glucose sensor as an implantable glucose sensor, but other types of devices capable of detecting the concentration of glucose and providing an output signal representative of the glucose concentration may similarly be used. Still further, the description herein refers to glucose as the analyte for which measurements, processing, etc. are performed, but other analytes may similarly be used, including, for example, ketone bodies (e.g., acetone, acetoacetic acid, and beta-hydroxybutyric acid, lactate, etc.), glucagon, acetyl CoA, triglycerides, fatty acids, intermediates of the citric acid cycle, choline, insulin, cortisol, testosterone, etc.

[0100] FIG. 2A shows a system 200 for exchanging and communicating glucose level data among various components according to some implementations. System 200 is a variation of the system of FIG. 1A. In particular, system 200 includes additional components that can receive and / or exchange information with sensor system 8 and further identify features of network 120. Patient 100 has a continuous glucose sensor system 8 on his or her body. Sensor system 8 can be applied to patient 100 using application device 7. Data receiver 16 and a first portable computing device 18 can communicate with sensor system 8. The system may also include one or more desktop or laptop computing devices 20, a network 120 including one or more servers, one or more second portable computing devices 19, and one or more additional persons who monitor the performance of the system. These additional persons may include technical support staff 220, product performance monitoring staff 222, and remote monitors (e.g., family members, guardians, physicians, nurses) 224.

[0101] The continuous glucose sensor system 200 may include various connections between electronic components. The sensor system 8 may be connected to the first portable computing device 18 and the receiver 16 via a low-energy near proximity wireless connection 212. In some implementations, the connection 212 may utilize Bluetooth® wireless technology. The receiver 16 and the laptop or desktop computing device 20 may be connected via a wired and / or wireless connection 14. This wired and / or wireless connection 14 may utilize a Universal Serial Bus (USB) port, a FireWire (e.g., IEEE 1394 high-speed serial bus) port, etc. The sensor system 8 may establish a constant or intermittent connection with the first portable computing device 18 and the receiver 16. In some implementations, the receiver 16 and / or the first portable computing device 18 may establish a constant or intermittent connection with the sensor system 8. These intermittent connections may be established at one or more predetermined frequencies, such as every 3, 5, 7, or 10 minutes, etc.

[0102] When a connection is established between the sensor system 8 and one or more of the receiver 16 and the first portable computing device 18, data corresponding to one or more glucose levels from the patient 100 may be exchanged between these components. In some implementations, the sensor system 8 may establish only one connection at a time such that the sensor system connects to either the receiver 16 or the first portable computing device 18. Each connection may end automatically or actively after a predetermined amount of data has been transferred, after a predetermined time, or after the user has initiated disconnection of the connection, etc.

[0103] In some implementations, the receiver 16 may be connected to the computing device 20 via a device cradle. This cradle may connect electrical contacts on the receiver 16 to ports on a laptop or desktop computing device 20. The first and second computing portable devices 18 and 19, and the laptop or desktop computing device 20 may communicate with each other via the network 120.

[0104] The network 120 may include servers 230, 232, 234, and 240. In some implementations, the servers 230, 232, 234, and 240 may be located in the cloud. These servers are illustrated as separate devices in the implementation of FIG. 2A, but they may be integrated as a single server, or one or more or all of the illustrated servers may be distributed across multiple devices or servers.

[0105] In the systems of FIGS. 1 and 2A, patient 100 or another user may monitor the patient's current glucose level and clinical risk, as well as the functionality of continuous glucose monitoring sensor system 8, in an unobtrusive manner. The other user may be a remote monitor, such as a parent, guardian, attending physician, nurse, etc. These remote monitors may use a portable computing device 19 to remotely monitor the status of patient 100. Remote monitoring server 230 may receive glucose level data from first portable computing device 18 or computing device 20 and push this data to remote monitoring device 19. This data may also include settings for communication with remote monitoring device 19. In some implementations, remote monitoring server 230 may push one or more alerts to the remote monitor, as described below with respect to FIGS. 3E - G. Portable computing device 19 may be a mobile smartphone, tablet computer, music or video playback device with Internet connectivity, etc. FIG. 2A illustrates remote monitoring device 19 as a smartphone, but the remote monitor may also access this information via a website on a desktop computing device 19, etc. In some implementations, patient's portable computing device 18 may be used in combination with receiver 16. By using both dedicated receiver 16 and portable computing device 18, insurance may be provided against scenarios where one of devices 16 or 18 fails. This redundancy also provides a safeguard for receiving alert notifications, for example, when one of the devices is placed in silent mode or malfunctions.

[0106] The compatibility server 232 can ensure the compatibility of various components within the system. This may include the compatibility of software (e.g., operating system) running on devices 18, 19, and / or 20 with other components or essential functions of system 200. The data synchronization server 234 can collect and store data and synchronize it with further components according to pre-defined permissions for data transfer. For example, the data synchronization server 234 may synchronize data with the data analysis and reporting server 240 as well as the product performance monitoring server 250.

[0107] In some implementations, system 200 of FIG. 2A may include one or more further servers configured to monitor the performance of the system. The user data server 236 can maintain medical information regarding users of the system (e.g., patient 100, remote monitor, etc.). The product performance monitoring server 250 can monitor the functionality of the sensor system 8, as well as servers 230, 232, 234, and 240. Server 242 can provide account information, e.g., sign-on or login information, for accessing the various servers in system 200.

[0108] Figure 2B illustrates a functional block diagram of the continuous glucose monitoring application 255 running on computing device 18 and / or 19. This block diagram includes various software modules or features that control the behavior of application 255. For simplicity of explanation, the software modules or features of application 255 are described as being performed by computing device 18 and / or 19. However, these software modules and features may be performed by other devices, including, for example, any one of the cloud-based analyte processors 114, servers 230, 232, 234, 236, 240, 242, and 250, or combinations thereof. The software modules and features of application 255 may include a data verification module 264, an event recording module 285, a remote monitoring module 290, a calibration module 280, and a warning module 275. Each of these modules is described below.

[0109] The data verification module 264 may display the patient's glucose level. As described below with respect to FIGS. 4A-8D, the data verification module 264 may provide information regarding the patient's current glucose level and the rate of change thereof. The data verification module 264 may also display a trend graph illustrating the variation of the patient's glucose level over time and may indicate to the patient the presence of clinical risk.

[0110] The remote monitoring module 290 may share the patient's glucose level information with other users such as the remote monitor 224. As described above with respect to system 200, the sharing server 230 may push this information to the second computing device 19. The patient may use the remote monitoring module 290 to invite remote monitors such that the remote monitors receive this information and can customize the types of information that can be confirmed by the invited remote monitors. The remote monitoring module 290 is described below with respect to FIGS. 3D and 3E.

[0111] The patient can use the event recording module 285 to input and trigger events. Examples of events include food intake, drug intake, exercise, etc. By recording this information, the patient can gain a better understanding of how different types of events can affect their glucose level. The event recording module 285 is described below with respect to FIGS. 3B and 3C.

[0112] The calibration module 280 can calibrate the glucose data measurements received from the sensor system 8. The calibration module 280 can alert the user when a calibration measurement is required. The calibration module 280 is described below with respect to FIG. 3H.

[0113] The warning module 275 can generate various alarms or warnings using the glucose level warning module 276, the silent mode warning module 278, and the communication failure warning module 277. The glucose level warning module 276 may be a sub-module of the warning module 275 and may be configured to generate an alarm when the patient's glucose level drops below or rises above a predetermined threshold. The patient may use the warning module 275 to set warnings for different parameters and specify which warnings to transmit to the remote monitor. The warning module 275 is described below with respect to FIGS. 9A - 14 and 16A - 17. The silent mode warning module 278 may be a sub-module of the warning module 275 and may be configured to warn the patient when it is determined that the patient's computing device 18 is silenced. Since the patient may not hear any warnings when their device 18 is silenced, the silent mode warning module 278 may initiate one or more corrective actions such as transmitting one or more warnings to the remote monitor. The silent mode warning module 278 is described below with respect to FIGS. 18 and 19. The communication failure warning module 277 may be a sub-module of the warning module 275 and may be configured to warn the patient or the remote follower when it is determined that the application 255 has ended. This notification may prompt the patient to restart or relaunch the application 255 so that the patient can continue to receive glucose level data from the sensor system 8. The communication failure warning module 277 is described below with respect to FIGS. 15 and 20.

[0114] FIG. 3A illustrates a home screen 310 that can be displayed by a data confirmation module 264 when application 255 is launched. A user, such as a patient and / or a remote monitor, can use the home screen 310 to access the patient's status and clinical risk, and to access various features associated with application 255. The home screen 310 may include icons 340, 342, 344, 346, and 347 that are selectable by one or more users. Selection of an icon may cause application 255 to perform a function associated with the icon (e.g., display a pop-up menu or open a new window related to the function). Descriptions of icons 340, 342, 344, 346, and 347 are provided below. The home screen 310 may also include a unitary icon 320 and a trend graph 330 that provides information regarding the patient's glucose level. The unitary icon 320 and the trend graph 330 are described in more detail below with reference to FIGS. 4A and 4B. The unitary icon 320 may provide a general representation of the patient's glucose level. The unitary icon 320 may include one or more graphics, one or more symbols, etc. The graphics and / or symbols in the unitary icon 320 may be static or may change based on the patient's glucose level. The graphics and / or symbols in the unitary icon 320 are integrated into a single integrated image in the implementation of FIG. 3A, but the unitary icon 320 may be divided into one or more non-adjacent graphics and / or symbols in other implementations.

[0115] The user can select the event input icon 340 to access the event recording software module 285. As described above, the user may use the event recording software module 285 to input information regarding events that may affect the patient's glucose level. Examples of events may include, for example, recent meals (e.g., food and beverage consumption), periods of activity or exercise, administration of medications (e.g., bolus administration of insulin), and the like. The input event information can be used to analyze the patient's health. In some implementations, as discussed below, the event marker can be displayed on the glucose trend graph to enable the user to retrospectively analyze how different types of events affect the patient's glucose level. The event information can also be used to determine when a warning should be generated (e.g., 30 minutes after exercise) and whether an adjustment is needed to the patient's dosing schedule (e.g., prompt the patient to administer a bolus of insulin after a particular event).

[0116] Figure 3B illustrates an exemplary interface for inputting meal-related event information. This interface may be displayed on the user interface of the patient's device 18 when selecting the event input icon 340, or may be automatically triggered when the application 255 receives an input indicating that the patient has eaten or is about to eat. The input may be one or more times of day (e.g., lunchtime), a change in glucose level indicating eating (e.g., rising glucose level), location (e.g., GPS location corresponding to a restaurant), etc. The patient may use the food input menu 1610 to provide information about recent meals such as breakfast 1622A, lunch 1624, dinner 1626, and snacks 1628. The menu 1610 may include an area 1614 for recording the consumption of favorite foods. For example, if the user consumes coffee, eggs, bread, and fruit for breakfast, the user may quickly record these items by selecting icons 1632, 1634, 1636, and 1638, respectively. The food input menu 1610 may also display the patient's current or recent glucose level reading 1616 and a trend graph 1620. The trend graph 1620 may provide a graphical display of the fluctuations in the patient's glucose level over a specific period.

[0117] Figure 3C illustrates another interface for inputting event information. This interface may appear when the patient selects the breakfast tab 1622A from Figure 3B. The drop-down menu 1630 may list various breakfast items, such as coffee, eggs, bread, apples, granola, etc. When the patient records their food intake, the event recording software module 285 may learn which foods are preferred in each meal and appropriately add them to the drop-down menu 1630. The module 285 may use this information to add different items to the favorite foods section 1614 in Figure 3B. In some implementations, the module 285 may vary the displayed favorite foods based on the time of day (e.g., display breakfast foods from 5 am to 8 am and lunch foods from 11 am to 1 pm).

[0118] Returning to FIG. 3A, the icon 342 can dynamically change to indicate whether remote monitoring is enabled. As an illustration, particularly when the patient is a child or an elderly person, the patient may wish to share their glucose level with one or more remote monitors such as a parent, caregiver, or attending physician. The patient can use the first device 18 to enable or disable remote monitoring. In some situations, remote monitoring may not be enabled, for example, if the patient is not enrolled in the remote monitoring feature. The remote monitoring module 290 can display the status of the remote monitoring function by adjusting the appearance of the icon 342 according to a plurality of states. In one implementation, the icon can be displayed in one of three states: a shared activity state, a remote monitoring disabled state, and a remote monitoring error state. The various states can be visually distinguished, for example, by changing the color of the icon 342 and / or by displaying one or more badges associated with the icon 342. In one exemplary implementation, the icon 342 is displayed in multiple colors when the device 18 is actively sharing data with another device 19, the icon 342 is displayed in gray when remote monitoring is disabled, and the icon 342 is displayed in gray with a badge to indicate that the device 18 cannot share data due to a technical error (e.g., the server 120 cannot push data to the second device 19). It is understood that the above implementation is merely an example of how the icon 342 can visually change based on the status of the remote monitoring function and that other visual changes can be used instead of or in addition to the above example.

[0119] Figures 3D and 3E illustrate a plurality of interfaces for controlling data sharing settings. When sharing is enabled, a patient may permit one or more remote monitors to receive messages or warnings regarding the patient's glucose levels. The remote monitoring module 290 may display a data sharing enrollment screen 380 if the user is not enrolled in the remote monitoring service. The user may select the "View Details" button to obtain further information about this service. When the "View Details" button is selected, the remote monitoring module 290 may launch a browser on device 18 and navigate to a website that provides further information about the remote monitoring service. Alternatively or in addition, the remote monitoring module may connect to a server (e.g., server 230) and display this information directly within application 255. However, if the user is already enrolled in the remote monitoring service, the remote monitoring module 290 may display a data sharing screen 381. Message 383 may provide the user with a textual explanation of whether sharing is currently enabled and the types of data that remote monitors can view. The patient may turn sharing on or off by toggling the share button 381. Area 384 may display information (e.g., identifier name and status indication) regarding the user's remote monitors, which may include invited remote monitors, excluded remote monitors, and active remote monitors. A field may be associated with each remote monitor. When a particular field is selected, the remote monitoring module 290 may navigate to a page that displays further information regarding the selected remote monitor. The user may invite additional remote monitors by selecting button 382, which may initiate the remote monitor invitation process described below with respect to FIGS. 3E - 3G.

[0120] Figures 3E - 3H illustrate an exemplary workflow for the remote viewer invitation process, which may be initiated, for example, when a user selects button 382 from the data sharing screen 381. The user may enter remote viewer information using interface 400 as illustrated in the flowchart of FIG. 3E. This information 402 may include, for example, the name and email address of the remote viewer. The system may send an invitation to the remote viewer using the entered email address. The user may manually enter this information using keyboard 404. In some implementations, the user may add remote viewers from their contacts as illustrated at interfaces 406 and 408, whereby application 255 can automatically add the remote viewer's information.

[0121] The application 255 may enable the user to define the types of information the user desires to share with the remote viewer. For example, the user may use interface 387 to indicate whether the selected remote viewer has permission to view the user's glucose trend graph. The user may use interface 412 to identify which warnings should be generated on the second computing device 19. These warnings may include, for example, a low - urgency notification 388A, a low notification 388B, a high notification 388C, and a no - data notification 388D. The low - urgency notification 388A and the low notification 388B may have certain thresholds 414A and 416A that define when the alarm is triggered. For example, Eric2 may receive a "low notification" warning when the user's glucose level has been below 70 mg / dL for more than 30 minutes. The user may set the thresholds 414A and 416A using interfaces 414B and 416B, respectively. The user may recommend different warning settings for each invited remote viewer during the invitation process described above with respect to FIG. 3E. The remote viewer may, in some implementations, approve or modify these warning settings.

[0122] Returning to FIG. 3A, the icon 344 may be a reference calibration icon. If calibration measurements are required, the calibration module 280 may display a badge on the icon 344. In the implementation of FIG. 3A, the badge may include a circle with a number positioned on top of the calibration icon 344. This number may represent the number of calibration readings required. For example, two configurations may be required during the initialization or warm-up of the new sensor system 8. In some implementations, calibration measurements may be required at a predetermined frequency (e.g., every 12 hours) or when abnormal glucose level readings are detected by the sensor system 8. Abnormal data may be caused, for example, by a malfunctioning sensor, illness, interfering components in the patient's body fluid, or electrostatic interference with the device electronics.

[0123] FIG. 3H illustrates a user interface 390 for entering calibration measurements. The calibration module 280 may display the user interface 390, for example, when the user selects the calibration icon 344 of FIG. 3A. The user may be prompted to measure their glucose level using an external blood glucose meter when the badge appears on the icon 344. The user may enter the measurement value 392 into the interface 390 using the numeric keypad 394. When the glucose measurement value 392 is entered, the interface 390 may prompt the user to confirm the value and time 396 of the reading using the OK button 398. When these values are confirmed, the application may start the calibration of the system using the entered values.

[0124] Returning to FIG. 3A, icon 346 may be a menu icon. By selecting icon 346, application 255 may display menu 360 shown in FIG. 3G. The user may use menu 360 to view or change various features of application 255. Menu 360 may include various sub-menus that enable the user to navigate to other screens and information. In the implementation of FIG. 3I, menu 360 may include the following sub-menus: trend 361, which causes application 255 to display home screen 310 shown in FIG. 3A upon selection; blood glucose meter 362, which causes application 255 to display the blood glucose input screen shown in FIG. 3H upon selection; warning 363, which causes the application to display the warning settings screen 910 shown in FIG. 9B upon selection; transmitter information 364, which causes application 255 to display a screen containing information about the currently used transmitter, such as, for example, the serial number of the transmitter, start date, battery level, expiration date, and pairing information (i.e., which device is currently paired with the transmitter), as described below with respect to FIG. 3J, upon selection; history 365, which causes application 255 to display a record of past operations, including, for example, triggered warnings, input events, sensor session start time, sensor session stop time, shared connectivity, etc., upon selection; report 366, which causes application 255 to display a screen providing a retrospective analysis of the user's data, including a trend graph comparing different time frames of the data and identification of patterns in the selected time frame of the data, upon selection; settings 367, which causes application 255 to display information about how the application displays information (e.g., the height of the trend graph), user account information, and factory settings upon selection; and session start 369, which causes application 255 to start a new sensor session if the sensor session is not already in progress upon selection. With respect to button 369, if the session is currently in progress, a session stop option may appear that enables the user to end the current sensor session.

[0125] When the transmitter button 364 is selected, the application 255 may display an exemplary interface 370 illustrated in FIG. 3H. The interface 370 displays the transmitter ID 372 of the sensor system 8, whether the transmitter is directly paired with the patient's glucose sensor 374, and a pairing button that the user can select to initiate pairing with the current display device (e.g., device 18) operating the transmitter and the application.

[0126] Returning to FIG. 3A, the application 255 may display an icon on its user interface to indicate that the user's device is muted. The user may not understand that by enabling the mute mode on a portable computing device such as the smartphone 18, the application 255 can be prevented from generating audible warnings. The icon 347 may indicate whether the mute mode on the computing device 18 is enabled or disabled (e.g., by a mute switch on the device). When the mute mode is enabled as illustrated in this figure, the application 255 may not be able to generate any audible warnings on the device 18.

[0127] FIG. 4A illustrates an exemplary user interface 300 that provides glucose level information of a patient. The data verification module 264 can change the information displayed on the user interface 300 based on the measurements received from the sensor system 8. For example, the data verification module 264 may show different representations 337A, 337B, 337C, 337D, 337E, 337F, 337G, 337H, 337I, and 337J of the home screen 310 when the patient's glucose level changes over a period of time. The patient can quickly and unobtrusively confirm their current glucose level, the rate of change of the current glucose level, and the critical state from the user interface 300. The interface 300 can be displayed on the patient's portable computing device 18 and the remote monitoring device 19. The user interface 300 may have a home screen 310 that includes a unitary icon 320 and a graph 330. The graph 330 may display the patient's glucose level over a predetermined period of time.

[0128] A user, such as a patient or a remote monitor, can quickly evaluate the patient's current glucose value, its rate of change, and the patient's status by looking at the unitary icon 320. The unitary icon 320 may be substantially circular in shape and may display a numerical indicator 324 corresponding to the patient's current glucose value. The unitary icon 320 may also include one or more arrows indicating whether the patient's current glucose value is increasing, decreasing, or stable (i.e., the rate of change). The background color 326 can change to indicate whether the patient's blood glucose state, e.g., whether the patient's current glucose level is low (e.g., hypoglycemia), within the target range, or high (e.g., hyperglycemia) relative to various thresholds. These thresholds may be provided by the user or may be provided as default values by the application 255.

[0129] The background 326 can change dynamically based on the determined clinical state of the user. For example, the background color 326 may be a first color when the patient's current glucose level is high (e.g., 210 mg / dL or higher, above the upper threshold level 334), a second color when the patient's current glucose level is within the target range (e.g., between 80 and 210 mg / dL, between the lower threshold level 332 and the upper threshold level 334), and a third color when the patient's current glucose level is low (e.g., 80 mg / dL or lower, below the lower threshold level 332). In the implementation of FIG. 4A, the first color may be yellow (as shown at 326A), the second color may be gray (as shown at 326B), and the third color may be red (as shown at 326C). In some implementations, different colors, patterns, or textures (e.g., a dotted or reticulated background) may be used alone or in combination within the unitary icon 320 to illustrate the patient's current glucose level.

[0130] The unitary icon 320 can also visually change based on the current determined rate of change of the user's glucose level. For example, the unitary icon may have a rate-of-change indicator 322, which points in different directions when rotating around the periphery of the unitary icon, as illustrated in FIG. 4A. The direction that the indicator 322 points can represent the calculated rate of change of the patient's current glucose level. This rate of change can be based on current and past glucose measurements received from the sensor system 8. In some implementations, the direction that the indicator 322 points can be represented by a numerical degree value. By moving the periphery of the unitary icon 320 clockwise, the indicator 322 can point north (corresponding to an indication direction of 0°) towards the top of the user interface 300, east (corresponding to an indication direction of 90°) towards the right side of the user interface, south (corresponding to an indication direction of 180°) towards the bottom of the user interface, and west (corresponding to an indication direction of 270°) towards the left side of the user interface. It is understood that the foregoing degree values are for illustrative purposes and the indication directions can be from 0° to 359°. For example, the indicator 322 can have an indication direction of 45° when it points in the northeast direction.

[0131] As illustrated at 322A, 322B, and 322C, the indicator 322 can point north or northeast (i.e., have an indication direction of 0° to 90°) when the patient's glucose level is increasing. In these cases, the patient's glucose level can experience a positive rate of change at the current time.

[0132] As illustrated at 322J, the indicator 322 can point east (i.e., have an indication direction of 90°) when the patient's glucose level is stable. In some implementations, the indicator 322 can point west (i.e., have an indication direction of 270°) when the patient's glucose level is stable, or can be omitted entirely from the unitary icon 320.

[0133] Indicator 322 may point south (i.e., having an indicating direction of 180°) or southeast (i.e., having an indicating direction of 90° - 180°) as illustrated at 322E, 322F, 322G, 322H, and 322I when the patient's glucose level is decreasing.

[0134] Indicator 322 may include one or more arrows or triangles indicating how fast the patient's glucose level is increasing or decreasing. For example, indicator 322C may include two arrows indicating that the glucose level is rapidly increasing while pointing north (i.e., having an indicating direction of 0°). In another example, indicators 322F and 322I may include two arrows indicating that the glucose level is rapidly decreasing while pointing south (i.e., having an indicating direction of 180°). The number of arrows in arrow indicator 322 may vary based on the magnitude of the rate of change.

[0135] Data verification module 264 may compare the calculated rate of change with one or more predetermined ranges to determine the direction that indicator 322 points and the number of indicators to display. These predetermined ranges may be automatically set as default values or may be manually set by an administrator or the patient. For purposes of illustration, the following examples explain how data verification module 264 makes these determinations. ● When the rate of change of the current glucose value is between -0.5 and 0.5, indicator 322 may point east or west (i.e., having indicating directions of approximately 90° or 270°, respectively) with one arrow indicating that the rate of change is stable. In some implementations, indicator 322 may be absent. ● When the rate of change of the current glucose value is between 0.6 and 1.5, indicator 322 may point northeast (i.e., having an indicating direction of approximately 0° - 90°) with one arrow indicating that the rate of change is increasing. ● When the rate of change of the current glucose value is between 1.6 and 2.5, indicator 322 may point north (i.e., having an indicating direction of approximately 0°) with one arrow indicating that the rate of change is increasing. ● When the change rate of the current glucose value exceeds 2.5, the indicator 322 may point north (i.e., have an indication direction of about 0°) with two arrows indicating that the change rate is increasing rapidly. ● When the change rate of the current glucose value is between -1.5 and -0.5, the indicator 322 may point southeast (i.e., have an indication direction of about 90° to 180°) with one arrow indicating that the change rate is decreasing. ● When the change rate of the current glucose value is between -1.6 and -2.5, the indicator 322 may point south (i.e., have an indication direction of about 180°) with one arrow indicating that the change rate is decreasing. ● When the change rate of the current glucose value is below -2.5, the indicator 322 may point south (i.e., have an indication direction of about 180°) with two arrows indicating that the change rate is decreasing rapidly.

[0136] The patient or remote monitor may have only a short time to glance at the home screen 310 to check the patient's glucose level. In some situations, the patient may want to check their glucose level unobtrusively without attracting the attention of others. It may be beneficial to have an indicator that is easy to identify the patient's glucose level and clinical risk. In some implementations, the data confirmation module 264 may incorporate different visual elements into the trend graph 330 and the unitary icon 320 to represent the patient's current blood glucose state. These visual elements may include different colors, textures, patterns, etc. Also, through the strategic use of these visual elements, it may be possible for the patient or remote monitor to quickly access the patient's glucose level and determine at a glance whether a medical examination is necessary.

[0137] The use of these visual elements may be incorporated, for example, into the trend graph 330 of FIG. 4A. The graph 330 may include a trend line 336 that shows how the patient's glucose level changes over a given period of time. The current glucose level may be displayed as the rightmost data point on the graph 330. The current glucose level may correspond to the user's current glucose level or the most recently received glucose level. The graph 330 may include one or more horizontal bands, for example, a first band 343, a second band 338, and a third band 341. These bands may be defined by a high threshold and a low threshold, which are illustrated as horizontal lines 334 and 332, respectively. These thresholds may be visually distinguishable from each other. For example, the graph 330 may include an upper threshold 334 of a first color (e.g., yellow) and a lower threshold 332 of a different second color (e.g., red). For example, the upper threshold 334 may be 210 mg / dL of glucose, and the lower threshold 332 may be 85 mg / dL of glucose. However, as further discussed herein, any values may be selected by the user. For illustrative purposes only, glucose levels above the upper threshold 334 (i.e., within the band 343) may be interpreted as high glucose levels, glucose levels below the lower threshold 332 (i.e., within the band 341) may be interpreted as low glucose levels, and glucose levels between the lower threshold 332 and the upper threshold 334 (i.e., within the band 338) may be interpreted as target glucose levels.

[0138] Bands 343, 338, and 341 may represent different ranges of glucose levels. To distinguish the bands from each other, bands 343, 338, and 341 may be visually different. In some embodiments, each band may be shaded with a different color(s). Also, other forms of visual distinction may be used, including the use of different textures or patterns as described above. The use of different visual elements may facilitate quick visual recognition of whether the patient's most recently measured glucose level is high, within target, or low.

[0139] In the implementation of FIG. 4A, for example, if the patient's current glucose level is within the target, bands 343 and 341 may be white or colorless, and band 338 may be gray. When the patient's current glucose level exceeds the high threshold 334, band 343 may change color, such as from white to yellow. When the patient's current glucose level drops below the low threshold 332, band 341 may change color, such as from white to red. Note that in this implementation, the in-target band 338 remains the same color (e.g., gray) whether the current glucose data point is inside or outside the in-target range.

[0140] The use of different visual elements may also be incorporated into the unitary icon 320 in some implementations. Similar to the bands in the trend graph 330, the background color 326 of the unitary icon 320 can correspondingly change depending on whether the patient's current glucose level is high, within the target, or low in the implementation of FIG. 4A. As shown, the background color 326 can match the color of the band into which the current glucose value falls. For example, when the patient's current glucose level is high (i.e., within band 343), the background color 326 of the unitary icon 320 may match the color of band 343. For example, if band 343 is yellow, the background color 326 can also be yellow. In another example, when the patient's current glucose level is within the target (i.e., within band 338), the background color 326 can match the color of band 338 (e.g., gray). In yet another example, when the patient's current glucose level is low (i.e., within band 341), the background color 326 can match the color of band 341 (e.g., red).

[0141] The trend line 336 may include a plurality of glucose value markers or glucose data points. Each data point may correspond to a specific glucose level measured at a specific time. These data points may be represented differently depending on the band in which the data point is included and / or whether the data point is the current data point.

[0142] As an example, data points within a particular band may be the same color as all other data points within that band. That is, all data points within the same band are colored the same, but are colored differently from data points that fall within one or more other bands. For example, data points that fall within band 341 are colored differently from data points that fall within bands 338 and 343. However, data points that fall within band 338 may be colored the same.

[0143] In some implementations, the color of a data point may depend on the band in which the current data point exists. In these implementations, the color of a data point within a particular band may change depending on whether the current data point also falls within the same band. For example, as illustrated during the implementation of screen 337J, data points within band 341 may be of a first color or shade when the data point is in a different band (i.e., band 338). However, if the current data point is also within band 341, the data points in this band may change color or shade from the first color or shade to a second color or shade, as illustrated in the implementation of screens 336G - 336I.

[0144] Data points may change color or shade depending on whether they exist within the same band as the current data point, but this change may occur only in a particular band according to some implementations. For example, this change may occur only for data points having a value below a low threshold 332 (i.e., within band 341), but may not apply to data points within the target (i.e., within band 338), or data points having a value above an upper threshold 334 (i.e., within band 343). This implementation may be beneficial to the user in order to enable the user to differentiate a critical low glucose level from a less risky target or high glucose level.

[0145] In some implementations, the data point corresponding to the current glucose measurement may have a unique visual representation of its own that is different from all other data points on the trend graph 330. For example, data points that exist within the same band as the current data point may have the same color, but the current data point may have a different color and / or may be presented differently. For example, a frame may be drawn around the current data point. In another example, the current data point may be represented using a different shape (e.g., a star) instead of the circular points used for other data points.

[0146] In some implementations, the color of the data point may be selected to provide a visual contrast with the color of the band. This can be a particular problem, for example, when a white data point is located within a yellow band. In these situations, the data confirmation module 264 may, for example, change the color of the data point from white to black when the band changes to yellow, so that the black data point stands out against the yellow band.

[0147] Figure 4A shows different representations 337A, 337B, 337C, 337D, 337E, 337F, 337G, 337H, 337I, and 337J of the home screen 310 over a period of time. The display on the left side of Figure 3A may correspond to the earliest point in time. The display on the right side of Figure 3A may correspond to the most recent point in time (e.g., the current time or the most recent time). The intermediate displays may represent intermediate points in time.

[0148] In displays 337A, 337B, and 337C, the patient's current glucose level is high (i.e., the current data point falls within band 343). The color of band 343 (e.g., yellow) matches the background color 326A of the unitary icon 320. Indicators 322A, 322B, and 322C point north (i.e., having an indication direction of approximately 0°) or northeast (i.e., having an indication direction of approximately 0° to 90°) and represent the forward rate of change in the patient's current glucose level.

[0149] In displays 337D, 337E, and 337F, the patient's current glucose level is within the target (i.e., within zone 338). For this reason, the color of zone 338 (e.g., gray) matches the background color 326B of the unitary icon. The patient's current glucose level is within the target in displays 337D, 337E, and 337F, but the rate of change in each display is different, as indicated by indicators 322D, 322E, and 322F.

[0150] For example, indicator 322D points east (i.e., has an indicated direction of approximately 90°), indicating that there is no significant change in the patient's glucose level over time. Since the patient's current glucose level is within the target and the rate of change is stable, the patient's glucose level remains constant. However, indicators 322E and 322F point southeast (i.e., have an indicated direction of approximately 90° - 180°) and south (i.e., have an indicated direction of 180°), respectively, indicating that the rate of change of the current glucose level is decreasing. The presence of the two downward-pointing triangles in indicator 322F indicates that the rate of change in display 337F is decreasing rapidly (i.e., is large-scale).

[0151] In displays 337G, 337H, and 337I, the patient's current glucose level is low (i.e., within zone 341). For this reason, the color of zone 341 (e.g., red) matches the background color 326C of the unitary icon. As trend lines 336G, 336H, and 336I move from zone 338 to zone 341 (i.e., from the target glucose level to a low glucose level), the indicators point in different directions to show how quickly the patient's glucose level is decreasing. For example, indicators 322G, 322H, and 322I move from pointing southeast (as shown in 322G) (i.e., having an indicated direction of approximately 90° - 180°) to pointing south (as shown in 322H) (i.e., having an indicated direction of approximately 180°). When the patient's glucose level is decreasing rapidly (i.e., has a large-scale rate of change), two arrows are used, as shown in indicator 322I.

[0152] In 337J, the trend line 336J rises within band 341 to band 338 (i.e., from a low glucose level to a target glucose level). When the current glucose level is within the target range (i.e., within band 338), the background color 326D of the unitary icon 320 matches the color of the band (e.g., gray). The indicator 322J points east (i.e., has an indication direction of about 90°), indicating that the rate of change of the patient's glucose level is relatively stable and that the patient's current glucose level is unlikely to change.

[0153] Figure 4B illustrates another display 450 of the user interface 300 including the unitary icon 320 and the trend graph 330. The unitary icon 320 indicates that the currently or most recently received glucose level is 77 mg / dL. This current glucose value may correspond to the data point 437 on the far right of the trend graph 330. The data point 437 may fall below the lower threshold level 332, may be present in band 341, and may correspond to a low glucose value. To indicate that the patient's current or most recent glucose value is low, the data confirmation module 264 may shade the band 341 and the background color of the unitary icon 320 red to indicate that the patient may need attention. Data points above the trend line 332 may be black, and data points 441 and 437 below the trend line 332 may be white. The change in the color of the data points from black to white may provide a stronger visual contrast between the data points and the color of the band. Additionally, this change in color may enable the user to quickly determine how long the patient's glucose value has remained low. In addition to using different colors to distinguish data points in different bands, the data confirmation module 264 may also use different graphics, shapes, sizes, etc.

[0154] The current data point 437 may also be illustrated differently from older data points using different types of data points. By doing so, the user will be able to quickly distinguish the current read value from past read values. The data point 437 may be a circle with a black border and a solid background fill of a color. The color of the solid background fill may be white since the data point 437 is below the threshold 332. Previous or past glucose level read values may be illustrated using filled circles. The color of the circle may be white or black depending on whether the data point is above or below the threshold 332 as described above.

[0155] Events may also be illustrated differently from other data points. In some implementations, the event marker may be placed around the data point that is temporally closest to that event. By quickly identifying events from the trend graph 330, a patient or remote monitor may be able to determine whether the event affected the patient's glucose level. An event may be associated with the data point recorded at the time closest to when the event occurred. In graph 330, data point 439 may be associated with an event. For example, if a patient consumed a beverage or was administered an insulin bolus and this event was recorded using the interface 1610, a box may appear around the data point that is closest to the recorded event. In this implementation, the box has a black border with a white background, although other colors, shapes, patterns, and textures may be used.

[0156] Figures 5A, 5B, 5C, and 5D illustrate another display 350 of the user interface (e.g., 350 in Figure 5A). The display 350 may provide detailed information regarding the history of the patient's glucose level and may correspond to a reflection mode. The data confirmation module 264 may enter the reflection mode when the computing device 18 and / or 19 detects, based on an accelerometer or the like, that it has rotated from a vertical orientation to a horizontal orientation.

[0157] Figures 5A, 5B, 5C, and 5D show various displays of trend graphs when a user interacts with the user interface. Time may be shown on the horizontal axis and glucose level may be illustrated on the vertical axis. These trend graphs may be similar to the trend graphs described above with respect to Figure 4A, but may be extended over different periods (e.g., longer or shorter periods). The implementations of Figures 5A, 5B, 5C, and 5D show glucose levels over a default 12 - hour period. Similar to the trend graphs of Figures 4A and 4B, current or most recent glucose level readout values may be shown on the right side. Data points to the left of the current data point may represent earlier readout values. These trend graphs may include horizontal lines representing the lower and higher thresholds described above.

[0158] When the user touches or selects a data point, a small icon 920 may appear on the data point closest to the location of the user's interaction with the user interface (e.g., the data point closest to the detected position of the user's finger, touch pen, mouse, etc.). The small icon 920 may display a numerical value corresponding to the glucose level at the date and time displayed at the top of the graph. This date and time may be associated with the data point closest to the location of the user's interaction with the user interface. The small icon 920 may have a background color or fill to indicate whether the glucose level at that data point was low, within target, or high, as described above with respect to Figure 4A. As the user traces along the trend graphs illustrated in Figures 5A, 5B, 5C, and 5D with their pointing device (e.g., finger, mouse, touch pen, etc.), the small icon 920 may appear at each data point. The small icon 920 in Figures 5A, 5B, 5C, and 5D does not include a rate - of - change indicator, but in some implementations, this indicator may be included in the small icon to represent the rate of change at that point in time.

[0159] Figures 6A, 6B, and 6C illustrate a further display 351 of a user interface in a reflection mode when a user interacts with event information displayed on the user interface. The data confirmation module 264 may generate the display 351 when the computing device 18 and / or 19 detects that it has rotated to a horizontal position. This detection may be based, for example, on input from an accelerometer within the computing device 18 and / or 19. The trend graphs in these displays may include data points associated with events 939A, 939B, and 939C. The data points associated with the events may be illustrated differently from other data points as described above. In the implementation of FIGS. 6A, 6B, and 6C, the data points 939A, 939B, and 939C may be illustrated as white boxes, and the non-event data points may be illustrated as black circles. Data points of different colors, shapes, patterns, textures, sizes, etc. may be used to distinguish the data points associated with the events from other data points. When a data point 939A, 939B, or 939C is selected, icons 940A, 940B, or 940C may appear. These icons may indicate the type of activity associated with the event (e.g., calibration event, food consumption, etc.). For example, further information about these activities or events, including the time of the event, any corresponding quantity (e.g., calories consumed), etc., may be displayed by selecting the icons 940A, 940B, and 940C.

[0160] Figures 7A, 7B, 7C, 7D, and 7E illustrate further displays 352 of the user interface in the reflection mode. The data confirmation module 264 can generate the display 352 when the computing device 18 and / or 19 rotates from the vertical direction to the horizontal direction or is held in the horizontal direction. The display 352 may include trend graphs covering different periods. For example, in the displays 350 and 351 of FIGS. 5A-5D and 6A-6C respectively, the trend graph displays glucose level data over 12 hours. If the user desires to view more data (e.g., data over 24 hours) or less data (e.g., data over 3 hours) on the warning graph, the user may change the amount of data displayed using the display 352. In the display 352, one or more selectable time frame icons (1 hour, 3 hours, 6 hours, 12 hours, and 24 hours) may be shown at the top of the display. The user can select the desired time frame icon to indicate the amount of data the user desires to view. These time frame icons may appear when the user is not interacting with the screen (e.g., the computing devices 18 and / or 19 do not detect any user input including the presence of a touch or selection). Also, other actions such as waving may be used to increase or decrease the time frame (e.g., swiping, pinching, and stretching the display on devices 18 and / or 19). These time specifications are merely illustrative and other increments may be used. The current time may be displayed on the right side of each trend graph. As the period increases, more data points may be displayed and the trend line may resemble a continuous line. As the period decreases, fewer data points may be displayed and since the data points are generated at regular intervals such as every 5 minutes, the individual data points may become more recognizable. Enabling the user to adjust the time scale and the resulting amount of data displayed can assist the user in detecting the trend of the patient's glucose level.

[0161] The application 255 running on the portable computing device 18 and / or 19 may provide a snapshot of the patient's current and previous glucose levels. In some implementations, the application may also indicate whether the patient is at risk of becoming hypoglycemic or hyperglycemic in the near future. Providing risk information can be beneficial for some users (i.e., patients and / or remote monitors) who focus only on the current glucose value and do not think much about whether the value is dropping or rising to dangerous levels. This clinical risk can be based on the patient's current or recent glucose level and rate of change. By way of illustration, the application may use the following guidelines to assess the patient's risk level. ● The patient's current glucose level is high and the rate of change is increasing = High clinical risk to the patient ● The patient's current glucose level is low and the rate of change is decreasing = High clinical risk to the patient ● The patient's current glucose level is low and the rate of change is stable (i.e., not changing) = High clinical risk to the patient ● The patient's current glucose level is high and the rate of change is stable (i.e., not changing) = High clinical risk to the patient ● The patient's current glucose level is high and the rate of change is decreasing = Low clinical risk to the patient ● The patient's current glucose level is low and the rate of change is increasing = Low clinical risk to the patient ● The patient's current glucose level is within the target range and the rate of change is stable (e.g., not changing or a relatively low rate of change) = Low clinical risk to the patient

[0162] Figures 8A, 8B, 8C, and 8D illustrate various mechanisms for communicating the patient's clinical risk level to the patient or a remote monitor. These mechanisms can be used separately or in combination to indicate high clinical risk, low clinical risk, or both.

[0163] Figures 8A and 8B illustrate an implementation for warning a user in a clinically dangerous state by applying a color scheme to a display on a portable computing device. The portable computing device in these drawings may be running multiple applications. In this implementation, the glucose monitoring application may run (i.e., be stopped) in the background while the user is operating a different application in the foreground. When the application determines that the patient may enter a clinically dangerous state as described above, the application may apply a color scheme to shade the display in a specific color. The color selected may be based on, for example, whether the patient is determined to be at risk of hypoglycemia or hyperglycemia, whether the clinical risk is low or high, etc. In some implementations, one or more of these parameters may be combined to determine the color scheme. In the implementation of Figure 8A, the application may apply a red color scheme 1710 to indicate that the patient may be at risk of hypoglycemia. In the implementation of Figure 8B, the application may apply a yellow color scheme 1720 to indicate that the patient may be at risk of hyperglycemia. In some implementations, application 255 may apply a red color scheme 1710 for high-risk situations, a yellow color scheme 1720 for moderate-risk situations, and no shading or gray shading for relatively low-risk situations. The shading on the screen may subtly prompt the patient or a remote monitor to take action to increase or decrease the patient's glucose level as needed.

[0164] FIG. 8C illustrates an implementation for communicating a clinically dangerous condition to a user in an unobtrusive manner by changing the background color 1826 of the unitary icon 1820. In the implementation of FIG. 8C, the unitary icon 1820 has a background of a color gradient. This gradient includes a plurality of colors arranged in various patterns to represent the clinical risk of the patient. By using a color gradient to illustrate the clinical risk of the patient, the patient can quickly ascertain whether corrective action is needed. For example, if the patient's current blood glucose state is low but rising towards a target value, the clinical risk to the patient may be low. Instead of filling and displaying the unitary icon in red based on the patient's current blood glucose state, a color gradient, for example, a gradient from red to gray, can be used to represent the expected change in the patient's blood glucose state. In this example, the gradient from red to gray enables the user to quickly understand that this own low glucose level is rising.

[0165] In the implementation of FIG. 8C, the patient's current blood glucose status can be visually represented below the lower left of the unitary icon 1820, and the patient's estimated blood glucose status can be visually represented above the upper right of the unitary icon. Other variations are possible, such as, for example, illustrating the current blood glucose status below or to the left of the unitary icon 1820 and the estimated blood glucose status above or to the right of the unitary icon. Here, the patient's current glucose level is 65 mg / dL, which is determined to be low. For this reason, the lower left of the unitary icon is shaded red. Since the indicator 1822 points northeast (i.e., a forward rate of change), the patient's glucose level tends to increase at a constant rate of change. For this reason, even if the patient's current glucose level is currently low, due to the forward rate of change, it is expected that the patient's current glucose level will increase, so the patient's clinical risk can be considered low. To indicate a low clinical risk of the patient's estimated blood glucose status, the upper right of the unitary icon is shaded gray. In contrast, as an example, if the rate of change is decreasing, the background color 1826 may be completely red without any gray coloring to indicate that the patient's current blood glucose status (low) continues to decline and the patient may enter a state of high clinical risk.

[0166] In some implementations, the application may change the appearance of the indicator 1822 to indicate a clinically dangerous situation. For example, the application may enlarge the indicator 1822, blink or flash the indicator, and / or change its color according to the determined level of the patient's clinical risk. In one implementation, the indicator 1822 may blink and / or be a first color when it is determined that the user is in a high-risk clinical situation, and may not blink and / or be a different second color when it is determined that the user is in a low-risk clinical situation.

[0167] FIG. 8D illustrates another mechanism for visualizing a patient's clinical risk state using application 255. Display 1910 may include two icons 1912 and 1922. Icon 1912 displays the patient's current glucose level 1914 and has a background color 1916. The background color 1916 indicates the patient's current glucose level, such as whether the current glucose level is low, within target, or high. Icon 1922 represents the patient's estimated glucose level 1924 and has a background color 1926. The background color 1926 indicates whether the estimated glucose level is predicted to be low, within target, or high. An estimated line 1918 connects the unitary icon 1912 and the unitary icon 1922. A time indicator 1920 is displayed adjacent to the estimated line 1918 to indicate when the estimated glucose level is expected to occur. In the implementation of FIG. 8D, the unitary icons 1912 and 1922 do not have indicators for representing the rate of change. Omitting these indicators may be beneficial as it thereby reduces the amount of information presented to the user. However, in some implementations, these indicators may be added to the unitary icons 1912 and 1922.

[0168] The glucose monitoring application may supplement the visualization described above with text messages to indicate clinical risk. These messages may include activities proposed to mitigate the risk. For example, when the user is at risk of hypoglycemia, the message may prompt the patient to administer insulin, consume glucose or food, request a medical examination, etc.

[0169] The application 225 running on the portable computing device 18 and / or 19 may be configured to issue warnings using the warning module 275. The warnings may, for example, notify the user of glucose levels that exceed or fall below certain predetermined thresholds. The generation of these warnings may prompt the patient or remote monitor to take corrective action to prevent harm to the patient. Different types of warnings may be generated, including, for example, auditory warnings, visual warnings, tactile warnings, message warnings (e.g., sending an email to the patient or remote monitor), and combinations thereof.

[0170] The warning module 275 may generate different warnings using the process 9000 illustrated in FIG. 9A. At 9010, the warning module 275 may receive glucose level data from the sensor system 8. At 9020, the warning module 275 may compare the received glucose level data with various predetermined thresholds, such as a threshold for glucose values and / or a threshold for the rate of change. For example, if a low glucose level warning is set in the warning module 275, the warning module may compare the received glucose level with the corresponding threshold for this warning. Based on this comparison, the warning module 275 may generate a warning at 9030 on the device 18 and / or 19. For example, the warning module 275 may generate a warning if the received glucose level is below the threshold. The following paragraphs describe different types of warnings maintained by the warning module 275.

[0171] FIG. 9B illustrates a user interface 910 for managing user warnings. These warnings may include glucose level warnings such as an emergency low warning 912, a low warning 914, a high warning 916, a rising rate warning 918, and a falling rate warning 930. The glucose level warning module 276 may manage these glucose level warnings. The user interface 910 may also include warnings related to communication failures, such as a no data warning 932. The communication failure warning module 277 may manage the no data warning 932.

[0172] The warning menu 910 can indicate whether these warnings are active or inactive. For example, the rate-of-rise warning 918 may be deactivated, as indicated by the word "Off" in the warning menu 910. In another example, the critically low warning 912 may be activated, as indicated by an adjacent green label. This green label may display a number or threshold indicating when the alarm may be triggered. In the implementation of FIG. 9B, the critically low warning 912 may be triggered when the glucose level drops below 55 mg / dL. The user may reset all warning settings to their default values by selecting item 934. When this is done, a user interface 936 appears, asking the user to confirm the reset request. However, if the user wishes to adjust the settings of a particular warning, the user may do so by selecting the appropriate warning. Each of these warnings is described below with respect to FIGS. 10A, 10B, 11, 12, 13, 14, and 15.

[0173] Figures 10A and 10B illustrate various user interfaces for adjusting settings related to low alerts. User interface 1000 may appear when low alert 914 is selected from alert menu 910. The user may enable or disable the low alert by adjusting slider 1010. The user may obtain information about the low alert by selecting the question mark icon 1005. Then, user interface 1025 may be displayed. User interface 1025 may be a help screen that provides an explanation of the low alert. The low alert may be generated or triggered when the patient's glucose level drops below a specific threshold. User interface 1000 may also display various settings related to the low alert. These settings may include the threshold or trigger 1013 for the alert, the frequency 1016 at which the alert should be repeated, and the sound 1019 for the alert. User interface 1000 may display the current values for settings 1013, 1016, and 1019. The user may change these values by selecting the desired settings.

[0174] For example, if the user selects item 1013 to change the threshold, user interface 1050 may be displayed. If the user selects item 1016 to change the repeat setting for the alert, user interface 1055 may be displayed. Similarly, if the user selects item 1019 to change the sound associated with the alert, user interface 1060 may be displayed. The user may select one sound from a predetermined list of sounds. By specifying different sounds for different alerts, the user may be able to distinguish between the alerts. The user may use the scroll key pads on interfaces 1050, 1055, and 1060 to select the desired values for settings 1013, 1016, and 1019, respectively.

[0175] Figure 11 illustrates user interfaces 1100 and 1125 associated with a low urgency warning. User interface 1100 may appear when a low urgency warning 912 is selected from warning menu 910. The user may obtain information about the low urgency warning by selecting question mark icon 1105. When so doing, user interface 1125 may be displayed. User interface 1125 may be a help screen that provides an explanation of the low urgency warning. The low urgency warning may be generated or triggered when the patient's glucose level drops below a predetermined threshold. In some implementations, this predetermined threshold may not be adjustable and this warning may not be disabled. User interface 1100 may also display various settings associated with the low urgency warning. These settings may include a threshold or trigger 1113 for the warning, a frequency 1116 at which the warning should be repeated, and a sound 1119 for the warning. The values associated with settings 1113, 1116, and 1119 may be adjusted using an interface similar to that illustrated in Figure 10B.

[0176] Figure 12 illustrates user interfaces 1200 and 1225 associated with high alerts. User interface 1200 may appear when high alert 916 is selected from alert menu 910. The user may enable or disable the high alert by adjusting slider 1210. The user may obtain information about the high alert by selecting the question mark icon 1205. Then, user interface 1225 may be displayed. User interface 1225 may be a help screen that provides an explanation of the high alert. The high alert may be generated or triggered when the patient's glucose level reading increases above a certain threshold. User interface 1200 may also display various settings associated with the high alert. These settings may include the threshold or trigger 1213 for the alert, the frequency 1216 at which the alert should be repeated, and the sound 1219 for the alert. The values associated with settings 1213, 1216, and 1219 may be adjusted using an interface similar to that illustrated in Figure 10B.

[0177] Figure 13 illustrates user interfaces 1300 and 1325 associated with rate-of-rise alerts. User interface 1300 may appear when rate-of-rise alert 918 is selected from alert menu 910. The user may enable or disable the rate-of-rise alert by adjusting slider 1310. The user may obtain information about the rate-of-rise alert by selecting the question mark icon 1305. Then, user interface 1325 may be displayed. User interface 1325 may be a help screen that provides an explanation of the rate-of-rise alert. The rate-of-rise alert may be generated or triggered when the patient's glucose level is rising too quickly relative to a certain threshold. User interface 1300 may also display various settings associated with the rate-of-rise alert. These settings may include the threshold or trigger 1313 for the alert, the frequency 1316 at which the alert should be repeated, and the sound 1319 for the alert. The values associated with settings 1313, 1316, and 1319 may be adjusted using an interface similar to that illustrated in Figure 10B.

[0178] Figure 14 illustrates user interfaces 1400 and 1425 related to the rate-of-descent warning. User interface 1400 may appear when the rate-of-descent warning 930 is selected from the warning menu 910. The user may enable or disable the rate-of-descent warning by adjusting the slider 1410. The user may obtain information about the rate-of-descent warning by selecting the question mark icon 1405. Then, user interface 1425 may be displayed. User interface 1425 may be a help screen that provides an explanation of the rate-of-descent warning. The rate-of-descent warning may be generated or triggered when the patient's glucose level is dropping too quickly relative to a specific threshold. User interface 1400 may also display various settings related to the rate-of-descent warning. These settings may include the threshold or trigger 1413 for the warning, the frequency 1416 at which the warning should be repeated, and the sound 1419 for the warning. The values associated with settings 1413, 1416, and 1419 may be adjusted using an interface similar to that illustrated in Figure 10B.

[0179] Figure 15 illustrates user interfaces 1500 and 1525 related to the no-data warning. User interface 1500 may be a help screen that provides an explanation of the no-data warning. The communication failure warning module 277 may generate a no-data warning when the application stops receiving glucose readings from the sensor system 8 after a predetermined period of time. The user may adjust the value of this predetermined time using the scroll keypad of user interface 1525.

[0180] The warning module 275 may generate warnings to advise the user that certain threshold conditions or levels have been met. The application may be a multi-purpose device that may involve different operating platforms (i.e., not a dedicated glucose monitoring device) and may run on different portable computing devices 18 and 19. Therefore, these warnings may be adjusted to operate within the constraints of each computing device. For example, the ringtone or warning volume in the settings of a smartphone may determine the volume of the warning. For example, if the mute switch is enabled on the phone, the application 255 may not be able to generate an audible warning. In another example, the user may set various notification settings on their phone. These settings may affect the manner in which the warnings are displayed. Various factors may affect this process, such as whether the phone is locked or unlocked, whether the application is currently in use or idling in the background, etc. The phone may be in a locked state, for example, when the user cannot interact with the applications running on the phone. While in the locked state, the user may enter a passcode to unlock the phone. When the phone is in the unlocked state, the user may be able to interact with the applications running on the phone. The following implementations disclose various solutions to these design constraints.

[0181] Figures 16A, 16B, and 16C illustrate a mechanism for warning the user when the user's portable computing devices 18 and / or 19 are locked. The implementations of Figures 16A, 16B, and 16C are described with respect to a rate-of-rise warning, but this implementation may be applicable to any of the warnings considered in this specification.

[0182] FIG. 16A illustrates an interface 1510 that displays a rate-of-rise warning 1512 on a locked screen. The glucose level warning module 276 can generate a warning 1512 when the user enables the warning and a threshold level is reached as described above with respect to process 9000 of FIG. 9A. The warning 1512 may include text indicating the type of warning generated or triggered, an icon or graphic display of the warning, etc. In the implementation of FIG. 16A, the warning does not display any numerical values associated with the warning (e.g., how fast the patient's glucose level is rising and for how long it has exceeded the threshold level). By omitting this information, the user may be able to view their warnings unobtrusively in a public place without drawing excessive attention to themselves. Also, by omitting this information, it may prevent the presentation of stale data and encourage the user to launch the application to obtain more detailed information. For example, if warning 1512 displays the patient's current blood glucose status on device 18 and the device loses connectivity with sensor system 8, the patient may think their current blood glucose status is stable, but in fact application 255 is unable to update this value. This situation can be particularly dangerous, for example, when warning 1512 provides a numerical value indicating that the patient's current blood glucose level is within target, but is actually dropping below the lower threshold 332 because the patient's phone 18 has lost connectivity with sensor system 8. Whether these numerical values and / or representations of the rate of change are displayed may be configurable by the user using warning module 275 and / or glucose level warning module 276 in some implementations.

[0183] Warning 1512 may display instructions for viewing further information regarding the warning. In this implementation, the warning may issue an instruction to the user to "slide to view". The glucose warning module 276 may display user interface 1514 of FIG. 16B after the user follows these instructions.

[0184] The user interface 1514 may provide details regarding the nature of the warning. The details displayed may depend on the warning generated. For example, if the warning relates to the state of the system, the warning may provide information regarding the state of the warning. For example, if a no data warning 932 is generated, the user interface 1514 may display the period since the application 255 last received glucose level data from the sensor system 8. In another example, if a calibration measurement is required, the user interface 1514 may display a message in characters indicating the same.

[0185] If the warning relates to the patient's glucose level, the user interface 1514 may display, for example, the patient's current glucose level, the threshold associated with the warning, etc. The user interface 1514 may identify the type of warning 1516 and display a unitary icon 1520 for the glucose level warning. The unitary icon may display the patient's current glucose level 1524. The background color 1526 may indicate that this glucose level is within the target. However, since the indicator 1522 has two arrow indicators, the rate of change of this glucose level is increasing rapidly. Under these circumstances, if no action is taken, the patient may develop hyperglycemia. The user interface 1514 may prompt the user to acknowledge this warning by selecting item 1541. If the user does not acknowledge the warning, the application may continue to re - warn until an acknowledgement is received or the conditions that triggered the warning are no longer met. The application may re - warn at a predetermined interval (e.g., every 5 minutes) until the user acknowledges the warning. Continuing to re - warn may help ensure that the user sees the warning, especially if the application 255 is idling in the background.

[0186] When the user becomes aware of the warning, the glucose warning module 276 may start or launch the application to display a user interface 1540 illustrated in FIG. 16C. The user interface 1540 may be a home screen and may provide detailed information regarding the patient's glucose level. Similar to the user interface 1514, this interface may include unitary icons 1520 and indicators 1522. Additionally, this interface may also display a trend graph 1530 of the patient's glucose level.

[0187] The implementations of FIGS. 16A, 16B, and 16C may vary according to the state of the portable computing device and / or the state of the application. For example, if the portable computing device is unlocked and the application is active (i.e., currently in use), the warning may be displayed as a notification within the application. However, if the portable computing device is unlocked and the application is idling in the background, the warning may be displayed as a banner. These banners may temporarily appear anywhere within the display screen of the computing device (e.g., near the top) and disappear after a predetermined period (e.g., 5 seconds). When the user slides his finger over the banner warning, the warning module 264 may display, for example, the user interface 1514 of FIG. 16B. If the mute switch on the device is enabled, the application may generate various non-auditory warnings, including, for example, vibration warnings or visualizations. Examples of visualizations include, as described above with respect to FIGS. 8A and 8B, a blinking screen, a shaded screen, etc. If the warning is not generated to be audible on the patient's portable computing device, a device such as the receiver 16 of FIG. 1 may generate these warnings. The application may regenerate these notifications, banners, vibration warnings, and visualizations until the warning is acknowledged or the conditions that triggered the warning are no longer met. The notification center on the portable computing device may maintain a record of these warnings. This record may identify, for example, the type of warning, when the warning was triggered, the number of times it was regenerated, etc. The notification center may remove the warning after it has been acknowledged. The user may view old warnings from the history display within the application.

[0188] In some implementations, the warning settings may be modified based on the time of day. For example, if a patient is sleeping at night between 10 PM and 6 AM, the likelihood that the user is conscious of their blood glucose status and / or able to hear or respond to a warning may be low. To account for the patient's reduced awareness and responsiveness during these times, the application may enter a night mode by tightening the glucose threshold levels for various warnings. By adjusting these threshold levels, it may be possible to account for the reduced responsiveness in the patient when they are likely to be sleeping. These adjustments may thus enable the patient or remote monitor to have more time to take corrective action before the patient suffers serious harm.

[0189] For example, if a low warning is normally triggered when the patient's glucose level drops below 60 mg / dL, the threshold for night mode may be 80 mg / dL. Increasing the threshold level for the low warning may enable the application to generate this warning earlier or more frequently. In another example, if a high warning is normally triggered when the patient's glucose level rises above 180 mg / dL, the threshold for night mode may be 190 mg / dL so as not to disturb the patient's sleep. Increasing the threshold level for the high warning may enable the application to generate this warning less frequently. FIG. 17 illustrates a user interface 1850 that explains night mode operation. The user may specify the times for night mode and select which warnings are subject to night mode adjustment. When night mode is disabled, the warnings may be active throughout the day. In some implementations, since hypoglycemic conditions are more dangerous than hyperglycemic conditions, only the low warnings may be active during night mode operation and the high warnings may be disabled.

[0190] In implementations where an insulin pump is attached to a patient, the insulin pump may have a different insulin delivery profile during nighttime mode. In some implementations, the warnings for nighttime mode may have a different warning sound, volume, and repetition frequency than the warnings for non-nighttime mode. For example, the application may use a loud, unpleasant sound for the alarm to wake the user during nighttime mode.

[0191] As described above, the state of the user's portable computing device can affect warning generation. For example, if the portable computing device is in a silent mode, the user may not be able to hear an audible warning. This can be a problem, for example, if the user accidentally silences their portable computing device. FIG. 18 illustrates a process 1907 for issuing an alarm when the computing device 18 is silenced or unable to generate an audible warning.

[0192] At 1910, the silent mode warning module 278 may determine whether the silent mode on the computing device 18 has been enabled or whether audible warnings from the application 255 are suppressed. In that case, the silent mode warning module 278 may perform one or more of processes 1920, 1930, and 1940. These processes may be performed sequentially or substantially simultaneously.

[0193] In 1920, the silent mode warning module 278 may notify the user that the silent mode has been enabled on the computing device 18. In some implementations, the silent mode warning module 278 may display the graphical user interface 1905 illustrated in FIG. 19 to inform the user of the drawbacks of silencing their computing device. The user interface 1905 may indicate that no sound is being played. The silent mode warning module 278 may display the user interface 1905 when the user uses the warning menu 910 to set a warning, or when the application detects that the computing device is in a silenced state. The silent mode warning module 278 may further generate a vibratory warning to draw the user's attention. To close the user interface 1905 and stop these vibrations, the user may need to acknowledge the message. In some implementations, the silent mode warning module 278 may send a text message or an email message to the user indicating that the computing device has been silenced. Additionally or alternatively, the silent mode warning module 278 may cause the computing device to send a message regarding the silenced device of the patient to a server such as server 230. The server may thus communicate with various remote monitors 19, such as family members, attending physicians, etc.

[0194] In addition to communicating to the remote monitor that the patient's device is muted, the Mute Mode Warning Module 278 may also communicate to the remote monitor that a warning has been triggered at the patient's computing device and that the mute mode has been enabled at the patient's computing device. For example, if the patient's low warning threshold level is met, the Mute Mode Warning Module 278 may send a message indicating the same to the server 230. The server 230 may in turn relay the message to the remote monitor. These messages may be sent as text messages, calls, emails, audible sounds, etc. at the remote monitor's device 19. To reduce excessive warnings, the server 230 may relay these warnings if the patient fails to acknowledge the warnings on their computing device 18.

[0195] In 1930, the Mute Mode Warning Module 278 may cooperate with other components in the system to generate a warning when the patient's computing device 18 is muted. For example, the Mute Mode Warning Module 278 on the patient's computing device 18 may cause the receiver 16 to display a warning if the patient fails to acknowledge the warning after a predetermined time (e.g., 15 minutes). Under these circumstances, the receiver 16 may serve as the first warning device. When this occurs, the receiver 16 may generate local audible and visual alarms and send a message regarding the same to the patient's remote monitor. In some implementations, the receiver 16 may cooperate with the sensor system 8 to issue these local alarms and messages. For example, if the sensor system 8 detects that the patient's computing device is muted and that the user has not acknowledged any warnings, the sensor system may trigger a warning on the receiver 16.

[0196] The importance of warnings can also be modified in 1940 in how the system responds. As described above, when the silence switch first engages on the patient's computing device 18, an attention alert can be visually presented. If the patient fails to recognize this attention and the patient progresses to a low / high risk state or becomes hypoglycemic / hyperglycemic for a predetermined period, the system (e.g., the silence mode warning module 278 on the patient's computing device, the receiver, and / or the remote monitor that receives messages through the server) may automatically alert medical personnel such as emergency medical staff. In some implementations, the silence mode warning module 278 may also tighten the warning threshold level when the patient's computing device is silenced. This tightening of the threshold level may be similar to the tightening of the threshold level described above for night mode operation. By tightening the threshold level, warnings may be triggered earlier and / or more frequently, and as a result, the time for the patient to respond may be extended. The above adjustments can be initiated during different times of the day. For example, since the effects of hypoglycemia tend not to be felt while the patient is sleeping, the option to contact medical personnel may only be enabled at night.

[0197] The initiation of the silence switch on the patient's computing device 18 can also trigger modifications to other processes in 1940, such as insulin dosing. These adjustments can be useful in implementations where the patient's computing device is communicating with an insulin pump. For example, if the silence mode warning module 278 detects that the silence switch is active, the application may interrupt the activity of the insulin pump.

[0198] Process 1907 may be applicable to any situation where an audible warning may not be heard on the patient's computing device 18. Thus, process 1907 is not limited to scenarios where the patient's computing device 18 is muted. Process 1907 may also be applicable when headphones or earphones are plugged into the patient's computing device 18, when another application running on the device suppresses sound from other applications, and so on.

[0199] The warning module 275 may check for warning conditions as long as the application 255 is running. However, in some situations, the application 255 may cease execution or functionality. This may occur, for example, when the patient's computing device 18 terminates the application 255 due to competing resources, when the power of the computing device 18 is turned off, when the user accidentally or intentionally terminates the application 255, when the application 255 and the computing device 18 lack sufficient connectivity to receive glucose data from the receiver 16 or issue a warning, and so on. Process 2007, as illustrated in FIG. 20, describes various mechanisms for warning the user that the application 255 has ceased execution.

[0200] In 2010, the communication failure warning module 277 may determine whether the application 255 is running. If the application 255 has ceased execution or functionality for any of the above reasons, the communication failure warning module 277 and / or the computing device 18 may perform one or more of processes 2020, 2030, 2040, and 2050. These processes may be performed sequentially or substantially simultaneously.

[0201] In 2020, the communication failure warning module 277 can notify the user on the patient's computing device 18 that the application 255 has stopped running by using locally available functions, such as a local calendar application or an alarm function. In these implementations, the communication failure warning module 277 can be scheduled to trigger an alarm at a predetermined time, for example, 30 minutes from the current time. The communication failure warning module 277 can continuously push out this alarm at fixed time intervals (for example, every 15 minutes) to reschedule the alarm. However, the communication failure warning module 277 may not be able to reschedule the alarm if the application 255 is terminated. When this occurs, a local alarm is ultimately triggered and can sound. The computing device 18 may display a notification indicating that the application 255 no longer operates in association with the local alarm.

[0202] In some situations, the application 255 may have a scheduled downtime. This can occur, for example, during software updates or routine maintenance. In 2030, the communication failure warning module 277 can issue a notification on the computing device 18 and / or 19 indicating that the termination of the application 255 is scheduled. This notification can prompt the patient and the patient's remote monitoring to ensure that other warning devices are available to generate a warning during this downtime.

[0203] In some situations, the computing device 18 can cause the application 255 to stop running. These events can require the user to restart the computing device 18 so that the application 255 can stop. These events can be, for example, an operating system update, etc. If the glucose monitoring application recognizes these scheduled restarts, the communication failure warning module 277 can notify the user in advance that the application 255 will stop functioning.

[0204] In 2040, the computing device 18 may receive from the server a notification that the application 255 is not operating. The server may predict notifications from the application 255 at predetermined intervals (e.g., every 5 minutes). If the server does not receive the predicted communication from the application 255, it may send a notification such as an email or a text message to the computing device 18 and / or 19 to indicate that the application 255 is not operating. Upon receiving this notification, the computing device 18 and / or 19 may notify the communication failure warning module 277 of this and may restart the application 255.

[0205] In 2050, the computing device 18 may perform a Bluetooth (registered trademark) restoration process when the application 255 stops execution. The terminated application 255 may be deactivated by a signal from the sensor system 8. As described above with respect to FIG. 2A, the sensor system 8 may be connected to the computing device 18 via an intermittent wireless connection such as a Bluetooth (registered trademark) connection. Each time the sensor system 8 initiates communication with the portable computing device 18, the sensor system may send a message to the computing device to deactivate the stop state of the glucose monitoring application 255. Upon receiving this message, the computing device 18 may start the application 255. In some implementations, the computing device 18 may notify the communication failure warning module 277 of this so that the module may restart the application 255.

[0206] In some implementations, the application may determine whether computing device 18 will be powered off due to insufficient power and warn the user of this. The application may make these determinations at a predetermined time. For example, if the night mode operation starts at 10 PM, the application may determine whether computing device 18 has enough power to last until the end of the night mode and may warn the user before going to bed (i.e., just before the application enters the night mode operation). If the power is insufficient, the application may display a notification prompting the user to charge their computing device 18.

[0207] In some implementations, the application may provide help to the user within the application. The application may detect, for example, whether the user needs assistance when the user has spent a long time on a particular screen, is navigating between screens, has missed a warning, etc. When this behavior is detected, the application may display a pop-up message to guide the user about the application and / or to inform the user how the system works.

[0208] As an illustration, in some implementations, application 255 may detect a user's interaction with the application that indicates the user is having difficulty understanding how to pair the device with a continuous glucose monitoring system. User interactions indicative of such difficulty may occur, for example, when the user stays on a particular screen for longer than a predetermined time, when the user navigates between some predetermined screens, when a combination of both occurs, etc. Application 255 may automatically generate a pop-up help message regarding the detected behavior. Continuing with the above example, the pop-up may provide instructions regarding device pairing.

[0209] The in-application help may also include a user help function that tells the user how the warnings work. In one implementation, the application 255 may detect whether the user has recognized a warning using a predetermined criterion, such as user awareness of the warning within a predetermined time. If the user does not recognize the warning within the predetermined time, when the user next interacts with the application 255, the application may display a pop-up message indicating that the user did not recognize the previous warning. The pop-up message may also provide textual guidance to the user on why the user did not recognize the warning and how the user may configure the warning so that the user is more likely to hear it the next time it is triggered. For example, when a low warning is triggered and the mute switch is enabled, and the user fails to recognize the warning within the predetermined time, the application 255 may display a pop-up message notifying the user that the user did not recognize the low warning and that the user should disable the mute switch so that the warning will be heard the next time it is triggered.

[0210] In addition, the application 255 may record the time it takes for the user to recognize each triggered warning. This record may be used later to modify the user's warning settings to increase the likelihood that the user will receive warnings in a timely manner. This modification may be done automatically by the application or the application may propose the modification to the user, for example, via a pop-up message, and the user may approve or reject the modification. Upon approval of the modification, the warning settings are automatically modified in the application as proposed by the application.

[0211] Various implementations of the subject matter described herein may be realized in digital electronic circuitry, integrated circuitry, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. The circuitry may be mounted on a printed circuit board (PCB) or the like and may take various forms, as described. These various implementations may be special purpose or general purpose and may include at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a memory system, at least one input device, and at least one output device. Implementations may be included in one or more computer programs executable and / or interpretable on a programmable system including the at least one programmable processor.

[0212] These computer programs (also known as programs, software, software applications, or code) include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages, and / or in assembly / machine language. As used herein, the term "machine-readable medium" refers to any non-transitory computer program product, apparatus, and / or device (e.g., magnetic disks, optical disks, memory, programmable logic devices (PLDs)) used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions.

[0213] To provide interaction with a user, the subject matter disclosed herein may be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user, as well as a keyboard and a pointing device (e.g., a mouse or trackball) by which the user may provide input to the computer. Similarly, other kinds of devices may be used to provide interaction with the user. For example, the feedback provided to the user may be in any form of sensory feedback (e.g., visual feedback, audible feedback, or tactile feedback), and the input received from the user may be in any form including acoustic, voice, or tactile input.

[0214] The subject matter described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., a client computer having a graphical user interface or a web browser by which a user may interact with an implementation of the subject matter described herein), or in any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), and the Internet.

[0215] Although several variations have been described above, other modifications are possible. For example, the description of a particular implementation of the present subject matter considers analytical applications, but the present subject matter is equally applicable to other types of software and data service access. Further, the above description refers to specific products, but other products may equally be used. Additionally, the logical flow shown in the accompanying drawings and described herein need not be the particular order or sequence shown to achieve desirable results. Other implementations may be within the scope of the following claims.

[0216] The above description presents the best mode contemplated for carrying out the invention, as well as the best mode of making and using it, in terms that are complete, clear, concise, and accurate so that any person skilled in the art to which the invention pertains can make and use the invention. However, the invention is subject to modifications and alternative constructions that are fully equivalent to those considered above. Accordingly, the invention is not limited to the specific embodiments disclosed. Rather, the invention encompasses all modifications and alternative constructions that fall within the spirit and scope of the invention as generally represented by the following claims that specifically point out and distinctly claim the subject matter of the invention. The present disclosure has been illustrated and described in detail in the drawings and foregoing description, but such illustration and description are illustrative or exemplary and are not to be construed as limiting.

[0217] All references cited herein are hereby incorporated by reference in their entirety. To the extent that the publications and patents or patent applications incorporated by reference conflict with the present disclosure contained herein, the present specification is intended to supersede and / or precede any such conflicting elements.

[0218] Unless otherwise defined, all terms (including technical and scientific terms) shall have the meaning that is ordinary and customary to those of ordinary skill in the art and shall not be limited to a special or customized meaning unless explicitly defined herein. It should be noted that the use of a particular term in describing a particular feature or aspect of the present disclosure is not to be construed as implying that the term is redefined herein to include any specific characteristics of the feature or aspect of the present disclosure to which the term is related. The terms and phrases used in this application, as well as variations thereof, should be construed as having no limiting constraints as opposed to limitations, unless otherwise explicitly stated, especially in the appended claims.As an example of the foregoing, the term "including" means "including without limitation", "including but not limited to", etc., and the term "comprising", as used herein, is synonymous with "including", "containing", or "characterized by", is inclusive or open-ended and does not exclude additional, unrecited elements or method steps. The term "has" should be construed to mean "at least has", the term "include" should be construed to mean "include but not limited to", the term "example" is used to provide an illustrative example of the item being discussed and is not intended to be complete or to limit the list thereof. Adjectives such as "known", "conventional", "standard", etc. and terms of similar import should not be construed as limiting the item described to items available at a given time or point in time, but rather should be construed to include known, conventional, or standard techniques that are or may become available or known at any time, present or future. Terms such as "preferably", "preferred", "desired", or "desirable" and words of similar import should not be understood to imply that a particular feature is extremely important, essential, or even more important for the structure or function of the present invention, but rather are merely intended to emphasize alternative or additional features that may or may not be utilized in a particular embodiment of the present invention. Similarly, a group of items associated by the conjunction "and" should not be construed to require that every one of those items be present within the group, but rather should be construed as "and / or" unless expressly stated otherwise. Similarly, a group of items associated by the conjunction "or" should not be construed to require mutual exclusion among the members of that group, but rather should be construed as "and / or" unless expressly stated otherwise.

[0219] Where a range of values is provided, the upper and lower limits thereof, as well as each intermediate value therebetween, are included in the embodiment.

[0220] With respect to the use of substantially all plural and / or singular terms in this specification, those skilled in the art can convert from plural to singular and / or from singular to plural as appropriate for the situation and / or application. Various singular / plural substitutions may be explicitly described herein for clarity. The indefinite article "a" or "an" does not exclude the plural. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs within the claims shall not be construed as limiting the scope.

[0221] If a specific number of claim limitations is intended, it will be further understood by those skilled in the art that such intent is explicitly recited within the claims and that such intent does not exist absent such recitation. For example, by way of illustration, the appended claims may include the use of the introductory phrases "at least one" and "one or more" to introduce claim limitations. However, the use of such phrases does not imply that the same claim limitations are limited to embodiments containing only one such limitation where the claim includes both an introductory phrase such as "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should typically be construed to mean "at least one" or "one or more"), which applies to the use of indefinite articles used to introduce claim limitations. Additionally, it will be understood that even if a specific number of claim limitations is explicitly recited, such recitation should typically be construed to mean at least the recited number (e.g., the bare recitation "two limitations" typically means at least two or more limitations without a modifying clause). Further, in instances where conventional equivalent forms are used for "at least one of A, B, and C, etc.", generally such limitations are intended in the sense that those skilled in the art will understand the convention (e.g., "a system having at least one of A, B, and C" will include, but not be limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together).In cases where conventional similar forms for "at least one of A, B, or C, etc." are used, generally, such a limitation is intended in the sense that a person skilled in the art understands the convention (for example, "a system having at least one of A, B, or C" would include, but not be limited to, systems having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together). It will be further understood by a person skilled in the art that virtually all disjunctive words and / or phrases representing two or more alternative terms, whether within the description, claims, or drawings, are intended to encompass one of those terms, any of those terms, or both of those terms. For example, the phrase "A or B" will be understood to include the possibilities of "A" or "B" or "A and B".

[0222] All numbers representing amounts of components, reaction conditions, etc. are to be understood as being modified by the term "about" in all instances. Accordingly, unless otherwise indicated, the numerical parameters described in this specification are approximate values and can vary depending on the desired characteristics for which acquisition is sought. At a minimum, and not as an attempt to limit the scope of any claim in any application claiming priority to this specification, each numerical parameter should be construed in light of the number of significant digits and the customary rounding techniques.

[0223] Furthermore, although the foregoing has been described in some detail by way of illustration and example for purposes of clarity and understanding, it will be apparent to those skilled in the art that certain changes and modifications can be made. Accordingly, the description and examples should not be regarded as limiting the scope of the invention to the specific embodiments and examples described herein, but should also cover all modifications and alternative means that fall within the true scope and spirit of the invention.

Claims

1. A method for measuring a patient's glucose level by a sensor electronic device module, comprising: executing, by at least one processor, an application on a first device for measuring the glucose level of the patient, the first device communicating with the sensor electronic device module; determining, by the at least one processor, whether the application on the first device has stopped execution; generating, by the at least one processor, a notification based on the determination, the notification indicating that the application has stopped execution and the period since the data indicating the glucose level transmitted from the sensor electronic device module was last received by the application; when a loss of connectivity between the first device and the sensor electronic device module is detected, the application is stopped; A method.

2. The method according to claim 1, wherein the notification is generated locally on the first device.

3. The method according to claim 2, further comprising transmitting one or more notifications that the application has stopped execution to one or more remote monitors of the patient.

4. The method according to claim 1, further comprising starting the application when receiving communication from a third device related to the operation of the application.

5. The method according to claim 4, wherein the first device and the third device are paired using a Bluetooth (registered trademark) connection.

6. The application is configured to set an alarm on the first device to start at a predetermined time, reset the alarm on the first device before the alarm starts by extending the predetermined time.

7. The method according to claim 6, wherein determining whether the application has stopped execution is based on the start of the alarm.

8. The method according to claim 1, wherein the notification is generated when receiving a message indicating that the application has failed to communicate with a second device during a predetermined period.

9. The method according to claim 1, wherein said determining comprises determining whether the battery of the first device has sufficient power to continue the operation of the first device for a predetermined period.

10. A system comprising: a processor; a sensor electronics module configured to measure a glucose level of a patient; a memory, wherein the processor and the memory are configured to: execute an application on a first device for measuring the glucose level of the patient, the first device communicating with the sensor electronics module; determine whether the application on the first device has stopped execution; generate a notification based on the determination, the notification indicating that the application has stopped execution and the period since the data indicating the glucose level transmitted from the sensor electronics module was last received by the application; be configured to perform operations including: when a loss of connectivity between the first device and the sensor electronics module is detected, the application stops execution. A system.

11. The system according to claim 10, wherein the notification is generated locally on the first device.

12. The operations further comprise: transmitting one or more notifications indicating that the application has stopped execution to one or more remote monitors of the patient.

13. The operations further comprise: starting the application when receiving communication from a third device related to the operation of the application.

14. The system according to claim 13, wherein the first device and the third device are paired using a Bluetooth® connection.

15. The application is configured to: set an alarm on the first device to be started at a predetermined time; reset the alarm on the first device before the alarm is started by extending the predetermined time.

16. The system according to claim 15, wherein determining whether the application has stopped execution is based on the start of the alarm. **Claim 17** The system according to claim 10, wherein the notification is generated when receiving a message indicating that the application has failed to communicate with a second device during a predetermined period. **Claim 18** The system according to claim 10, wherein the determining includes determining whether the battery of the first device has sufficient power to continue operating the first device during a predetermined period.

Images