Remote monitoring of analyte measurements

Abstract

To provide methods and apparatuses, including computer program products, for remote monitoring.SOLUTION: A method is provided in some example implementations. The method may include: receiving, at a remote monitor, a notification message representing an event detected by a server, from analyte sensor data obtained from a receiver monitoring an analyte state of a host; presenting, at the remote monitor, the notification message to activate the remote monitor, the remote monitor being configured by the server to receive the notification message to augment the receiver monitoring the analyte state of the host; accessing, by the remote monitor, the server in response to the presenting of the notification message; and receiving, in response to the accessing, information including at least the analyte sensor data. Related systems, methods, and articles of manufacture are also disclosed.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS Any and all priority claims identified in this application data sheet, or any amendment thereto, are incorporated herein by reference under 37 CFR 1.57. This application claims the benefit of U.S. Provisional Application No. 61 / 747,717, filed December 31, 2012, U.S. Application No. 13 / 842,679, filed March 15, 2013, and U.S. Application No. 13 / 843,382, filed March 15, 2013, the disclosures of which are expressly incorporated herein by reference in their entireties and are expressly made a part of this application.

[0002] The present disclosure relates generally to remote monitoring. [Background technology]

[0003] Diabetes mellitus is a disease in which the pancreas does not produce enough insulin, such as in type 1 diabetes, and / or in which insulin is ineffective, such as in type 2 diabetes. In diabetes, patients suffer from hyperglycemia, which is associated with deterioration of capillaries and leads to various physiological disorders, such as kidney failure, skin ulcers, or bleeding into the vitreous of the eye. A hypoglycemic response, such as hypoglycemia, can be precipitated by accidental overdosing of insulin or after regular administration of insulin or glucose-lowering drugs in conjunction with excessive exercise or inadequate food intake.

[0004] Diabetics may carry self-monitoring blood glucose (SMBG) monitors, which typically require an uncomfortable fingerstick method. Due to a lack of comfort and convenience, diabetics typically measure their glucose levels only two to four times per day. Unfortunately, these time intervals are so far apart that diabetics are likely to discover a hyperglycemic or hypoglycemic state too late, sometimes with dangerous side effects. In fact, not only are diabetics unlikely to obtain SMBG readings in a timely manner, but diabetics also may not know whether their blood glucose levels are high or low based on traditional methods. Accordingly, a variety of noninvasive transdermal (e.g., transcutaneous) and / or implantable electrochemical sensors have been developed to continuously detect and / or quantify blood glucose levels. These, and other types of devices, generally transmit raw or minimally processed data for subsequent analysis at a remote device, which may include a display to enable presentation of information to the user hosting the sensor. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2006-239084 [Patent Document 2] International Publication No. 2011 / 021118 [Patent Document 3] Special Publication No. 2009-500047 [Patent Document 4] International Publication No. 2011 / 124993 [Patent Document 5] Japanese Patent Application Laid-Open No. 2000-316819 Summary of the Invention [Means for solving the problem]

[0006] Methods and apparatus, including computer program products, are provided for remote monitoring of analyte data. In some implementations, a method is provided that may include receiving, at a remote monitor, a notification message representing an event detected by a server from analyte sensor data obtained from a receiver monitoring an analyte status of a host; presenting, at the remote monitor, the notification message for enabling the remote monitor, where the remote monitor is configured to receive, by the server, the notification message for enabling the receiver monitoring the analyte status of the host; accessing, by the remote monitor, the server in response to presenting the notification message; and receiving, in response to the access, information including at least the analyte sensor data.

[0007] In some implementations, the above aspects may further include additional features described herein, including one or more of the following: The notification message may be received from at least a first wireless connection between the remote monitor and a notification service coupled to the server, and the additional information may be received from at least a second wireless connection between the remote monitor and the server. The first wireless connection may include a persistent encrypted connection configured to carry short messages pushed by the notification service to a notification message center at the remote monitor, and the second wireless connection may include a temporary encrypted connection established in response to the access to provide the additional information including at least the additional analyte sensor data. The presenting may further include blocking access to one or more applications at the remote monitor until activity at the remote monitor is detected indicating receipt of the notification message, and the remote monitor may further include a monitoring application. The notification message may be presented as a temporary message on a display of the remote monitor without blocking access. At least one of the remote monitor and the receiver may include one or more of a mobile station, a wireless terminal, a tablet, a smartphone, a multi-mode wireless device, and a computer. The server may comprise at least one processor configured to receive analyte sensor data from the receiver, process the analyte sensor data to detect an event, and, upon detection of an event, forward a notification message to a remote monitor based on one or more rules that map the event to a remote monitor designated to receive a notification message for the detected event. The event may be detected at the server based on a first set of rules, and the first set of rules used to generate the notification message may be different from a second set of rules used to detect an alert sent to a receiver coupled to the sensor system at a host. The receiver may include or be coupled to a gateway that interfaces with a public land mobile network and a wireless connection to the server.Multiple remote monitors may be configured, and at least one of the multiple remote monitors may be designated as a primary monitor and at least one of the multiple remote monitors may be designated as a secondary monitor. The remote monitor may configure at least one rule representing a trigger that causes an alert to be sent by the server to the receiver. The remote monitor may configure one or more invitations to be sent to the one or more devices to invite the one or more devices to monitor the receiver. The server may send a message confirming receipt of the notification message. The notification message may include at least one of an indication of a need to calibrate the sensor and a confirmation message indicating at least one of an action or confirmation sent by the receiver in response to the alert sent to the receiver. Enabling the remote monitor may include opening a monitoring application. A connection may be established between the remote monitor and the server to enable receipt of information including analyte sensor data. The server may register at least one of the remote monitor, the receiver, and the analyte sensor coupled to the receiver, where the registration may include a code provided by a medical professional. The method may be implemented on a device comprising at least one processor and at least one memory including code that, when executed by the at least one processor, causes the device to provide the method. A computer-readable storage medium may include code that, when executed by at least one processor, causes the method to occur.

[0008] In another aspect, a method is provided that includes receiving, at a remote monitor, an invitation to access a secure server and data associated with a receiver that monitors an analyte status of a host, and modifying, by the remote monitor, rules that define alerts that represent events associated with the analyte status of the host, the alerts, when triggered, causing the remote monitor to send a message to notify the remote monitor of the event.

[0009] In some implementations, the above aspects may further include additional features described herein, including one or more of the following: modifying the rule may include varying a first threshold associated with a low level of glucose at the host, varying a second threshold associated with a high level of glucose at the host, varying a delay between when an associated alert is triggered by the receiver and when a notification message is sent to the remote monitor, and / or varying a time value at which a reminder notification is sent to the remote monitor. The method may be implemented on an apparatus comprising at least one processor and at least one memory including code that, when executed by the at least one processor, causes the apparatus to provide the method. A computer-readable storage medium may include code that, when executed by the at least one processor, causes the method to occur.

[0010] It should be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not limiting. Additional features and / or variations may be provided in addition to the features and / or variations described herein. For example, implementations described herein may relate to various combinations and subcombinations of the disclosed features and / or combinations and subcombinations of several additional features disclosed in the following detailed description. [Brief explanation of the drawings]

[0011] In the drawings,

[0012] [Figure 1] 1 illustrates a high-level system architecture of a remote monitoring system according to some implementation examples. [Figure 2A] 2 illustrates different system architectures of the remote monitoring system of FIG. 1 according to some example implementations. [Figure 2B] 2 illustrates different system architectures of the remote monitoring system of FIG. 1 according to some example implementations. [Figure 2C]2 illustrates different system architectures of the remote monitoring system of FIG. 1 according to some example implementations. [Figure 3] 10 depicts an exemplary process for notifying a remote monitor of an event, according to some implementations. [Figure 4A] 1 illustrates an example notification message 170 according to some example implementations. [Figure 4B] 1 illustrates an example notification message 172 according to some implementation examples. [Figure 5] 1 illustrates an example of a sensor electronics module, according to some implementations. [Figure 6] FIG. 1 is a block diagram of an implementation of a gateway, according to some example implementations. [Figure 7A] 1 illustrates an example docking station, according to some example implementations. [Figure 7B] 1 illustrates an example docking station, according to some example implementations. [Figure 8] Represents a gateway or docking station implementation, following some example implementations. [Figure 9] 10 illustrates an example display page for prompting entry of a receiver's serial number or other unique identifier, according to some implementations. [Figure 10] 1 is a flowchart illustrating steps for configuring a host monitoring system, according to some example implementations. [Figure 11A] 1 is an exemplary display of a status page, according to some example implementations. [Figure 11B] 1 is an exemplary display of a status page, according to some example implementations. [Figure 12] 10 depicts an exemplary invitation page in the form of an email message presented to a remote monitor according to some implementations. [Figure 13] 10 depicts an exemplary alert settings page that may be presented on a display of a host computing device. [Figure 14] 1 illustrates a remote monitor summary page displayed by a host monitoring device, according to some example implementations. [Figure 15] 1 is an exemplary remote monitor settings display page displayed by a host monitoring device according to some implementations. [Figure 16] 1 is a flowchart of an exemplary remote monitor configuration, according to some implementations. [Figure 17] In some implementations, it is a port of a settings page that can allow a remote monitor to configure the remote monitoring settings of the host. [Figure 18A] 1A and 1B are two different implementations of a dashboard page displayed by a remote monitor, according to some example implementations. [Figure 18B] 1A and 1B are two different implementations of a dashboard page displayed by a remote monitor, according to some example implementations. [Figure 19] 1 is an example page providing a trend graph of monitored analyte concentrations of a host, according to some implementations. DETAILED DESCRIPTION OF THE INVENTION

[0013] Implementations described herein can include a system for one or more caregivers (e.g., parents, spouses, or healthcare professionals) to remotely monitor one or more host health characteristics. Health characteristics can include host analyte concentrations, such as glucose, or bodily functions, such as heart rate, blood pressure, or temperature. In addition, other characteristics of the host, such as the host's geographic location, the host's condition (e.g., exercise, sleep, or work), etc., can be monitored to facilitate care of the host. Health and other characteristics can be collected using a host monitoring system that incorporates a computing device, such as a smartphone, and one or more sensors, such as a continuous glucose sensor, a heart rate monitor, a GPS device, etc. In addition, the host can manually enter information, such as meal information, medication dose frequency and amount, into the computing device. Information collected by the host monitoring system can then be transmitted to one or more remote monitors used by the caregivers. The caregiver(s) can then receive information regarding the host's health status using the remote monitoring system. In some implementations, the host monitoring system can transmit information directly to one or more remote monitors, and / or the host monitoring system first transmits information to a remote server, which then transmits the information to the host monitor.

[0014] For purposes of illustration only, the following examples are non-limiting example environments in which implementations of the remote monitoring system described herein may be used.

[0015] In this exemplary environment, a diabetic host is monitored by several different caregivers. The host has a continuous glucose monitoring system, such as the DexCom G4® Platinum continuous glucose monitoring system, available from DexCom, Inc., which provides measurements of the host's glucose level on a display device, such as the DexCom G4® Platinum Receiver, also available from DexCom, Inc.

[0016] Further, in this exemplary environment, the display device may be in communication with a gateway device, such as via wired or wireless communication. The gateway device collects information from the display device, including real-time or near-real-time glucose concentration values, and transmits this information to a secure server. The gateway device may include a smartphone, such as an iPhone® 4S or iPhone® 5, each commercially available from Apple, Inc., and a host monitoring software application including instructions configured to cause the smartphone to function as a gateway. The host monitoring software application may be in the form of a so-called “app” downloaded from the Apple App Store (service mark) operated by Apple, Inc. The gateway may wirelessly transmit information collected from the continuous glucose monitoring system to the secure server over a cellular network, a Wi-Fi network, or the like.

[0017] The remote server can store and monitor information received from the remote monitoring system. Monitoring can include comparing the host's glucose value (generated by the continuous glucose monitoring system and transmitted to the server via the gateway) to a predetermined threshold and initiating action if the threshold is exceeded. For example, the server can compare the most recent glucose value (e.g., the most recently displayed glucose value) to a predetermined glucose threshold and initiate a notification, such as a text message over a cellular network, to the remote monitoring system if the glucose value exceeds the threshold. The server can also provide past and recent glucose values ​​to the remote monitoring system upon request.

[0018] As described above, the remote monitor can be used by a caregiver to monitor a health characteristic of the host, which in this exemplary environment is the host's glucose concentration level. Similar to the host monitoring system, the remote monitoring system can be a smartphone, such as an iPhone® 4S or iPhone® 5, and a remote monitoring software application containing instructions configured to cause the smartphone to function as a remote monitoring system. The remote monitoring software application can be in the form of a so-called "app" downloaded from the Apple App Store operated by Apple, Inc. The remote monitoring system can receive notifications from a server when thresholds are exceeded, informing the caregiver using the remote monitoring system of the host's condition. The remote monitoring system can also be used to view historical information about the host's monitored glucose levels and to change notification rules, such as the threshold levels that trigger notifications.

[0019] The following provides more details of specific implementation examples, which may or may not include the functionality illustrated in the example environments described above.

[0020] 1 depicts a high-level system architecture of an implementation of a remote monitoring system 100. Here, the remote monitoring system 100 includes multiple host monitoring systems 198A-198N connected to multiple remote monitors 114A-114M via a network 118. Each host monitoring system 198 may be one or more health monitoring devices that collect health-related data associated with the host and can transmit the health-related data via the network 108. Implementations of the health monitoring systems 198A-198N are described in more detail elsewhere in this disclosure, but in some implementations, they may include one or more sensors and computing devices operably coupled to the sensors to collect, process, and transmit the health-related data. The network 108 may include any communication medium, such as wired and wireless networks, including cellular networks, local area networks, wide area networks, Wi-Fi networks, the Internet, etc. Network 108 also includes one or more servers 110 that can process health-related data received from one or more remote monitors 114A-114M and transmit notifications and data to one or more remote monitors 114A-114M, either automatically or in response to a request from the remote monitor.

[0021] Each remote monitor 114A-114M can be associated with an individual or entity that is monitoring the health of one or more of the hosts using the host monitoring systems 198A-198N. Each remote monitor 114 can be associated with a caregiver, such as a parent, spouse, doctor, nurse, hospital, etc. The remote monitor 114 can include a computing device that receives notifications from the network 108 and requests additional information, such as historical health-related data collected by one or more of the host monitoring systems 198A-198N.

[0022] 1 may also include a workstation 22. The workstation 22 may be a computing device, such as a personal computer, that has access to the remote monitoring system 100 for configuring settings of the system 100 and / or for viewing information associated with one or more host monitoring systems 198, such as reports generated by the remote monitoring system based on the host's health-related data.

[0023] 1, one or more remote monitors 114A-114M can monitor one or more host monitoring systems 198A-198N. As an example, host monitoring system 198A can be monitored by remote monitors 114A and 114B, while remote monitor 114A can also monitor host monitoring system 198B. ​​As described in more detail later in this disclosure, various permissions and invitations can be used to limit which remote monitors 114A-114M can monitor host monitoring systems 198A-198N.

[0024] In one non-limiting example of remote monitoring system 100, each host monitoring device 198A-198N comprises a smart device such as an iPhone® mobile phone or an iPod® touch® mobile device from Apple, Inc. Similarly, each remote monitor 114A-114M comprises a smart device such as an iPhone® or iPod® touch. Each host smart device has a host software application downloaded from a server on network 108 that configures the smart device to perform any of the functions described herein by host monitoring system 198, including collecting and transmitting health-related data used in remote monitoring system 100. The host software application can be an application downloaded using the App Store service hosted by Apple, Inc. Similarly, each remote monitor 114A-114M has a remote monitoring application downloaded from a server on network 108 that configures the smart device to perform any of the remote monitoring functions described herein, including receiving notifications and requesting host health-related data. The remote monitoring application may also be a software application downloaded using the App Store service hosted by Apple, Inc.

[0025] 2A depicts an example of a system 100 for monitoring health-related information of a host 199, according to some implementations. Here, remote system 100 includes a continuous analyte monitoring system 8, which includes a sensor electronics module 12 and a continuous analyte sensor 10. System 100 may also include other devices and / or sensors, such as a medication delivery pump 2 (e.g., an insulin or glucagon pump), a glucose meter 4 (e.g., a fingerstick blood glucose meter), and any other devices and / or sensors. Continuous analyte sensor 10 may be physically connected to sensor electronics module 12, and may be integral with (e.g., permanently attached to) or removably attached to continuous analyte sensor 10.

[0026] The sensor electronics module 12, drug delivery pump 2, glucose meter 4, and / or other devices / sensors may be coupled via wired or wireless links to one or more devices, such as a receiver 102. The receiver 102 may include a display 122 to allow a host 199 to present and / or control information from the continuous analyte sensor 10, delivery pump 2, glucose meter 4, and / or other devices / sensors.

[0027] 2A provides notification messages to one or more remote monitors 114A-114M, such as remote monitor 114A, via gateway 104, networks 108A-C, secure server 110, and notification service 112. Each remote monitor 114 may be configured to provide a separate mechanism for monitoring activities associated with host 199 in system 100, including receiver 102, continuous analyte sensor 10, delivery pump 2, glucose meter 4, and / or any other sensors associated with host 199.

[0028] To illustrate by way of example, the host 199 may access the receiver 102 to display data from or control aspects of the continuous analyte sensor 10, delivery pump 2, and / or glucose meter 4. However, another entity, such as a parent, caregiver, medical professional, school nurse, or the like, may have the remote monitor 114 receive notification messages representing predetermined events determined based on sensor data from the receiver 102, continuous analyte sensor 10, delivery pump 2, and / or glucose meter 4, and display historical and substantially real-time sensor data. For example, the events may include one or more of a measured analyte sensor value above or below a predetermined threshold, a rate of change or level of a glucose measurement exceeding a predetermined threshold, a predicted (or predicted to reach) a predicted threshold, the host 199 not responding to a prompt, or an alert displayed at the receiver 102, and / or any other event detected by the secure server 110 and / or the receiver 102. In the example of FIG. 2A , the remote monitor 114 displays a notification message 132 indicating a low glucose level for the host 199. In this manner, the entity with the remote monitor 114 can assist the host 199 by providing an additional layer of monitoring and supervision of the host 199, as well as the receiver 102, continuous analyte sensor 10, delivery pump 2, glucose meter 4, etc.

[0029] In some implementations, the remote monitor 114 may include a processor, a non-transitory computer-readable storage medium (e.g., memory, storage, etc.), a radio access mechanism (e.g., modem, etc.), and / or a user interface. The computer-readable medium may include code that, when executed by the processor, provides one or more applications, an operating system, etc. For example, the application may be configured as a remote monitoring application configured to monitor and / or control one or more of the receiver 102, the continuous analyte sensor 10, the delivery pump 2, the glucose meter 4, etc. In some implementations, the remote monitor 114 is an iPhone® mobile phone from Apple, Inc., and the application is an application downloaded from the internet using an app store service operated by Apple, Inc.

[0030] In some implementations, the remote monitor 114 may comprise one or more of a mobile station, a wireless terminal, a tablet, a smartphone, etc. For example, the remote monitor 114 may be implemented as a wireless handheld device, a wireless plug-in accessory, etc. Additionally, the remote monitor 114 may be implemented as a multi-mode device configured to operate using multiple radio access technologies, such as Long Term Evolution (LTE), wireless local area network (WLAN) technologies such as 802.11 Wi-Fi, Bluetooth, Bluetooth low energy (BT-LE), near field communications (NFC), and any other radio access technology. Additionally, the remote monitor 114 may be configured to establish a connection to an access point of the network 108A, such as a cellular base station, a Wi-Fi access point, or the like, using at least one of the multiple radio access technologies. Also, although some of the examples herein refer to the remote monitor 114 as a mobile, wireless computing device for purposes of explanation, the remote monitor may also be implemented as a fixed device, such as a personal computer.

[0031] In some implementations, the alert rules of the receiver 102 may be different from those of the remote monitor 114. For example, a different set of rules may define when alerts are sent and / or triggered by the receiver 102 compared to the set of rules used to trigger notifications to the remote monitor 114. Furthermore, while the receiver 102 may trigger alerts independently (e.g., by applying thresholds to sensor data received from the sensor system 8), receive alerts from the sensor system 8, or receive alerts directly from the secure server 110, the remote monitor 114 may be configured to receive messages, such as short messages, text messages, etc., from the notification service 112, which may function to enable the remote monitor 114, such as enabling the remote monitor's remote monitor application. For example, the remote monitor 114 may close the remote monitor application session (as well as the proximate network connection 109 to the secure server 110) if the remote monitor application is not being used effectively to conserve power at the remote monitor. In such cases, notification service 112 may send a message over network connection 111 to enable remote monitor 114 and / or the remote monitor application (and this enablement may be automatic or under the control of the user of remote monitor 114).

[0032] Although some of the examples described herein refer to the secure server 110 as an intermediate node between the receiver 102 and the remote monitor 114, in some implementations the secure server 110 may be bypassed. For example, the gateway 104 can communicate directly with the remote monitor 114, or vice versa. Additionally, the gateway 104 and the receiver 102 can receive notification messages to enable applications on the receiver 102 or gateway 104 to allow the host to be alerted.

[0033] 3 depicts an example process 197 for notifying a remote monitor 114 of an event associated with a receiver 102, a continuous analyte sensor 10, a delivery pump 2, a glucose meter 4, and / or a host 199, according to some implementations. The description of FIG. 3 also refers to FIG. 2A.

[0034] In some implementations, the secure server 110 may register and / or configure one or more of the receiver 102, the continuous analyte sensor 10, the delivery pump 2, the glucose meter 4, and the host 199 before step 197 begins, although registration and / or configuration may occur at other times. A registration step may be performed to register the receiver 102, the continuous analyte sensor 10, the delivery pump 2, the glucose meter 4, the remote monitor 114, and / or the host 199 with the secure server 110. Additionally, a configuration step may be performed to configure the system 100, including identifying one or more remote monitors used to monitor the receiver 102, configuring one or more rules used to trigger notification messages to the remote monitors, configuring one or more rules specifying primary and secondary remote monitors, configuring one or more rules establishing schedules for the primary and secondary monitors, configuring one or more rules defining an escalation sequence indicating when to escalate events to the primary or secondary monitor, etc.

[0035] At 180, receiver 102 may transmit sensor data, such as analyte data from sensor system 8, to gateway 104, which then forwards the sensor data to secure server 110 at 182. For example, receiver 102 may be coupled to gateway 104 via a wired or wireless connection, and gateway 104 may be coupled to secure server 110 via network 108A. Gateway 104 may be configured to pull current and / or historical data from receiver 102 on its own or in response to a request from secure server 110.

[0036] At 186, secure server 110 can determine whether to send a notification message regarding the event to one or more of remote monitors 114A-114M, such as remote monitor 114A. Secure server 110 can trigger an event (or satisfy a rule) at the secure server and determine whether to send a notification message to remote monitor 114 based on the received sensor data (as well as any other data available to the secure server). For example, secure server 110 can receive sensor data at 182 and then process the received sensor data alone or together with other data (e.g., historical data, data from other sources of patient information, etc.) to determine whether to send a notification message to remote monitor 114 alerting it to the event. Secure server 110 can also receive information from other systems, such as a health management system or a medical professional's system, which may be used to trigger a notification message to the remote monitor. Additionally, secure server 110 can send a notification message to verify whether the remote monitor is still actively monitoring host 199.

[0037] By way of example, receiver 102 can receive sensor data from host 199 and transmit the sensor data via gateway 104 and network 108A to secure server 110, which can process the sensor data and determine a glucose level event by comparing the most recent glucose level data to a predefined low glucose threshold, although other events described herein may also be detected. Secure server 110 can include one or more rules that define an event, such as a low level of glucose above a threshold, and can include rules that define the identity of a remote monitor that should receive a notification message indicating a low level of glucose at host 199. For example, a rule can define that when a low level of glucose is detected at a given host, a given remote monitor should receive a notification message. The notification message can include an indication of the low level of glucose (e.g., glucose value), the time of the event, and other information, such as a graph of the most recent and historical glucose levels, host information (e.g., name), and / or any other information associated with the host.

[0038] The one or more rules defining the events may be defined by a user, such as the host 199, a caregiver, etc., during the configuration process, and / or may be predefined as default rules (which may be reconfigured by the user over time to suit the host, or may be adapted by the system 100). In some implementations, the one or more rules may define a threshold representing the severity of the event to be reported to one or more remote monitors, a time(s) at which a notification message should be sent to each of the remote monitors, an identification of the one or more remote monitors (e.g., a telephone number, Internet Protocol address, email address, etc.), etc.

[0039] Additionally, one or more rules may include escalation rules so that events can be handled differently based on the severity of the event, the type of event, and / or the lack of a response by a designated remote monitor. For example, a rule may define that glucose values ​​below a predetermined value should not be the subject of a notification message to the remote monitor 114 (although an alert message may be sent to the receiver 102 or gateway 104 to notify the host 199), another rule may define that glucose values ​​between a certain range of values ​​must be the subject of a notification message to the remote monitor 114, while another rule may define that a detection of a dangerously low glucose value will send a notification message to the remote monitor 114A as well as other remote monitors 114B-M. In some implementations, the rules used to trigger an alert to the host 199 at the receiver 102 may be different from the rules used to send a notification message to the remote monitor 114, although one or more of the rules may be the same.

[0040] While the above examples described events associated with low glucose levels, other types of events described herein may also be defined in the secure server 110 to trigger a notification message to the remote monitor 114 and / or an alert to the receiver 102.

[0041] At 187, secure server 110 can send an alert to receiver 102 and / or gateway 104. The alert may be triggered based on the same or different event as the rules used to trigger the event of the notification message to remote monitor 114. Moreover, secure server 110 can include a delay between when the alert is sent at 187 and when the notification message is sent at 188-190. For example, the receiver may also have a set of rules stored on the secure server that are the same or different from the receiver's rules, so the delay can allow receiver 102 to perform a check or action before sending the message at 188-190. That is, receiver 102 may trigger an alert based on rules residing internally to the receiver, and the receiver may receive an alert from the secure server based on a different set of rules stored on the secure server. The delay before secure server 110 sends a notification to receiver 102 can be varied by the secure server based on the severity or type of event, and the delay may be user-configured and / or programmatically configured. For example, a first delay may be used for a first low analyte threshold, but no delay at all may be used for a second, more severe, low glucose threshold.

[0042] At 188-190, a notification message may be sent to one or more remote monitors based on whether one or more rules are triggered at 186. In some implementations, a secure server can send the notification message to a push notification service 112, which then pushes a notification to the remote monitor. Examples of push notification services include the Apple Push Notification Service (APNS) and Google Cloud Messaging, although any other messaging mechanism, such as email, short messaging service, tweets, etc., may also be used. In the case of an APNS, the remote monitor 114 (or a notification message center therein) can establish an Internet Protocol (IP) connection with the APNS. This connection may be encrypted, persistent, and / or authenticated, allowing the notification service to send notification messages to the notification message center even when the remote monitor application and / or the remote monitor are not actively in use. For example, the notification message center can alert a user of the remote monitor 114 that a notification message has arrived at the remote monitor application.

[0043] In an implementation using a push notification service, the notification service 112 can receive a notification message from the secure server 110. The notification message can include a destination address, such as the phone number or IP address of the remote monitor 114, and a payload, such as the content of the notification message. Returning to the previous example regarding a low glucose level, the notification message can include the phone number of the remote monitor 114 and a short text message, such as the low glucose level value, the time the value was measured, and / or the host's identification. The notification message can be limited to 256 bytes, although messages of other sizes can be used. In either case, the notification service 112 pushes the notification message to the remote monitor 114 over a connection, such as an Internet Protocol (IP) connection, between the notification service server 112 and the notification message center of the remote monitor 114. When the notification message center of the remote monitor 114 receives the notification message, the notification message center can display the notification message and generate a sound, vibration, or other indication to the user of the remote monitor 114. Additionally, in some implementations, a notification message center or user of the remote monitor can enable the remote monitoring application of the remote monitor 114 if the remote monitoring application is not actively being used. In implementations where the remote monitor 114 resides on a device such as a smartphone, the notification service 112 may be used to place the remote monitor 114 or its application in an idle or disabled mode to conserve power or reduce signaling to or from the network.

[0044] In some implementations, the push notification service may be bypassed so that the secure server 110 sends notification messages directly to the remote monitor 114 and / or its internal remote monitoring application. This may occur, for example, when the remote monitoring application is opened on the remote monitoring device.

[0045] At 192, upon receiving the notification message, the remote monitor 114 or the remote monitoring application therein may be enabled if it is in an idle or disabled mode. Once enabled (which may be programmatic or under user control), the remote monitor 114 may attempt to establish a connection to the secure server 110. For example, the remote monitoring application may not be actively being used (e.g., in idle mode, sleep mode, powered off, background mode, etc.). To enable the remote monitoring application, the remote monitoring application may be enabled, for example, by opening the remote monitoring application by selecting and expanding the remote monitoring application, actively using the remote monitoring application by entering a value, selecting an element of the remote monitoring application's user interface, etc. Additionally, the remote monitor and / or remote monitoring application may be enabled by other manners. For example, activation may be triggered by movement of the remote monitor detected by a motion sensor and / or by enabling a display or increasing the brightness of a display on the remote monitor.

[0046] In response to confirmation that the remote monitor 114 has enabled the remote monitoring application via access message 194, secure server 110 may transmit additional information to the remote monitor at 196. The content of the additional information transmitted from secure server 110 to remote monitor 114 may be determined automatically or may be defined by a request from the remote monitor, which may be a request included in access message 194 or a subsequent message from the remote monitor. The additional information may include one or more of all available sensor data not currently stored in remote monitor 114, sensor data for a predetermined time period, such as the previous 3 or 24 hours, of glucose data obtained from sensor system 100, receiver 102, and / or secure server 110, a graph of glucose levels versus time, glucose variable values, instructions, encouragement messages, host status, remote monitoring privileges changed by the host, etc.

[0047] In some implementations, secure server 110 automatically sends the past three hours of sensor data to the remote monitor, and the remote monitor can request any additional amount of past sensor data if the remote monitor needs to evaluate the host for a longer period of time. Secure server 110 can query receiver 102, via gateway 104, for additional data in order to respond if the secure server does not have all the sensor data specified in a request from remote monitor 114.

[0048] 2A , the remote monitor 114 may respond with a message 132 on its display screen. From the message 132, the remote monitoring application may activate the notification, either spontaneously or under the direction of the user and / or the notification message center. The remote monitoring application may then access the secure server 110 at 192 to programmatically receive any additional information associated with the event or other data since the last connection to the secure server 110. For example, when the notification message is acknowledged at 194 or with an acknowledgement message, the secure server 110 may automatically respond with a page having a trend graph of the latest glucose status and event severity (or any other information available to the secure sensor 110). The secure server 110 may instead respond with a subset of the data, in which case the secure server 110 may automatically respond with new data since the last connection to the secure server 110, and the remote monitor may generate a page including a trend graph showing the glucose levels for the past three hours. In either case, the remote monitor may be configured to automatically present a page showing pertinent event information, such as a trend graph covering a specified time period for the host (e.g., three hours of historical glucose levels), upon receipt of message 196. An exemplary page that may be automatically presented is illustrated in FIG. 19 and discussed in more detail elsewhere in this disclosure.

[0049] While FIG. 3 is discussed primarily with respect to remote monitor 114 monitoring a single host for ease of understanding, it should be understood that the remote monitor may be monitoring multiple hosts, as discussed elsewhere herein. In this manner, secure server 110 may have sensor data and additional information associated with other hosts. Thus, in some implementations, the secure server may automatically send sensor data of other hosts that the remote monitor is monitoring in addition to the sensor data from the host that triggered notification 190 to the remote monitor. In this manner, remote monitor 114 may have an updated set of sensor data and other information associated with each of the hosts that the remote monitor is monitoring.

[0050] 4A and 4B illustrate examples of notification messages 170 and 172, respectively. In the example of notification message 170, notification message 170 may be presented to remote monitor 114 as a window requesting user interaction upon receipt of the notification message by remote monitor 114. For example, user interaction may include pressing a button on remote monitor 114, touching the screen of the remote monitor in an area associated with a portion of message 170, or activating (e.g., running, opening, etc.) the remote monitoring application on remote monitor 114. In some cases, notification message 170 may indicate that another application on remote monitor 114 is actively being used. In this case, user interaction may include touching the screen in an area associated with a portion of message 170 to acknowledge receipt of notification message 170 before allowing the user to relaunch the other application, although the user's action may prevent the other application from launching and make the remote monitoring application the active application displayed on the remote monitor. Additionally, the decision to prevent other applications from launching or to restart other applications may be predetermined based on the severity level of the event, such that relatively more severe events will prevent other applications from launching, while less severe events will not.

[0051] In the example of notification message 172, notification message 172 may be presented as a message displayed in a user interface on remote monitor 114 as an informational message that does not require intervention on the part of the user. Moreover, if notification message 172 is displayed while another application is being used on remote monitor 114, notification message 172 does not require the user to acknowledge notification message 172 or even enable the remote monitoring application (which may be idle or disabled on remote monitor 114), thereby causing the user to continue using the other application.

[0052] 2B depicts another exemplary architecture of the remote monitoring system 100. Referring to FIG. 2B, the receiver 102 may incorporate the gateway 104 of FIG. 2A. For example, the receiver 102 may include an interface to the network 108A, such as a radio frequency modem. To further illustrate, in the example of FIG. 2B, the receiver 102 may include a smartphone or other processor-based wireless device and provide access to the network 108A, which may provide access to the secure server 110 via public land mobile networks and other networks (e.g., the Internet).

[0053] Additionally, although illustrated separately in Figure 2B, in some implementations, secure server 110 can incorporate or bypass notification service 112. In such implementations, the operation of the system in Figure 2B is similar to the process described in Figure 3, but sensor data 180 may be sent directly to secure server 110 at 180, and secure server 110 may send notification messages directly to remote monitor 114 at 188.

[0054] 2C depicts yet another exemplary architecture of the remote monitoring system 100. Here, the gateway 104 is depicted as a dashed box containing separate devices, including a docking station 103 and a host communication device 105. In some implementations, any of the functions of the gateway 104 described herein can be split between the docking station and the host communication device. For example, the docking station 103 can communicate with the receiver 102, and the host communication device 105 can communicate with the secure server 110.

[0055] In some implementations, the host communication device 105 is a smartphone, and the docking station 103 physically, electrically, and communicatively couples to the receiver 102 to hold, power, and communicate with the receiver. In one implementation, the docking station 103 couples to the receiver via a USB connection for both powering and communicating with the receiver 102. The docking station 103 then communicates with the host communication device 105 via wireless communication, for example, using the Bluetooth® Low-Energy (BLE) protocol, and the host communication device communicates with the secure server 110 over the network 108A. Such an implementation including the docking station 103 may be used when the receiver 102 and the host communication device 105 do not have the ability to communicate directly with each other, for example, because the receiver and the host communication device do not use compatible communication protocols.

[0056] In the implementation of FIG. 2C, the host communication device 105 is a mobile phone with a host monitoring application downloaded from the Apple App Store that configures the mobile phone to collect information from the receiver 102 via the docking station 103 and transmit that information to the secure server 110, as well as any other functionality described herein associated with the gateway 104.

[0057] Before providing further implementation examples of the gateway 104, networks 108A-C, secure server 110, notification service 112, and remote monitor 114, the following provides implementation examples of the receiver 102, continuous analyte sensor 10, delivery pump 2, and / or glucose meter 4.

[0058] 2A-2C, the sensor electronics module 12, in some implementations, can include electronic circuitry associated with measuring and processing data generated by the continuous analyte sensor 10. This generated continuous analyte sensor data can also include algorithms that can be used to process and calibrate the continuous analyte sensor data, although these algorithms can be provided in other manners. The sensor electronics module 12 can 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. An example implementation of the sensor electronics module 12 will now be described in detail with reference to FIG. 5.

[0059] As described above, the sensor electronics module 12 can be coupled (e.g., wirelessly, etc.) to one or more devices, such as the receiver 102, to present (and / or alert) information, such as sensor information, transmitted by the sensor electronics module 12 for display on the receiver 102.

[0060] As shown in FIG. 5 , the receiver 102 can include one or more interfaces, such as a machine-to-machine interface and a user interface. For example, the user interface can include various interfaces, such as one or more buttons 124, a liquid crystal display 122, a vibrator, an audio transducer (e.g., a speaker), a backlight, etc. Components comprising the user interface can provide controls for interacting with a user (e.g., a host). The one or more buttons can enable, for example, a toggle, a menu selection, an option selection, a status selection, a yes / no response to an on-screen question, an “off” function (e.g., for an alert), a “snooze” function (e.g., for an alert), a reset, etc. The LCD 122 provides, for example, visual data output to the user. The audio transducer 230 (e.g., a speaker) can provide an audible signal in response to the triggering of a predetermined alert, such as current and / or predicted hyperglycemic and hypoglycemic conditions. In some implementations, the audible signal can be differentiated by tone, volume, duty cycle, pattern, duration, etc. In some implementations, the audible signal may be configured to be muted (e.g., snooze or off) by pressing one or more buttons 224 on the receiver 102 and / or by signaling the sensor electronics module using a button or selection on the receiver.

[0061] 2A and 2B depict an implementation of the receiver 102 as a handheld display device, other types of elements may also be used, such as a relatively small key fob-like, dongle-like display device, a mobile phone (e.g., a smartphone, a tablet, etc.), a personal computer 20, and / or any other user equipment configured to present at least information (e.g., medication delivery information, individual self-monitoring glucose measurements, a heart rate monitor, a calorie intake monitor, etc.).

[0062] In some implementations, the continuous analyte sensor 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 an analyte as a non-invasive, subcutaneous, transcutaneous, and / or intravascular device. In some implementations, the continuous analyte sensor 10 may analyze multiple intermittent blood samples, although other analytes may also be used.

[0063] In some implementations, the continuous analyte sensor 10 may comprise a glucose sensor configured to measure glucose in blood using one or more measurement techniques, such as enzymatic, chemical, physical, electrochemical, spectroscopic, polarimetric, calorimetric, electrophoretic, radiometric, immunochemical, etc. In implementations in which 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 a variety of glucose measurement techniques, including invasive, minimally invasive, and non-invasive techniques (e.g., fluorescence monitoring), to provide data, such as a data stream indicative of the concentration of glucose in a host. The data stream may be a raw data signal or converted into a calibrated and / or filtered data stream used to provide glucose values ​​to a user, such as a host or caregiver (e.g., a parent, family member, guardian, teacher, doctor, nurse, or any other individual interested in the health status of the host). Moreover, the continuous analyte sensor 10 may be implanted as at least one of an implantable glucose sensor, a transcutaneous glucose sensor implanted within a host blood vessel or outside the body, a subcutaneous sensor, a refillable subcutaneous sensor, and an intravascular sensor.

[0064] While the description herein refers to some implementations including the continuous analyte sensor 10 comprising a glucose sensor, the continuous analyte sensor 10 can also comprise other types of analyte sensors. Moreover, while some implementations refer to the glucose sensor as an implantable glucose sensor, other types of devices capable of detecting the concentration of glucose and providing an output signal representative of the glucose concentration may also be used. Furthermore, while the description herein refers to glucose as the analyte being measured, processed, etc., other analytes may instead or in addition be used, including, for example, ketone bodies (e.g., acetone, acetoacetate, and beta-hydroxybutyrate, lactate, etc.), glucagon, acetyl-CoA, triglycerides, fatty acids, citric acid cycle intermediates, choline, insulin, cortisol, testosterone, etc. In some implementations, other health characteristics of the host are monitored in addition to or in lieu of the analyte monitoring described herein, including, but not limited to, heart rate, blood pressure levels, blood oxygen levels, body temperature, calorie intake, drug delivery, etc.

[0065] In one embodiment, sensor system 8 and receiver 102 comprise a DexCom G4® Platinum continuous glucose monitoring system available from DexCom, Inc., and gateway 104 comprises an Apple iPhone® smartphone available from Apple, Inc., including software downloaded thereon that causes the smartphone to perform some or all of the functions of gateway 104 described herein.

[0066] 5 illustrates an example of the sensor electronics module 12, according to some implementations. The sensor electronics module 12 may include sensor electronics configured to process sensor information, such as sensor data. For example, the sensor electronics module may process the sensor data into one or more of filtered sensor data (e.g., one or more filtered analyte concentration values), raw sensor data, calibrated sensor data (e.g., one or more calibrated analyte concentration values), rate of change information, trend information, acceleration information, sensor diagnostic information, location information (which may be provided by a location module 269 that provides location information, such as global positioning / navigation system information), alarm / alert information, calibration information, sensor data smoothing and / or filtering algorithms, etc.

[0067] In some implementations, sensor electronics module 12 may be configured to calibrate the sensor data, and data storage memory 220 may store the calibrated sensor data points. Moreover, in some implementations, sensor electronics module 12 may be configured to wirelessly receive calibration information from a device such as receiver 102 to enable calibration of the sensor data. Furthermore, sensor electronics module 12 may be configured to perform additional algorithmic processing on the sensor data (e.g., structured and / or filtered data and / or other sensor information), and data storage memory 220 may be configured to store converted sensor data and / or sensor diagnostic information associated with the algorithm.

[0068] In some implementations, sensor electronics module 12 can include an application-specific integrated circuit (ASIC) 205 coupled to user interface 122. ASIC 205 can further include a low-potential electrolyzer 210, a telemetry module 232 for transmitting data from sensor electronics module 12 to one or more devices, such as receiver 102, and / or other components for signal processing and data storage (e.g., processor module 214 and data store 220). While Figure 2 depicts ASIC 205, other types of circuitry may also be used, including a field-programmable gate array (FPGA), one or more microprocessors configured to provide some (if not all) of the processing performed by sensor electronics module 12, analog circuitry, digital circuitry, or a combination thereof.

[0069] 5, a low potential electrolysis device 210 is coupled to a continuous analyte sensor 10, such as a glucose sensor, via data line 212 to receive sensor data from the analyte. The low potential electrolysis device 210 can also provide a voltage to the continuous analyte sensor 10 (also referred to as the analog portion of the sensor) via data line 212 to energize the sensor for measuring a value (e.g., current) indicative of the analyte concentration in the host. The low potential electrolysis device 210 can have one or more channels (and corresponding one or more data lines 212) depending on the number of working electrodes in the continuous analyte sensor 10.

[0070] In some implementations, the low potential electrolysis device 210 can include a register that converts the most recent value from the sensor 10 into a voltage value, while in some implementations, a current-to-frequency converter can be configured to continuously integrate the most recent value measured from the sensor 10, for example, using a charge counting device. In some implementations, an analog-to-digital converter can digitize the analog signal from the sensor 10 into so-called "counts" for processing by the processor module 214. The resulting counts can be directly related to the current measured by the low potential electrolysis device 210 and, in turn, to an analyte level, such as a glucose level, in the host.

[0071] The telemetry module 232 may be operatively connected to the processor module 214 and may provide hardware, firmware, and / or software that enables wireless communication between the sensor electronics module 12 and one or more other devices, such as the receiver 102, a display device, a processor, a network access device / gateway, etc. A wide variety of wireless radio technologies may be implemented in the telemetry module 232, including Bluetooth®, Bluetooth® Low-Energy, ANT protocol, NFC (Near Field Communication), ZigBee, IEEE 802.11, IEEE 802.16, cellular radio access technology, radio frequency (RF), infrared (IR), paging network communication, magnetic induction, satellite data communication, spread spectrum communication, frequency hopping communication, short-range communication, etc. In some implementations, the telemetry module 232 includes a Bluetooth® chip, although Bluetooth® technology may also be implemented in a combination of the telemetry module 232 and the processor module 214. Additionally, although in FIG. 2 the telemetry module is depicted as part of ASIC 205, in other implementations some or all of the telemetry module may be separate from the ASIC.

[0072] The processor module 214 may control the processing performed by the sensor electronics module 12. For example, the processor module 214 may be configured to process data (e.g., counts) from the sensors, filter the data, calibrate the data, perform fail-safe checks, etc.

[0073] In some implementations, the processor module 214 can include a digital filter, such as an infinite impulse response (IIR) or finite impulse response (FIR) filter. This digital filter can smooth the raw data stream received from the sensor 10, the data line 212, and the low-potential electrolysis device 210 (e.g., after analog-to-digital conversion of the sensor data). Typically, the digital filter is programmed to filter sampled data at predetermined time intervals (also called a sample rate). In some implementations, such as when the low-potential electrolysis device 210 is configured to measure the analyte at discrete time intervals, these time intervals determine the sampling rate of the digital filter. In some implementations, the low-potential electrolysis device 210 is configured to continuously measure the analyte, for example, using a current-to-frequency converter. In these current-to-frequency converter implementations, the processor module 214 can be programmed to request a digital value from the integrator of the current-to-frequency converter at predetermined time intervals (acquisition time). These digital values ​​obtained from the integrator by the processor module 214 may be averaged over the acquisition time for continuity of the current measurement. Thus, the acquisition time may be determined by the sampling rate of the digital filter.

[0074] The processor module 214 may further include a data generator configured to generate data packages for transmission to devices, such as the receiver 102. Additionally, the processor module 215 may generate data packets for transmission to these outside sources via the telemetry module 232. In some example implementations, the data packages may be customizable, as described above, and / or may include any available data, such as timestamps, displayable sensor information, converted sensor data, sensor and / or sensor electronics module identifier codes, raw data, filtered data, calibrated data, rate of change information, trend information, error detection or correction, etc.

[0075] The processor module 214 may also include a program memory 216 and other memory 218. The processor module 214 may be coupled to a communication interface, such as a communication port 238, and a power source, such as a battery 234. Moreover, the battery 234 may be further coupled to a charger and / or regulator 236 to power the sensor electronics module 12 and / or charge the battery 234.

[0076] The program memory 216 may be implemented as a pseudo-static memory for storing data, such as identifiers (e.g., sensor identifiers (IDs)) of the coupled sensors 10, and for storing code (also referred to as program code) for configuring the ASIC 205 to perform one or more of the operations / functions described herein. For example, the program code may configure the processor module 214 to process, filter, calibrate, perform fail-safe checks, etc. on data streams or counts.

[0077] The memory 218 may also be used to store information. For example, the processor module 214 including the memory 218 may be used as a system cache memory, providing temporary storage of recent sensor data received from the data lines 212 and the low potential electrolysis device 210. In some implementations, the memory may comprise memory storage components such as read-only memory (ROM), random access memory (RAM), dynamic RAM, static RAM, non-static RAM, easily erasable programmable read-only memory (EEPROM), rewritable ROM, flash memory, etc.

[0078] The data storage memory 220 may be coupled to the processor module 214 and may be configured to store a variety of sensor information. In some implementations, the data storage memory 220 stores one or more days of continuous analyte sensor data. For example, the data storage memory may store 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 20, and / or 30 (or more) days of continuous analyte sensor data received from the sensor 10 via the data line 212. The stored sensor information may include one or more of a timestamp, raw sensor data (one or more raw analyte concentration values), calibrated data, filtered data, converted sensor data, location information, and / or any other sensor-related or displayable information.

[0079] The user interface 222 can include various interfaces, such as one or more buttons 224, a liquid crystal display (LCD) 226, a vibrator 228, an audio transducer (e.g., a speaker) 230, a backlight, etc. The components that comprise the user interface 222 can provide controls for interacting with a user (e.g., a host). The one or more buttons 224 can enable, for example, a toggle, a menu selection, an option selection, a status selection, a yes / no response to an on-screen question, an "off" function (e.g., for an alert), a "snooze" function (e.g., for an alert), a reset, and / or the like. The LCD 226 can provide, for example, visual data output to the user. The audio transducer 230 (e.g., a speaker) can provide an audible signal in response to the triggering of a given alert, such as current and / or predicted hyperglycemic and hypoglycemic conditions. In some implementations, the audible signal can be differentiated by tone, volume, duty cycle, pattern, duration, etc. In some implementations, the audible signal may be configured to be muted (e.g., snooze or off) by pressing one or more buttons 224 on the sensor electronics module and / or by signaling the sensor electronics module using a button or selection on a display device (e.g., a key fob, cell phone, etc.).

[0080] Although audio and vibration alerts are described with reference to Figure 2, other alert mechanisms may also be used. For example, in some implementations, a tactile alert is provided that includes a poking mechanism configured to "poke" the patient in response to one or more alert conditions.

[0081] A battery 234 may be operably connected to the processor module 214 (and possibly other components of the sensor electronics module 12) and can provide the necessary power source for the sensor electronics module 12. In some implementations, the battery is a lithium manganese dioxide battery; however, any suitable size and power battery can be used (e.g., AAA, nickel-cadmium, zinc-carbon, alkaline, lithium, nickel-metal hydride, lithium-ion, zinc-air, mercury-zinc oxide, silver-zinc, or sealed). In some implementations, the battery is rechargeable. In some implementations, multiple batteries can be used to power the system. In yet other implementations, the receiver can be powered transcutaneously, for example, via inductive coupling.

[0082] The battery charger and / or balancer 236 may be configured to receive energy from an internal and / or external charger. In some implementations, the battery conditioner (or balancer) 236 regulates the charging process by reducing excess charging current to allow all cells or batteries in the sensor electronics module to be fully charged without overcharging other cells or batteries. In some implementations, the battery(ies) 234 are configured to charge via an inductive and / or wireless charging pad, although any other charging and / or power supply mechanism may also be used.

[0083] One or more communication ports 238, also referred to as external connectors, may be provided to enable communication with other devices; for example, a communication (com) port on a personal computer (PC) can be provided to enable communication with systems separate from or integrated with the sensor electronics module. The communication port can comprise, for example, a serial (e.g., universal serial bus or “USB”) communication port for communication with another computer system (e.g., a PC, a personal digital assistant or “PDA,” a server, etc.), a dongle with a wireless transceiver coupled to a docking station, described in more detail below, and / or any other interface. The communication port can also be coupled to or include a wireless transceiver to enable wireless communication. In some implementations, the sensor electronics module 12 can transmit historical data to a PC or other computing device (e.g., a secure server as disclosed herein) for retrospective analysis by the patient and / or physician.

[0084] In some continuous analyte sensor systems, the on-skin portion of the sensor electronics may be simplified to minimize the complexity and / or size of the on-skin electronics, for example, providing only raw, calibrated, and / or filtered data to a display device such as receiver 102 configured to execute the calibration and other algorithms described above with respect to sensor electronics module 12. However, sensor electronics module 12 may also be implemented to execute the expected algorithms used to generate the converted sensor data and / or displayable sensor information, including, for example, algorithms to evaluate the clinical acceptability of the reference and / or sensor data, evaluate calibration data for optimal calibration based on clinical conditions, evaluate the quality of the calibration, compare estimated analyte values ​​to measured analyte values ​​over time, analyze variability in estimated analyte values, evaluate the stability of the sensor and / or sensor data, detect signal artifacts (noise), replace signal artifacts, determine rate of change and / or trends in sensor data, perform dynamic and advanced analyte value estimation, perform diagnostics on the sensor and / or sensor data, set the mode of operation, evaluate data anomalies, etc.

[0085] 5 shows separate data storage and program memory, various configurations may be used. For example, sensor electronics module 12 may use one or more memories to provide storage space to support data processing and storage requirements.

[0086] Although some of the described examples refer to continuous analyte sensor 10, glucose meter 4, and pump 2 in communication with sensor electronics module 12 and / or receiver 102, other devices may also be used. For example, sensor electronics module 12 and / or receiver 102 may be coupled (either via wired and / or wireless links) to other sensors, including glucose sensors, altimeters, accelerometers, temperature sensors, location modules (e.g., global positioning system processors or other sources of location information), heart rate monitors, blood pressure monitors, oximeters, calorie intake monitors, medication delivery devices, etc.

[0087] As described above, sensor electronics module 12 can generate data packages and transmit the data packages via wireless or wired media to a device, such as receiver 102, configured to receive, store, forward / retransmit, and / or display the sensor data. As described above, sensor electronics module 12 analyzes sensor data from multiple sensors and determines which sensor data to transmit based on one or more of numerous characteristics of the host, receiver 102, a user of receiver 102, remote monitor 114, and / or characteristics of the sensor data. Furthermore, one or more of the functions and / or components described herein with respect to sensor system 8 may also or instead be found in one or more of receiver 102, gateway, or secure server 110, and one or more of the functions described herein with respect to receiver 102 may also be found on sensor system 8.

[0088] 2A for illustrative purposes, the receiver 102 can forward the analyte sensor data, as well as other available data, to the gateway 104 via wired and / or wireless links. In some implementations, the gateway 104 can include a network interface configured as a radio interface, such as a cellular radio interface (e.g., Long Term Evolution, etc.), a wireless local area network interface (e.g., Wi-Fi, etc.), and / or any other type of wireless or wired interface. For example, the gateway 104 can include at least one processor that includes a radio frequency subsystem (e.g., a modem). In these wireless examples, when the receiver 102 couples to the gateway 104, the gateway 104 transmits the analyte sensor data, etc., wirelessly to the secure server 110 via the network 108A, which can include an access network, a wireless local area network, a radio access network, a cellular network, the Internet, and / or any other communication mechanism. In some implementations, the gateway 104 may also include a wireless access network 108A, which further couples to a secure server 110.

[0089] The gateway 104 can automatically transmit the sensor analyte data and additional information from the receiver 102 in one or more of a number of ways. For example, the receiver 102 can provide the information to the gateway 104 without a request from the gateway. The information can be provided automatically, such as after a timer expires or upon the generation of a new sensor data point, or in response to user input to the receiver 102. The gateway 104 can then automatically transmit the information from the receiver to the secure server 110. In another example, the gateway can automatically request the information based on predefined rules, such as after a timer expires, such as a five-minute timer. The information provided by the receiver 102 may then be automatically transmitted to the secure server 110. In yet another example, the gateway can send a request for information to the gateway 104, which then forwards the request to the receiver 102. The receiver 102 then provides the requested information to the gateway, which then forwards the information to the secure server 110. In each of these examples, the requested information may be specific information (e.g., sensor data for a particular time period) or simply a general request to transmit information. In the latter case, the receiver 102 may determine what information to transmit in response to the request, such as any new sensor data generated by the receiver since the receiver last provided information to the server 110.

[0090] 6 is a block diagram of an example implementation of the gateway 104. The gateway 104 may include a power supply module 302 for charging the receiver 102 when coupled to the gateway 104, a wireless network interface 304 for enabling wireless access to the network 108A using a variety of network access technologies, although a wired connection to the network 108A may also be provided by the gateway 104, and computer memory for a processor 314 to store instructions for performing the functions of the gateway 104 and to store health-related information received from the receiver 102.

[0091] Additionally, the gateway 104 may include a receiver interface 306 that provides a wired and / or wireless interface to the receiver 102 in implementations where the receiver is separate from the gateway and the gateway does not include an intermediate docking station 103. For example, the receiver interface 306 may include a Universal Serial Bus interface through which the receiver 102 can communicate with the gateway, the secure server 110, etc. The Universal Serial Bus may also provide a physical connection for charging the receiver 102, although wireless charging may also be used. Moreover, the receiver interface 306 may include a wireless interface, such as Bluetooth, Bluetooth low energy, Zig-Bee, Atom, or any other wireless technology, through which the receiver 102 can communicate with the gateway 104, the secure server 110, etc. The gateway 104 may also include a user interface 310, such as a display, a touch screen display, a keypad, a speaker, a light emitting diode, etc. For example, one or more light-emitting diodes may be used to indicate whether gateway 104 is properly coupled to receiver 102, network 108A, secure server 110, etc., whether gateway 104 is connected to a power source (e.g., an outlet), whether a battery is charging, etc. The display may also allow for the presentation of sensor data, alerts, notifications, etc. For example, a user interface such as a display, light-emitting diode, etc. may provide an indication, such as a particular colored light-emitting diode, message, etc., that a connection, such as an Internet Protocol connection, a secure tunnel, etc., has been established between gateway 104 and secure server 110 so that a user of gateway 104 knows that the receiver is coupled to the so-called "cloud," which includes secure server 110.

[0092] As mentioned above, in some implementations, the gateway 104 may comprise a smartphone having a host monitoring application stored thereon that configures the smartphone to perform the functions of the gateway 104 described herein.

[0093] 7A and 7B illustrate an example of a docking station 700, which may be the docking station 103 described with reference to FIG. 2C. FIG. 7A shows a perspective view of the docking station 700 without the receiver 102 physically coupled to the docking station, and FIG. 7B shows a front view of the docking station with the receiver 102 physically coupled to the docking station. The docking station 700 may have a cavity 710 that allows the receiver 102 to be slidably inserted into and removably retained in the docking station. The docking station 700 may also include a mechanical mechanism (not shown) for removably securing the receiver 102 to the docking station. The mechanism may be a latch assembly or the like. The docking station may be electrically coupled to the receiver 102 via an electronic connector, such as a Universal Serial Bus connector, and / or a wireless interface, such as Bluetooth®, Bluetooth® low-energy, Wi-Fi, and any other wireless technology, and may transmit data received from the receiver 102 to the host communication device 105, the secure server 110, or the remote monitor 114 using the electronic connector and / or Bluetooth®, Bluetooth® low-energy, Wi-Fi, and any other wireless technology.

[0094] The docking station 700 can also function as a repeater and / or amplifier of any alerts triggered by the receiver 102 and / or the secure server 110. For example, the docking station 103 can receive an indication of an alert triggered by the receiver 102 from the receiver. The docking station 700 can repeat the alert and indicate the alert to the user, for example, by emitting an audible alert, generating a vibration, and / or illuminating a light-emitting diode. Moreover, the receiver 102 can alert using a first alert, such as a vibration, while the docking station 700 can re-alert using a second type of alert that is different from the first alert. For example, the first alert can be a vibration alert and the second alert can be an audible alert, or vice versa. As another example, the first alert can be an audible alert and the second alert can also be an audible alert, but the second audible alert is louder and / or has a different tone pattern than the first alert.

[0095] In some implementations, the docking station 700 can trigger an alert by physically sensing the alert from the receiver 102. For example, the docking station can include vibration and / or sound sensors that can sense vibrations or sounds, respectively, emanating from the receiver 102. In this manner, the docking station 103 can trigger an alert when it detects that the receiver 102 is triggering an alert while the receiver is docked at the docking station.

[0096] Additionally, the alert settings at the docking station 700 may be the same as or different from the alert settings at the receiver 102. For example, the alert settings at the docking station 700 may be more stringent than the alert settings at the receiver 102. For example, the receiver 102 may have a low glucose threshold at a value greater than the corresponding low glucose threshold at the docking station 700. The alert settings at the docking station 700 may be user-configurable, for example, using a user interface at the docking station or a user interface at the host communication device 105.

[0097] Additionally or alternatively, in some implementations, the docking station 700 delays triggering an alert triggered by the receiver 102 to allow time for the host to resolve the alert before the docking station triggers the alert. If the host resolves the alert before the delay expires, the docking station 700 does not trigger the alert.

[0098] 7A and 7B, the docking station 700 may include one or more indicator lights, such as LEDs, that indicate the status of the docking station 700 and / or other components of the system 100. For example, a first indicator light 712 may indicate (by lighting up or changing color) whether the docking station 700 is receiving power from an external power source, and a second indicator light 714 may indicate (by lighting up, changing color, or flashing) whether the docking station is paired to the host communication device 105. Other indicator lights may also be used, such as a third indicator light that indicates whether a communication channel between the docking station 700 and the host communication device 105 and / or secure server 110 has been opened and sensor data has been successfully transmitted from the receiver 102.

[0099] 8 illustrates another example implementation of gateway 104. In the example of FIG. 8, gateway 104 is configured as a dongle, such as a Universal Serial Bus dongle, and includes a Universal Serial Bus connector 392 for coupling to receiver 102 and a user interface, such as a button 394, for performing Bluetooth pairing to another device, such as host device 105, that has access to network 108A, or directly to network 108A over a Wi-Fi or cellular communication channel. While the gateway / dongle may be configured for Bluetooth pairing, the gateway / dongle may also support establishing connections to other devices using other radio access technologies, such as Bluetooth low energy, Wi-Fi, Atom, Zig-Bee, NFC, etc. 8 may also include a light emitting diode 396 to provide an indication of the status of the gateway 104 or the receiver 102 (e.g., battery level, glucose level status, whether the user is in a hypo- or hyperglycemic state, connection status to the network, connection status to the secure server, etc.). In some implementations, the gateway of FIG. 8 may include its own rechargeable battery to power the gateway and / or receiver 102, but may rely on the receiver 102 as a power source.

[0100] In some implementations, the gateway 104 may include a radio frequency interface to allow data to be automatically uploaded in compressed or uncompressed format from the receiver 102 to the secure server 110, as described, and may be implemented as a so-called "cloud." Additionally, the upload may occur programmatically, without user intervention, when the receiver 102 is in communication with the gateway 104. The gateway 104 may also be configured to collect an identifier for the receiver 102 (or the receiver may automatically provide the identifier without a request for the identifier from the gateway 104) and provide the identifier to the secure server 110 to allow the secure server 110 to associate the received sensor data with the host 199, the receiver, and any previously provided sensor data stored on the secure server 110 associated with the host (or a repository coupled to the secure server 110). In some implementations, the identifier is the serial number of the receiver 102, and the receiver automatically transmits the identifier in addition to any sensor data it provides to the gateway. Moreover, in some implementations, gateway 104 may be configured to transmit data incrementally, i.e., previously received data is not retransmitted to secure server 110 unless requested by secure server 110. Furthermore, gateway 104 may select between a cellular connection and a Wi-Fi connection based on connection speed, cost, etc. For example, if available, a free Wi-Fi connection may be selected over a paid cellular connection. Furthermore, while a cellular connection may be used to transmit substantially real-time data generated by sensor system 8, in some implementations, a Wi-Fi connection is used to transmit historical data because transmitting historical data in a timely manner may not be important.

[0101] In some implementations, the gateway 104, the receiver 102, the sensor system 8, and the remote monitor 114 may be pre-configured such that when the sensor system 8 and the receiver 102 are communicatively coupled to the gateway 104, the gateway 104 recognizes the sensor system / receiver and / or its user. Additionally, the remote monitor 114 may also be recognized by the server 110 to allow remote monitoring of the receiver 102 to occur with little, if any, configuration by the end user / host of the receiver 102. For example, the secure server 110, the gateway 104, the receiver 102, the sensor system 8, and the remote monitor 114 may be pre-configured and pre-registered with little, if any, configuration or registration effort on the part of the host.

[0102] 2A-2C, network 108A may include a wireless access network, such as a cellular network, a wireless local area network, etc. Additionally, network 108A may be coupled to other networks. For example, gateway 104 may be coupled to an access network served by a base station or a Wi-Fi access point, which may have backhaul links to other networks, including a public land mobile network, the Internet, etc. Networks 108B-C may be implemented in the same or similar manner as network 108A.

[0103] The secure server 110 may receive the analyte sensor data, store the analyte sensor data, process the analyte sensor data to detect events, thereby enabling the generation of notifications to the remote monitor 114 and / or the generation of alerts to the receiver 102 and / or gateway 104, generate pages or reports for display on the remote monitor 114, the receiver 102, and / or the gateway 104, and enable registration and / or configuration of the host 199, the sensor system 8, the receiver 102, the gateway 104, and the remote monitor 114.

[0104] In some implementations, one or more entities may have remote monitors 114A-114M. For example, secure server 110 may register the identities of users of remote monitors 114A-114M and the schedules on which each entity performs monitoring. Moreover, one or more of the entities may be configured with secure server 110 as a primary monitor for receiving notifications, while other entities may be configured as backup secondary monitors for receiving notifications if the primary monitor does not acknowledge or act accordingly on notification messages sent to remote monitors 114 according to one or more predefined rules. Furthermore, secure server 110 may include one or more rules that define when an event will result in a notification to one or more of remote monitors 114.

[0105] The secure server 110 can also provide a cloud-based diabetes data management framework that receives patient-related data from a variety of devices, such as medical devices, glucose meters, continuous glucose meters, sensor systems, receivers, and / or other devices, including any device disclosed herein (e.g., devices that provide food intake, such as carbohydrates, consumed by the host or patient, medication delivery data, time of day, temperature sensors, movement / activity sensors, etc.). Additionally, the cloud-based diabetes data management system can receive data programmatically with little or no intervention on the part of the user. The data received from devices, receivers, source systems, etc. can be in a variety of formats and can be structured or unstructured. For example, the secure server 110 can receive raw sensor data, which has been minimally processed or analyzed, from the sensor system 8 and the receiver 102, and the received data is then formatted, processed (e.g., analyzed), and / or stored to enable report generation by the secure server 110. In addition to sensor data, the secure server 110 can also receive data from source systems such as healthcare management systems, patient management systems, prescription management systems, electronic medical record systems, personal health record systems, and the like.

[0106] In some implementations, the secure server 110 can check for errors associated with the transmission of received data, data format, device-related error codes, data validation, duplicate data points, and / or other aspects of the data. Furthermore, if out-of-range data points or device errors are detected, the secure server 110 can identify these data points, for example, by flagging them, and then programmatically or by a system administrator correct the identified data points and store the corrected data points. Additionally, the secure server 110 can be configured by a user, such as a clinical technician or physician, to perform additional data processing steps, such as time correction, date correction, and analysis of specific cohort, group, and relationship-specific data (e.g., age, city, state, gender, race, type 1 diabetes, type 2 diabetes, age at diabetes diagnosis, lab results, prescription medications used, patient self-reported medical conditions, patient diagnosed medical conditions, answers to questions asked of the patient, and any other metadata describing the host / patient). Once secure server 110 performs the initial data processing (eg, checking, cleaning, and analyzing), the processed and / or unprocessed data may be stored in a repository coupled to secure server 110.

[0107] Processing at secure server 110 may also include associating metadata with the data received from the devices and / or sensors. Examples of metadata include patient information, the key used to encrypt the data, patient accelerometer data, location data (e.g., the patient's location or the patient's hospital location), time, date, the type of device used to generate the associated sensor data, etc. Patient information may include the patient's age, weight, sex, home address, and / or any past health-related information, such as whether the patient has been diagnosed with type 1 or type 2 diabetes, high blood pressure, or any other medical condition.

[0108] Processing may also include one or more of: determining one or more descriptive measures, detecting or predicting an event (e.g., hypoglycemia, hyperglycemia, and / or any other feature detected in the sensor data), applying a pattern detector to the received sensor data, and analyzing the information, such as generating a report based on the received information, such as the sensor data, and descriptive measures of the information, including the sensor data. Descriptive measures may include statistics (e.g., median, within and outside interquartile range, mean, sum, n, standard deviation, and coefficient of variation). In some implementations, the secure server 110 can also associate metadata with data received from devices, sensors, source systems, and / or receivers; determine one or more descriptive measures, such as statistics (e.g., median, interquartile range and out-of-range, mean, sum, n, standard deviation, and coefficient of variation); generate reports including the descriptive measures; authenticate and verify the integrity of the data received from devices, sensors, source systems, and / or receivers; process the received data based on the metadata (e.g., to select a given patient, device, medical condition, type of diabetes, etc.); and / or correlate the data received from devices, sensors, source systems, and / or receivers so that the data can be compared and combined for processing, including analysis. Furthermore, the results of any processing performed by the secure server 110 can be used to generate one or more reports, such as graphs, bar graphs, static charts, charts, etc. Moreover, reports and other output generated by the secure server 110 can be provided to the receiver 102, the remote monitor 114, and any other processors via one or more delivery mechanisms.

[0109] Secure server 110 may be considered secure in the sense that it stores private patient-identifiable information and / or restricts access to users registered, i.e., authorized, to use secure server 110. For example, secure server 110 may receive a request from a device, such as receiver 102 or remote monitor 114, to perform an action (e.g., provide data, store data, analyze / process data, request a report, request configuration information, request registration, etc.). Before secure server 110 services the request, secure server 110 may process the request to determine whether the request is authorized and certified. For example, the authorization and certification functions may determine whether the source of the request is authorized by requiring the user to provide security credentials (e.g., a user identifier, password, stored security token, and / or authentication identifier provided via text message, phone call, or email) at a user interface presented on a processor, such as receiver 102, remote monitor 114, and / or any other computer. If approved, the authorization and certification functions can authenticate the sender of the request and check whether the security credentials associated with the sender of the request indicate that the sender is indeed authorized to access specific resources in system 100 to perform actions such as storing (or uploading) data to a repository, performing analysis / processing of data, requesting report generation, receiving alerts, receiving notification messages, etc.

[0110] In some implementations, the secure server 100 can include a pattern detector to perform pattern detection on data such as sensor data representing blood glucose data, analytes, and other data (e.g., insulin pump data, carbohydrate intake data, etc.). The pattern detector can detect patterns and generate an output that can be provided to a report generation function at the secure server to generate an alert to the receiver 102, a notification message to the remote monitor 114, and / or a page containing a report.

[0111] Moreover, the pattern detector can detect patterns in data / sensor data retrospectively for a predetermined period defined by the system 100 and / or a user. For example, the pattern detector can receive input data from a repository coupled to the secure server 110, where the input data can include sensor data representing glucose concentration data, analytes, and other data (e.g., insulin pump data, carbohydrate intake data, histograms, and / or counts, data from continuous glucose monitors (CGM data), time of day, carbohydrate amounts, other food-related information, exercise, wake / sleep intervals, medications taken, etc.). Moreover, the input data can include historical data obtained over a time frame such as 8 hours, 1 day, 2 days, 7 days, 30 days, and / or any other period. For example, the input data can include counts representing monitored analyte detection levels (e.g., glucose concentration levels) received and stored by the system 100 over a period covering a 4-week time frame.

[0112] To further describe the pattern detector, patterns can be recognized based on one or more predefined triggers (also referred to as conditions, rules, and filters). Furthermore, the one or more predefined triggers may be programmatically variable and adjustable based on user input and / or based on one or more rules located on secure server 110. And, while some types of patterns may be selected, enabled and disabled, and / or modified by the user, the user's physician, or the user's guardian, system 100 may programmatically select, adjust, and / or otherwise modify triggers.

[0113] Some examples of the types of relationships in the input data that can be considered patterns are one or more of: a glucose level above a target glucose range (which may be defined by a user, a healthcare professional, the secure server 110, or a combination thereof); a glucose level below a target glucose range; a rapid change in glucose level from low to high (or vice versa); the time of day when a low, high, range, or rapid glucose level event occurred; the day on which a low, high, range, or rapid glucose level event occurred; a hyperglycemic pattern; a hypoglycemic pattern; a pattern associated with time of day or day of week; a weighted score for different patterns based on frequency, sequence, and severity; a user's custom sensitivity; a transition from a hypoglycemic to a hyperglycemic pattern; the amount of time spent in a severe event; a combination of glucose change and time information; and / or a pattern of high variability in glucose data. Additionally, patterns may be based on a combination of previous pattern data and a currently detected situation, whereby the combined information generates a predicted alert.

[0114] Time-of-day hypoglycemic patterns may be detected based on events detected by secure server 110. For example, a pattern may be identified in which a user has low glucose levels at approximately the same time of day. Another type of pattern that may be identified is a "hyperglycemic rebound" situation. For example, a hyperglycemic rebound may be defined as a user over-correcting a hypoglycemic event by over-increasing glucose intake, resulting in a hyperglycemic event. These events may be detected based on one or more pre-defined triggers.

[0115] To further illustrate examples of patterns, basic patterns may be configured to allow for the search for predetermined patterns of data, such as values ​​within a range, a high coefficient of variation, etc. Each pattern may have one aspect, such as within the range, another pattern specifically detecting values ​​below the range, another detecting a low coefficient of variation, etc. Each pattern may be statistically based, using standard descriptive statistics in pattern matching applications. Each pattern may be assigned a score for various rules encoded in the pattern, such as positive or negative, how important the consideration is, etc. Each pattern may also be assigned a set of possible data ranges to which the pattern is applicable. For example, counting the number of times a high glucose value is followed by a low value below the range is a pattern that applies only to the entire range. However, detecting high levels of variation may apply to a month, a week, a day, a daytime, every two hours, every hour, and combinations thereof. Every pattern may be assigned a minimum acceptable score before it can be considered for display or generation of an alert to be sent to the receiver 102 (or host 199) or a notification message to the remote monitor 114. Each pattern (and any associated triggers / rules) may be processed against a set of data for a predetermined time frame, and if the pattern applies and meets predetermined minimum requirements, the pattern is ranked according to significance. Each ranked pattern in this manner may correspond to an alert sent to receiver 102 (or host 199) and / or a notification message sent to remote monitor 114 (or a primary or secondary monitor accessing remote monitor 114).

[0116] 1, host monitoring system 198A can have a single remote monitor 114A or multiple remote monitors 114A-114M, and rules associated with when remote monitors receive alerts and the types of alerts to be sent may be stored on secure server 110. For example, a first remote monitor 114A may receive notification messages during the day, while a second remote monitor 114B may receive notification messages at night, although other schedules may also be used. Additionally or alternatively, a first remote monitor 114A may receive notifications only if the server identifies host system 198 as being in a predetermined geographic location, such as a school (e.g., using geographic location information provided by host system 198), while a second remote monitor 114B receives notifications regardless of the host's geographic location. As another example, a first remote monitor 114A may have high and low thresholds that trigger an alert to the remote monitor 114A that are different from one or both of the high and low thresholds that trigger an alert to the remote monitor 114B. Additionally, one or more rules may define the first remote monitor 114A as the primary monitor, while the second remote monitor 114B may be defined as a backup or secondary monitor.

[0117] The remote monitor 114 can acknowledge the received notification message at 194 (FIG. 3) by enabling (e.g., opening, interacting with, accessing, selecting, etc.) the remote monitoring application, causing a message to be sent to the secure server 110, or responding to a message presented in the remote monitor's user interface. If the secure server 110 does not receive some form of acknowledgement that the user has seen or otherwise acknowledged the notification message on the remote monitor after a predetermined amount of time (which may depend on the severity or type of event), the secure server 110 can resend the notification to the remote monitor 114. In some implementations, the secure server 110 can receive a message from the notification service 112 that the remote monitor 114A has failed or is otherwise unreachable, in which case the secure server 110 can resend the notification message to a different remote monitor 114B. The delay used by the secure server to resend notification messages may be configurable based on the severity or type of event, and the secure server may also include rules defining a default number of failed retransmissions or a default amount of time before escalation to another primary monitor, a secondary / backup monitor, emergency medical services, etc. And this default number of failed retransmissions may also be configured in the secure server to vary based on the severity or type of event or user configuration.

[0118] In some implementations, referring to FIG. 1 , remote monitor 114 can receive notification messages for a single host monitoring system 198A or multiple host monitoring systems 198A-198N. Additionally, pages may be generated by secure server 110 and then sent to one or more remote monitors for presentation in a user interface on each of the remote monitors, or secure server 110 may alternatively send data to remote monitor 114 to enable page generation at the remote monitor. Pages may include text and / or graphic indications of the status of one or more hosts being monitored. To illustrate, a school nurse may have a remote monitor 114 with a page representing each of the host monitoring systems 198A that the remote monitor is monitoring. Each remote monitoring system 198A-198N may be associated with one student. In this example, the page may include status information for each of the students, a recent notification message for each of the students, a graphical or textual indication that the student is within limits or an indication that the student is over limits, etc. Each student may be associated with a cell (a defined space on the display). In this way, the nurse can quickly view the user interface and see the status of each of the students being monitored. Graphical indications may be used within each student's cell to visually communicate each student's overall status. For example, a so-called "smiley" face icon may indicate that the student's glucose level is within limits, while a so-called "sad" face icon may indicate that the host's glucose level is above a threshold and therefore of concern. Moreover, in some implementations, this page may be presented on the display such that selection of a cell, notification, or face icon (e.g., by touching a touchscreen, hovering over, clicking, etc.) provides additional information to the remote monitor.For example, selecting a student's cell may cause the remote monitor 114 to access the secure server 110, which may then receive additional information, such as one or more of the latest or previous glucose levels, patient information, etc., and update the display page or navigate to a new display page displaying more detailed information about the selected student (e.g., displaying a trend graph of the student's glucose levels over the past three hours). Although the above examples refer to glucose levels and specific types of messages and icons, other types of events, messages, and icons discussed herein may be used to communicate the status of the host. Dashboard

[0119] In some implementations, the above-described pages may be configured as so-called "dashboards" that include dynamic content. For example, icons for host patients requiring the greatest care or attention (e.g., patients with very high or low glycemic levels) may be placed in the top row of the page to allow a remote monitor to quickly check the status of higher-risk host patients. While the above arrangement is described using the top row of the page to distinguish some of the so-called higher-risk host patients, other distinction schemes may be used (e.g., different colors, densities, and / or locations on the page). Moreover, the patients distinguished for extra attention may change over time, and the page may be considered dynamic because the page will display different icons for different patients in the distinguished top row of the page. An example dashboard is discussed in more detail with reference to Figures 18A and 18B. Specifying a remote monitor

[0120] In some implementations, an entity such as a user may be designated by secure server 110 as a primary remote monitor. In this case, the primary monitor at remote monitor 114 may be unavailable due to, for example, a dead battery, a malfunctioning device, or a lack of radio reception at remote monitor 114A. A secondary remote monitor may therefore be designated by secure server 110 to receive notification messages that would otherwise be sent to the primary monitor. The secondary monitor has access to another remote monitoring device 114B and can therefore receive a notification message if a first notification message to the primary monitor is not received or acknowledged within a predetermined amount of time. The amount of time can vary based on the severity or type of event. In addition to monitoring for acknowledgements from remote monitor 114, secure server 110 can access a quality of service mechanism of notification service 112 to determine if the remote monitor 114 device is not operational (due to malfunction, dead battery, out of range, or otherwise not receiving notification messages) and enable secure server 110 to select another operational monitor. petition

[0121] In some implementations, the remote monitor 114 can generate a message for presentation requesting some form of confirmation or action by the user of the remote monitor 114 (e.g., the primary or secondary monitor) to acknowledge receipt of the notification message. The confirmation or action can include responding to the notification message, opening a remote monitoring application on the remote monitor 114, etc. Furthermore, if the action is not performed within a predetermined amount of time, the secure server 110 can determine that the user of the remote monitor has not seen (or otherwise been notified of) the notification message. In this case, the secure server can escalate the notification message to another remote monitor as defined by one or more rules residing on the secure server. The secure server can also check the push notification service (or a quality of service mechanism therein) to determine whether the notification message has been delivered. If not, the secure server can determine that the user of the remote monitor has not seen the notification message and use this as evidence to escalate the notification message to another remote monitor.

[0122] In some implementations, the secure server 110 can include one or more rules defining an escalation sequence that defines which notification messages should be sent to a first remote monitor 114A and, in the case of a failure condition, when to resend the messages to one or more other remote monitors 114B-114M. During configuration of the remote monitors 114A-114M, the secure server 110 can configure, via user input (e.g., from the host and / or one or more of the remote monitors), how and / or when each of the remote monitors 114A-114M is notified in the escalation sequence. This escalation sequence configuration can be user-defined or provided as a default setting (which may be reconfigurable or adaptable over time based on user / host / monitor responsiveness) and can vary based on the severity of the event and the type of event. For example, the escalation sequence may define rules that define when to alert the host patient at the receiver 102, when to escalate to the primary monitor 114A, when to escalate to the secondary remote monitor 114B, and / or when to escalate to emergency medical services or a 911 ambulance.

[0123] In some implementations, the escalation rules may be different for each of the remote monitors 114A-114N and / or may be different from the set of thresholds in the host monitoring system 198. For example, a first rule may define that the secure server 110 should send an alert to a first remote monitor 114A if the glucose value exceeds a first threshold. The secure server 110 may include a second, separate rule that defines sending a notification message to a second remote monitor 114B if the glucose value exceeds a second threshold, and a third, separate rule that defines sending a notification message to a third remote monitor 114M if the glucose value exceeds a third threshold. In addition, a rule may define sending notifications to more than one remote monitor, such as all or a subset of the remote monitors monitoring the host. Rules may be configured by the user (e.g., using the receiver 102, gateway 104, workstation 22, etc.) or provided as default settings (which may be reconfigurable by the user).

[0124] Additionally, an escalation sequence may also be implemented if the user does not acknowledge the alert at the receiver 102 within a predetermined amount of time. For example, referring to FIG. 2A , the secure server 110 may determine that the receiver 102 has (or should have) alerted the host 199 if the alert requires acknowledgment (e.g., by monitoring sensor data received from the receiver 102 and knowing thresholds on the receiver). The acknowledgment may be in the form of the user resolving the alert, such as by responding to a message presented on the user interface 122 of the receiver 102 or by the user taking some other action that can be measured by a device associated with the host user (e.g., a drug pump 2 indicating insulin has been administered to the user, an analyte measurement indicating the underlying cause of the alert is no longer an issue because the measurement level exceeds a threshold or the trend is moving in a desired direction, etc.). In this example, if secure server 110 does not receive some form of confirmation and / or indication that the underlying event that triggered the alert has been resolved after waiting a predetermined amount of time, secure server 110 may resend the alert and / or send a notification message to a primary remote monitor (e.g., 114A), a secondary remote monitor (e.g., 114B), and / or emergency medical services, and this escalation, including retries and delays, may be configured by secure server 110 to vary based on the severity and / or type of event triggering the alert. Reminders

[0125] In some implementations, secure server 110 can include rules that provide so-called "follow-up" reminders. For example, if the host user has not taken an action on receiver 102, such as taking insulin or drinking a glass of juice, secure server 110 can send a reminder notification to remote monitor 114 and / or receiver 102 and / or gateway 104 after a predetermined amount of time. The predetermined amount of time and any one or more of remote monitors 114A-114M, receiver 102, and / or gateway 104 associated with the reminder may be configurable and may vary based on the severity of the event and / or the type of event.

[0126] Additionally, in some implementations, the secure server 110 can repeatedly resend notifications to the remote monitor 114 and / or receiver 102 (e.g., every five minutes or any other time period) until receipt of the notification message is acknowledged. In some implementations, the secure server 110 can configure different alert types to be triggered by the receiving device (e.g., the remote monitor 114 or receiver 102) as each retransmission is sent to the receiving device (e.g., the remote monitor 114 or receiver 102) (e.g., successively increasing volume, brightness, or vibration with each repetition; unacknowledging the notification message; triggering a vibration alert on a first reminder and a vibration alert on a second reminder, etc.). Opening a message from the secure server 110 on the receiving device can serve as an acknowledgement, as well as other actions detectable by the secure server.

[0127] In some implementations, a user designated as a primary monitor can signal to secure server 110 that they are unable to provide monitoring by, for example, using remote monitor 114A or workstation 22, sending a message to secure server 110 and / or receiver 102. In this case, secure server 110 can demote the primary monitor to a secondary (or backup) monitor and promote one of the secondary monitors to the primary monitor. The secure server can have rules that define which of the secondary monitors may be promoted, or each of the secondary monitors may be polled to assess their availability to serve as the primary remote monitor. Secure server 110 can then send a message (e.g., via a notification service) to the secondary monitor that has been promoted to the primary monitor designated as the primary monitor (and send a corresponding message to the demoted primary monitor).

[0128] To ensure quality of service with respect to receipt of notification messages by the remote monitors, one or more operations may be performed to mitigate potential loss of notification messages sent to the remote monitors 114. For example, if notification service 112 includes a push notification service (e.g., Apple Push Notification Server, Google Cloud Messaging Server, etc.) and the notification service cannot be contacted (or a connection cannot be established between secure server 110 and notification service 112), secure server 110 may send a notification to the remote monitors 114 via another mechanism, such as another short message service (SMS) message directly, a phone call, an email, or any other mechanism, to establish contact with the remote monitor(s) and / or users associated with these remote monitoring devices. Remote monitoring registration / invitation

[0129] As noted above, in some implementations, devices used in system 100 may be required to register with secure server 110. To illustrate, and referring to FIG. 2B , receiver 102 (which may be implemented on a processor-based wireless device, such as a smartphone or tablet computer) sends a message over a public land mobile network or other network(s) to invite remote monitor 114 to accept a connection establishment request from secure server 110. If accepted, remote monitor 114 may be provided with notification messages of events associated with receiver 102, as well as access to sensor data and reports associated with host 199. While the above example described receiver 102 sending details to remote monitor 114, depending on the implementation, other devices, such as secure server 110, gateway 104, user communication device 105, workstation 22, and / or remote monitor 114, may also or instead send invitations.

[0130] In some implementations, the receiver 102 can send multiple invitations to each of multiple remote monitors 114A-114M. Furthermore, the invitations may be managed by the receiver 102, the gateway 104, the user communication device 105, and / or the secure server 110, so that at any given moment, the user can monitor the status of the invitations, such as how many invitations have been sent, how many have been accepted, how many have been rejected, and the identity of any primary and secondary remote monitors. For example, the receiver 102, the gateway 104, the user communication device 105, and / or the secure server 110 can manage the invitations so that the number of remote monitors 114A-114M at any given moment does not exceed a threshold amount (e.g., 5 or 10 remote monitors).

[0131] Additionally, the receiver 102, gateway 104, user communication device 105, and / or secure server 110 may also manage the quantity of remote monitors 114 based on location and / or time, such that a host user has a predetermined quantity of remote monitors 114 at any given location and / or at any given time.

[0132] In some implementations, the host 199 or a caregiver of the host can manage the status of invitations (e.g., invitations sent, invitations accepted, monitoring canceled, etc.) via the receiver 102, gateway 104, user communication device 105, and / or secure server 110. For example, one or more user interaction pages may be presented on a computer display (e.g., the receiver 102, gateway 104, user communication device 105, or workstation 22) including the status of the invitation (e.g., whether the invitation is pending, rejected, or accepted). These one or more pages may be configured to allow changes to rules associated with the remote monitors 114A-114M. For example, changes may be made to the rules used to trigger notification messages, such as the primary monitor designation (including time and location designation), secondary monitor designation (including time and location designation), escalation sequence, and escalation threshold settings. Additionally, the page(s) may provide a list of remote monitors from which the user can designate primary and secondary remote monitors and send invitations to any selected monitor. The page(s) may allow for configuration of permissions, such as whether the remote monitor 114 is authorized to receive one or more notification messages and whether it is authorized to view patient data (e.g., sensor data, including current and / or historical data).

[0133] 12 depicts an exemplary invitation page 500 presented at the remote monitor 114 in the form of an email message. In this example, a user "John Doe" associated with the sensor system 8 and the receiver 102 has invited the remote monitor 114 to be a monitor, as indicated by the invitation at 502. Additionally, the invitation may include instructions for the remote monitor, in this example, to click on a link at 504 to enable download of the remote monitor application code from the secure server 110 or another server (e.g., an iTunes® server operated by Apple, Inc.), and to accept the invitation at 506 (thereby sending an acceptance message to the secure server 110). The remote monitor may also be given the option of not accepting the invitation to monitor by selecting a user-selectable decline icon 508, which can communicate a decline instruction to the secure server 110.

[0134] In some implementations, to register an invited remote monitor 114 with the secure server 110, the remote monitor and receiver 102 may each enter a value, such as a code, a shared secret, a link (e.g., a uniform resource locator), a password, or a combination thereof, to receive notification messages for events associated with the receiver 102 and have access to sensor data and reports on the secure server 110. Additionally, a user, such as a host 199, may access an internet browser, for example, using the workstation 22 of FIG. 1, to access the secure server 110 and log in to view and manage one or more devices for which they have been granted remote monitoring privileges.

[0135] Establishing a connection refers to the process of adding one or more remote monitors to the system 100 to provide a second layer of oversight over the operation of the sensor system 8 and the receiver 102. A connection to a remote monitor 114 may be established based on an invitation sent to the remote monitor 114. The invitation may be sent with the consent of the receiver 102, the gateway 104 (e.g., via a user interface therein), and / or the host 199. For example, the receiver 102 and the remote monitor 114 may be required to both accept the invitation or enter a code (e.g., a password, a shared secret, etc.) to consent to the remote monitoring provided to the system 100.

[0136] In some implementations, one or more of the devices of the remote monitoring system 100 (e.g., the remote monitor 114, the receiver 102, the gateway 104, the user communication device 105, or the workstation 22) may require a code, such as a prescription code provided by a healthcare professional, to register with the secure server 110. The code may expire after a predetermined time and / or may be limited to a predetermined number of uses (e.g., a single-use code that can be used once to register with the secure server 110 to obtain a remote monitor code). Additionally, the code may also define the configuration of the device registered as a remote monitor 114 with the server 110, such as the remote monitor's permissions (e.g., whether it can receive notifications, view past sensor data, and / or view the most recent sensor data) and / or alert settings associated with the remote monitor.

[0137] In some implementations, the secure server 110 can have configuration information defining the identities of the receiver 102 and the remote monitor 114 so that a user, such as a host 199, can access the secure server 110 and then add one or more devices, such as the receiver 102 and the remote monitor 114, to the user's system. The remote monitor 114 can query the secure server 110 to obtain information about the hosts (or receivers) that the remote monitor is capable of monitoring, and the secure server can configure the remote monitor 114 accordingly. In some implementations, notification messages sent to a remote monitor can be configured to suit the needs of a given remote monitor user, which may differ from the needs of a host patient. Thus, the rules governing the sending of notification messages to the remote monitor 114 may differ from the rules for triggering alerts to the receiver 102 used by the host patient.

[0138] 2A , an illustrative example of a caregiver using the remote monitor 114 as part of host patient care is provided. Specifically, the caregiver may be administering analytical therapy to the host patient. For example, the caregiver may be the parent of a young child. In this example, the parent may wish to receive notification messages that are identical to the alerts sent to (or triggered by) the receiver 102 and the host patient (the child in this example). Additionally, the secure server 110 can obtain the settings of the receiver 102 through the gateway 104. During configuration of the remote monitor 114, the secure server 110 can prompt the parent to select a set of rules that are identical to those used by the child's receiver. In this example, any subsequent changes made to the set of rules used for the child's receiver are programmatically propagated to the set of rules used to send notifications to the parent's remote monitor 114. While the above example describes the same set of rules being used from the host and monitor, the host and monitor can also implement different rules.

[0139] The following provides another illustrative example of a host patient managed therapy, where the host patient or caregiver may not desire a high degree of supervision of the host patient. In this regard, the caregiver may notify the remote monitor 114 that the host patient initially receives an alert, but allows the patient host time to act on the alert to correct or acknowledge the event before the alert is sent to the caregiver. As an example, an alert triggered by the receiver 102 may indicate a hypoglycemic or hyperglycemic event, and if after a predetermined time the host patient has not taken one or more predefined actions to correct the event (e.g., evidenced by subsequent glucose readings indicating the same or worsening patient condition), the caregiver may receive a notification message on the remote monitor 114 in response to this event. That is, if the patient host using the receiver 102 does not respond to or acknowledge the alert in a predefined manner, the caregiver may receive a notification message on the remote monitor 114. The caregiver can receive a notification message at the remote monitor 114, and thus at the receiver 102, when the host patient fails to respond to or acknowledge a predetermined real-time event, such as a low glucose event (which may be considered serious because the host patient may be impaired or unaware of the event, and for which notification to the remote monitor is desirable). However, the secure server 110 either delays sending reminders in response to the notification message or stops sending reminders when one or more predetermined occurrences are identified by the secure server. The one or more predetermined occurrences can take predetermined action, such as correcting the underlying event triggering the alert, acknowledging the alert, or administering insulin.

[0140] Additionally, secure server 110 may be configured to include a delay for waiting for confirmation or action before notifying remote monitor 114, which may vary based on the type and / or severity of the condition generating the alert and may vary depending on default or user-configured settings of the remote monitor. Additionally, secure server 110 may be configured to monitor data from receiver 102 even after a confirmation message is received from receiver 102 in response to an alert. For example, secure server 110 may receive a confirmation message (which may be a message sent by receiver 102), but the secure server 110 may wait a predetermined amount of time for sensor data from receiver 102 to confirm that the host patient has indeed taken action. Again, this delay may vary based on the type and / or severity of the condition generating the alert.

[0141] The following provides another illustrative example of a host patient administering therapy, where the host patient is highly independent and the remote monitor may only be triggered in an emergency. For example, secure server 110 may include rules for triggering the remote monitor in an emergency, such as if a severe hypoglycemic event occurs overnight. In this case, the host patient may not be able to respond to an event alert, so secure server 110 may trigger a notification message if glucose drops to an extremely low level for a certain period of time or if the user does not respond to a very low glucose alert sent to receiver 102 after a certain period of time. This period may vary based on the type and / or severity of the condition generating the alert.

[0142] The following provides another illustrative example of a host patient who is highly independent, but who is unaware of hypoglycemia and has no reliable source of information for emergency response. In this case, the host patient can select a remote monitor 114 associated with emergency medical services to automatically notify the services in the event of a severe hypoglycemic event if the glucose falls to an extremely low level for a period of time or if the user does not respond to a very low glucose triggered by the receiver 102 after a period of time. Managing Remote Monitor Alert Settings

[0143] In some implementations, a user can manage the alerts of each of the remote monitors 114A-114M monitoring the host 199. For example, the host 199 can use the host monitoring system 198A to invite the remote monitor 114A to be a monitor and configure permissions on the secure server 114 using the receiver 102, gateway 104 (including the host communication device), or workstation 22. Permissions may be specific to one or more given alerts or may be global, meaning that all of the alerts on the remote monitor 114A may be manipulated by the user. While the above examples describe permissions as being set by the user, permissions may also be determined programmatically.

[0144] To manage alerts, a user can access the secure server 110 using a computing device, such as the remote monitor 114, the receiver 102, the gateway 104, the host communication device 105, or the workstation 22, to manage alerts, for example, by setting alerts, changing thresholds, enabling or disabling alerts, etc. FIG. 13 illustrates an exemplary page 600 that may be presented on the display of a host computing device. Page 600 may allow changes to the alerts of a given remote monitor 114A. In the example of FIG. 6, a low glucose alert 602 may be enabled at 610, and threshold 604 defines the threshold configured by the user. FIG. 6 also illustrates that a delay 606 may be managed using page 600. For example, delay 606 may define how long the secure server 110 waits before sending a notification message from the secure server to the remote monitor 114A (via the notification service) if the host's glucose concentration remains below a low threshold. In this example, the delay is 0 seconds, but can be changed using page 600 to be another amount of time, such as 5, 10, 15, or 30 minutes, or 1 hour. Page 600 also allows secure server 110 and / or notification service 112 to trigger the sending of a reminder 612 and vary the time 606 associated with the triggering of the reminder. For example, if the remote monitor does not acknowledge the alert or the host does not resolve the event that originally triggered the alert, the reminder indicates the amount of time that will elapse before secure server 110 triggers another notification of remote monitor 114A. In this example, if the user fails to acknowledge the alert or take corrective action within 30 minutes of the original notification in response to a reading below 70 mg / dL, secure server 110 sends another notification of the low glucose level to remote monitor 114A. Although the example described with reference to FIG. 6 refers to low glucose values, delays, and reminders, any other aspect of the remote monitor 114 alerts described elsewhere herein, such as high glucose level alerts, high rate of change alerts, etc., can be similarly managed.

[0145] 6 refers to managing alerts on the remote monitor 114, a similar page can be used by the receiver 102, the gateway 104, or the host communication device 105 to manage alerts triggered by the host communication device in the implementation of FIGS. 2A-2C. By way of example, the host communication device 105 can display page 600 for managing alerts by the host communication device independently of the receiver 102. In this manner, the host communication device 105 can function as a secondary alerting device for the host 199.

[0146] In some implementations, a user can change one or more rules that define alerts that represent events associated with the host's analyte status. A user can change alert settings, such as low glucose level thresholds, of the host monitoring system 198 using a computing device, such as the remote monitor 114, receiver 102, gateway 104, host communication device 105, or workstation 22. In this manner, for example, a parent can change settings on their child's remote monitoring system 198.

[0147] While the above examples refer to modifying a low glucose alert, the modifications may include varying a first threshold associated with a low glucose level in the host, varying a second threshold associated with a high glucose level in the host, varying the delay between when a message is triggered by the receiver 102, varying the time value between when a reminder message is sent, or any other alert that may be triggered to the host monitoring system 198 or remote monitor 114.

[0148] Additionally, the secure server 110 can adapt a set of rules associated with the host 199. For example, a set of rules for the remote monitor monitoring the host 199 may be predetermined based on some basic host patient demographics. After the initial use of the remote monitoring system 100, the secure server 110 can programmatically adjust the thresholds used to trigger some or all events. These adjustments may be made for a variety of reasons. For example, thresholds for glucose level, glucose rate of change, etc. used to determine when to trigger an event may be adjusted to reduce the frequency of some alerts and / or notifications, since a remote monitor 114 receiving too many messages may decide to ignore them. Thresholds may also be adjusted to narrow the range of a patient's glucose fluctuations during the day to reduce fluctuations in the host's daily glucose variability.

[0149] In some implementations, data management tools and CGM analysis may be used to help improve a patient's diabetes management or to assist physicians in reinforcing recommendations. Because glucose data (and / or other analyte data) may be provided to the secure server 110 in near real time, the data may be used by case managers in payer systems and / or healthcare systems to enhance ongoing diabetes management. However, it may be impractical for diabetes case managers to review the resulting so-called "big data." Thus, to facilitate efficient use of case managers' time by identifying specific issues, filters may be used to enable exceptions based on reported usage or glycemic patterns. In this regard, one or more patterns may be defined on the secure server to identify issues requiring case manager attention. Patterns may include longitudinal analysis or comparisons over time. These patterns may also identify high-risk patients, such as those with frequent or severe lows, frequent or severe highs, and / or notable glucose variability. This may be considered important for use with patients on intensive insulin therapy, particularly those who are unaware of hypoglycemia, have poor control, or are not accustomed to insulin. Patterns may also identify non-responders to treatment, such as those with persistent hyperglycemia, suggesting non-responsiveness to treatment or worsening control, suggesting non-adherence, disease progression, or tachycardia resistance. This may be considered useful, particularly when new medications are added or therapy is optimized. Patterns may also be linked to diabetes education or identify responders or non-responders by a particular provider or consultant.

[0150] In some example implementations, additional performance information may be collected by the secure server 110 from patients at multiple locations. This additional information may be used to evaluate environmental factors that may impact and affect sensor performance. Rather than collecting and analyzing information only from a single host patient, data may be collected by the secure server and then compared at a macro level across multiple host patients and / or multiple geographic locations (or regions). That is, the overall effectiveness of the sensor system 8 may be evaluated based on the various environmental factors being monitored. For example, data collected in real time across the United States or even the world can indicate whether temperature, humidity, altitude, etc. affect the performance of the sensor system 8 and thus provide an indication of whether the sensor system 8 and / or sensors 10 should be replaced or repaired. Moreover, the secure server 110 can process the received sensor information and identify patterns (e.g., by lot number, region, etc.), and additional algorithms, calibration information, or fail-safes may be uploaded based on these identified patterns to improve the accuracy and / or performance of the sensor.

[0151] In some implementations, the secure server 110 can programmatically track the product performance and utilization of a sensor system, including the sensor 8 and / or the receiver 102. For example, the sensor system and / or the receiver can programmatically provide information to the secure server 110 that identifies the sensor (e.g., lot number) and summarizes its performance. Performance metrics can include accuracy, timeliness, data capture, etc. Moreover, if one or more sensor performance metrics fall outside of expected ranges, the secure server 110 can request that additional information be transmitted from the sensor system / receiver to the secure server to enable classification of the failure mode. For example, the secure server 110 can send alerts and / or notifications to the receiver 102, the gateway 104, and / or the remote monitor 114 that the sensor system 8 and / or the receiver 102 need to be maintained (e.g., replaced, repaired, calibrated, etc.) based on the determined performance information. Additionally, secure server 110 may also be configured to send warning or notification messages based on the performance information, indicating that a sensor needs to be reset, that new calibration values ​​are needed, or that a new sensor should be ordered. The data provided to secure server 110 is configurable and may be stored in a repository coupled to secure server 110.

[0152] Additionally, tracking of the sensor system by the secure server may include tracking the performance of the receiving wireless interface. For example, when a hardware error (or any detected error condition) occurs, information related to the error may be transmitted to the secure server 110. The transmitted data may also be used to track feature usage and may include alert settings, screen visit counts, etc. Additionally, this data may be used to collect and manage data during clinical trials. Furthermore, the sensor data transmitted to the secure server 110 may also be extended to track patient performance in glycemic management. In this case, performance metrics may include "time spent" in different glucose ranges, magnitude of glycemic excursions, insulin dosing information, etc. For example, during a continuous glucose monitoring (CGM) session, data may be automatically transmitted to the secure server 110 and / or a linked repository accessible to the host patient and / or the patient's clinical care provider. Thus, the above-described automatic tracking of product performance and failure mode classification may, in some implementations, provide more accurate information regarding product performance, facilitate resolution of sensor issues experienced by patients, and automate product replacement (or shipping) when sensor performance is deemed appropriate for replacement.

[0153] In some implementations, the secure server 110 can provide a closed control loop. Specifically, the secure server 110 can send messages to the receiver 102, and the receiver responds to the secure server 110. Additionally, the secure server 110 can send messages to the remote monitor 114, and the remote monitor 114 responds to the secure server 110. Thus, the secure server 110 can request actions from the receiver 102 and / or the remote monitor 114 and receive confirmation from the receiver 102 and / or the remote monitor 114 once the actions are completed, thereby forming a closed loop. The receiver 102 can include one or more aspects of the functionality provided by the remote monitor 114, and the remote monitor 114 can include one or more aspects of the functionality provided by the receiver 102. Exemplary Host Monitoring System Configuration Process 1000

[0154] 10 is a flowchart illustrating a process 1000 for configuring a host monitoring system 198, according to some example implementations. For illustrative purposes, the configuration process 1000 will be discussed with reference to the remote monitoring system architecture illustrated in FIG. 2C, although the configuration process 1000 can be applied to the architectures of FIG. 2A or 2B, with variations to accommodate different architectures.

[0155] Additionally, to further facilitate understanding, the following components of FIG. 2C are used in one example of process 1000: sensor system 8 and receiver 102 may comprise a DexCom G4 Platinum continuous monitoring system available from DexCom, Inc., where sensor 10 is a DexCom G4 sensor, sensor electronics module 12 is a DexCom G4 transmitter, and receiver is a DexCom G4 receiver; receiver 102 is docked to docking station 103 as shown and discussed with reference to FIG. 7B; host communication device 105 comprises an Apple iPhone® available from Apple, Inc.; each remote monitor 114A-114M may comprise an Apple iPhone® or other mobile phone having a mobile operating system based on iOS® (commercially manufactured by Apple, Inc.), Android® (commercially manufactured by Google, Inc.), or Windows® (manufactured by Microsoft, Inc.).

[0156] At block 1000, a user downloads a host monitoring application system onto the host communication device 105. (It should be understood that the host monitoring application can be downloaded onto the gateway 104 in the implementation of FIG. 2A , for example, or onto the receiver 102 in the implementation of FIG. 2B where a host monitoring application is available.) In some implementations, the host monitoring application is downloaded from a server, which can be independent of (operated by a different entity than) the secure server 110, such as an Apple App Store server operated by Apple, Inc. However, in some implementations, the host monitoring application is downloaded from the server 110. The host monitoring application can include instructions for the host communication device 105 to perform the host communication device functions described herein, such as collecting sensor data from the receiver 102 via the docking station 103, transmitting sensor data to the secure server 110, managing alerts for the host monitoring system 198, inviting users to become remote monitors of the host, managing remote monitor settings, pairing with the docking station 103 and / or the receiver 102, etc.

[0157] Once the host monitoring application is downloaded to the host communication device 105, a user can open the application (e.g., by selecting an icon associated with the host communication application on the home screen of the host communication device) and create an account using the application at block 1012. In addition to storing account information on the host communication device 105, the account is created and stored on the secure server 110. In some implementations, creating an account includes entering user identification information, such as a name, email address, password, and a unique identifier associated with the receiver 102, such as a receiver serial number. As discussed below at block 1016, the receiver serial number can be used to pair the receiver 102 and / or docking station 103 with the host communication device 105, as well as other functions.

[0158] 9 illustrates an example page 900 that the host monitoring application may display to a user in the account setup block 1012 for submitting input of the receiver 102's serial number or other unique identifier. Here, page 900 is a diagram of the serial number location to assist the user in locating the input serial number. Page 900 also provides an alphanumeric input field that the user can select to manually enter the serial number. In addition, page 900 provides selectable icons 902 and 904 that allow the user to take a picture of the serial number using the host communication device 105's camera and scan the serial number using the host communication device 105's barcode scanner, respectively, for serial number entry.

[0159] At block 1014, a user uses the host monitoring application to manage alert settings for the host communication device 105. The host application may initially present default alert settings, and the user may change the default user settings using a user interface on the host communication device 105. In some implementations, the alert settings include repeating one or more alerts on the receiver 102. In this manner, the host communication device may amplify (e.g., trigger a different type of alert on the receiver, such as a louder alert) and / or echo (e.g., only play an audible alert a predetermined amount of time after the receiver alert if the event triggering the alert on the receiver is not resolved) the receiver alert. The alert settings may also include disabling or enabling alerts for various events.

[0160] At block 1016, the user pairs the host communication device 105 with the docking station 103. In some implementations, to pair the host communication device 105 with the docking station 103, the user powers on the docking station and connects the receiver 102 to the docking station. At this point, the host communication device 105 and the docking station 103 begin a pairing and authentication procedure.

[0161] In some implementations, the docking station 103 does not have a display, and therefore, traditional pairing and authentication procedures may not be appropriate. Thus, in some implementations, the receiver 102 provides a serial number stored in the receiver's memory to the docking station 103, and a user enters the receiver's serial number into the host communication device 105. The serial number stored in the receiver's memory may be stored during receiver manufacturing. The host communication device 105 can then transmit the serial number (or an encrypted version of the serial number) to the docking station to establish an authenticated communication channel.

[0162] The following pairing and authentication procedure may be used in some implementations: In response to the receiver 102 docking to the docking station 103, the docking station derives an authentication token from the receiver's serial number (which the receiver transmits to the docking station) and places it in a Generic Attribute Profile (GATT) feature. The docking station 103 then broadcasts and binds to a generic advertisement. The host communication device 105 searches for advertisements. After detecting the docking station 103, the host communication device 105 connects and performs service discovery. The host communication device 105 then attempts to read the aforementioned GATT feature. The docking station 103 responds with an insufficient authentication message (pairing and encryption required). The host communication device 105 then prompts the user to pair with the docking station 103. Both the docking station 103 and the host communication device 105 compromise the long-term keys used for encryption and are then paired. The host communication device 105 then reads the token from the aforementioned feature and uses this feature to verify the authentication of the docking station 103. The host communication device 105 previously derived its unique token from the receiver serial number previously entered into the host communication device in block 1012 and writes this token into the GATT feature of the docking station 103. The docking station 103 then uses this token to verify the authentication of the host communication device and, if authenticated, enters a persistently bound state.

[0163] In some implementations, using the pairing and authentication process described above, if the two devices (receiver 102 and docking station 103) become disconnected at any point, docking station 103 will command an advertisement for connection.

[0164] In block 1018, the user invites a remote monitor 114 using an application on the host device 105. Here, the application may prompt the user to identify information about the potential user of the remote monitor, including a name and email address accessible from a device that can be the remote monitor 114, such as a mobile smartphone or tablet computer. In addition, the application may prompt the user for permissions the user wants the remote monitor 114 to have, such as the ability to display trend graph data, and alert settings the user wants the remote monitor 114 to have. Upon completion, the application sends an invitation to the remote monitor 114, including information in the invitation, such as identifying the information stored on the secure server 110, the permissions, and the alert settings. The user can invite additional remote monitors using the invitation procedure described above. In some implementations, the application may include a page listing the status of all invitations sent by the user.

[0165] It should be noted that the process 1000 may be implemented using a configuration wizard implemented by a host monitoring application on the host monitoring device 105 to guide a user through the configuration process 1000 . Remote monitor setting process example 1600

[0166] Figure 16 is a flow chart of an exemplary process for remote monitoring using remote monitor 114. Similar to process 1000, Figure 16 is described for illustrative purposes only with reference to the architecture of remote monitoring system 100 of Figure 2C.

[0167] At block 1610, a user receives an invitation to become a remote monitor on a computing device, such as a smart mobile phone. An example invitation is illustrated and discussed in more detail with reference to FIG. 12. In some implementations, the user receiving the invitation can either accept or decline the invitation by selecting an accept icon or decline icon, respectively, in the email. Declining the invitation ends process 1600; accepting the invitation causes process 1600 to proceed to block 1620.

[0168] In block 1620, an invitation is programmatically sent to the user via the user's computing device, and if the user accepts the invitation, the user downloads the remote monitoring application. In some implementations, accepting the invitation in block 1610 programmatically triggers the user's computing device to automatically contact a server that has the remote monitoring application. The server can be the App Store operated by Apple, Inc. if the user's device is an Apple mobile device. The user then downloads the remote monitoring application onto their computing device.

[0169] Note that in some implementations, the user of the remote monitor 114 does not need to register with the secure server because in certain implementations, the secure server has the user's account information from when the invitation was created in block 1012 of process 1000 (FIG. 10).

[0170] At block 1630, the user manages alert settings using the remote monitoring application downloaded to the computing device (here considered the remote monitor 114). In some implementations, the alert settings may initially be set to the recommended alert settings set by the person sending the invitation in step 1012 of process 1000 (or default settings if the person sending the invitation did not enter any recommended settings). The user of the remote monitor 114 can then change either the recommended or default settings. Settings may include setting thresholds for when to trigger an alert to the remote monitor, delays, reminders, and no data alert settings, which are discussed in detail elsewhere herein. The remote monitor 114 then transmits the remote monitor settings to a secure store for storage and use in triggering alerts associated with the remote monitor.

[0171] At block 1640, the remote monitor 114 monitors the analyte levels of the hosts pursuant to authorization. Monitoring may include monitoring multiple hosts using the remote monitor, as described in detail with reference to FIG. 1. Monitoring may include receiving notifications triggered by the secure server 110 and sent via the notification service 112, and displaying sensor data accessible from the secure server. For example, in some implementations, a user may enable a remote monitoring application on the remote monitor 114 to display a dashboard page of glucose levels for multiple hosts. Example of an invitation to become a remote monitor

[0172] As described above in block 1610 of FIG. 16 , a user may receive an invitation to remotely monitor a host 199. In some implementations, the invitation is in the form of an email, as depicted in FIG. 12 . The user may accept or reject the invitation using the email. The user may accept the invitation by indicating that the user wishes to install the remote monitoring application by selecting selectable text 504, or reject the invitation by selecting selectable text 508. If the user rejects the invitation, the remote monitoring system 100 may notify the host that sent the invitation of the rejection via the server 110 and / or the notification service 112, for example, by sending a notification to the communication device 105. However, if the user accepts the invitation, the remote monitoring system 100 may notify the host that sent the invitation of the acceptance via the server 110 and / or the notification service 112, for example, by sending a notification to the communication device 105, and process 1600 continues to block 1620.

[0173] In some implementations, receipt of an invitation automatically sets up a remote monitoring account on server 110. That is, the recipient does not need to log in and create an account because the host provided the recipient's account creation information (recipient's name, email, phone number, etc.) when generating the invitation. Additionally, the host can include a photo of the host during the invitation creation process, so that the host's photo can be included in the invitation sent to the recipient (which can help the recipient know the invitation is valid), and the host's photo can be used as the host's photo on the remote monitor (such as on a dashboard, as discussed with reference to FIGS. 18A and 18B and elsewhere).

[0174] In some implementations, the invitation may include a one-time token that the recipient of the invitation can use to accept the invitation without requiring the recipient to log in to the remote monitoring system. The token may be in the form of a GUID (Globally Unique Identifier). The invitation may also include timestamps for when the invitation was sent and when the invitation expires. System Status Display

[0175] In some implementations, a user of the remote monitoring system 100 may not readily know whether the remote monitoring system 100 is working or why the system may not be working. For example, in the implementation of FIG. 2B , the host 199 may not understand that data is being transmitted from the sensor system 8 to the server 110, or even if the host understands that data is not being transmitted, the host may not recognize where the problem lies because the data transmission can resume. Therefore, some embodiments provide a system status page to help the user identify whether the system is working properly and, if not, what the cause of the problem may be.

[0176] 11A and 11B are exemplary displays of a status page 1100 according to some implementations. The status page 1100 includes a status bar 1110 that includes representations of various components of the remote monitoring system 100. In this example, the components of the system 100 include a docking station 1114, a host communication device 1118, and a server 1112. 11A and 11B also include communication channels between each of the components of the system 100, such as a first communication channel 1116 (e.g., Bluetooth) between the docking station 1114 and the host communication device 1118, and a second communication channel 1120 (e.g., Wi-Fi or cellular) between the host communication device 1118 and the server 1122. The status bar 1110 may indicate components and communication channels that are determined to be working and not working. For example, if the connection is determined to be working, the connection may be graphically displayed in a first state, and if the connection is not working, the connection may be graphically displayed in a second, different state. The first and second states may be indicated, for example, by color (e.g., green for the first state and red for the second state) and / or a grayscale. The status bar may be represented differently using different graphics (e.g., a solid line for a first state and a dashed line for a second state). Additionally, each portion of the status bar 1114, 1116, 1118, 1120, and 1122 may be user-selectable, and when the user selects a particular portion, the host monitoring application may display help information (e.g., in the form of a pop-up message or a new display screen) that may help the user resolve a problem associated with the portion selected by the user. For example, when docking station icon 1114 is in the second state and the user selects the docking station icon, the remote monitoring application may display a message asking the user to ensure that the docking station is plugged in.Additionally, the remote monitoring application may, for example, display a message asking to ensure that the Bluetooth® connection of the host monitoring device is enabled if the first communication channel is in the second state and the user selects the first communication channel.

[0177] The status page 1100 may also include a character icon 1132 that displays the overall status of the system. In the example of FIGS. 11A and 11B , the character icon 1132 is in the form of a monster holding a sign. The appearance of the character icon 1132 may change based on the status of the system, allowing a user to quickly determine the status by looking at the character icon. For example, the character icon 1132 may have a smiling expression and a check mark indicator, as shown in FIG. 11A , indicating that the system is running and transmitting sensor data. In contrast, the character icon 1132 may have an angry expression and an X indicator, as shown in FIG. 11B , indicating that the system is not running. The color of the character icon 1132 may also vary depending on the system status, such as green when the system determines that the system 100 is running (i.e., data is being sent from the host to the server 1110) and red when the system determines that the system is not running.

[0178] The eyes of the character icon 1132 can also help indicate to the user whether the system is running, such as blinking if the host monitoring application is running or not blinking if the eyes are not blinking. The blinking of the eyes can also correspond to the transmission rate between the docking station 103 and the host communication device. In this manner, the user can know whether the remote monitoring system is running effectively, as opposed to the remote monitoring application freezing in a state indicating that the system is running when it is not.

[0179] As shown in FIGS. 11A and 11B, the host monitor application can also display a status tab 1124 on status page 1100 and any other page displayed by the host monitor application. The status tab can be part of a menu including multiple different selectable tabs associated with different display pages of the host monitor application that, when selected, displays the associated display page. The tabs in FIGS. 11A and 11B additionally include a followers tab 1126, an accounts tab 1128, and a details tab 1130. That is, the status tab can always display an indication of the system's connection status, which, if the system is up, is displayed in green with a check mark, as shown in FIG. 11A, and, if the system is down, is displayed in red with an X, as shown in FIG. 11B. The status bar can be displayed regardless of the current page being displayed, thereby providing the user with an indication of the system's status regardless of the page being displayed.

[0180] In some implementations, the host monitoring system 198 may be configured to periodically send messages to the server 110. If the server detects that there have been no messages from the host communication system 198 for a predetermined amount of time, the server may trigger a notification that is sent to the host monitoring system (such as the receiver 102, gateway 104, or host communication device 105), informing the host of the absence of messages so that the host can check to determine whether the host monitoring system is operational using the exemplary status page 1100. Host Monitoring Control Page

[0181] The host monitoring application may also include various display pages that allow a user to view the status of the remote monitors 114 and configure permissions and settings associated with the remote monitors.

[0182] FIG. 14 illustrates an overview page 1400 according to some example implementations. The overview page can include multiple cells 1402a-1402e, each associated with a remote monitor or potential remote monitor. Each cell can include a name 1410a-1410e associated with the remote monitor for identification purposes. Cells 1402a-1402e can also be displayed according to the status of the remote monitor. For example, cell 1402a is grouped under a deleted by remote monitor (referred to as followers in FIG. 14) status 1404a, cell 1402b is grouped under an invitation expired status 1404b, cell 1402c is grouped under an active status 1404c, cell 1402d is grouped under an invited status 1404d, and cell 1402e is grouped under a not sharing status 1404e. Note that multiple cells can appear under each grouping, and that FIG. 14 only illustrates one cell per grouping for ease of illustrating the different groupings.

[0183] Page 1400 also includes selectable help icons 1406a-1406e associated with each group status. By selecting a help icon, the host monitor application can provide the user with further information explaining what the associated status involves. The help information can be displayed, for example, in a pop-up window.

[0184] Icons may also be displayed in cells indicating the permissions and / or enabled features associated with that remote monitor. For example, icons 1412 and 1414 indicate that the remote monitor associated with cell 1402c has notifications enabled and is authorized to view trend graph information associated with the monitored host, respectively. In contrast, if a remote monitor does not have permission for a particular feature, such as viewing trend graphs for a host, the corresponding icon may either not be displayed in the cell or, alternatively, a different icon may be provided to indicate the lack of permission.

[0185] Each cell may also be provided with selectable tabs. For example, FIG. 14 illustrates delete tabs 1408a and 1408b that, when selected by a user, remove the cell from the page. Arrow tabs 1416c-1416e may also be used to provide more information about the remote monitor associated with the cell. For example, selecting selectable arrow 1416 causes the host monitoring application to navigate to a settings display page that provides details about the associated remote monitor and remote monitor settings.

[0186] An exemplary settings display page 1500, according to some implementations, is illustrated in FIG. 15. The settings display page 1500 can include identifying information, such as a name 1502 and email address 1504, associated with a remote monitor, the remote monitor's permissions, and the remote monitor's notification settings. In the example of FIG. 15, the permissions can include a trend graph permissions 1504 tab that a user can use to allow or deny permission to view graphs. If allowed, the remote monitoring system 100 allows the remote monitor to view trend graph information for the host 199; if denied, the remote monitor cannot view trend graph information for the host. The notification settings allow a user of the host monitoring application to view the current notification settings for the associated remote monitor. The notification settings can include an urgent low notification alert 1506, a low notification alert 1508, a high notification alert 1509, and a no data notification alert 1510, with each alert associated with a status (e.g., associated with a threshold and whether the alert is disabled or enabled). In some implementations, a user using the host monitoring application can change the settings of the remote monitor, for example, using page 1500, while in other implementations, some or all of the settings can only be changed by the remote monitor, as shown in FIG.

[0187] The display page 1500 may also allow a user of the host monitoring application to pause and resume the remote monitor 114A's ability to monitor the host 199. A pause / resume control button 1514 may selectively pause and resume the remote monitor's remote monitoring functions, such as pausing and starting notifications sent to the remote monitor and / or the remote monitor's permission to view the host's sensor data. Such functionality may be useful when the host does not necessarily want the remote monitor to monitor the host. A particular example may include a babysitter as a remote monitor. It may be desirable for the babysitter to have remote monitoring capabilities when caring for a child being monitored by the host monitoring system, but to stop remote monitoring when the babysitter is no longer caring for the child. In this way, selective control of babysitter monitoring does not require a new invitation to be sent to the babysitter each time the babysitter cares for a child.

[0188] The remove remote monitor control button 1516 can be used to remove a remote monitor from the list of remote monitors that can monitor the host. In contrast to the pause / resume control 1514, in some implementations, removing a remote monitor using the remove control 1516 requires the host to re-invite the person to become a remote monitor. As described elsewhere herein, the remote monitoring system 100 may have a default limit on the number of remote monitors that can monitor a host, so in some implementations the host may need to remove a remote monitor before the host can add another remote monitor.

[0189] In some implementations, the remote monitoring system 100 sends notification messages to remote monitors whose permissions or settings have been changed, or paused, resumed, or unpaused, by the associated host system. In this way, the remote monitors are notified of changes and are not dependent on previous configurations.

[0190] Additionally, each of the pause, release, and resume functions may be configured globally across all remote monitors associated with the host instead of, or in addition to, individual monitors as described above. For global functions, individual global pause, release, and resume control buttons may be provided on page 1400 (not shown in FIG. 14), e.g., pressing the global control button implements the respective function globally across all remote monitors monitoring the host. Remote monitoring dashboard display

[0191] As described elsewhere herein, the remote monitor 114 can provide a so-called dashboard view of the monitored hosts implemented on the remote monitoring device. Figures 18A and 18B are dashboard pages 1800 of two different implementations, according to some implementations. The dashboard 1800 can include multiple cells 1802a-1802d, each associated with a different host. Each cell 1802 can include an identifier for the host, such as the host's default name, and a photo of the host 1804a-1804d provided in the invitation.

[0192] In the implementation of FIG. 18A , each cell lists the current status of the cell, such as the time 1812 a when the analyte value 1806 a currently displayed in the cell was measured, a description 1812 b of whether the host is using the remote monitoring system 100, a description 1812 c of whether the host's host monitoring system is running, or a description 1812 d indicating that the remote monitor is paused.

[0193] In the implementation of FIG. 18B, cells 1802 may be grouped on page 1800 according to their status, such as removed by host (referred to as Sharer in FIG. 18B) 1814, enabled 1818 (i.e., the system is connected and providing the associated host's data to remote monitoring), disconnected 1824 (i.e., the system is not connected, for example, because the receiver 102 is not in a docking station in the implementation of FIG. 2B), and not shared 1826 (i.e., the host has paused remote monitoring). Additionally, cells within a group may be ordered by the severity of the monitored condition or other conditions, as discussed elsewhere herein.

[0194] Cell 1802 may also include an indication of the permissions and / or settings of a remote monitor associated with that host. For example, trend graph icon 1810 may indicate that the remote monitor has permission to display trend graphs of sensor data for that host.

[0195] 18B, cells 1802 within the active group 1818 may also include information regarding the health condition being monitored. For example, cell 1802 may display the most recent analyte concentration value 1806a provided to the remote monitor and a trend arrow 1808a indicating the rate of change of the measured analyte. Further information may also be provided in the cell, such as the time 1812a associated with the displayed analyte concentration measurement, or whether data has been received from the host monitoring system.

[0196] A user selection of a cell 1802 may also move the remote monitor display to another display page that provides additional information about the host associated with that cell. For example, the remote monitor may be moved to a trend graph display (FIG. 19) associated with that host, or to a settings page (FIG. 17) associated with that host. An arrow ">" may indicate whether more information is available for the cell. Trend graph display

[0197] 19 is an example page providing a trend graph 914 of monitored analyte concentrations for a host, according to some implementations. The trend graph can display a trend line 1916 of the measured analyte concentration, as well as low and high thresholds 1918 and 1920 used to alert either the remote monitor 114 or the host monitoring system 198. The trend graph page can also include a user-selectable slider bar that allows the user to select different time frames of sensor data to display, such as a 3-, 6-, 12-, and 24-hour display. If the remote monitor is monitoring multiple different hosts, the remote monitor can also provide a photo 1904 of the host and the name 1902 of the host to avoid confusion about the individual being monitored.

[0198] 19 may be displayed automatically when the remote monitoring application first opens in response to a user directly opening the application and / or when a user opens a remote monitoring notification on the remote monitor 114 sent by the server 110 or the notification service 112. Illustratively, when a notification is received by the remote monitor 114, the remote monitor may display the notification on a lock or home screen. The user may select the notification (e.g., using a default gesture), which recognition by the remote monitoring device 114 causes the remote monitoring device to display a trend graph for the host associated with the notification. Remote Monitor Settings Page

[0199] FIG. 17 is an example implementation of a settings page 1700 displayed on the remote monitoring device 114 that can allow a remote monitor to configure remote monitoring settings for a host. The settings page can include a photo field displaying a photo of the host 1506 and a name field displaying the host's name, both of which can be changed by the remote monitor using the settings page 1700. In some implementations, the photo and / or name are provided at least initially by the host during the invitation process described above, but the remote monitoring system allows the user of the remote monitor to change the photo and / or name later. The settings page can also include settings / notification settings for various alerts, such as an emergency low alert 1706, a low alert 1714, a high alert 1724, and a no data alert 1736. The functionality of each of these alerts is described elsewhere herein. As illustrated in FIG. 17 , the settings associated with each of these alerts can be changed, such as enabling and disabling the alert, changing the threshold associated with each alert, and changing the alert alarm (e.g., sound, volume, vibration, tone) associated with each alert. Automatic detection of new receivers and registrations

[0200] In some implementations, the receiver 102 needs to be associated with the host 199 so that once the glucose data arrives at the server 110, the data can be associated with the host. Thus, the remote monitoring system 100 can assign the receiver to a host. This can be done initially through the pairing process described above with respect to block 1016 of FIG. 10. When the host receives a new receiver, to ensure a good user experience and prevent errors, the host monitoring application can verify that a different serial number is being used, check with the server 110 to see if this is a new receiver or if this receiver is already owned by another host, and, via the communication device 105, ask if this is the receiver and allow ownership or give an error indicating that it is already owned.

[0201] Thus, an exemplary process for detecting a new receiver may be as follows: First, the host communication device 105 verifies whether a new receiver is being used by verifying with the server whether the receiver is owned by someone else (e.g., by comparing the receiver's serial number with a database). If the server determines that no one else owns the receiver, the host monitoring application asks the user if they would like to make the receiver their own. If so, the receiver and data from the receiver are associated with the host. Data Loss Warning

[0202] In some example implementations, the secure server 110 may include rules for automatically triggering a notification message or another communication mechanism (e.g., a phone call, a short message service message, etc.) to the remote monitor 114 if data has not been received from the host monitoring system 198 associated with the remote monitor for a predetermined amount of time. In this way, the user of the remote monitor 114 may be aware that something may not be right with the host monitoring system 198 and may attempt to contact the host. Location-Based Warnings

[0203] In some implementations, the secure server 110 may use the location of the receiver 102, gateway 104, host 199, and / or remote monitor 114 when determining whether to send a notification message and / or when determining where to send the notification message. For example, when a monitored host is at a first location and moves to a second location, the secure server 110 may select a first remote monitor 114A near the first location based on records, and when the host moves to the second location, the secure server 110 may select a second remote monitor 114B near the second location. Location may also be used to vary alerts and notifications. For example, the secure server 110 may vary the rules used to trigger alerts or notifications based on the location of the host. Location may also be used in combination with the time of day, and the secure server 110 may vary thresholds associated with alerts and notifications based on the location and / or the time of day. Confirmation Notice

[0204] In some implementations, the receiver 102 or gateway 104 can present a prompt (e.g., a message, a window, etc.) in a user interface requesting the host to acknowledge the triggered alert and / or indicate any corrective action taken in response to the alert. The prompt can include a pre-populated list of options (e.g., insulin administered, carbohydrates ingested, etc.) from which the user can select to indicate the corrective action taken. The notification message can be sent directly to one or more remote monitors 114 or via the secure server 110 and / or notification service 112 to the remote monitors so that the remote monitors are aware that the patient has acknowledged the alert and / or that corrective action has been taken (and / or a description of the corrective action).

[0205] Additionally, the remote monitor 114 may allow the user to select from multiple pre-entered messages to send to the host monitoring system. The user may select a notification, at which time the remote monitor displays a list of pre-entered text messages that the user can select to send to the host monitoring system. The message may be selected by the remote monitor to be relevant to the underlying cause that triggered the notification message. For example, if the notification message is triggered by a low glucose level in the host, the message may be a statement related to the low glucose level, such as "Are you feeling unwell?" or "You should have some orange juice." Each message may be user-selectable, and when selected, either directly from the remote monitor to the host system 198 or indirectly, e.g., through the server 110, causes the remote monitor 114 to send the message to the host monitoring system for display on the host monitoring system. Additionally, selecting a notification may automatically display a prompt to call the host, which, when selected by the user, causes the remote monitor 114 to call a phone number associated with the host (e.g., a smartphone that is part of the host monitoring system 198). Message of Support

[0206] In some implementations, the alert and / or notification message sent to the receiver 102 can include a cheering concept. For example, if the host patient achieves a minimal rate of change in glycemic levels, the secure server may send an alert to the receiver 102 and / or a notification message to the remote monitor 114 stating, "Treatment is going well! Keep it up!" These cheering concepts can actively encourage the user to continue with the treatment program. In some implementations, the secure server 110 can include one or more events mapped to cheering concepts, such that triggering an event causes a message containing the cheering concept to be sent to the receiver 102 and / or the remote monitor 114.

[0207] In some implementations, the secure server 110 can use patterns to predict aspects of the patient host's treatment, as described above. For example, a pattern can detect a glycemic change at a given time of day from a previously established pattern, which then triggers a rule that sends an alert to the receiver 102 and a notification to the receiver 114, asking, "Did you skip lunch?" These simple, non-technical query messages can elicit a better response from the host patient to maintain treatment than simply providing measurement data or statistics to the host patient or remote monitor. In some implementations, the secure server 110 can include one or more events mapped to simple messages, such that triggering an event causes a message containing the simple message to be sent to the receiver 102 and / or remote monitor 114. Audit Trail

[0208] Secure server 110 may also provide an audit trail. For example, secure server 110 may store information related to when notifications are pushed to remote monitors 114, e.g., using notification service 112, and when the remote monitors acknowledge the notifications. Secure server 110 may also generate one or more reports to determine timelines and / or identify the effectiveness of remote monitors 114 (which may be used to select remote monitor and / or system 100 settings, such as alert settings, to more effectively monitor hosts 199). timestamp

[0209] In some implementations, the analyte level provided to the remote monitor 114 may not be in real time. For example, while it may be desirable to provide the analyte value to the remote monitor in real time, there may be a time delay between when the analyte value is measured by the analyte sensor system 8 and when the analyte level is provided to the remote monitor 114 and / or secure server 110. The delay may be due, for example, to the sensor system 8 only periodically transmitting values ​​to the receiver 102, the receiver 102 only periodically forwarding values ​​to the gateway 104, the gateway having difficulty connecting to the secure server 110, or the secure server having difficulty connecting to the remote monitor 114. To this end, in some implementations, the glucose value transmitted to the remote monitor 114 is displayed on the remote monitor including a time indicating the corresponding time of the analyte value that triggered the notification (e.g., the analyte value reaching or exceeding the threshold that triggered the notification). The time may be the time the analyte value was measured (e.g., 2:10 PM Pacific Time) or the difference in time since the analyte value was measured (e.g., 2 minutes ago, 30 minutes ago, 4 hours ago, etc.).

[0210] Additionally, due to time delays, the secure server 110 may send notifications to the remote monitor 114 based on time-delayed analyte values. In such cases, the notification may include the time associated with the alert that triggered the notification, such as "Mike's blood glucose level went below 70 mg / dL at 2:10 PST" or "Mike's blood glucose level went below 70 mg / dL 25 minutes ago." Furthermore, because notifications may not be displayed immediately on the remote monitoring device, the remote monitoring device 114 may automatically update any time associated with the notification until the notification is acknowledged.

[0211] To accommodate time zone differences between the host and the remote monitor, according to some implementations, the remote monitoring system can use Universal Time to convert Universal Time to the time zone of the remote monitor. That is, the timestamps of sensor data values ​​generated by the host monitoring system 198 and provided to the secure server 110 can be in Universal Time (UST) or Greenwich Mean Time (GMT) and provided to the remote monitor 114 in the same time zone, thereby causing the remote monitor to convert the common time as indicated by the remote monitoring device to the time zone in which the remote monitor is located.

[0212] In some implementations, notifications sent to the remote monitor 114 do not display the time due to the difficulty of displaying the time due to the time difference between the host monitoring system 198 and the remote monitor 114 and potential time zone differences, which can lead to errors. To remedy the lack of a time indication, some implementations automatically open the remote monitoring application on the remote monitor 114 and display the user's monitored health status information when the user acknowledges the notification. The host's monitored health status information, which is initially displayed when the application is opened, can include an indication of the host's current status, such as the most recent analyte value and / or a trend graph showing the host's measured analyte levels for the past three hours, such as the trend graph page illustrated in FIG. 19. Data transmission loss

[0213] In some implementations, data may sometimes not be transmitted from the sensor system 8 to the secure server 110. Depending on the system, this may be due to an unintentional loss of the data transmission connection between, for example, the sensor system 8 and the receiver 102, the receiver 102 and the gateway 104, the docking station 103 and the host communication device 105, or one or more of the gateway 104 and the secure server 110. Alternatively, the loss may be intentional, such as when a user powers off one or more of the components of the remote monitoring system 100, such as the receiver 102 or the host communication device 105. In any such case, the secure server 110 may be configured to automatically send a notification indicating the loss of data transmission to the host monitoring system 198 and one or more of the remote monitors 114A-114M upon detecting such a loss.

[0214] However, at times, it may be desirable not to send such a data transmission loss notification so that the remote monitor 114 does not receive excessive messages. As an example, the monitored host may be asleep at night and wake up to go to the kitchen to get a drink of water. This could result in a data transmission loss if, for example, the sensor system 8 is out of range from the receiver 102 on the host's 199 bedside table. For this reason, a delay associated with a data transmission loss error can be implemented so that the server 110 initiates a data transmission loss notification only if no data is received after a predetermined amount of time or after a predetermined number of connection attempts with the host monitoring system 198.

[0215] Furthermore, it may be desirable not to send a data loss notification every time there is a loss of data transmission, even if the loss of data transmission occurs over an extended period of time. For example, in the implementation of FIG. 2C , the docking station 103 may be fixed. Thus, the host may be able to transmit health measurements only when the host places the receiver 102 in the docking station and is close enough to the receiver and docking station for data transmission. However, the host may need to remove its receiver from the docking station 103, for example, to go to work. This may not be considered a sufficiently important event, so it may not be desirable to trigger a notification to the remote monitor 114 when the host removes the receiver from the docking station 103.

[0216] Thus, in some implementations, the remote monitoring system 100 can determine that the receiver has been removed from the docking station 103 rather than that the host monitoring system 198 is, for some reason, malfunctioning and not providing sensor data to the secure server. In one implementation, the remote monitoring system 100 determines that the receiver is not present at the docking station 103 by monitoring transmissions from the docking station. For example, a transmission from the docking station 103 that includes information generated by the receiver 102 indicates that the receiver is present, and a transmission from the docking station 103 that does not include information generated by the receiver indicates that the receiver has been removed from the docking station. Eyeglass display device

[0217] While the above disclosure has been primarily described with respect to the use of handheld computing devices, it should be understood that other devices can be used in place of or in place of a smartphone. For example, in some implementations, sensor data is transmitted from a personal computing device to a computing device in the form of eyeglasses, and the user views messages and information displayed on the eyeglasses. An example of such eyeglasses is Google Glass, manufactured by Google, Inc. The user's eyeglasses interface can use a short-range radio link to receive data from the sensor system 8 either directly or through an intermediate device such as receiver 102 or gateway 104.

[0218] In some implementations, the transmission of data may be event-driven, such as driven by the occurrence of a low or high glucose excursion, as discussed herein.

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

[0220] 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 assembly / machine languages. As used herein, "machine-readable medium" refers to any non-transitory computer program product, apparatus, and / or device (e.g., magnetic disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, and includes a machine-readable medium for receiving machine instructions.

[0221] To provide for interaction with a user, the subject matter described 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 a user and a pointing device (e.g., a mouse or trackball) by which the user can provide input to the computer. Other types of devices may also be used to provide for interaction with a user; for example, feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user may be received in any form, including voice, speech, and tactile input.

[0222] The subject matter described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or that includes middleware components (e.g., an application server), or that includes front-end components (e.g., a client computer having a graphical user interface or a web browser through which a user may interact with an implementation of the subject matter described herein), or 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 communications network). Examples of communications networks include a local area network ("LAN"), a wide area network ("WAN"), a public land mobile network, a satellite network, and the Internet.

[0223] While several variations have been described above, other modifications are possible. For example, while the description of specific implementations of the present subject matter discusses a sample application, the present subject matter is also applicable to other types of software and data service access. Further, while the above references specific products, other products may also be used. In addition, the logic flows depicted in the accompanying figures and described herein do not require the particular order shown, or sequential order, to achieve the desired results. Furthermore, as used herein, the term "set" includes zero or more items, and the term "based on" can be used interchangeably with the phrase "based at least on" (unless otherwise specifically stated). Other implementations may be within the scope of the following claims.

[0224] While the present disclosure has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description are illustrative or exemplary and are not to be considered restrictive. The present disclosure is not limited to the disclosed embodiments. Variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed disclosure, from a study of the drawings, the disclosure, and the appended claims.

[0225] All references cited herein are incorporated herein by reference in their entirety. In the event that any references and patents or patent specifications incorporated by reference conflict with the disclosure contained herein, it is intended that the present specification supersede and / or take precedence over any such conflicting references.

[0226] Unless otherwise specifically defined, all terms (including technical and scientific terms) shall be given their ordinary and customary meaning to those skilled in the art and shall not be limited to any special or customized meaning unless expressly defined as such herein. Note that the use of a particular term when describing a certain feature or aspect of the present disclosure should not be construed as implying that the term is redefined herein to be limited to include any particular feature of the feature or aspect of the present disclosure with which the term is associated. Terms and phrases used herein, and variations thereof, should be construed as open-ended, rather than limiting, unless expressly stated otherwise, particularly in the appended claims. As examples of the foregoing, the term "including" should be interpreted to mean "including without limitation," "including but not limited to," etc.; as used herein, the term "comprising" 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 "having" should be interpreted as "having at least," the term "including" should be interpreted as "including but not limited to," the term "example" is used to provide illustrative instances of a described item rather than an exclusive or limiting list thereof, and adjectives such as "well-known," "conventional," "standard," and terms of similar import are used. should not be construed as limiting the items described for a given period of time or available at a given time, but rather as referring to well-known, conventional, or standard technology that may be available or known at any time now or in the future, and the use of terms such as "preferably," "preferred," "desired," or "desired" and words of similar import should not be understood to imply that a given feature is essential, essential, or even critical to the structure or function of the invention, but rather is intended merely to highlight alternative or additional features that may or may not be utilized in a particular embodiment of the invention.Similarly, a group of items joined by the conjunction "and" should not be construed as requiring each and every one of the items to be present in the group, but rather should be construed as "and / or" unless expressly stated otherwise. Similarly, a group of items joined by the conjunction "or" should not be construed as requiring mutual exclusivity among the group, but rather should be construed as "and / or" unless expressly stated otherwise.

[0227] When a range of values ​​is provided, it is to be understood that the upper and lower limits, as well as each intervening value between the upper and lower limits of the range, are encompassed within the embodiments.

[0228] With respect to the use of virtually any plural and / or singular term herein, those skilled in the art can convert the plural to the singular and / or the singular to the plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for clarity. The indefinite article "one" ("a" or "an") does not exclude a plurality. A single processor or other device may fulfill the functions of several items recited in a claim. 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 indication in a claim should not be construed as limiting the scope.

[0229] Furthermore, where a specific numbered introduced claim recitation is intended, such intention will be explicitly stated in the claim; the absence of such a recitation will be understood by those skilled in the art to mean that no such intention exists. For example, as an aid to understanding, the following appended claims may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases should not be construed as implying that introducing a claim recitation with the indefinite article "a" or "an" is intended to limit any claim including such an introduced claim recitation to embodiments including only one such recitation, even if the same claim also includes the introductory phrases "one or more" or "at least one" and an indefinite article such as "a" or "an," and the same applies to the use of a definite article used to introduce a claim recitation. In addition, even if a claim description containing a specific number is explicitly stated, a person skilled in the art should interpret such a description as typically meaning at least the stated number (i.e., a description of only "two descriptions" without other modifiers typically means at least two descriptions, or two or more descriptions). Furthermore, when a rule similar to "at least one of A, B, and C, etc." is used, such a configuration is generally intended in the sense that a person skilled in the art would understand the rule (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, a system 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). When a rule similar to "at least one of A, B, or C, etc." is used, generally such a configuration is intended in the sense that one of ordinary skill in the art would understand the rule (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, a system 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, etc.).Furthermore, it should be understood by those skilled in the art that nearly any disjunction and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, can be interpreted as including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" is understood to include the possibilities of "A" or "B" or "A and B."

[0230] All numbers expressing quantities of ingredients, reaction conditions, and so forth used in the specifications should be understood to be modified in all instances by the term "about." Accordingly, unless otherwise indicated, the numerical parameters set forth herein are approximations that may vary depending upon the desired properties sought to be obtained. At the very least, and not as an attempt to limit the application of the doctrine of equivalents to the scope of any claim in any specification claiming priority to this specification, each numerical parameter should be construed in light of the number of significant digits and ordinary rounding approaches.

[0231] Moreover, while the foregoing has set forth certain details 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 may be practiced. Therefore, the descriptions and examples should not be construed to limit the scope of the invention to the specific embodiments and examples described herein, but rather, to cover all modifications and alternatives that come within the true scope and spirit of the invention. [Explanation of symbols]

[0232] 22 workstations 100 Remote Monitoring System 108 Network 110 Secure Server 114A Remote Monitor 114B Remote Monitor 114M Remote Monitor 198A Host Monitoring System 198B Host Monitoring System 198N Host Monitoring System

Claims

1. receiving, at the remote monitor, a notification message representing an event detected by the server from analyte sensor data obtained from a receiver monitoring an analyte status of the host; presenting, at the remote monitor, the notification message for enabling the remote monitor, the remote monitor being configured by the server to receive the notification message for augmenting the receiver monitoring the analyte status of the host; accessing the server by the remote monitor in response to the presentation of the notification message; and receiving information including at least the analyte sensor data in response to the access.

2. The receiving 2. The method of claim 1, further comprising receiving the notification message from at least a first wireless connection between the remote monitor and a notification service coupled to the server, and wherein the additional information is received from at least a second wireless connection between the remote monitor and the server.

3. 3. The method of claim 1, wherein the first wireless connection comprises a persistent encrypted connection configured to carry short messages pushed by the notification service to a notification message center at the remote monitor, and the second wireless connection comprises a temporary encrypted connection established in response to the access to provide the additional information including at least additional analyte sensor data.

4. The presentation: The method of any one of claims 1 to 3, further comprising: blocking access to one or more applications on the remote monitor until activity on the remote monitor is detected indicating receipt of the notification message, the remote monitor further comprising a monitoring application.

5. The presentation: The method of any one of claims 1 to 4, further comprising presenting said notification message as a temporary message on a display on said remote monitor without blocking said access.

6. The method of any of claims 1 to 5, wherein at least one of the remote monitor and the receiver comprises one or more of a mobile station, a wireless terminal, a tablet, a smartphone, a multi-mode wireless device, and a computer.

7. 7. The method of claim 1, wherein the server comprises at least one processor configured to receive analyte sensor data from the receiver, process the analyte sensor data to detect the event, and, upon detection of the event, forward the notification message to the remote monitor based on one or more rules that map the event to the remote monitor designated to receive the notification message for the detected event.

8. 8. The method of claim 1, further comprising detecting the event based on a first set of rules at the server, wherein the first set of rules used to generate the notification message is different from a second set of rules used to detect an alert to be sent to the receiver coupled to a sensor system at the host.

9. A method according to any preceding claim, wherein the receiver comprises or is coupled to a gateway that interfaces a public land mobile network and a wireless connection to the server.

10. 10. The method of claim 1, further comprising configuring a plurality of remote monitors, wherein at least one of the plurality of remote monitors is designated as a primary monitor and at least one of the plurality of remote monitors is designated as a secondary monitor.

11. The method of any preceding claim, further comprising configuring, by said remote monitor, at least one rule representing a trigger that causes an alert to be sent by said server to said receiver.

12. 12. The method of claim 1, further comprising configuring, by the remote monitor, one or more invitations to be sent to one or more devices inviting the one or more devices to monitor the receiver.

13. The method according to any one of claims 1 to 12, further comprising sending a message to the server confirming receipt of the notification message.

14. 14. The method of any preceding claim, wherein the notification message includes at least one of an indication of a need to calibrate a sensor and a confirmation message indicating at least one of an action or a confirmation sent by the receiver in response to an alert sent to the receiver.

15. The method of any preceding claim, wherein said enabling said remote monitor comprises opening said monitoring application.

16. The access is The method of any preceding claim, further comprising establishing a connection between the remote monitor and the server to enable the reception of the information including the analyte sensor data.

17. 17. The method of any of claims 1-16, further comprising registering at least one of the remote monitor, the receiver, and an analyte sensor coupled to the receiver with the server, the registration including a code provided by a healthcare professional.

18. 18. A remote monitoring system for monitoring a analyte status of a host, said system comprising: at least one processor; and at least one memory comprising code that, when executed by said at least one processor, causes said system to implement a method according to any one of claims 1 to 17.

19. A computer readable storage medium comprising code that, when executed by at least one processor, causes the processor to provide the method of any one of claims 1 to 17.

20. receiving, at the remote monitor, an invitation to access a secure server and data associated with the receiver that monitors the analyte status of the host; modifying, by the remote monitor, rules defining an alert representing an event associated with the analyte status of the host, wherein the alert, when triggered, causes a message to be sent from a server to the remote monitor to notify the remote monitor of the event.

21. 21. The method of claim 20, wherein the alteration of the rule comprises varying a first threshold associated with a low glucose level in the host.

22. The method of any of claims 20-21, wherein the alteration of the rule comprises varying a second threshold associated with high glucose levels in the host.

23. A method according to any of claims 20 to 22, wherein the modification of the rules comprises varying the delay between when the message is sent to the receiver and when a notification message is sent to the remote monitor.

24. A method according to any one of claims 20 to 23, wherein the modification of the rules comprises varying a time value between when the message is sent to the remote monitor and when a reminder message is sent to the remote monitor.

25. 25. A remote monitoring system for monitoring a analyte status of a host, said system comprising: at least one processor; and at least one memory comprising code that, when executed by said at least one processor, causes said system to implement a method according to any one of claims 20 to 24.

26. A computer readable storage medium comprising code which, when executed by at least one processor, causes the processor to provide the method of any one of claims 20 to 24.

Images