Remote monitoring of analyte measurements

Abstract

Methods for remote monitoring are provided. In some example implementations, the methods can include authorizing a request of a first remote monitoring application to receive glucose information of a first host; authorizing a request of a second remote monitoring application to receive glucose information of a second host; establishing a plurality of rule sets; determining that at least some glucose concentration data indicative of a glucose concentration of the first host exceeds or falls below a first threshold; generating a first alert providing event information; sending the first alert to a first remote wireless computing device; receiving and confirming a first confirmation from the first remote monitoring application; determining that at least some glucose concentration data indicative of a glucose concentration of the second host exceeds or falls below a second threshold; generating a second alert providing event information; sending the second alert to a second remote wireless computing device; and receiving and confirming a second confirmation from the second remote monitoring application.

Description

[0001] Related applications

[0002] This application is a divisional application of Chinese invention patent application filed on December 19, 2013, with application number 201810549393.X and invention title "Remote Monitoring of Analyte Measurement".

[0003] Incorporate the relevant application by reference.

[0004] Any and all priority claims identified in the application data sheet, or any amendments thereto, are incorporated herein by reference in accordance with 37 CFR 1.57. This application claims the benefits 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 entirety and are expressly incorporated herein by reference to form a part of this application. Technical Field

[0005] This disclosure generally relates to remote monitoring. Background Technology

[0006] Diabetes is a disorder in which the pancreas cannot produce enough insulin (as in type 1 diabetes) and / or where insulin is ineffective (as in type 2 diabetes). In a diabetic state, patients suffer from hyperglycemia, which causes a range of physiological disturbances associated with the degeneration of small blood vessels (such as kidney failure, skin ulcers, or vitreous congestion). Hypoglycemic reactions (such as hypoglycemia) can be caused by an accidental overdose of insulin or after a normal dose of insulin or glucose-lowering agents accompanied by abnormal exercise or insufficient food intake.

[0007] People with diabetes can carry a self-monitoring blood glucose (SMBG) device, which typically requires an uncomfortable finger prick method. Due to this lack of comfort and convenience, people with diabetes usually only measure their glucose levels two to four times a day. Unfortunately, spreading these intervals so far apart makes it possible for people with diabetes to be too late in detecting the occasional dangerous side effects of high or low blood sugar. In fact, not only will people with diabetes not be able to obtain timely SMBG values, but they will also not be able to know whether their blood glucose levels are high or low based on conventional methods.

[0008] Therefore, various non-invasive, transdermal (e.g., percutaneous) and / or implantable electrochemical sensors are being developed for the continuous detection and / or quantification of blood glucose levels. These and other types of devices generally transmit raw or minimally processed data for subsequent analysis at a remote device that may include a display, allowing information to be presented to the user holding the sensor. Summary of the Invention

[0009] Methods and apparatus for remote monitoring of analyte data are provided, including computer program products. In some exemplary embodiments, a method is provided. The method may include receiving at a remote monitor a notification message representing an event detected by analyte sensor data obtained by a server from a receiver, the receiver monitoring the analyte status of a host; presenting the notification message at the remote monitor to activate the remote monitor, wherein the remote monitor is configured by the server to receive the notification message to augment receiver monitoring of the analyte status of the host; accessing the server through 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.

[0010] In some exemplary implementations, the foregoing aspects may further include additional features described herein, including one or more of the following: Notification messages can be received from at least a first wireless connection between the remote monitor and a notification service coupled to a server, wherein additional information can 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 a short message pushed by the notification service to a notification message center at the remote monitor, and wherein the second wireless connection may include a transient encrypted connection established in response to access to provide additional information including at least additional analyte sensor data. Presentation may further include suppressing access to one or more applications at the remote monitor until an action indicating receipt of a notification message is detected at the remote monitor, wherein the remote monitor may further include a monitoring application. The notification message may be presented as a transient message on a display at the remote monitor without suppressing 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 computer, a smartphone, a multi-mode wireless device, and a computer. The server may include at least one processor configured to: receive analyte sensor data from a receiver; process the analyte sensor data to detect events; and, when an event is detected, 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 the notification message for the detected event. Events may be detected at the server based on a first set of rules, where the first set of rules for generating the notification message may differ from a second set of rules for detecting an alarm sent to a receiver connected to a sensor system at the host. The receiver may include or be connected to a gateway that wirelessly connects to a public terrestrial mobile network and the server via an interface. Multiple remote monitors may be configured, where at least one of the remote monitors may be designated as a primary monitor, and at least one of the remote monitors may be designated as a secondary monitor. Each remote monitor may be configured with at least one rule representing a trigger that causes an alarm to be sent from the server to the receiver. Each remote monitor may be configured to send one or more invitations to one or more devices to invite one or more devices to monitor the receiver. The server may send a message acknowledging receipt of the notification message. The notification message may include at least one of the following: an indication that the sensor needs calibration; and a confirmation message indicating at least one of an action or confirmation sent by the receiver in response to a warning sent to the receiver. Activation of the remote monitor may include opening the monitoring application. A connection may be established between the remote monitor and the server to enable the reception of information including analyte sensor data.The server can register at least one of a remote monitor, a receiver, and an analyte sensor coupled to the receiver, and the registration may include code provided by a healthcare provider. The method can be implemented on a device including at least one processor and at least one memory, the 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 the at least one processor, causes the method.

[0011] On the other hand, a method is provided. The method may include receiving an invitation at a remote monitor to access a security server and data associated with a receiver monitoring the state of an analyte on a host; and modifying rules defining alarms via the remote monitor, the alarms representing events associated with the state of an analyte on the host, wherein, when the alarm is triggered, a message is sent to the remote monitor to notify the remote monitor of the event.

[0012] In some exemplary implementations, the foregoing aspects may further include additional features described herein, including one or more of the following: Modification rules may include changing a first threshold associated with low levels of host glucose, changing a second threshold associated with high levels of host glucose, changing the delay between when a related alarm is triggered by a receiver and when a notification message is sent to a remote monitor, and / or changing the time value at which an alert notification is sent to the remote monitor. The method may be implemented on a device including at least one processor and at least one memory, the 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 the at least one processor, causes the method.

[0013] It should be understood that the above general description and the following detailed description are exemplary and explanatory, not restrictive. Other features and / or variations may be provided in addition to those set forth herein. For example, the implementations described herein may involve various combinations and sub-combinations of the disclosed features and / or combinations and sub-combinations of several other features disclosed below in the detailed description. Attached Figure Description

[0014] In the attached diagram,

[0015] Figure 1 Describe the high-level system architecture of a remote monitoring system based on some exemplary implementations;

[0016] Figures 2A to 2C The illustrations are based on some exemplary implementations. Figure 1 Different system architectures of remote monitoring systems;

[0017] Figure 3Describe an exemplary process for notifying a remote monitor of an event, based on some exemplary implementations;

[0018] Figure 4A and Figure 4B Examples of notification messages 170 and 172 according to some implementation are described respectively;

[0019] Figure 5 Examples of sensor electronic modules according to some exemplary implementations are described;

[0020] Figure 6 It is a block diagram based on the implementation of some gateways;

[0021] Figure 7A and Figure 7B Describe examples of plug-in stations based on some implementations;

[0022] Figure 8 Describe the implementation of a gateway or plug-in station based on some implementations;

[0023] Figure 9 The illustration shows an exemplary display page that facilitates the input receiver's serial number or other unique identifier according to some implementations;

[0024] Figure 10 It is a flowchart depicting the process of setting up a host monitoring system according to some implementations;

[0025] Figure 11A and Figure 11B This is an exemplary view based on some implementations of the status page;

[0026] Figure 12 Describes an exemplary invitation page presented as an email message at a remote monitor, according to some implementations;

[0027] Figure 13 Depicts an exemplary alarm settings page that can be displayed on the monitor of a host computing device;

[0028] Figure 14 The illustration is based on an overview page of a remote monitor displayed by a host monitoring device in some implementations;

[0029] Figure 15 It is based on some implementations of an exemplary remote monitor settings display page displayed by the host monitoring device;

[0030] Figure 16 This is a flowchart of an exemplary remote monitor setup process based on some implementations;

[0031] Figure 17 It involves the implantation of settings pages in some implementations that allow remote monitors to configure the host's remote monitoring settings;

[0032] Figure 18A and Figure 18B These are two different implementations of a dashboard page displayed by a remote monitor, based on some implementations; and

[0033] Figure 19 This is an example page that provides trend graphs of analyte concentrations for monitoring the host, based on some implementations. Detailed Implementation

[0034] The implementations described herein may include systems for one or more caregivers (e.g., parents, spouses, or healthcare providers) to remotely monitor the health characteristics of one or more hosts. Health characteristics may include the host's analyte concentration (e.g., glucose) or bodily functions (e.g., heart rate, blood pressure, or temperature). Additionally, other host characteristics may be monitored to facilitate host care, such as the host's geographic location, host status (e.g., exercise, sleep, or work). A host monitoring system incorporating a computing device (e.g., a smartphone) and one or more sensors (e.g., a continuous glucose sensor, heart rate monitor, GPS device, etc.) may be used to collect health characteristics and other features. Alternatively, the host may manually input information into the computing device, such as meal information, medication time and dosage. The information collected by the host monitoring system may then be transmitted to one or more remote monitors used by the caregiver. The caregiver can then use the remote monitoring system to receive information about the host's health status. In some implementations, the host monitoring system may transmit information directly to one or more remote monitors, and / or the host monitoring system may first transmit the information to a remote server, which then transmits the information to the host monitor.

[0035] For illustrative purposes only, the following examples are non-limiting exemplary environments in which the remote monitoring system described herein can be implemented.

[0036] In this exemplary environment, the host with diabetes is monitored by several different caregivers. The host has a continuous glucose monitoring system, such as the DexCom system commercially available from DexCom, Inc. The Platinum continuous glucose monitoring system provides a measurement of the host's glucose levels on a display device, such as the DexCom system also commercially available from DexCom, Inc. Platinum receiver.

[0037] Furthermore, in this exemplary environment, the display device can communicate with the gateway device, for example, 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 the information to a secure server. The gateway device may include: a smartphone, for example... The device must be either a 4S or an iPhone 5, each commercially available from Apple, Inc.; and a host monitoring software application, which includes instructions configured to make the smartphone act as a gateway. The host monitoring software application can be obtained as a so-called "app" from the Apple App Store, operated by Apple. SM Download now. The gateway can wirelessly transmit information collected from the continuous glucose monitoring system to a secure server via cellular networks, Wi-Fi networks, etc.

[0038] A remote server can store and monitor information received from a remote monitoring system. Monitoring may include comparing the host's glucose level (generated by a continuous glucose monitoring system and transmitted to the server via a gateway) with predetermined thresholds and initiating actions when the threshold is exceeded. For example, the server may compare the current glucose level (e.g., a recently viewed glucose level) with a predetermined glucose threshold and initiate a notification to the remote monitoring system, such as a text message on a cellular network, when the glucose level exceeds the threshold. The server may also provide historical and current glucose levels to the remote monitoring system as needed.

[0039] As described above, a remote monitor can be used by a caregiver to monitor the host's health characteristics, which in this exemplary environment is the host's glucose concentration level. Similar to a 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 that includes instructions configured to make the smartphone act as a remote monitoring system. The remote monitoring software application can be downloaded from the Apple App Store, operated by Apple Inc., in the form of a so-called "application." 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 modify notification rules, such as the threshold level that triggers the notification.

[0040] Further details of the specific implementation are provided below, which may or may not include the features described in the exemplary environment above.

[0041] Figure 1A high-level system architecture is described for an implementation of a remote monitoring system 100. Here, the remote monitoring system 100 includes multiple host monitoring systems 198A-198N connected via a network 118 to multiple remote monitors 114A-114M. Each host monitoring system 198 may be one or more health monitoring devices that collect health-related data associated with a host and transmit the health-related data via the network 108. Exemplary implementations of the health monitoring systems 198A-198N are described in more detail elsewhere in this disclosure, but in some implementations may include one or more sensors and computing devices operatively coupled to the sensors to collect, process, and transmit 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 may also include one or more servers 110 to process health-related data received from one or more remote monitors 114A-114M, and automatically or in response to requests from the remote monitors to transmit notifications and data to one or more remote monitors 114A-114M.

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

[0043] Figure 1 The remote monitoring system 100 may also include a workstation 22. The workstation 22 may be a computing device (e.g., a personal computer) that accesses the remote monitoring system 100 to configure the settings of the system 100 and / or view information associated with one or more host monitoring systems 198, such as reports generated by the remote monitoring systems based on host health-related data.

[0044] use Figure 1 The remote monitoring system 100 allows one or more remote monitors 114A-11M to 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, and simultaneously, 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 restrict which remote monitors 114A-114M can monitor host monitoring systems 198A-118N.

[0045] In a non-limiting instance of the remote monitoring system 100, each host monitoring system 198A-198N includes a smart device, such as an iPhone or iPod from Apple Inc. Mobile devices, and similarly, each remote monitor 114A-114M has 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, which configures the smart device to perform any function of the host monitoring system 198 described herein, including collecting and transmitting health-related data for use in the remote monitoring system 100. The host software application may be an application downloaded using Apple's App Store service. Similarly, each remote monitor 114A-114M has a remote monitoring application downloaded from a server on network 108, which is configured to perform any of the remote monitoring functions described herein, including receiving notifications and requesting health-related data from the host. The remote monitoring application may also be a software application downloaded using Apple's App Store service.

[0046] Figure 2A Examples of a system 100 for monitoring health-related information of a host 199, implemented according to some exemplary embodiments, are depicted. Here, the remote system 100 includes a continuous analyte monitoring system 8, which includes a sensor electronics module 12 and a continuous analyte sensor 10. The 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 finger-prick blood sampler), and any other devices and / or sensors. The continuous analyte sensor 10 may be physically connected to the sensor electronics module 12 and may be integral with the continuous analyte sensor 10 (e.g., non-releasably attached to the continuous analyte sensor 10) or releasably attached to the continuous analyte sensor 10.

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

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

[0049] To illustrate this by example, host 199 can access receiver 102 to view data from continuous analyte sensor 10, delivery pump 2, and / or glucose meter 4, or control aspects of continuous analyte sensor 10, delivery pump 2, and / or glucose meter 4. However, another entity (e.g., a parent, caregiver, healthcare professional, school nurse, etc.) can allow remote monitor 114 to receive notification messages representing certain events determined based on sensor data from receiver 102, continuous analyte sensor 10, delivery pump 2, and / or glucose meter 4, and to view historical and generally real-time sensor data. For example, events may include one or more of the following: a measured analyte sensor value above or below a predetermined threshold, a rate of change or glucose measurement level above a predetermined threshold, a predicted glucose value approaching (or predicted to approach) a predetermined threshold, host 199 not responding to a prompt, message, or alarm displayed on receiver 102, and / or any other event detected by security server 110 and / or receiver 102. Figure 2A In this example, remote monitor 114 describes a notification message 132 indicating a low glucose level in host 199. Therefore, an entity with remote monitor 114 can assist host 199 by providing an additional layer of monitoring and supervision of host 199, along with receiver 102, continuous analyte sensor 10, delivery pump 2, glucose meter 4, etc.

[0050] In some exemplary embodiments, the remote monitor 114 may include a processor, a persistent computer-readable storage medium (e.g., memory, storage device, etc.), a radio access mechanism (e.g., a 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 embodiments, the remote monitor 114 is an iPhone mobile phone from Apple Inc., and the application is an application downloaded via the Internet using Apple's App Store service.

[0051] In some exemplary embodiments, the remote monitor 114 may include one or more of the following: a mobile station, a wireless terminal, a tablet computer, a smartphone, etc. For example, the remote monitor 114 may be implemented as a wireless handheld device, a wireless plug-in accessory, etc. Furthermore, 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 (e.g., 802.11 Wi-Fi), Bluetooth, Bluetooth Low Energy (BT-LE), Near Field Communication (NFC), and any other radio access technology. Additionally, the remote monitor 114 may be configured to use at least one of the multiple radio access technologies to establish a connection with an access point (e.g., a cellular base station, a Wi-Fi access point, etc.) in network 108A. It should also be understood that although some examples herein treat the remote monitor 114 as a mobile, wireless computing device for illustrative purposes, the remote monitor may be implemented as a fixed device (e.g., a personal computer, etc.).

[0052] In some exemplary implementations, the alarm rules for receiver 102 may differ from those for remote monitor 114. For example, a different set of rules may define when alarms are sent to and / or triggered by receiver 102, and when they are compared with the set of rules used to trigger notifications to remote monitor 114. Furthermore, while receiver 102 may trigger alarms itself (e.g., by applying a threshold to sensor data received from sensor system 8), receive alarms from sensor system 8, or receive alarms directly from security server 110, remote monitor 114 may be configured to receive messages (e.g., short messages, text messages, etc.) from notification service 112, and these messages may be used to activate remote monitor 114, such as activating a remote monitoring application on the remote monitor. For example, when the remote monitoring application is not actively used to conserve power on the remote monitor, remote monitor 114 may close the remote monitoring application session (and disconnect the network connection 109 to security server 110). In this scenario, notification service 112 can send a message via network connection 111 to activate remote monitor 114 and / or remote monitoring application (and this activation can be automatic or under the control of the user of remote monitor 114).

[0053] While some instances described herein use security server 110 as an intermediary node between receiver 102 and remote monitor 114, in some exemplary implementations, security server 110 can be bypassed. For example, gateway 104 can communicate directly with remote monitor 114, and vice versa. Additionally, gateway 104 and receiver 102 can receive notification messages to activate an application at receiver 102 or gateway 104 to allow alarms to be sent to the host.

[0054] Figure 3 An exemplary process 197, according to some exemplary implementations, is described for notifying a remote monitor 114 of events associated with receiver 102, continuous analyte sensor 10, delivery pump 2, glucose meter 4, and / or host 199. Figure 3 The description also involves Figure 2A .

[0055] In some exemplary implementations, the security server 110 may register and / or configure one or more of the receiver 102, continuous analyte sensor 10, delivery pump 2, glucose meter 4, and host 199 before process 197 is initiated; however, registration and / or configuration may also occur at other times. The registration process may be executed to register the receiver 102, continuous analyte sensor 10, delivery pump 2, glucose meter 4, remote monitor 114, and / or host 199 with the security server 110. Furthermore, the configuration process may be executed to configure the system 100, including the identity of one or more remote monitors for monitoring the receiver 102, one or more rules for triggering notification messages to the remote monitors, one or more rules for specifying a primary remote monitor and secondary remote monitors, one or more rules for establishing a schedule for the primary and secondary monitors, and one or more rules for defining an escalation sequence representing when an event is escalated to the primary or secondary monitor, etc.

[0056] At 180, receiver 102 can send sensor data (e.g., analyte data from sensor system 8, etc.) to gateway 104, which then forwards the sensor data to security server 110 at 182. For example, receiver 102 can be connected to gateway 104 via a wired or wireless connection, and gateway 104 can be connected to security server 110 via network 108A. Gateway 104 can be configured to retrieve current and / or historical data from receiver 102, either independently or in response to a request from security server 110.

[0057] At 186, security server 110 can determine whether a notification message regarding an event should be sent to one or more of the remote monitors 114A-114M (e.g., remote monitor 114A). Security server 110 can determine whether to send a notification message to remote monitor 114 based on received sensor data (and any other data available on the security server), data that triggers an event (or satisfies a rule) on the security server. For example, security server 110 can receive sensor data at 182 and then process the received sensor data alone or in conjunction with other data (e.g., historical data, data from other sources of patient information, etc.) to determine whether to send a notification message for an alarm event to remote monitor 114. Security server 110 can also receive information from other systems (e.g., health management systems or healthcare provider systems), and this information can be used to trigger a notification message to the remote monitor. Additionally, security server 110 can send a notification message to confirm whether the remote monitor is still actively monitoring host 199.

[0058] To illustrate this, receiver 102 can receive sensor data from host 199 and transmit the sensor data to security server 110 via gateway 104 and network 108A. Security server 110 can process the sensor data and determine glucose level events by comparing the latest glucose level data with a predetermined low glucose threshold; however, it can also detect other events described herein. Security server 110 may include one or more rules defining events (e.g., a low glucose level exceeding a threshold) and rules defining the identity of a remote monitor that receives a notification message indicating a low glucose level in host 199. For example, a rule may define that a remote monitor should receive a notification message when a low glucose level is detected in a host. The notification message may include indications of the low glucose level (e.g., glucose value), the time of the event, and other information such as graphs of current and past glucose levels, host information (e.g., name), and / or any other host-related information.

[0059] One or more rules defining an event may be defined by a user (e.g., host 199, caregiver) during the configuration process, and / or predefined as default rules (which may be reconfigured by the user or modified by system 100 over time to suit the host). In some exemplary implementations, one or more rules may define thresholds representing the severity of an event that should be reported to one or more remote monitors, when a notification message should be sent to each remote monitor, and the identity of one or more remote monitors (e.g., phone number, Internet Protocol address, email address, etc.).

[0060] Furthermore, one or more rules may include escalation rules, allowing events to be handled differently based on the severity of the event, the type of event, and / or the lack of a response from a designated remote monitor. For example, a rule may define that glucose values ​​below a certain value should not be the subject of a notification message to remote monitor 114 (although an alarm message may be sent to receiver 102 or gateway 104 to notify host 199); another rule may define that glucose values ​​within a certain range should be the subject of a notification message to remote monitor 114; and yet another rule may define that a notification message is sent to remote monitor 114A and other remote monitors 114B-114M when a dangerously low glucose value is detected. In some exemplary implementations, the rule used to trigger an alarm to host 199 at receiver 102 may differ from the rule used to send a notification message to remote monitor 114; however, one or more of the rules may also be the same.

[0061] Although the preceding examples describe events associated with low glucose levels, other types of events described herein can also be defined at security server 110 to trigger notification messages to remote monitor 114 and / or trigger alarms to receiver 102.

[0062] At 187, security server 110 can send an alert to receiver 102 and / or gateway 104. The alert can be triggered based on an event that is the same as or different from the event used to trigger a notification message to remote monitor 114. Furthermore, security 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 delay can allow receiver 102 to acknowledge or take action before the message is sent at 188-190, because the receiver can also have the same or different set of rules as the receiver's rules stored on the security server. That is, receiver 102 can trigger an alert based on rules residing within the receiver, and the receiver can receive an alert from the security server based on a different set of rules stored on the security server. The security server can vary the delay before security server 110 sends a notification to receiver 102 based on the severity or type of the event, and the delay can be configured by the user and / or programmatically. For example, a first delay can be used for a first low analyte threshold, but no delay can be used for a second, more severe low glucose threshold.

[0063] Between 188 and 190, based on whether one or more rules are triggered at 186, a notification message can be sent to one or more remote monitors. In some exemplary implementations, the security server can send the notification message to push notification service 112, which then pushes the notification to the remote monitors. Examples of push notification services include Apple Push Notification Service (APNS) and Google Cloud Messaging; however, any other messaging mechanism can be used, including email, SMS, Twitter, etc. In the case of APNS, remote monitor 114 (or its notification message center) can establish an Internet Protocol (IP) connection to APNS. This connection can be encrypted, persistent, and / or authenticated, allowing the notification service to send notification messages to the notification message center even when the remote monitoring application and / or the remote monitor is not actively used. For example, the notification message center can alert the user of remote monitor 114 that a notification message has arrived at the remote monitoring application.

[0064] In implementations utilizing push notification services, notification service 112 can receive notification messages from security server 110. The notification message may include a destination address (e.g., the phone number, IP address, etc. of remote monitor 114) and a payload (e.g., the content of the notification message). Returning to the previous example regarding low glucose levels, the notification message may include the phone number of remote monitor 114 and a short text message, such as the low glucose level value, the time of measurement of the value, and / or the identity of the host. The notification message may be limited to 256 bytes; however, other message sizes may also be used. In any case, notification service 112 pushes the notification message to remote monitor 114 via a connection (e.g., an Internet Protocol (IP) connection) between notification service 112 and a notification message center at remote monitor 114. When the notification message is received at the notification message center at remote monitor 114, the notification message center may display the notification message, generate a sound, vibration, and other other instructions for the user of remote monitor 114. Additionally, in some exemplary implementations, the notification message center or the user of the remote monitor may activate the remote monitoring application if it is not actively used at remote monitor 114. Notification service 112 can be used in implementations where remote monitor 114 resides on a device (e.g., a smartphone), which puts remote monitor 114 or its applications in an idle or inactive mode to save power or reduce signaling to and from the network.

[0065] In some exemplary implementations, push notification services can be bypassed, allowing the security server 110 to send notification messages directly to the remote monitor 114 and / or the remote monitoring application therein. This could happen, for example, when the remote monitoring application is open on the remote monitoring device.

[0066] When a notification message is received at 192, if the remote monitor 114 or its remote monitoring application is in idle or inactive mode, the remote monitor 114 or its remote monitoring application can be activated. Once activated (either programmatically or under user control), the remote monitor 114 may attempt to establish a connection with the security server 110. For example, the remote monitoring application may not be actively used (e.g., in idle mode, sleep mode, off, in background mode, etc.). To activate the remote monitoring application, it can be activated by actively using it, for example, by opening the remote monitoring application by selecting and expanding it, by entering values ​​into the user interface of the remote monitoring application, by selecting elements of the user interface, etc. Alternatively, the remote monitor and / or the remote monitoring application can be activated in other ways. For example, activation can be invoked by motion of the remote monitor detected by a motion sensor and / or by turning on or increasing the intensity of the display on the remote monitor.

[0067] In response to confirmation that remote monitor 114 has activated the remote monitoring application via access message 194, security server 110 may send additional information to remote monitor 196. The content of the additional information sent from security server 110 to remote monitor 114 may be determined automatically or defined by a request from remote monitor, which may be a request included in access message 194 or a subsequent message from remote monitor. The additional information may include one or more of the following: all available sensor data not currently stored in remote monitor 114; sensor data over a predetermined period (e.g., glucose data from the previous 3 or 24 hours obtained from sensor system 100, receiver 102, and / or security server 110); a graph of glucose levels over time; changes in glucose values; instructions; motivational messages; host status; remote monitoring permissions modified by the host, etc.

[0068] In some implementations, security server 110 automatically sends sensor data from the past three hours to the remote monitor, and the remote monitor can request any additional amount of past sensor data if it wants to assess the host over a longer period. If the security server does not have all the sensor data specified in the request from remote monitor 114, security server 110 can query receiver 102 via gateway 104 to obtain additional data in order to respond.

[0069] To further illustrate, when the remote monitor 114 receives a notification message, the notification can cause message 132 to be displayed on the screen of the remote monitor 114, such as... Figure 2AThe remote monitoring application can be activated autonomously or under the guidance of a user and / or notification message center, as described in message 132. The remote monitoring application can then access security server 110 at 192 and programmatically receive any additional information associated with the event or other data following the last connection with security server 110. For example, once the notification message is confirmed via an access or confirmation message at 194, security server 110 can automatically respond using a page with a trend graph of the current glucose status and information indicating the severity of the event (or any other information available on security sensor 110). However, security server 100 can alternatively respond using a subset of the data, in which case security server 110 can automatically respond using new data following the last connection with security server 110, allowing the remote monitor to generate a page including a trend graph displaying glucose level values ​​for the last 3 hours. In any case, the remote monitor can be configured to automatically present a page displaying relevant event information (e.g., a trend graph covering a predetermined time period of the host (e.g., a three-hour history of glucose levels)) upon receiving message 196. Figure 19 The illustrations are exemplary pages that can be automatically rendered, which are discussed in more detail elsewhere in this disclosure.

[0070] Although for ease of understanding, Figure 3 This discussion primarily focuses on remote monitor 114 monitoring a single host; however, it should be understood that a remote monitor can monitor multiple hosts, as discussed elsewhere herein. Therefore, security server 110 can possess sensor data and additional information associated with other hosts. Thus, in some implementations, security server can automatically send sensor data from other hosts monitored by the remote monitor, as well as sensor data from hosts that trigger notifications 190 to the remote monitor. In this way, remote monitor 114 can possess a set of updated sensor data and other information associated with each host monitored by the remote monitor.

[0071] Figure 4A and Figure 4BExamples of notification messages 170 and 172 are depicted respectively. In the example of notification message 170, when the remote monitor 114 receives the notification message, notification message 170 may be presented on the remote monitor 114 as a window requiring user interaction. For example, user interaction may include pressing a button on the remote monitor 114, touching the screen of the remote monitor over an area associated with a portion of message 170, or activating (e.g., executing, opening, etc.) a remote monitoring application on the remote monitor 114. In some cases, notification message 170 may appear while another application on the remote monitor 114 is being actively used. In this case, user interaction may include touching the screen over an area associated with a portion of message 170 to acknowledge receipt of notification message 170 before allowing the user to resume the other application; however, the user action may also preemptively occupy the other application and make the remote monitoring application the active application viewed on the remote monitor. Furthermore, the decision of whether to preempt or resume another application may be predetermined based on the severity level of the event, such that relatively more severe events preempt the other application, while less severe events do not preempt the other application.

[0072] In an instance of notification message 172, notification message 172 may be presented on remote monitor 114 as a message appearing in the user interface. This message appears as an informational message that does not require partial user intervention. Furthermore, when notification message 172 appears while another application is being used on remote monitor 114, notification message 172 does not require user confirmation of notification message 172, or even activation of the remote monitoring application (which may be idle or inactive on remote monitor 114), thus allowing the user to continue using the other application.

[0073] Figure 2B Another exemplary architecture of the remote monitoring system 100 is depicted. (Refer to...) Figure 2B Receiver 102 may include Figure 2A Gateway 104. For example, receiver 102 may include an interface (e.g., an RF modem) with network 108A. To further illustrate, in Figure 2B In one example, receiver 102 may include a smartphone or other processor-based wireless device and provide access to network 108A and thus to security server 110 via public terrestrial mobile networks and other networks such as the Internet.

[0074] Additionally, although security server 110 is in Figure 2B The notification service 112 is shown separately, but in some implementations, the security server 110 may include or bypass the notification service 112. In these implementations, in Figure 2BThe operation of the system can be similar to Figure 3 The process described herein, however, sensor data 180 can be directly sent to security server 110 at 180, and security server 110 can directly send notification messages to remote monitor 114 at 188.

[0075] Figure 2C Another exemplary architecture of the remote monitoring system 100 is depicted. Here, gateway 104 is depicted as a dashed box, which includes separate devices, including a plug-in station 103 and a host communication device 105. In some implementations, any of the functions described herein for gateway 104 can be divided between the plug-in station and the host communication device. For example, plug-in station 103 may communicate with receiver 102, and host communication device 105 may communicate with security server 110.

[0076] In some implementations, the host communication device 105 is a smartphone, and the plug-in station 103 is physically, electrically, and communicatively connected to the receiver 102 to secure the receiver, power the receiver, and communicate with the receiver. In one implementation, the plug-in station 103 is connected to the receiver via USB to simultaneously power the receiver 102 and communicate with it. The plug-in station 103 then communicates wirelessly (e.g., using...) The receiver 102 communicates with the host communication device 105 via a low-power (BLE) protocol, and the host communication device communicates with the security server 110 via network 108A. This implementation, including the plug-in station 103, can be used in situations where the receiver 102 and the host communication device 105 do not have the ability to communicate directly with each other, because, for example, the receiver and the host communication device do not use compatible communication protocols.

[0077] exist Figure 2C In one implementation example, the host communication device 105 is a mobile phone with a host monitoring application downloaded from the Apple App Store, wherein the application configures the mobile phone to collect information from the receiver 102 via the plug-in station 103 and transmit this information to the security server 110, as well as any other functions described herein associated with the gateway 104.

[0078] Before providing additional implementation examples for gateway 104, network 108A-108C, security server 110, notification service 112, and remote monitor 114, implementation examples for receiver 102, continuous analyte sensor 10, delivery pump 2, and / or glucose meter 4 are provided below.

[0079] Refer again Figures 2A to 2CIn some exemplary embodiments, the sensor electronics module 12 may include electronic circuitry associated with measuring and processing data generated by the continuous analyte sensor 10. This generated continuous analyte sensor data may also include algorithms that can be used to process and calibrate the continuous analyte sensor data; however, these algorithms may also be provided in other ways. The sensor electronics module 12 may include hardware, firmware, software, or a combination thereof to provide measurement of analyte levels via a continuous analyte sensor (e.g., a continuous glucose sensor). Reference will now be made to... Figure 5 An exemplary implementation of the sensor electronics module 12 is further described.

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

[0081] like Figure 5 As shown, receiver 102 may include one or more interfaces, such as machine-to-machine interfaces and user interfaces. For example, the user interface may include various interfaces, such as one or more buttons 124, an LCD 122, a vibrator, an audio transducer (e.g., a speaker), a backlight, etc. Components including the user interface can provide controls for interaction with a user (e.g., a host). One or more buttons may allow, for example, toggling, menu selection, option selection, status selection, yes / no response to on-screen questions, "off" function (e.g., for alarms), "sleep" function (e.g., for alarms), reset, etc. LCD 122 may provide, for example, visual data output to the user. Audio transducer 230 (e.g., a speaker) may provide an auditory signal in response to triggering certain alarms (e.g., current and / or predicted hyperglycemia and hypoglycemia). In some exemplary embodiments, the auditory signal may be distinguished by tone, volume, duty cycle, mode, duration, etc. In some exemplary embodiments, the auditory signal may be configured to be silent (e.g., sleep or off) by pressing one or more buttons 224 on receiver 102 and / or by signaling the sensor electronics module using buttons or selections on the receiver.

[0082] although Figure 2A and Figure 2B An exemplary implementation of receiver 102 is depicted as a handheld display device, but other forms of devices may also be used, such as relatively small key card-like, dongle-like display devices, cellular phones (e.g., smartphones, tablets, etc.), personal computers 20, and / or any other user device configured to present at least information (e.g., medication delivery information, discrete self-monitoring glucose readings, heart rate monitoring, calorie intake monitoring, etc.).

[0083] In some exemplary embodiments, the continuous analyte sensor 10 includes a sensor for detecting and / or measuring an analyte, and the continuous analyte sensor 10 can be configured as a non-invasive device, subcutaneous device, transdermal device, and / or intravascular device to continuously detect and / or measure an analyte. In some exemplary embodiments, the continuous analyte sensor 10 can analyze multiple intermittent blood samples; however, other analytes may also be used.

[0084] In some exemplary embodiments, the continuous analyte sensor 10 may include a glucose sensor configured to measure glucose in the blood using one or more measurement techniques (e.g., enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, iontophoresis, radiotherapy, immunochemistry, etc.). In embodiments where the continuous analyte sensor 10 includes a glucose sensor, the glucose sensor may include any device capable of measuring glucose concentration, and various techniques may be used to measure glucose, including invasive, minimally invasive, and non-invasive sensing techniques (e.g., fluorescence monitoring), to provide data (e.g., a data stream) indicating glucose concentration in the host. The data stream may be a raw data signal converted into a calibrated and / or filtered data stream for providing glucose values ​​to a user (e.g., the host or caregiver (e.g., a parent, relative, guardian, teacher, doctor, nurse, or any other individual concerned with the host's health)). Furthermore, the continuous analyte sensor 10 may be implanted as at least one of the following types of sensors: an implantable glucose sensor, a percutaneous glucose sensor implanted in the host's blood vessels or externally, a subcutaneous sensor, a refillable subcutaneous sensor, or an intravascular sensor.

[0085] While the description herein relates to embodiments including a continuous analyte sensor 10 (including a glucose sensor), the continuous analyte sensor 10 may also include other types of analyte sensors. Furthermore, although some embodiments involve using a glucose sensor as an implantable glucose sensor, other types of devices capable of detecting glucose concentration and providing an output signal representing glucose concentration may also be used. Additionally, although the description herein uses glucose as an analyte to be measured, processed, etc., other analytes may be used alternatively or may also be used, including, for example, ketone bodies (e.g., acetone, acetoacetic acid and β-hydroxybutyrate, lactate, etc.), glucagon, acetyl-CoA, triglycerides, fatty acids, intermediates in the tricarboxylic acid cycle, choline, insulin, cortisol, testosterone, etc. In some embodiments, as a supplement to or alternative to the analyte monitoring described herein, other health characteristics of the host are monitored, including but not limited to heart rate, blood pressure level, blood oxygen level, body temperature, calorie intake, drug delivery, etc.

[0086] In one implementation, the sensor system 8 and receiver 102 include DexCom, commercially available from DexCom, Inc. The Platinum continuous glucose monitoring system, and gateway 104 includes Apple products commercially available from Apple Inc. A smartphone with downloaded software that enables the smartphone to perform some or all of the functions of the gateway 104 described herein.

[0087] Figure 5 Examples of sensor electronics module 12 according to some exemplary embodiments are depicted. Sensor electronics module 12 may include sensor electronics configured to process sensor information (e.g., sensor data). For example, the sensor electronics module may process sensor data into one or more of the following: 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 location module 269 providing location information (e.g., GPS / Navigation System information)), warning / alarm information, calibration information, sensor data smoothing and / or filtering algorithms, etc.

[0088] In some exemplary embodiments, the sensor electronics module 12 can be configured to calibrate sensor data, and the data storage memory 220 can store the calibrated sensor data points. Furthermore, in some exemplary embodiments, the sensor electronics module 12 can be configured to wirelessly receive calibration information from a device (e.g., receiver 102) to enable the calibration of the sensor data. Additionally, the sensor electronics module 12 can be configured to perform additional algorithmic processing on the sensor data (e.g., calibration and / or filtered data and / or other sensor information), and the data storage memory 220 can be configured to store sensor data transformed with respect to the algorithm and / or sensor diagnostic information.

[0089] In some exemplary implementations, sensor electronics 12 may include an application-specific integrated circuit (ASIC) 205 coupled to user interface 122. ASIC 205 may further include a potentiostat 210, a telemetry module 232 for transferring data from sensor electronics 12 to one or more devices (e.g., receiver 102, etc.), and / or other components for signal processing and data storage (e.g., processor module 214 and data memory 220). Although FIG. 2 depicts ASIC 205, other types of circuit systems may also be used, including field-programmable gate arrays (FPGAs), one or more microprocessors configured to provide some (if not all) of the processing performed by sensor electronics 12, analog circuit systems, digital circuit systems, or combinations thereof.

[0090] exist Figure 5 In the depicted example, the potentiostat 210 is connected to the continuous analyte sensor 10 (e.g., a glucose sensor) via data line 212 to receive sensor data from the analyte. The potentiostat 210 may also supply voltage to the continuous analyte sensor 10 via data line 212 as a measurement bias sensor (also referred to as the analog portion of the sensor) indicating the concentration of the analyte in the host (e.g., current, etc.). The potentiostat 210 may have one or more channels (and corresponding one or more data lines 212), depending on the number of working electrodes on the continuous analyte sensor 10.

[0091] In some exemplary embodiments, the potentiostat 210 may include a resistor that converts a current value from sensor 10 into a voltage value. In some exemplary embodiments, a current-frequency converter may also be configured to continuously integrate measured current values ​​from sensor 10 using, for example, a charge counting device. In some exemplary embodiments, an analog-to-digital converter may digitize the analog signal from sensor 10 into a so-called "count" to allow processing by processor module 214. The resulting count may be directly correlated with the current measured by potentiostat 210, which may be directly correlated with the level of an analyte (e.g., glucose level) in the host.

[0092] Telemetry module 232 is operatively connectable to processor module 214 and may provide hardware, firmware, and / or software that enables wireless communication between sensor electronics module 12 and one or more other devices (e.g., receiver 102, display device, processor, network access device / gateway, etc.). Various radio technologies can be implemented in 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, near field communication, etc. In some exemplary embodiments, telemetry module 232 includes a Bluetooth chip; however, Bluetooth technology can also be implemented in a combination of telemetry module 232 and processor module 214. Furthermore, although the telemetry module is depicted as part of ASIC 205 in Figure 2, in other embodiments, some or all of the telemetry module may be separate from the ASIC.

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

[0094] In some exemplary embodiments, processor module 214 may 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 sensor 10, data line 212, and potentiostat 210 (e.g., after analog-to-digital conversion of the sensor data). Generally, the digital filter is programmed to filter data sampled at predetermined time intervals (also known as the sampling rate). In some exemplary embodiments, such as when potentiostat 210 is configured to measure an analyte (e.g., glucose) at discrete time intervals, these time intervals determine the sampling rate of the digital filter. In some exemplary embodiments, potentiostat 210 is configured to measure the analyte continuously, for example, using a current-frequency converter. In these current-frequency converter implementations, processor module 214 may be programmed to request digital values ​​from the integrator of the current-frequency converter at predetermined time intervals (capture times). Due to the continuity of current measurement, these digital values ​​obtained by processor module 214 from the integrator can be averaged over the capture time. Therefore, the capture time can be determined by the sampling rate of the digital filter.

[0095] Processor module 214 may further include a data generator configured to generate data packets for transmission to a device (e.g., receiver 102). Additionally, processor module 215 may generate data packets for transmission to these external sources via telemetry module 232. In some exemplary embodiments, as described above, the data packets may be customizable and / or may include any available data, such as timestamps, displayable sensor information, transformed sensor data, identifier codes for sensors and / or sensor electronics modules, raw data, filtered data, calibrated data, rate of change information, trend information, error detection or correction, etc.

[0096] The processor module 214 may also include a program memory 216 and other memories 218. The processor module 214 may be coupled to a communication interface (e.g., a communication port 238) and a power source (e.g., a battery 234). Furthermore, the battery 234 may be coupled to a battery charger and / or a regulator 236 to provide power to the sensor electronics module 12 and / or to charge the battery 234.

[0097] Program memory 216 can be implemented as a semi-static memory for storing data, such as identifiers for the coupled sensor 10 (e.g., sensor identifier (ID)), and for storing code (also referred to as program code) to configure ASIC 205 to perform one or more operations / functions described herein. For example, program code can configure processor module 214 to process data streams or perform counting, filtering, calibration, perform fail-safe checks, etc.

[0098] Memory 218 can also be used to store information. For example, processor module 214, which includes memory 218, can be used as a system cache memory, providing temporary memory for recent sensor data received from data line 212 and potentiostat 210. In some exemplary embodiments, the memory may include storage components of memory, 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.

[0099] Data storage memory 220 can be coupled to processor module 214 and can be configured to store various sensor information. In some exemplary embodiments, data storage memory 220 stores continuous analyte sensor data for one or more days. For example, data storage memory can store continuous analyte sensor data for 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 20 and / or 30 days (or more) received from sensor 10 via data line 212. The stored sensor information may include one or more of the following: timestamps, raw sensor data (one or more raw analyte concentration values), calibration data, filtered data, transformed sensor data, location information, and / or any other sensor-related or displayable information.

[0100] User interface 222 may 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. Components including user interface 222 may provide controls for interaction with a user (e.g., a host). One or more buttons 224 may allow, for example, toggling, menu selection, option selection, status selection, yes / no response to on-screen questions, "off" function (e.g., for alarms), "sleep" function (e.g., for alarms), reset, etc. LCD 226 may provide, for example, visual data output to the user. Audio transducer 230 (e.g., a speaker) may provide an auditory signal in response to triggering certain alarms (e.g., current and / or predicted hyperglycemia and hypoglycemia). In some exemplary embodiments, the auditory signal may be distinguished by tone, volume, duty cycle, mode, duration, etc. In some exemplary implementations, the auditory signal can be configured to be silent (e.g., sleep or turn off) by pressing one or more buttons 224 on the sensor electronics module and / or by signaling the sensor electronics module with a button or selection on a display device (e.g., key card, mobile phone, etc.).

[0101] Although audio and vibration alarms are described with reference to FIG2, other alarm mechanisms may also be used. For example, in some exemplary implementations, a tactile alarm is provided, which includes a prying mechanism configured to “pry” the patient in response to one or more alarm conditions.

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

[0103] The battery charger and / or regulator 236 can be configured to receive energy from an internal and / or external charger. In some exemplary embodiments, the battery regulator (or balancer) 236 regulates the recharging process by discharging excess charging current to allow all batteries or battery packs in the sensor electronics module to be fully charged without overcharging other batteries or battery packs. In some exemplary embodiments, the battery 234 (or multiple batteries) is configured to be charged via an inductive and / or wireless charging pad; however, any other charging and / or power mechanism may also be used.

[0104] One or more communication ports 238 (also referred to as external connectors) may be provided to allow communication with other devices (e.g., personal computer (PC) communication (com) ports), which may be provided to enable communication with systems that are separate from or integrated with the sensor electronics module. For example, the communication port may include a serial (e.g., Universal Serial Bus or "USB") communication port for communication with another computer system (e.g., a PC, personal digital assistant or "PDA", server, etc.), a dongle with a wireless transceiver coupled to a plug-in station, as further described below, and / or any other interface. The communication port may also be coupled to or include a wireless transceiver to also allow wireless communication. In some exemplary embodiments, the sensor electronics module 12 is capable of transmitting historical data to a PC or other computing device (e.g., a secure server as disclosed herein) for retrospective analysis by patients and / or physicians.

[0105] In some continuous analyte sensor systems, the skin portion of the sensor electronics can be simplified to minimize the complexity and / or size of the on-skin electronics, for example, by providing only raw, calibrated, and / or filtered data to a display device (e.g., receiver 102) configured to run the calibration and other algorithms described above with respect to sensor electronics module 12. However, sensor electronics module 12 can be implemented to perform prospective algorithms for generating transformed sensor data and / or displaying sensor information, including algorithms that, for example, perform the following operations: assess the clinical acceptability of reference and / or sensor data; evaluate calibration data for optimal calibration based on inclusion criteria; assess the quality of calibration; compare estimated analyte values ​​with time-corresponding measured analyte values; analyze changes in estimated analyte values; assess the stability of the sensor and / or sensor data; detect signal artifacts (noise); replace signal artifacts; determine the rate of change and / or trend of sensor data; perform dynamic and intelligent analyte value estimation; perform diagnostics on the sensor and / or sensor data; set operating modes; evaluate data for anomalies, etc.

[0106] Despite Figure 5 Separate data storage and program memory are shown, but various configurations can also be used. For example, one or more memories can be used to provide storage space to support the data processing and storage requirements on sensor electronics module 12.

[0107] While some of the examples described relate to a continuous analyzer sensor 10, a glucose meter 4, and a pump 2 communicating with sensor electronics 12 and / or receiver 102, other devices may also be used. For example, sensor electronics 12 and / or receiver 102 may be coupled (via wired and / or wireless links) to other sensors, including glucose sensors, altimeters, accelerometers, temperature sensors, location modules (e.g., a GPS processor or other source of location information), heart rate monitors, blood pressure monitors, pulse oximeters, calorie intake monitors, medication delivery devices, etc.

[0108] As described above, sensor electronics module 12 can generate data packets and transmit them via wireless or wired media to a device (e.g., receiver 102) configured to receive, store, forward / rebroadcast, and / or display sensor data. As described above, sensor electronics module 12 can analyze sensor data from multiple sensors and determine which sensor data to transmit based on one or more of a number of characteristics of the host, receiver 102, the 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 be found, or alternatively, on one or more of receiver 102, gateway, or security server 110, and one or more of the functions described herein with respect to receiver 102 may also be found on sensor system 8.

[0109] For illustrative purposes, see again. Figure 2A Receiver 102 can forward analyte sensor data and other available data to gateway 104 via wired and / or wireless links. In some exemplary embodiments, gateway 104 may include a network interface configured as a radio interface (e.g., a cellular radio interface (e.g., LTE), a wireless LAN interface (e.g., Wi-Fi), and / or any other type of wireless or wired interface. For example, gateway 104 may include at least one processor including a radio frequency subsystem (e.g., a modem). In these wireless examples, when receiver 102 is connected to gateway 104, gateway 104 wirelessly transmits analyte sensor data, etc., to security server 110 via network 108A, which may include one or more of an access network, wireless LAN, wireless access network, cellular network, the Internet, and / or any other communication mechanism. In some exemplary embodiments, gateway 104 may also include a wired connection network 108A, which is further connected to security server 110.

[0110] Gateway 104 can automatically send sensor analysis data and additional information from receiver 102 in one or more of a variety of ways. For example, receiver 102 can provide information to gateway 104 without a request from the gateway. The information can be provided automatically, such as after a timer expires or after new sensor data points are generated, or the information can be provided in response to user input to receiver 102. Gateway 104 can then automatically send the information from the receiver to security server 110. In another instance, based on predetermined rules, such as after a timer (e.g., a 5-minute timer) expires, the gateway can automatically request information. The information provided by receiver 102 can then be automatically sent to security server 110. In yet another instance, the gateway can send a request for information to gateway 104, which then forwards the request to receiver 102. Receiver 102 can then provide the requested information to the gateway, which then forwards the information to security server 110. In each of these instances, the requested information can be specific (e.g., a specific time period of sensor data) or simply a general request to send information. In the latter case, receiver 102 can determine what information will be sent in response to the request, such as any new sensor data generated by the receiver since the last time the receiver provided information to server 110.

[0111] Figure 6 This is a block diagram of an implementation of gateway 104. Gateway 104 may include a power module 302 for charging receiver 102 when it is connected to gateway 104 and wireless network interface 304 to allow wireless access to network 108A using various network access technologies. However, gateway 104 may also provide wired connections to network 108A, processor 414, and computer memory, which stores instructions for processor 314 to perform the functions of gateway 104 and stores health-related information received from receiver 102.

[0112] Furthermore, in implementations where the receiver and gateway are separate and the gateway does not include intermediate plug-in station 103, gateway 104 may include receiver interface 306 to provide a wired and / or wireless interface to receiver 102. For example, receiver interface 306 may include a Universal Serial Bus (USB) interface through which receiver 102 can communicate with gateway 104, security server 110, etc. USB may also provide a physical connection for charging receiver 102; however, wireless charging may also be used. Additionally, receiver interface 306 may include a wireless interface, such as Bluetooth, Bluetooth Low Energy, Zigbee, Atom, and any other wireless technology, through which receiver 102 can communicate with gateway 104, security server 110, etc. Gateway 104 may also include user interface 310, such as a display, touchscreen display, keyboard, speaker, light-emitting diodes (LEDs), etc. For example, one or more LEDs may be used to indicate whether gateway 104 is properly connected to receiver 102, network 108A, security server 110, etc., whether gateway 104 is connected to a power source (e.g., an electrical outlet), whether the battery is being charged, etc. The display can also allow the presentation of sensor data, alarms, notifications, etc. For example, the user interface (e.g., display, LED, etc.) can provide indications (e.g., LEDs of a specific color, messages, etc.) that a connection has been established between gateway 104 and security server 110 (e.g., Internet Protocol connection, secure channel, etc.), thereby making the user of gateway 104 aware that the receiver is connected to the so-called "cloud" including security server 110.

[0113] As described above, in some implementations, gateway 104 may include a smartphone on which a host monitoring application is stored, the application configuring the smartphone to perform the functions of gateway 104 as described herein.

[0114] Figure 7A and Figure 7B An example of a plug-in station 700 is described; plug-in station 700 can be used as a reference. Figure 2C The described plug-in station 103. Figure 7A The diagram shows a perspective view of a plug-in station 700 that is not physically connected to a plug-in station receiver 102, and... Figure 7BThe figure shows a front view of a plug-in station 700 having a receiver 102 physically connected to it. The plug-in station 700 may have a cavity 710 to allow the receiver 102 to be slidably inserted into and releasably secured within the plug-in station. The plug-in station 700 may also include a mechanical mechanism (not shown) for releasably securing the receiver 102 to the plug-in station. The mechanism may be a latch assembly, etc. The plug-in station may be electrically connected to the receiver 102 via, for example, an electrical connector (e.g., a Universal Serial Bus connector) and / or a wireless interface (e.g., Bluetooth, Bluetooth Low Energy, Wi-Fi, and any other wireless technology), and data received from the receiver 102 can be transmitted to a host communication device 105, a security server 110, or a remote monitor 114 using the electrical connector and / or the wireless interface (e.g., Bluetooth, Bluetooth Low Energy, Wi-Fi, and any other wireless technology).

[0115] Plug-in station 700 can also act as a repeater and / or amplifier for any alarms triggered by receiver 102 and / or security server 110. For example, plug-in station 103 can receive indication of an alarm triggered by receiver 102. Plug-in station 700 can repeat an alarm by, for example, emitting an audible warning, causing vibration, and / or illuminating an LED to indicate the alarm to the user. Furthermore, receiver 102 can use a first warning (e.g., vibration) to trigger an alarm, while plug-in station 700 can repeat the alarm using a second type of warning different from the first warning. For example, the first warning could be a vibration warning and the second warning could be an audible warning, or vice versa. As another example, the first warning could be an audible warning and the second warning could also be an audible warning, but the second audible warning is louder and / or has a different tone pattern than the first warning.

[0116] In some implementations, the plug-in station 700 can trigger an alarm by physically sensing a warning from the receiver 102. For example, the plug-in station may include vibration and / or sound sensors capable of sensing vibrations or sounds emitted from the receiver 102, respectively. In this way, when the receiver is plugged into the plug-in station, the plug-in station 103 can trigger an alarm after sensing that the receiver 102 has triggered a warning.

[0117] Furthermore, the alarm settings at the plug-in station 700 can be the same as or different from the alarm settings at the receiver 102. For example, the alarm settings at the plug-in station 700 can be more stringent than the alarm settings at the receiver 102. For example, the receiver 102 can have a low glucose threshold that is greater than the corresponding low glucose threshold at the plug-in station 700. For example, the alarm settings at the plug-in station 700 can be configurable by the user using the user interface of the plug-in station or the user interface of the host communication device 105.

[0118] Alternatively, in some implementations, the plug-in station 700 delays the triggering of an alarm initiated by the receiver 102 to allow the host to clear the alarm in time before the plug-in station triggers a warning. If the host clears the alarm before the delay expires, the plug-in station 700 does not trigger an alarm.

[0119] Further reference Figure 7A and Figure 7B The plug-in station 700 may include one or more light indicators (e.g., LEDs) that indicate the status of the plug-in station 700 and / or other components of the system 100. For example, a first light indicator 712 may indicate (by turning on or changing color) whether the plug-in station 700 is receiving power from an external power source, and a second light indicator 714 may indicate (by turning on, changing color, or flashing) whether the plug-in station is paired with the host communication device 105. Other light indicators may also be used, such as a third light indicator that indicates whether the communication channel between the plug-in station 700 and the host communication device 105 and / or the security server 110 is open and successfully transmitting sensor data from the receiver 102.

[0120] Figure 8 Another implementation of gateway 104 is depicted. Figure 8 In this example, gateway 104 is configured as a dongle (e.g., a Universal Serial Bus (USB) dongle) including a USB connector 392 for coupling to receiver 102 and a user interface (e.g., a button 394) for performing Bluetooth pairing with another device (e.g., host device 105) accessing network 108A or for direct connection to network 108A via Wi-Fi or cellular communication channels. While the gateway / donkey can be configured for Bluetooth pairing, it can also support connection establishment with other devices using other radio access technologies (e.g., Bluetooth Low Energy, Wi-Fi, Atom, Zigbee, NFC, etc.). Figure 8 The gateway / donkey depicted may also include a light-emitting diode 396 for providing indications of the status of the gateway 104 or receiver 102 (e.g., battery level, glucose level, whether the user is in a low or high blood sugar state, network connectivity, connection to a security server, etc.). In some exemplary embodiments, Figure 8 The gateway may include its own rechargeable battery for powering the gateway and / or receiver 102; however, the battery may also rely on receiver 102 as a power source.

[0121] In some exemplary embodiments, as described above, gateway 104 may include a radio frequency interface to allow the automatic uploading of data from receiver 102, in compressed or uncompressed format, to security server 110, which may be implemented as a so-called "cloud". Additionally, the uploading may occur programmatically without user intervention when receiver 102 communicates with gateway 104. Gateway 104 may also be configured to collect an identifier from receiver 102 (or the receiver may automatically provide the identifier without requesting it from gateway 104) and provide the identifier to security server 110 to allow security server 110 to associate received sensor data with host 199, receiver, and any previously provided sensor data stored in security server 110 (or a repository connected to security server 110) associated with the host. In some embodiments, the identifier is the serial number of receiver 102, and the receiver automatically sends the identifier along with any sensor data provided to the gateway. Furthermore, in some exemplary embodiments, gateway 104 may be configured to send data incrementally, i.e., previously received data will not be resent to security server 110 unless requested by security server 110. Furthermore, gateway 104 can select between cellular and Wi-Fi connections based on factors such as connection speed and cost. For example, a free Wi-Fi connection might be chosen over a paid cellular connection (if available). Additionally, the cellular connection can be used to transmit generally real-time data generated by sensor system 8, while the Wi-Fi connection can be used to transmit historical data, since timely transmission of historical data may not be as important in some implementations.

[0122] In some exemplary implementations, gateway 104, receiver 102, sensor system 8, and remote monitor 114 may be pre-configured such that when sensor system 8 and receiver 102 are communicatively connected to gateway 104, gateway 104 identifies the sensor system / receiver and / or its users. Furthermore, remote monitor 114 may also be identified by server 110 to allow remote monitoring of receiver 102 to occur with minimal (if any) configuration of the receiver 102's end user / host. For example, security server 110, gateway 104, receiver 102, sensor system 8, and remote monitor 114 may be pre-configured and pre-registered, with minimal (if any) configuration or registration effort required for the host portion.

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

[0124] Security server 110 can receive analyte sensor data, store analyte sensor data, process analyte sensor data to detect events and thus allow the generation of notifications to remote monitor 114 and / or alarms to receiver 102 and / or gateway 104, generate pages or reports displayed on remote monitor 114, receiver 102 and / or gateway 104, and allow registration and / or configuration of host 199, sensor system 8, receiver 102, gateway 104 and remote monitor 114.

[0125] In some exemplary implementations, one or more entities may have remote monitors 114A-114M. For example, security server 110 may register the identities of users of remote monitors 114A-114M and the schedule for each entity to perform monitoring. Furthermore, one or more entities may be configured at security server 110 as a primary monitor for receiving notifications, while other entities may be configured as backup or auxiliary monitors for receiving notifications when the primary monitor does not acknowledge or act on notification messages sent to remote monitors 114 according to one or more predefined rules. Additionally, security server 110 may include one or more rules defining when an event results in a notification to one or more of the remote monitors 114.

[0126] The security server 110 can also provide a cloud-based diabetes data management framework that receives patient-related data from various devices, such as medical devices, glucose meters, continuous glucose monitors, sensor systems, receivers, and / or other devices including any of the devices disclosed herein (e.g., devices providing data on food consumption (e.g., carbohydrates), medication delivery, time, temperature sensors, motion / activity sensors, etc.). Furthermore, the cloud-based diabetes data management system may receive data programmatically, with little (or no) intervention for the user. Data received from devices, receivers, source systems, etc., can be in various formats and can be structured or unstructured. For example, the security server 110 can receive raw sensor data from sensor system 8 and receiver 102 that has been minimally processed or analyzed, and then format, process (e.g., analyze), and / or store the received data to enable report generation by the security server 110. In addition to sensor data, the security server 110 can also receive data from source systems (e.g., healthcare management systems, patient management systems, prescription management systems, electronic medical record systems, personal health record systems, etc.).

[0127] In some exemplary implementations, the security server 110 can inspect received data for transmission-related errors, data formatting, device-related error codes, data validity, duplicate data points, and / or other aspects of the data. Furthermore, if out-of-bounds data points or device errors are found, the security server 110 can identify those data points by, for example, marking them, and then programmatically or via a system administrator to correct the identified data points and store the corrected data points. Additionally, the security server 110 can be configured by users (e.g., clinicians, doctors, etc.) to perform additional data processing steps, such as correcting time, correction date, and analyzing data by specific populations, groups, and relationships (e.g., demographics such as age, city, country, sex, race, type 1 diabetes, type 2 diabetes, age at diabetes diagnosis, laboratory results, prescription drugs used, patient self-reported conditions, patient diagnostic conditions, responses to patient questions, and any other metadata representing the host / patient). Once the security server 110 has performed initial data processing (e.g., inspection, cleaning, and analysis), the processed data and / or raw data can be stored in a repository linked to the security server 110.

[0128] Processing on the security server 110 may also include associating metadata with data received from devices and / or sensors. Examples of metadata include patient information, keys used to encrypt data, patient accelerometer data, location data (e.g., the patient's location or the location of the patient's clinic), time, date, 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, hypertension, or any other health condition.

[0129] The processing may also include one or more of the following: analysis, such as determining one or more descriptive measurements; detecting or predicting events (e.g., hypoglycemia, hyperglycemia, and / or any other feature detected in sensor data); applying a pattern detector to the received sensor data; and generating a report based on the received information (e.g., sensor data and descriptive measurements including information from the sensor data). Descriptive measurements may include statistical data (e.g., median, inner and outer quartile ranges, mean, sum, n, standard deviation, and coefficient of variation). In some exemplary implementations, the security server 110 may also associate metadata with data received from devices, sensors, source systems, and / or receivers; determine one or more descriptive measurements, such as statistical data (e.g., median, inner and outer quartile ranges, mean, and n and standard deviation); generate reports that include descriptive measurements; verify and validate the integrity of data received from devices, sensors, source systems, and / or receivers; process received data based on metadata (e.g., to select specific patients, devices, conditions, diabetes types, etc.); and / or correlate data received from devices, sensors, source systems, and / or receivers, such that the data can be compared and combined for processing including analysis. Furthermore, the results of any processing performed by the security server 110 may be used to generate one or more reports, such as line graphs, bar charts, static graphs, graphs, etc. Additionally, reports and other outputs generated by the security server 110 may be provided to receiver 102, remote monitor 114, and any other processor via one or more delivery mechanisms.

[0130] Security server 110 can be considered secure in the sense that it maintains private, patient-identifiable information and / or restricts access to users who are registered and thus authorized to use it. For example, security server 110 may receive requests from devices (e.g., receiver 102 or remote monitor 114) to perform actions (e.g., providing data, storing data, analyzing / processing data, requesting reports, requesting configuration information, requesting registration, etc.). Before serving a request, security server 110 may process the request to determine whether it is authorized and verified. For example, authenticators and authorized persons can determine whether the sender of the request is authorized by requiring the user to provide security credentials (e.g., user identifier, password, stored security token, and / or verification identifier provided by text message, telephone, or email) on a user interface presented on a processor (e.g., receiver 102, remote monitor 114, and / or any other computer). If authorized, the certifier and certifier can verify the sender of the request to check whether the security certificate associated with the sender of the request indicates that the sender is indeed allowed to access specific resources in System 100 in order to perform actions such as storing (or uploading) data in a repository, performing data analysis / processing, requesting report generation, receiving alerts, receiving notification messages, etc.

[0131] In some exemplary implementations, security server 100 may 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 consumption data, etc.). The pattern detector may detect patterns and generate output, which may be provided to a report generator at the security server to generate alarms to receiver 102, notification messages to remote monitor 114, and / or pages including reports.

[0132] Furthermore, the pattern detector can detect patterns in pre-defined time-retrospective detection data / sensor data by system 100 and / or users. For example, the pattern detector can receive input data from a repository connected to security server 110, and the input data may include sensor data representing glucose concentration data, analytes, and other data (e.g., insulin pump data, carbohydrate consumption data, histograms and / or counts, data from a continuous glucose monitor (CGM data), time of day, amount of carbohydrates, information related to other foods, exercise, wake / sleep timer intervals, ingested medications, etc.). Additionally, the input data may include historical data acquired within time frames (e.g., 8 hours, 1 day, 2 days, 7 days, 30 days, and / or any other time period). For example, the input data may include counts representing monitored analyte detection levels (e.g., glucose concentration levels) received and stored on system 100 within a time period covering four-week time frames.

[0133] To further illustrate the pattern detector, patterns can be identified based on one or more predefined triggers (also referred to as criteria, rules, and filters). Furthermore, one or more predefined triggers can be variable and adjustable based on user input and / or programmatically variable and adjustable based on one or more rules on security server 110. Additionally, the user, the user's physician, or the user's guardian can select, turn on and off, and / or modify certain types of patterns; however, system 100 can also select, adjust, and / or additionally programmatically modify the triggers.

[0134] Some examples of the types of relationships that can be considered in the input data of a pattern are one or more of the following: glucose levels exceeding a target glucose range (which may be defined by the user, healthcare provider, security server 110, or a combination thereof); glucose levels below the target glucose range; abrupt changes in glucose levels from low to high (or vice versa); the time when low, high, within a range, or rapid glucose level events occur; the period when low, high, within a range, or rapid glucose level events occur; hyperglycemia patterns; hypoglycemia patterns; patterns associated with time of day or week; weighted scores of different patterns based on frequency, sequence, and severity; user-defined sensitivity; transitions from hypoglycemia to hyperglycemia patterns; the amount of time spent in severe events; combinations of glucose variation and time information; and / or patterns with high variability in glucose data. Furthermore, a pattern can be based on a combination of previous pattern data and current detection conditions, with the combined information generating predictive alerts.

[0135] Hypoglycemia patterns at a given moment can be detected based on events detected by security server 110. For example, a pattern can be identified if a user has low glucose concentrations around the same time of day. Another type of pattern that can be identified is a "rebound high." For example, a rebound high can be defined as a situation where a user overcorrects a hypoglycemic event by excessively increasing glucose intake, thus entering a hyperglycemic event. These events can be detected based on one or more predefined triggers.

[0136] To further illustrate examples of patterns, a basic pattern can be configured to allow searching for certain patterns in the data, such as values ​​within a range, high coefficient of variation, etc. Each pattern can have a dimension, such as within a range, where one pattern specifically looks for values ​​below the range, another pattern looks for low coefficient of variation, etc. Each pattern can be statistically based and use standard descriptive statistics in pattern matching applications. Each pattern can be assigned a score for various rules encoded with each pattern, such as whether it is positive, negative, or of significant insight. Each pattern can also be assigned a set of possible date ranges to which the pattern applies. For example, counting the number of times a high glucose value is high, followed by a low value below the range, is a pattern that applies only to the full range. However, viewing high levels of variation can apply to a month, week, day, day, every hour, hour, and combinations thereof. Each pattern can be assigned an acceptable minimum score before it can be considered for display or to generate an alarm sent to receiver 102 (or host 199) and / or a notification message sent to remote monitor 114. Each pattern (and any associated triggers / rules) can be processed within a given time frame to obtain a set of data, and patterns are ranked according to importance if they are applied and meet specific minimum requirements. Therefore, the ranked patterns can each correspond to an alarm 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).

[0137] Further reference Figure 1The host monitoring system 198A may have a single remote monitor 114A or multiple remote monitors 114A-114M, and rules relating when a remote monitor receives an alarm and what type of alarm should be sent may be stored on the security server 110. For example, the first remote monitor 114A may receive notification messages during the day, while the second remote monitor 114B may receive notification messages at night; however, other schedules may also be used. Alternatively, the first remote monitor 114A may receive notifications only when the server identifies the host system 198 as being in a predefined geographic location (using, for example, geographic location information provided by the host system 198) (e.g., a school), while the second remote monitor 114B receives notifications regardless of the host's geographic location. As another example, the first remote monitor 114A may have high and low thresholds for triggering alarms to the remote monitor 114A, which are different from one or both of the high and low thresholds for triggering alarms to the remote monitor 114B. In addition, one or more rules can define the first remote monitor 114A as the master monitor, while the second remote monitor 114B can be defined as a backup or auxiliary monitor.

[0138] Remote monitor 114 can acknowledge received notification messages by activating (e.g., opening, interacting with, accessing, selecting, etc.) the remote monitoring application or in response to messages presented on the remote monitor's user interface. The remote monitoring application causes the message to appear in 194 ( Figure 3 The notification message is sent to security server 110. If security server 110 does not receive any form of acknowledgment, whereby 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 the event), security server 110 may resend the notification to remote monitor 114. In some exemplary implementations, security server 110 may receive a message from notification service 112 that remote monitor 114A has stopped operating or is otherwise unreachable, in which case security server 110 may resend the notification message to a different remote monitor 114B. The delay used by the security server to resend notification messages can be configured based on the severity or type of the event, and the security server may also include rules defining a predetermined number of unsuccessful resends, or a predetermined amount of time before upgrading to another primary monitor, secondary / backup monitor, emergency medical services, etc. Additionally, this predetermined number of unsuccessful resends can also be configured on the security server to vary based on the severity or type of the event or user configuration.

[0139] In some exemplary implementations, refer to Figure 1Remote monitor 114 can receive notification messages for a single host monitoring system 198A or multiple host monitoring systems 198A-198N. Furthermore, pages can be generated by security server 110 and then sent to one or more remote monitors for display on the user interface of each remote monitor; however, security server 110 can alternatively send data to remote monitor 114 to enable page generation on remote monitor 114. Pages may include text and / or graphical indications of the status of one or more monitored hosts. To illustrate this, a school nurse may have remote monitor 114 with a page depicting each host monitoring system 198A being monitored by the remote monitor. Each remote monitoring system 198A-198N may be associated with a student. In this example, the page may contain status information about each student, recent notification messages about each student, graphical or textual indications that the student is within limits, or indications that the student has exceeded limits, etc. Each student may be associated with a cell (a defined space on a display). Therefore, the nurse can quickly view the user interface and see the status of each monitored student. Graphical indicators can be used to visually convey the overall status of each student in each student's unit. For example, a so-called "smiley" face icon can indicate that a student's glucose level is within limits, and a so-called "sad" face icon can indicate that a host's glucose level is of concern because these levels exceed a threshold. Furthermore, in some exemplary implementations, the page can be displayed on a monitor such that selecting a unit (e.g., a touch on a touchscreen, mouse hover, click, etc.), notification, or face icon triggers the provision of additional information to a remote monitor. For example, selecting a student's unit can cause remote monitor 114 to access security server 110 and receive additional information, such as current and previous glucose levels, patient information, etc., and update the display page or switch to a new display page that shows more detailed information about the selected student (e.g., a trend graph of the student's glucose levels over the past three hours). While the preceding examples involve glucose levels and specific types of messages and icons, other types of events, messages, and icons discussed herein can be used to convey the host's status.

[0140] Dashboard

[0141] In some exemplary implementations, the page discussed above can be configured as a so-called "dashboard" that includes dynamic content. For example, icons for host-patients requiring the greatest care or attention (e.g., patients with very high or low blood sugar levels) can be placed in the top row of the page to allow remote monitors to quickly determine the status of higher-risk host-patients. While the described prior arrangement uses the top row of the page to isolate some so-called higher-risk host-patients, other isolation schemes can be used (e.g., different colors, intensities, and / or positions on the page). Furthermore, the page can be considered dynamic because the patients isolated for additional attention may change over time, thus allowing the page to depict different icons for different patients in the isolated top row of the page. (See also...) Figure 18A and Figure 18B Let's discuss examples of dashboards in more detail.

[0142] Designated remote monitor

[0143] In some exemplary implementations, an entity (e.g., a user) may be designated as the primary remote monitor by security server 110. In this case, the primary monitor at remote monitor 114 may be unavailable due to factors such as a dead battery, device malfunction, or lack of radio reception at remote monitor 114A. Therefore, a secondary remote monitor may be designated by security server 110 to receive notification messages, which will otherwise be sent to the primary monitor. When the primary monitor fails to receive or acknowledge the first notification message from the primary monitor within a predetermined time period, the secondary monitor may access another remote monitor device 114B and thus receive the notification message. The time period may vary based on the severity or type of the event. In addition to monitoring acknowledgments from remote monitor 114, security server 110 may access the quality of the service mechanism at notification service 112 to determine if remote monitor 114 has stopped operating (e.g., due to a malfunction, dead battery, out of range, or otherwise not accepting notification messages) so that security server 110 can select another monitor in operation.

[0144] upgrade

[0145] In some exemplary implementations, remote monitor 114 may generate a message for presentation that requires some form of confirmation or action from the user of remote monitor 114 (e.g., a primary or secondary monitor) to acknowledge receipt of the notification message. Confirmation or action may include opening a remote monitoring application on remote monitor 114 in response to the notification message. Furthermore, if an action is not performed within a predetermined time period, security server 110 may determine that the user of the remote monitor has not yet seen the notification message (or been notified in other ways). In this case, security server may escalate the notification message to another remote monitor defined by one or more rules on security server. Security server may also check the quality of the push notification service (or the service mechanism therein) to see if the notification message has been delivered. If not, security server may determine that the user of the remote monitor has not yet seen the notification message and use this notification message as the basis for escalating the notification message to another remote monitor.

[0146] In some implementations, security server 110 may include one or more rules defining escalation sequences that define which notification messages should be sent to the first remote monitor 114A, and when messages should be resent to one or more other remote monitors 114B-114M in the event of a shutdown. During the configuration of remote monitors 114A-114M, security server 110 may be configured via user input (e.g., one or more of the host and / or remote monitors) to notify each remote monitor 114A-114M with an escalation sequence. This escalation sequence configuration may be user-defined or provided as a default setting (which may be reconfigurable or adaptable over time based on user / host / monitor responsiveness) and may vary based on the severity and type of the event. For example, escalation sequences may define rules that define when to alert the host-patient at 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 911 emergency response.

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

[0148] Furthermore, if the user at receiver 102 fails to acknowledge the alarm within a predetermined timeframe, an escalation sequence can also be implemented. For example, refer to... Figure 2A Security server 110 can determine (e.g., by monitoring sensor data received from receiver 102 and knowing the threshold on the receiver) that receiver 102 should alarm host 199, where the alarm requires confirmation. Confirmation can take the form of a user response to a message presented on user interface 122 of receiver 102, or the user otherwise clearing the alarm, such as by taking an action that can be measured by a device associated with the host-user (e.g., a medication pump 2 indicating that insulin has been given to the user, an analyte measurement indicating that the root cause of the alarm is no longer a measurement level above a threshold, or a trend moving in the desired direction). In this example, if security server 110 does not receive some form of confirmation and / or indication that the underlying event triggering the clearing of the alarm after a predetermined amount of time has elapsed, security server 110 can resend the alarm and / or send a notification message to the primary remote monitor (e.g., 114A), the secondary remote monitor (e.g., 114B), and / or emergency medical services. Additionally, this upgrade (including retries and delays) can be configured on security server 110 to vary based on the severity and / or type of the event that triggered the alert.

[0149] remind

[0150] In some exemplary implementations, security server 110 may include rules for providing so-called “follow-up” alerts. For example, if the host-user at receiver 102 does not take any action, such as taking insulin, drinking a glass of juice, etc., security server 110 may send an alert 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 which of one or more remote monitors 114A-114M, receiver 102, and gateway 104 are associated with the alert can be configurable and can vary based on the severity and / or type of the event.

[0151] Furthermore, in some implementations, the security server 110 may repeatedly (e.g., every 5 minutes or any other time) resend notifications to the remote monitor 114 and / or receiver 102 until the notification message is acknowledged. In some exemplary implementations, when each resend is sent to the receiving device, the security server 110 may configure different warning types to be triggered by the receiving device (e.g., the remote monitor 114 or receiver 102) (e.g., continuously increasing volume, brightness, or vibration with each repeated, unacknowledged notification message, or triggering a vibration warning with a first alert and a vibration warning with a second alert, etc.). Messages from the security server 110 at the receiving device and other actions detectable by the security server can serve as acknowledgments.

[0152] In some exemplary implementations, a user designated as the primary monitor may signal to security server 110 that monitoring cannot be provided by sending messages to security server 110 and / or receiver 102 using, for example, remote monitor 114A or workstation 22. In this case, security server 110 may demote the primary monitor to a secondary (or backup) monitor and promote one of the secondary monitors to primary monitor. The security server may have rules defining which secondary monitors can be promoted, or each secondary remote monitor may be polled to assess its availability to assume the role of primary remote monitor. Additionally, security server 110 may send messages (e.g., via a notification service) to the secondary monitor that has been promoted to primary monitor (which has already been designated as primary monitor) (and send corresponding messages to the demoted primary monitor).

[0153] To ensure the quality of service regarding notification messages received by the remote monitor, one or more actions can be performed to mitigate the potential loss of notification messages sent to the remote monitor 114. For example, if the 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 the security server 110 and the notification service 112), the security server 110 can send notifications via another entity (e.g., a separate Short Message Service (SMS) message, telephone, email, or any other entity directly to the remote monitor 114) to establish contact with the remote monitor and / or with the users associated with those remote monitoring devices.

[0154] Registration / Invitation for Remote Monitoring

[0155] As described above, in some exemplary implementations, devices used on system 100 may need to register with security server 110. To illustrate this, refer to... Figure 2B Receiver 102 (which may be implemented on a processor-based wireless device, such as a smartphone or tablet) may send a message via a public terrestrial mobile network or other network to invite remote monitor 114 to accept a connection establishment request from security server 110. If accepted, remote monitor 114 may be provided with notification messages for events associated with receiver 102 and access sensor data and reports associated with host 199. Although the foregoing example describes receiver 102 sending an invitation to remote monitor 114, other devices (such as security server 110, gateway 104, user communication device 105, workstation 22, and / or remote monitor 114) may also or alternatively send invitations, depending on the implementation.

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

[0157] In addition, receiver 102, gateway 104, user communication device 105 and / or security server 110 can also manage the number of remote monitors 114 based on location and / or time, so that the host-user has a predetermined number of remote monitors 114 at any given location and / or at any given time.

[0158] In some exemplary implementations, host 199 or a caretaker of the host can manage the status of invitations (e.g., invitation sent, invitation accepted, monitoring canceled, etc.) via receiver 102, gateway 104, user communication device 105, and / or security server 110. For example, one or more user-interactive pages can be displayed on a computer monitor (e.g., receiver 102, gateway 104, user communication device 105, or workstation 22, etc.), including the status of the invitation (e.g., whether the invitation is pending, rejected, or accepted). These pages can be configured to allow changes to rules associated with remote monitors 114A-114M. For example, changes can be made to rules used to trigger notification messages, the designation of the primary monitor (including time and location), the designation of secondary monitors (including time and location), escalation sequences, and escalation threshold settings. Additionally, the pages can provide a list of remote monitors, allowing the user to specify a primary and secondary remote monitor and send invitations to any selected monitor. The page can allow permission configuration, such as whether the remote monitor 114 is authorized to receive one or more notification messages, or to view patient data (e.g., sensor data including current and / or past data), etc.

[0159] Figure 12 An exemplary invitation page 500 is depicted at remote monitor 114 in the form of an email message. In this example, at 502, a user “John Doe” associated with sensor system 8 and receiver 102 invites remote monitor 114 to become a monitor as instructed by the invitation. Furthermore, the invitation may include instructions for the remote monitor, in this example including clicking a link at 504 to allow downloading remote monitoring application code from security server 110 or another server (e.g., an iTunes server operated by Apple), and accepting the invitation at 506 (which sends an acceptance message to security server 110). The remote monitor may also provide the option to not accept the invitation by selecting a user-selectable rejection icon 508, which can notify security server 110 of the rejection instruction.

[0160] In some implementations, in order to register an invited remote monitor 114 with security server 110, the remote monitor and receiver 102 may each input values, such as codes, shared secrets, links (e.g., Uniform Resource Locators), passwords, or combinations thereof, to allow a connection to be established and thus enable the remote monitor 114 to receive notification messages for events associated with receiver 102 and to access sensor data and reports on security server 110. Furthermore, users (e.g., host 199) can use, for example... Figure 1 Workstation 22 accesses an internet browser to access security server 110 and logs in to view and manage one or more devices granted remote monitoring privileges.

[0161] Connection establishment refers to the process of adding one or more remote monitors to system 100 to provide second-layer supervision to the operation of sensor system 8 and receiver 102. A connection with remote monitor 114 can be established based on an invitation sent to remote monitor 114. This invitation may be sent based on the consent of receiver 102, gateway 104 (e.g., via a user interface therein), and / or host 199. For example, receiver 102 and remote monitor 114 may both need to accept the invitation or enter a code (e.g., password, shared secret, etc.) to opt into joining the remote monitoring provided at system 100.

[0162] In some exemplary implementations, one or more devices of the remote monitoring system 100 (e.g., remote monitor 114, receiver 102, gateway 104, user communication device 105, or workstation 22) may require codes, such as prescription codes provided by a healthcare provider, to register with the security server 110. Codes may expire after a predetermined time and / or may be limited to a predetermined number of uses (e.g., a one-time code that can be used once to register with the security server 110 to obtain a remote monitoring code). Furthermore, codes may also define the configuration of the device registered as remote monitor 114 on the server 110, such as permissions for alarm settings associated with the remote monitor (e.g., whether it can receive notifications, view past sensor data, and / or view current sensor data) and / or alarm settings associated with the remote monitor.

[0163] In some exemplary implementations, security server 110 may have configuration information defining the identities of receiver 102 and remote monitor 114, allowing a user (e.g., host 199) to access security server 110 and then add one or more devices (e.g., receiver 102 and remote monitor 114) to the user's system. Remote monitor 114 can query security server 110 for information about which hosts (or receivers) are allowed to monitor, and security server can configure remote monitor 114 accordingly. In some exemplary implementations, notification messages sent to remote monitors can be configured to suit the needs of a given remote monitor-user, and these needs may differ from those of a host-patient. Therefore, the rules governing the sending of notification messages to remote monitor 114 may differ from the rules used to trigger alarms to receiver 102 used by the host-patient.

[0164] The following reference Figure 2A An illustrative example of a caregiver using remote monitor 114 as part of host-patient care is provided. Specifically, the caregiver may administer analytical treatment to the host-patient. For example, the caregiver might be the parent of a young child. In this example, the parent might want to receive notification messages that are the same as alerts sent to (or triggered by) receiver 102 and the host-patient (in this case, the child). Furthermore, security server 110 can obtain the settings of receiver 102 via gateway 104. During the configuration of remote monitor 114, security server 110 may prompt the parent to select the same set of rules used by the child's receiver. In this example, any subsequent changes to this set of rules for the child's receiver will programmatically propagate to the set of rules used by remote monitor 114 to send notifications to the parent. Although the preceding example describes the same set of rules used by both the host and the monitor, the host and the monitor can also implement different sets of rules.

[0165] The following provides another illustrative example of a host-patient receiving treatment, but in this case, the host-patient or caregiver may not want a high degree of supervision of the host-patient. Therefore, the caregiver at remote monitor 114 may want the host-patient to receive the alarm first, but allow the patient-host to act on the alarm in a timely manner to correct or acknowledge the event before the alarm is sent to the caregiver. As an example, an alarm triggered by receiver 102 may indicate a hypoglycemic or hyperglycemic event, and if the host-patient does not take one or more predetermined actions to remedy the event after a certain period of time (e.g., as it becomes apparent by subsequent glucose measurements indicating the same or worsening patient condition), the caregiver at remote monitor 114 may receive a notification message in response to the event. That is, if the patient-host using receiver 102 does not respond to or acknowledge the alarm in a predetermined manner, the caregiver at remote monitor 114 may receive a notification message. When the host patient at receiver 102 fails to respond to or acknowledge a specific real-time event (e.g., a hypoglycemic event), which may be considered serious because the host-patient may be incapacitated or unaware of the event, and notification to the remote monitor is proceeding in an orderly manner, the caregiver at remote monitor 114 can therefore receive a notification message. However, if one or more predefined events are identified by the security server, the security server 110 responds to the notification message by delaying or ceasing the transmission of an alert. One or more predefined events may be the underlying events for clearing a trigger alarm, acknowledging an alarm, or taking a defined action (e.g., administering insulin).

[0166] Furthermore, the security server 110 can be configured to have a delay to wait for confirmation or action before notifying the remote monitor 114, and this delay can vary based on the type and / or severity of the condition that caused the warning, and according to the default or user-configured settings of the remote monitor. Additionally, the security server 110 can be configured to monitor data from the receiver 102 even after receiving a confirmation message from the receiver 102 in response to an alarm. For example, the security server 110 may receive a confirmation message (which could be a message sent by the receiver 102), but the security server 110 may need a predetermined time to wait for sensor data from the 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 that caused the warning.

[0167] The following provides another illustrative example of a host-patient relationship where treatment is administered, but in this case, the host-patient relationship is highly independent, so the remote monitor may only be triggered in emergency situations. For example, security server 110 may include rules to trigger the remote monitor in emergency situations (such as a severe hypoglycemic event occurring at night). In this case, the host-patient may not respond to an alert for the event, so security server 110 may trigger a notification message if glucose levels drop to extremely low levels over a period of time or if the user does not respond to a very low glucose alert sent to receiver 102 after a period of time. Additionally, the time period may vary based on the type and / or severity of the condition that triggered the alert.

[0168] Below is another illustrative example of a host-patient who is highly independent but unaware of hypoglycemia and has no trusted source for an emergency response. In this use case, the host-patient can select a remote monitor 114 associated with emergency medical services to automatically notify the service in the event of a severe hypoglycemic event, such as when glucose levels drop to extremely low levels over a period of time or when the user does not respond to a very low glucose level triggered by receiver 102 after a period of time.

[0169] Managing alarm settings for remote monitors

[0170] In some exemplary implementations, a user can manage alarms for each remote monitor 114A-114M monitoring host 199. For example, host 199 can use host monitoring system 198A to invite remote monitor 114A to become a monitor and configure permissions on security server 114 using receiver 102, gateway 104 (including host communication equipment), or workstation 22. Permissions can be specific to one or more specific alarms or global; in this sense, all alarms for remote monitor 114A can be manipulated by the user. Although the preceding examples describe user-set permissions, permissions can also be determined programmatically.

[0171] To manage alarms, users can access the security server 110 using computing devices (e.g., remote monitor 114, receiver 102, gateway 104, host communication device 105, or workstation 22) and manage alarms by, for example, setting alarms, changing thresholds, turning alarms on or off. Figure 13 An exemplary page 600 is depicted that can be displayed on a host computing device's screen. Page 600 may allow changes to alarms used by a remote monitor 114A. Figure 6 In this example, a low glucose warning 602 can be enabled at 610, and a threshold 604 is defined as a threshold that is configured by the user. Figure 6Page 600 also describes how delay 606 can be managed. For example, delay 606 could define how long security server 110 waits before sending a notification message from the security server (via the notification service) to remote monitor 114A if the host's glucose concentration remains below a low threshold. In this example, the delay is zero seconds, but this can be changed to another amount of time, such as 5, 10, 15, or 30 minutes or an hour, using page 600. Page 600 also allows security server 110 and / or notification service 112 to trigger sending an alert 612 and change the time 606 associated with triggering the alert. For example, an alert represents the amount of time elapsed before security server 110 triggers another notification to remote monitor 114A if the remote monitor has not yet acknowledged the alert or if the host has not cleared the event that initially triggered the alert. 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, security server 110 will send another notification about the low glucose level to remote monitor 114A. (See reference...) Figure 6 The examples described involve low glucose levels, delays, and alerts, but any other aspect of the alerts for remote monitor 114 described elsewhere in this document can be managed in the same way, such as high glucose level alerts, high rate of change alerts, etc.

[0172] In addition, although the above reference Figure 6 The description pertains to managing alarms for remote monitor 114, but in Figures 2A to 2C In implementation, a similar page can be used by receiver 102, gateway 104, or host communication device 105 to manage alarms triggered by the host communication device. As an example, host communication device 105 can display page 600, which is used to manage alarms through a host communication device independent of receiver 102. In this way, host communication device 105 can act as an auxiliary alarm device for host 199.

[0173] In some implementations, users can modify one or more rules that define alarms representing events associated with the state of the host's analyte. Users can use computing devices (e.g., remote monitor 114, receiver 102, gateway 104, host communication device 105, or workstation 22) to modify the alarm settings (e.g., low glucose level threshold, etc.) of the host monitoring system 198. In this way, parents, for example, can modify the settings of their child's remote monitoring system 198.

[0174] While the preceding examples involve modifying low glucose warnings, modifications may include changing a first threshold associated with low glucose levels in the host, changing a second threshold associated with high glucose levels in the host, changing the delay between when a message is triggered by receiver 102, changing the time value between when an alert message is sent, and any other alarms that may be triggered for host monitoring system 198 or remote monitor 114.

[0175] Furthermore, the security server 110 can adapt to this set of rules associated with host 199. For example, this set of rules for the remote monitor 114 used to monitor host 199 can be predetermined based on some basic host-patient demographics. After the initial use of the remote monitoring system 100, the security server 110 may programmatically adjust the thresholds used to trigger some or all events. These adjustments may be made for various reasons. For example, the thresholds used to determine when to trigger events (e.g., glucose levels, rate of glucose change, etc.) may be adjusted to reduce the frequency of some alarms and / or notifications, as the remote monitor 114 may decide to ignore these messages if it receives too many. The thresholds may also be adjusted to strengthen control over the range of glucose changes in the patient during the day in order to reduce the variability of the host's daily glucose variability.

[0176] In some exemplary implementations, data management tools and CGM analysis can be used to help patients better manage their diabetes or assist clinicians in making better recommendations. Because glucose data (and / or other analyte data) can be provided to a secure server 110 in approximately real-time, case managers in payment and / or healthcare systems can use the data to enhance ongoing diabetes management. However, the so-called “big data” obtained by diabetes case managers for review may be impractical. Therefore, filters can be used to facilitate the effective use of case managers’ time by identifying specific issues that allow the use of abnormal reports based on blood glucose patterns. For this purpose, one or more patterns can be defined at the secure server to identify issues requiring the attention of case managers. Patterns can include longitudinal analyses or comparisons between time periods. These patterns can also identify high-risk patients, such as those with frequent or severe lows, frequent or severe highs, and / or significant glucose variability. This may be considered particularly important for patients using intensive insulin therapy, those unaware of hypoglycemia, those with poor control, and those unfamiliar with insulin. Patterns can also identify treatment-unresponsive individuals, such as patients with persistent hyperglycemia, suggestive of treatment inresponse or worsening control, suggestive of non-compliance, disease progression, or rapid immunization. This can be particularly useful when a new medication is added or treatment is optimized. The pattern can also identify responders or non-responders who have been contacted with diabetes education or by a specific provider or counselor.

[0177] In some exemplary implementations, additional performance information can be collected from patients located in multiple locations at the security server 110. This additional information can be used to assess environmental factors that may affect and alter sensor performance. Instead of collecting and analyzing information from a single host-patient, data can be collected at the security server and then compared at a macro level across multiple host patients and / or across multiple geographic locations (or regions). Essentially, the overall effectiveness of sensor system 8 can be evaluated based on various monitored environmental factors. For example, data collected in real time from across the United States or even the world can show whether temperature, humidity, altitude, etc., affect the performance of sensor system 8, and thus provide indications about whether sensor system 8 and / or sensor 10 should be replaced or repaired. Furthermore, the security server 110 can also process the received sensor information and identify patterns (e.g., by batch number, region, etc.), and can upload additional algorithms, calibration information, or fail-safe features based on these identified patterns to improve sensor accuracy and / or performance.

[0178] In some exemplary implementations, the security server 110 may be programmatically track the product performance and utilization of a sensor system, including sensor 8 and / or receiver 102. For example, the sensor system and / or receiver may be programmatically provided to the security server 110 with information identifying the sensor (e.g., batch number) and outlining its performance. Performance metrics may include accuracy, timeliness, data acquisition, etc. Furthermore, if one or more sensor performance metrics fall outside the expected range, the security server 110 may request additional information to be transmitted from the sensor system / receiver to the security server to allow for failure mode classification. For example, the security server 110 may send alarms and / or notifications to receiver 102, gateway 104, and / or remote monitor 114 indicating that maintenance (e.g., replacement, repair, calibration, etc.) of sensor system 8 and / or receiver 102 is required based on determined performance information. Additionally, the security server 110 may be configured to send alarm or notification messages based on performance information indicating that a sensor needs to be reset, requires new calibration values, or that a new sensor should be ordered. The data provided to the security server 110 may be configurable and stored in a repository connected to the security server 110.

[0179] Furthermore, sensor system tracking performed by the security server can include tracking the performance of the receiver's wireless interface. For example, if a hardware error (or any detected error condition) occurs, error-related information can be transmitted to the security server 110. The transmitted data can also be used to track feature utilization, which may include alarm settings, screen access counts, etc. Additionally, this data can be used to collect and manage data during clinical studies. Furthermore, the sensor data transmitted to the security server 110 can be extended to track patient performance in glycemic control. In this case, performance metrics may include "time spent" across different glucose ranges, the magnitude of glycemic drift, insulin dosage information, etc. For example, during a continuous glucose monitoring (CGM) session, data can be automatically transmitted to the security server 110 and / or a host-patient and / or patient's clinical care provider's accessible linked repository. Thus, in some exemplary implementations, the aforementioned automated tracking of product performance and classification of failure modes can provide more accurate information about product performance, facilitate the resolution of sensor problems encountered by patients, and automate product replacement (or shipment) when sensor performance is deemed ready for replacement.

[0180] In some exemplary implementations, security server 110 can provide a closed control loop. Specifically, security server 110 can send messages to receiver 102, and receiver 102 responds to security server 110. Furthermore, security server 110 can send messages to remote monitor 114, and remote monitor 114 responds to security server 110. Therefore, security server 110 can request actions from receiver 102 and / or remote monitor 114, and receive acknowledgments from receiver 102 and / or remote monitor 114 upon completion of the action, thereby forming a closed loop. Receiver 102 may include one or more aspects of the functionality provided by remote monitor 114, and remote monitor 114 may include one or more aspects of the functionality provided by receiver 102.

[0181] Exemplary Host Monitoring System Setup Procedure 1000

[0182] Figure 10 This is a flowchart depicting a process 1000 for setting up a host monitoring system 198 according to some implementations. For illustrative purposes, reference will be made to... Figure 2C The setup process 1000 is discussed using the remote monitoring system architecture shown; however, it should be understood that the setup process 1000 can be applied to... Figure 2A or Figure 2B The architecture, in which changes are made to accommodate differences in architecture.

[0183] In addition, to further facilitate understanding, Figure 2CThe following components are used in one example of process 1000: sensor system 8 and receiver 102 constitute a DexCom G4 Platinum continuous monitoring system commercially available from DexCom, Inc., wherein 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 plugged into as shown in reference Figure 7B In the plug-in station 103 described and discussed; the host communication device 105 includes an Apple iPhone commercially available from Apple Inc.; and each remote monitor 114A-114M includes a... (Commercially manufactured by Apple Inc.) (Commercially produced by Google) or Apple iPhones or other mobile phones based on a mobile operating system (manufactured by Microsoft).

[0184] In box 1000, the user downloads the host monitoring application to the host communication device 105. (It should be understood that in...) Figure 2A In the implementation, the host monitoring application can be downloaded to gateway 104, or... Figure 2B In some implementations, the host monitoring application may be downloaded to receiver 102, for example. In some implementations, the host monitoring application is downloaded from a server, which may be independent of security server 110 (e.g., operated by a different entity), such as the Apple App Store server operated by Apple Inc. However, in some implementations, the host monitoring application is downloaded from server 110. The host monitoring application may include instructions for host communication device 105 to perform the host communication device functions described herein, such as collecting sensor data from receiver 102 via plug-in station 103, transmitting sensor data to security server 110, managing alarms of host monitoring system 198, inviting users to become remote monitors of the host, managing remote monitor settings, pairing with plug-in station 103 and / or receiver 102, etc.

[0185] Once the host monitoring application is downloaded to the host communication device 105, the user can open the application (e.g., by selecting the icon associated with the host monitoring application on the host communication device's home screen) and use the application to create an account in box 1012. In addition to storing account information on the host communication device 105, accounts are also created and stored on the security server 110. In some implementations, creating an account includes entering user identification information such as a name and email address, a password, and a unique identifier associated with the receiver 102 (e.g., the receiver's serial number). As discussed below in box 1016, the receiver's serial number can be used to pair the receiver 102 and / or the plug-in station 103 with the host communication device 105, among other functions.

[0186] Figure 9 The illustration shows an exemplary page 900 displayed on the account settings box 1012 by the host monitoring application to facilitate the input of the serial number or other unique identifier of the receiver 102. Here, page 900 is a diagram illustrating the location of the serial number to help the user locate the entered serial number. Page 900 also provides an alphanumeric input field that the user can optionally use to manually enter the serial number. Additionally, page 900 provides selectable icons 902 and 904 that allow the user to take a picture of the serial number using the camera of the host communication device 105 and to scan the serial number using the barcode scanner of the host communication device 105, respectively, to input the serial number.

[0187] In box 1014, the user uses a host monitoring application to manage alarm settings for the host communication device 105. The host application may initially present default alarm settings, which the user can modify using the user interface of the host communication device 105. In some implementations, alarm settings include repeating one or more alarms on receiver 102. In this way, the host communication device 105 can amplify (e.g., trigger an alarm of a different type than the one from the receiver, such as a louder alarm) and / or echo the alarm from the receiver (e.g., if the event that triggered the alarm on the receiver has not yet been cleared, then only sound the alarm after a predetermined amount of time from the alarm from the receiver). Alarm settings may also include turning alarms off or on for various events.

[0188] In box 1016, the user pairs the host communication device 105 with the plug-in station 103. In some implementations, to pair the host communication device 105 with the plug-in station 103, the user powers on the plug-in station and connects the receiver 102 to the plug-in station. At this point, the host communication device 105 and the plug-in station 103 begin the pairing and authentication process.

[0189] In some implementations, the plug-in station 103 does not have a display, and therefore conventional pairing and authentication procedures may be insufficient. Therefore, in some implementations, the receiver 102 provides the plug-in station 103 with a serial number stored in its memory, and the user inputs the receiver serial number into the host communication device 105. The serial number stored in the receiver 102's memory may be stored during the receiver's manufacturing process. The host communication device 105 can then transmit the serial number (or an encrypted version of the serial number) to the plug-in station to establish an authenticated communication channel.

[0190] The following pairing and verification procedure can be used in some implementations. In response to receiver 102 being plugged into plug station 103, plug station derives a verification token from the receiver's serial number (the receiver transmits the serial number to plug station) and places the verification token in a General Attribute Profile (GATT) feature. Plug station 103 then broadcasts a general advertisement for binding. Host communication device 105 searches for the advertisement. Upon discovering plug station 103, host communication device 105 connects and performs service discovery. Host communication device 105 then attempts to read the aforementioned GATT feature. Plug station 103 responds with an insufficient authorization message (pairing and encryption are required). Host communication device 105 then prompts the user to pair with plug station 103. Both plug station 103 and host communication device 105 compromise by using a long-term key for encryption before pairing. Host communication device 105 then reads the token from the aforementioned feature and uses this feature to verify the authenticity of plug station 103. The host communication device 105 has previously derived its own token from the receiver serial number previously entered into the host communication device in box 1012, and the host communication device 105 writes this token into the GATT feature in the plug-in station 103. The plug-in station 103 then uses this token to verify the authenticity of the host communication device, and if authentic, enters a persistent binding state.

[0191] In some implementations, using the pairing and authentication process described above, if the two devices (receiver 102 and plug station 103) are disconnected at any point, plug station 103 indicates an advertisement to establish a connection.

[0192] In box 1018, the user uses an application on host device 105 to invite remote monitor 114. Here, the application may prompt the user for information identifying potential users of the remote monitor, including names and email addresses accessible from the device capable of acting as remote monitor 114 (e.g., a mobile smartphone or tablet). Additionally, the application may prompt the user for permissions they desire for remote monitor 114 (e.g., permission to view trend chart data) and alarm settings they desire for remote monitor 114. Once complete, the application sends an invitation to remote monitor 114, where the information in the invitation (e.g., identification information, permissions, and alarm settings) is stored on security server 110. The user can use the above invitation procedure to invite additional remote monitors. In some implementations, the application may include a page listing the status of all invitations sent by the user.

[0193] It should be noted that the installation wizard implemented by the host monitoring application on the host monitoring device 105 can be used to implement the process 1000 in order to guide the user through the setup process 1000.

[0194] Example of remote monitor setup process 1600

[0195] Figure 16 This is a flowchart of an exemplary process for remote monitoring using remote monitor 114. Similar to process 1000, it will be referred to only for illustrative purposes. Figure 2C The architecture of the remote monitoring system 100 is described. Figure 16 .

[0196] In box 1610, the user receives an invitation to become a remote monitor on a computing device (e.g., a smartphone). (See reference...) Figure 12 The exemplary invitation is described and discussed in more detail. In some implementations, the user receiving the invitation can accept or reject it by selecting an accept icon or a reject icon in the email, respectively. Rejecting the invitation ends process 1600, while accepting the invitation moves process 1600 to box 1620.

[0197] In box 1620, if the user accepts the invitation, the invitation programmatically instructs the user to download the remote monitoring application via the user's computing device. In some implementations, accepting the invitation in box 1610 programmatically triggers the user's computing device to automatically access the server carrying the remote monitoring application. In the case of the user's device being an Apple mobile device, the server could be the App Store operated by Apple Inc. The user then downloads the remote monitoring application to their computing device.

[0198] It should be noted that in some implementations, the user of remote monitor 114 does not need to register with security server 110 because in some implementations, an invitation is formed from box 1012 of process 1000 ( Figure 10 The security server already has the user's account information at that time.

[0199] In box 1630, the user manages alarm settings using a remote monitoring application downloaded to the computing device (now considered to be remote monitor 114). In some implementations, alarm settings can initially be set under recommended alarm settings (or default settings if the person sending the invitation does not enter any recommended settings) set by the person sending the invitation in step 1012 of process 1000. The user of remote monitor 114 can then modify any recommended or default settings. These settings can include setting thresholds for when to trigger alarms to the remote monitor, delays, alerts, and no-data alarm settings, as discussed in more detail elsewhere herein. Remote monitor 114 can then transfer the remote monitor's settings to secure memory for storage and use when triggering alarms associated with the remote monitor.

[0200] In box 1640, remote monitor 114 monitors the analyte levels of the host when permitted. Monitoring may include using a remote monitor to monitor multiple hosts, as described in reference... Figure 1 This will be discussed in more detail. Monitoring may include receiving notifications triggered by security server 110 and sent via notification service 112, as well as viewing sensor data accessible from the security server. For example, in some implementations, a user may activate a remote monitoring application on remote monitor 114 to view a dashboard page showing glucose levels for multiple hosts.

[0201] Example invitation to become a remote monitor

[0202] As above Figure 16 As discussed in box 1610, users can receive invitations to remotely monitor host 199. In some implementations, the invitation is in the form of an email, for example... Figure 12 The invitation is depicted in the diagram. Users can accept or decline the invitation via email. Users can accept the invitation by indicating they wish to install the remote monitoring application by selecting optional text 504, or decline the invitation by selecting optional text 508. If a user declines the invitation, the remote monitoring system 100 can notify the host that sent the invitation, for example, by sending a notification to the communication device 105 via server 110 and / or notification service 112. However, if a user accepts the invitation, the remote monitoring system 100 can notify the host that they accepted, for example, by sending a notification to the communication device 105 via server 110 and / or notification service 112, and process 1600 continues to box 1620.

[0203] In some implementations, the recipient of the 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 provides account creation information (recipient name, email, phone number, etc.) when the invitation is generated. Furthermore, the host can include its own image during the invitation creation process, thus making the invitation include the host's image sent to the recipient (this helps the recipient know the invitation is valid), and the host's image can be used as the host's image in the remote monitor (e.g., in reference...). Figure 18A and Figure 18B (On the dashboard discussed elsewhere).

[0204] In some implementations, an invitation may include a single usage token, which the recipient can use to accept the invitation without needing to log in to the remote monitoring system. The token can be in the form of a globally unique identifier (GUID). The invitation may also include timestamps indicating when it was sent and when it expires.

[0205] System status check

[0206] In some implementations, users of the remote monitoring system 100 may not easily know whether the remote monitoring system 100 is working or why the system is not working. For example, in Figure 2B In implementation, the host 199 may not be aware that data is not being transmitted from the sensor system 8 to the server 110, or even if the host is aware that data is not being transmitted, it may not be able to identify the problem so that data transmission can be restored. Therefore, some implementations provide a system status page to help users identify whether the system is working properly, and if not, what the root cause of the problem might be.

[0207] Figure 11A and Figure 11B This is an exemplary view of a status page 1100 based on some implementations. Status page 1100 includes a status bar 1110 that includes representations of various components of the remote monitoring system 100. In this example, components of system 100 include a plug-in station 1114, a host communication device 1118, and a server 1112. Figure 11A and Figure 11B It also includes communication channels between each component of system 100, such as the first communication channel 1116 between plug-in station 1114 and host communication device 1118 (e.g. The status bar 1110 can indicate which components and communication channels are determined to be active and which are not. For example, if the connection is determined to be active, the connection may be graphically displayed in a first state, and if the connection is not active, the connection may be graphically displayed in a second, different state. The first and second states can be depicted in different ways, for example, using colors (e.g., green if in the first state and red if in the second state), and / or graphics (e.g., solid lines if in the first state and dashed lines if in the second state), etc. In addition, each section of the status bars 1114, 1116, 1118, 1120 and 1122 can be user-selectable, wherein if the user selects a specific section, the host monitoring application can display help information (e.g., in the form of a pop-up message or a new display) that can help the user resolve problems associated with the section selected by the user. For example, if the plug-in icon 1114 is in the second state and the user selects the plug-in icon, the remote monitoring application can display a message prompting the user to ensure the plug-in is plugged into a power source. Furthermore, for example, if the first communication channel is in the second state and the user selects the first communication channel, the remote monitoring application can display a message prompting the user to ensure the host monitoring device has an enabled Bluetooth connection.

[0208] Status page 1100 may also include role icons 1132 that display the overall status of the system. Figure 11A and Figure 11B In this example, character icon 1132 is depicted as a monster holding a sign. The appearance of character icon 1132 can change based on the system's state, allowing users to quickly determine the status by viewing the icon. For instance, character icon 1132 could have a smiling expression and hold a sign with checkmarks to indicate that the system is working and transmitting sensor data. Figure 11A As shown in the image. Conversely, character icon 1132 can have a frowning expression and hold a sign with an X to indicate that the system is not working, as shown in the image. Figure 11B As shown in the diagram. The color of the character icon 1132 can also change according to the system's state, for example, it is green when the system 100 determines that the system is working (i.e., sending data from the host to the server 1110), and red when the system determines that the system is not working.

[0209] The eye icon 1132 can also help indicate to the user whether the system is working; for example, it blinks if the host monitoring application is working, or it doesn't blink if it doesn't. The blinking can also correspond to the transmission rate between the plug-in station 103 and the host communication device. In this way, the user can distinguish whether the remote monitoring system is actively working, rather than the remote monitoring application being frozen in a state that indicates the system is working even when it is not.

[0210] The host monitoring application can also display status label 1124 on status page 1100 and any other pages displayed by the host monitoring application, such as in Figure 11A and Figure 11B As shown in the diagram. Status labels can be part of a menu that includes multiple different selectable labels associated with different display pages of the host monitoring application, which display the associated display page when selected. Figure 11A and Figure 11B The additional labels include follower label 1126, account label 1128, and more labels 1130. It is worth noting that the status label can always display an indication of the system's connection status; for example, it is displayed in green with a checkmark if the system is working (e.g., ...). Figure 11A As shown in the image), or if the system is not working, it will be displayed in red with an X (as shown in the image). Figure 11B (As shown in the image). Status labels can be displayed regardless of the current page, thus providing the user with an indication of the system's status regardless of the page displayed.

[0211] In some implementations, host monitoring system 198 may be configured to periodically send messages to server 110. If the server detects a lack of messages from host monitoring system 198 for a predetermined amount of time, the server may trigger a notification to be sent to the host monitoring system (e.g., receiver 102, gateway 104, or host communication device 105) to notify the host of the lack of messages, thereby allowing the host to use, for example, status page 1100 to check and determine whether the host monitoring system is working.

[0212] Host monitoring control page

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

[0214] Figure 14The illustration is based on an overview page 1400 of some implementations. The overview page may include multiple cells 1402a-1402e, each cell associated with a remote monitor or potential remote monitor. For identification purposes, each cell may include a name 1410a-1410e associated with the remote monitor. Cells 1402a-1402e may also be displayed according to the status of the remote monitor. For example, cell 1402a is associated with a remote monitor (in... Figure 14 Cells are grouped under state 1404a (referred to as "follower"), cell 1402b under expired invitation state 1404b, cell 1402c under active state 1404c, cell 1402d under invited state 1404d, and cell 1402e under non-shared state 1404e. Note that multiple cells can be displayed under each group; for easier explanation of the different groupings, Figure 14 Only one cell is shown for each group.

[0215] Page 1400 also includes selectable help icons 1406a-1406e associated with each group status. By selecting a help icon, the host monitoring application can provide the user with additional information explaining the content related to the associated status. For example, help information can be displayed in a pop-up window.

[0216] Icons may also appear in cells that describe the permissions and / or enabled features associated with the remote monitor. For example, icons 1412 and 1414 indicate that the remote monitor associated with cell 1402c has enabled notifications and permission to view trend graph information associated with the monitored host, respectively. Conversely, if the remote monitor does not have permissions for a specific feature (such as viewing the host's trend graph), the corresponding icon may not be displayed in the cell indicating that the missing permission can be provided alternatively, or in a different icon.

[0217] You can also provide selectable labels in each cell. For example, Figure 14 The illustration shows the removal labels 1408a and 1408b, which remove cells from the page when selected by the user. Arrow labels 1416c-1416e can be used to provide additional information about the remote monitors associated with this cell. For example, selecting the selectable arrow 1416 can redirect the host monitoring application to a settings display page, which provides more details about the associated remote monitors and their settings.

[0218] exist Figure 15The diagram illustrates an exemplary settings display page 1500 based on some implementations. Settings display page 1500 may include identification information, such as the name 1502 and email address 1504 associated with the remote monitor, the remote monitor's permissions, and the remote monitor's notification settings. Figure 15 In an example, permissions may include a trend chart permission 1504 label, which a user can use to toggle between allowing permission to view the chart and denying permission to view the chart. If allowed, the remote monitoring system 100 allows the remote monitor to view the trend chart information of the host 199, and if denied, the remote monitor cannot view the host's trend chart information. Notification settings allow users of the host monitoring application to view the current notification settings of the relevant remote monitor. Notification settings may include urgent low notification alarms 1506, low notification alarms 1508, high notification alarms 1509, and no data notification alarms 1510, as well as the status associated with each alarm (e.g., relevant thresholds and whether the alarm is off or on). In some implementations, users of the host monitoring application can modify the remote monitor settings, for example, using page 1500, but in other implementations, some or all settings may be modified only by the remote monitor, such as... Figure 15 As indicated in the document.

[0219] Display page 1500 also allows users of the host monitoring application to pause and cancel the remote monitor 114A's ability to monitor the host 199. The pause / resume control button 1514 can selectively stop and restart the remote monitor's remote monitoring capabilities, such as stopping and starting notifications sent to the remote monitor and / or the remote monitor's permission to view the host's sensor data. This functionality can be useful when the host does not always want the remote monitor to monitor it. A specific example could be a caregiver acting as a remote monitor. It might be necessary for the caregiver to have remote monitoring capabilities while caring for a child monitored by the host monitoring system, but to stop remote monitoring when the caregiver no longer cares for the child. In this way, it is not necessary to send a new invitation to the caregiver every time she cares for the child, allowing the caregiver to selectively control monitoring.

[0220] The delete 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 some implementations, compared to the pause / resume control 1514, deleting a remote monitor using the delete control 1516 will require the host to re-invite the person to become a remote monitor. As discussed elsewhere herein, the remote monitoring system 100 may have a predefined limit on the number of remote monitors that can monitor the host; therefore, in some implementations, it may be necessary for the host to delete a remote monitor so that the host can add another remote monitor.

[0221] In some implementations, the remote monitoring system 100 sends notification messages to the remote monitor indicating that its permissions or settings have been changed or that it has been suspended, resumed, or canceled by the relevant host system. In this way, the remote monitor is notified of changes without relying on previous configurations.

[0222] Furthermore, each pause, cancel, and resume function can be configured globally on all remote monitors associated with the host, rather than just on individual monitors as described above. In the case of global functionality, for example, it can be configured on page 1400 (in... Figure 14 (Not shown in the image) provides separate global pause, cancel, and resume control buttons, where pressing the global control button globally implements the respective functions on all remote monitors of the monitoring host.

[0223] Remote monitoring dashboard view

[0224] As discussed elsewhere in this document, remote monitor 114 can provide a so-called dashboard view of the host performing monitoring on the remote monitoring device. Figure 18A and Figure 18B These are two different implementations of dashboard page 1800. Dashboard 1800 may include multiple cells 1802a-1802d, each associated with a different host. Each cell 1802 may include the host's identifier, such as the host's default name, and an image of the host 1804a-1804d provided in the invitation.

[0225] exist Figure 18A In implementation, each cell lists the current status of the cell, such as the time when the analyte value 1806a currently displayed in the cell was measured (1812a), a statement 1812b indicating whether the host is using the remote monitoring system 100, a statement 1812c indicating whether the host's host monitoring system is working, or a statement 1812d indicating, for example, that the remote monitor has been suspended.

[0226] exist Figure 18B In implementation, cells 1802 can be grouped on page 1800 based on their status, for example, cells 1814 can be removed by the host (in...). Figure 18B (Referred to as a sharer in the original text) Activity 1818 (i.e., the system is connected to the remote monitor and provides relevant host data to the remote monitor), Disconnect 1824 (i.e., the system is not connected, for example, because...) Figure 2B In the implementation, receiver 102 is not in plug-in station 103) and there is no sharing 1826 (i.e., the host has suspended the remote monitor). Furthermore, cells within a group can be ordered by the severity of the monitoring situation or other criteria, as discussed elsewhere in this document.

[0227] Cell 1802 may also include indications of permissions and / or settings for remote monitors associated with the host. For example, a trend chart icon 1810 may indicate that the remote monitor has permission to view trend charts of this host's sensor data.

[0228] Refer again Figure 18B Cell 1802 in activity group 1818 may also include information about the monitored health status. For example, cell 1802 may display the latest analyte concentration value 1806a provided to the remote monitor and a trend arrow 1808a indicating the rate of change of the measured analyte. Other information may also be provided in the cell, such as the time 1812a associated with the measurement of the displayed analyte concentration or whether data has not yet been received from the host monitoring system.

[0229] The user selection in cell 1802 can also switch the remote monitor display to another page that provides additional information about the host associated with this cell. For example, the remote monitor can switch to a trend chart display associated with this host. Figure 19 ) or the settings page associated with this host ( Figure 17 (The arrow ">" indicates whether more information is available for the cell.)

[0230] View trend chart

[0231] Figure 19 This is an exemplary page providing a trend graph 1914 of analyte concentration for host monitoring, based on some implementations. The trend graph may display a trend line 1916 of the measured analyte concentration, as well as low thresholds 1918 and high thresholds 1920 for alarming remote monitor 114 or host monitoring system 198. The trend graph page may also include a user-selectable slider that allows the user to select different time frames of sensor data to view, for example, 3, 6, 12, and 24-hour views. An image of host 1904 and the name of host 1902 may also be provided, so that the remote monitor will not be confused about the individual being monitored if it is monitoring multiple different hosts.

[0232] In some implementations, when the remote monitoring application is initially opened in response to a user directly opening the application and / or a remote monitoring notification sent by server 110 or notification service 112 on remote monitor 114, it can be automatically displayed. Figure 19The page is as discussed elsewhere in this document. To illustrate this, when the remote monitor 114 receives a notification, it can display the notification on the lock or home screen. The user can select the notification (e.g., using a predefined gesture), and the remote monitor 114's recognition of the notification causes it to display a trend graph of the host associated with the notification.

[0233] Remote monitoring settings page

[0234] Figure 17 This is an implementation of a settings page 1700 displayed on a remote monitoring device 114, which allows the remote monitor to configure the host's remote monitoring settings. The settings page may include a picture bar displaying a picture of the host 1506 and a name bar displaying the host's name; both the picture and name bars can be modified by the remote monitor using settings page 1700. In some implementations, the host initially provides a picture and / or name during the aforementioned invitation process, but the remote monitoring system allows the user of the remote monitor to later modify the picture and / or name. The settings page also includes settings for various alarm / notification settings (e.g., urgent low alarm 1706, low alarm 1714, high alarm 1724, and alarm with no data 1736). The functionality of each of these alarms is discussed elsewhere in this document. Figure 17 As shown, settings associated with each of these alarms can be modified, such as turning the alarm on or off, changing the threshold associated with each alarm, and changing the alarm warning associated with each alarm (e.g., sound, volume, vibration, or tone).

[0235] Automatic detection and registration of new receivers

[0236] In some implementations, receiver 102 needs to be associated with host 199 so that when glucose data arrives at server 110, the data can be associated with the host. Therefore, remote monitoring system 100 can assign a receiver to a host. This can be initially referred to above. Figure 10 The pairing process discussed in box 1016 is completed. If the host receives a new receiver for a user-friendly experience and to prevent errors, the host monitoring application can see that a different serial number is being used, check with server 110 to see if it is a new receiver, or if this receiver already belongs to another host, and ask the host via communication device 105 if this is their receiver and allow them to take ownership, or give them an error, telling them: this receiver is already owned.

[0237] Therefore, an exemplary detection process for a new receiver can be as follows. First, it is determined whether the host communication device 105 is using a new receiver by verifying with a server whether the receiver belongs to someone else (e.g., via a comparison of 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 he or she wants to make this receiver their receiver. If so, the receiver and the data from this receiver are associated with this host.

[0238] Data alarm lost

[0239] In some exemplary implementations, the security server 110 may include rules that automatically trigger a notification message or another communication mechanism (e.g., a telephone call, SMS service message, etc.) to the remote monitor 114 if no data is received from the host monitoring system 198 associated with the remote monitor within a predetermined amount of time. In this way, the user of the remote monitor 114 can become aware that the host monitoring system 198 may be malfunctioning and attempt to contact the host.

[0240] Location-based alerts

[0241] In some exemplary implementations, the security server 110 may use the locations of receiver 102, gateway 104, host 199, and / or remote monitor 114 when determining whether to send a notification message and / or determining the destination of the notification message. For example, when a monitored host is at a first location and moves to a second location, the security server 110 may select a first remote monitor 114A located near the first location based on rules, and select a second remote monitor 114B located near the second location when the host moves to the second location. Location can also be used to modify alarms and notifications. For example, the security server 110 may change the rules used to trigger alarms or notifications based on the host's location. Location may also be used in conjunction with time, allowing the security server 110 to change thresholds associated with alarms and notifications based on location and / or time.

[0242] Confirmation Notice

[0243] In some exemplary implementations, receiver 102 or gateway 104 may present a prompt (e.g., message, window, etc.) on the user interface that requires host confirmation to trigger an alarm and / or indicates what corrective action to take in response to the alarm. The prompt may include a pre-populated list of options that the user can select (e.g., administered insulin, consumed carbohydrates, etc.) to indicate the corrective action to be taken. The notification message may be sent directly to one or more remote monitors 114, or via security server 110 and / or notification service 112 to the remote monitors, thereby informing the remote monitors that the patient has confirmed the alarm and / or taken a corrective action (and / or a description of the corrective action).

[0244] Additionally, remote monitor 114 can allow the user to select from a plurality of pre-filled messages to send to the host monitoring system. The user can select a notification, and the remote monitor displays a list of pre-filled text messages from which the user can select to send to the host monitoring system. Messages can be selected by the remote monitor as relating to the underlying cause that triggered the notification message. For example, if the notification message is triggered by the host's low glucose level, the message could be a statement related to the low glucose level, such as "Are you feeling well?", "Should you drink some orange juice?", etc. Each message can be user-selectable, and when selected, causes remote monitor 114 to send the message to the host monitoring system for display on the host monitoring system, for example, directly from the remote monitor to the host system 198 or indirectly via server 110. Furthermore, the selection of a notification can automatically display a prompt to call the host, whereby the user's selection prompts remote monitor 114 to dial a phone number associated with the host (e.g., a smartphone that is part of the host monitoring system 198).

[0245] Motivation message

[0246] In some exemplary implementations, alarm and / or notification messages sent to receiver 102 may include motivational concepts. For example, if the host-patient has minimized the rate of change in blood glucose levels, the security server may send an alarm to receiver 102 and / or a notification message stating "Well done, keep your treatment—stick with it!" to remote monitor 114. These motivational concepts can positively encourage the user to remain on the treatment regimen. In some exemplary implementations, security server 110 may include one or more events mapped to motivational concepts, such that triggering events cause messages including motivational concepts to be sent to receiver 102 and / or remote monitor 114.

[0247] In some exemplary implementations, security server 110 may use patterns as described above to predict aspects of patient-host treatment. For example, a pattern may detect changes in blood glucose levels from a previously established pattern at a given time, then trigger rules to send an alert to receiver 102 and a notification stating "Did you miss lunch?" to receiver 114. These simple, non-technical query messages may 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 exemplary implementations, security server 110 may include one or more events mapped to simple messages, such that triggering an event causes a message including the simple message to be sent to receiver 102 and / or remote monitor 114.

[0248] Audit trail

[0249] Security server 110 may also provide audit trails. For example, security server 110 may store information about when notifications are pushed to remote monitor 114 using, for example, notification service 112, and when the remote monitor acknowledges the notifications. Security server 110 may also generate one or more reports to determine timelines and / or identify the effectiveness of remote monitor 114 (this effectiveness may be used to select settings for remote monitor and / or system 100, such as alarm settings, to more effectively monitor host 199).

[0250] Timestamp

[0251] In some implementations, the analyte level provided to remote monitor 114 may not be real-time. For example, where it may be necessary to provide analyte values ​​to the remote monitor in real time, there may be a time delay between when the analyte value is measured by analyte sensor system 8 and when the analyte level is provided to remote monitor 114 and / or security server 110. For example, the delay may be due to any sensor system 8 only periodically transmitting values ​​to receiver 102, receiver 102 only periodically transmitting values ​​to gateway 104, the gateway being difficult to connect to security server 110, and the security server being difficult to connect to remote monitor 114. Therefore, in some implementations, the glucose value transmitted to remote monitor 114 is displayed on the remote monitor, where the time indicates the time corresponding to the analyte value that triggered the notification (e.g., the analyte value that reached or exceeded the threshold for triggering the notification). The time may be the moment the analyte value was measured (e.g., 2:10 PM Pacific Standard Time) or a time difference since the analyte value was measured (e.g., 2 minutes ago, 30 minutes ago, 4 hours ago, etc.).

[0252] Additionally, due to time delays, the security server 110 may ultimately send a notification to the remote monitor 114 based on the analyzed values ​​at that time delay. In this case, the notification may include the time associated with the alarm that triggered the notification, such as "Mike's blood glucose is below 70 mg / dL at 2:10 p.s." or "Mike's blood glucose was below 70 mg / dL 25 minutes ago." Furthermore, because the notification may not be immediately visible on the remote monitoring device, the remote monitoring device 114 may automatically update any time associated with the notification until the notification is acknowledged.

[0253] In some implementations, to accommodate the time zone difference between the host and the remote monitor, the remote monitoring system can use World Time (UTC) and then convert UTC to the remote monitor's time zone. That is, the timestamps of sensor data values ​​generated by the host monitoring system 198 and provided to the security server 110 can be in UTC or Greenwich Mean Time (GMT) and provided to the remote monitor 114 in the same UTC, whereby the remote monitor converts UTC to its own time zone, as indicated by the remote monitoring device.

[0254] In some implementations, time lag and potential time zone differences between the host monitoring system 198 and the remote monitor 114 make it difficult to display time, which may cause confusion. Therefore, notifications sent to the remote monitor 114 do not display time. To compensate for the lack of time indication, some implementations automatically open the remote monitoring application on the remote monitor 114 and display the user's monitored health information after the user confirms the notification. The host's monitored health information initially displayed after opening the application may include an indication of the host's current status, such as the latest analyte values ​​and / or a trend graph showing the host's measured analyte levels over the past three hours, such as... Figure 19 The trend chart page shown.

[0255] Data transmission loss

[0256] In some implementations, data may sometimes fail to be transmitted from sensor system 8 to security server 110. Depending on the system, this could be due to unintentional loss of data transmission connections, for example, between sensor system 8 and receiver 102, receiver 102 and gateway 104, plug-in station 103 and host communication device 105, or gateway 104 and security server 110. Alternatively, the loss could be intentional, such as when a user shuts down one or more components of remote monitoring system 100 (e.g., receiver 102 or host communication device 105). In any such case, security server 110 can be configured to automatically send a notification indicating data transmission loss to one or more of host monitoring system 198 and remote monitors 114A-114M upon detecting such loss.

[0257] However, sometimes it may be necessary not to send such data transmission loss notifications so that the remote monitor 114 is not over-messaged. For example, the monitored host might be sleeping at night and get up to go to the kitchen for a glass of water. This could lead to data transmission loss, for instance, if the sensor system 8 is outside the range of the receiver 102 located on the host 199's bedside table. Therefore, a delay associated with data transmission loss errors can be implemented so that the server 110 initiates a data loss notification only after a predetermined amount of time or after a predetermined number of connection attempts with the host monitoring system 198 have failed to receive data.

[0258] Furthermore, it may be necessary to not send a data loss notification each time data transmission is lost, even if the data transmission loss occurs over an extended period of time. For example, in Figure 2C In this implementation, the plug-in station 103 can be fixed. Therefore, the host may only be able to transmit health readings when the host has a receiver 102 plugged into the plug-in station and the host is sufficiently close to the receiver and the plug-in station for data transmission. However, for example, when the host leaves to go to work, the host may want to remove his or her receiver 102 from the plug-in station 103. When the host removes the receiver from the plug-in station 103, it may not be necessary to trigger a notification to the remote monitor 114, as this may not be considered an event of sufficient importance.

[0259] Therefore, in some implementations, the remote monitoring system 100 can determine that the receiver has been removed from the plug-in station 103, rather than because the host monitoring system 198 is malfunctioning or failing to provide sensor data to the security server for some reason. In one implementation, the remote monitoring system 100 determines that the receiver is not plugged into the plug-in station 103 by monitoring transmissions from the plug-in station. For example, a transmission from the plug-in station 103 including information generated by the receiver 102 indicates that the receiver is plugged in, and a transmission from the plug-in station 103 not including information generated by the receiver indicates that the receiver has been removed from the plug-in station.

[0260] Glasses display device

[0261] Although the above disclosure is primarily described in relation to the use of handheld computing devices, it should be understood that other devices can be used in place of or replace smartphones. For example, in some implementations, sensor data is transmitted from a personal computing device to a computing device in the form of glasses, and messages and information are displayed on the glasses for the user to view. An example of such glasses is Google Glass, manufactured by Google. The user's glasses interface can receive data directly from the sensor system 8 or through an intermediate device (such as receiver 102 or gateway 104) using a near-field radio link.

[0262] In some implementations, data transfer can be event-driven, for example, driven by events such as low or high glucose drift, as discussed herein.

[0263] Various implementations of the subject matter described herein can be implemented using digital electronic circuit systems, integrated circuit systems, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. The circuit systems can be mounted on printed circuit boards (PCBs), etc., and can take the various forms described above. These various implementations can include implementations in one or more computer programs executable and / or interpretable on a programmable system comprising at least one programmable processor, which can be a dedicated or general-purpose programmable processor coupled to receive data and instructions from a storage system, at least one input device, and at least one output device, and to transfer data and instructions to the storage system, at least one input device, and at least one output device.

[0264] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level programming and / or object-oriented programming languages ​​and / or assembly / machine language. As used herein, the term "machine-readable medium" refers to any permanent computer program product, apparatus, and / or device (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, which includes a machine-readable medium for receiving machine instructions.

[0265] To provide interaction with a user, the subject matter described herein can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user, and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form, including sound, speech, or tactile input.

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

[0267] Although some variations have been described in detail above, other modifications are also possible. For example, while the description of specific embodiments of the present subject discusses analytical applications, the present subject is also applicable to other types of software and data access services. Furthermore, although the above description relates to a specific product, other products may also be used. Additionally, the logical flows depicted in the accompanying drawings and described herein do not require the specific or sequential order shown to achieve the desired results. Moreover, as used herein, the term "group" includes zero or more items, and the phrase "based on" may be used interchangeably with the phrase "at least based on" (unless otherwise stated). Other embodiments may be within the scope of the following claims.

[0268] Although this disclosure has been described and illustrated in detail in the accompanying drawings and the foregoing description, such description and illustration are to be regarded as illustrative or exemplary rather than restrictive. This disclosure is not limited to the disclosed embodiments. Those skilled in the art can understand and implement variations of the disclosed embodiments from a reading of the drawings, the disclosure, and the appended claims when practicing the claimed disclosure.

[0269] All references cited herein are incorporated herein by reference in their entirety. Where any publication or patent or patent application cited herein contradicts the disclosure contained in the specification, the specification is intended to supersede and / or take precedence over any such contradictory material.

[0270] Unless otherwise defined, all terms (including technical and scientific terms) will be given their common and customary meaning to those skilled in the art, and unless expressly defined herein, these terms will not be limited to any particular or customary meaning. It should be noted that the use of a particular term in describing certain features or aspects of the disclosure should not be construed as meaning that the term is hereby redefined as limited to any specific characteristic of the features or aspects of the disclosure to which this term is associated. Unless otherwise expressly stated, terms and phrases used in this application and its variations (especially in the appended claims) should be interpreted as open-ended rather than restrictive. As an example of the foregoing, the term 'including' should be interpreted as meaning 'including but not limited to,' 'including but not limited to,' etc.; as used herein, the term 'including'... The terms 'ing', 'including', 'comprise', or 'characterized in' are synonymous and are all-encompassing or open-ended, and do not exclude additional, unlisted elements or method steps; the term 'having' should be interpreted as 'having at least'; the term 'includes' should be interpreted as 'including but not limited to'; the term 'example' is used to provide exemplary instances of the items under discussion rather than an exhaustive or limiting list thereof; adjectives (e.g., 'known', 'normal', 'standard') and terms with similar meanings should not be interpreted as limiting the described items to items available up to a given time period or a given time, but rather should be interpreted as covering known, normal, or standard techniques that may be available or known at any time now or in the future; and the use of terms such as 'preferred', 'ideal', 'desired', or 'hopefully' and terms with similar meanings should not be construed as meaning that certain features are critical, necessary, or even important to the structure or function of the invention, but rather are intended only to highlight alternative or additional features that may or may not be utilized in a particular embodiment of the invention. Similarly, unless explicitly stated otherwise, a group of items connected by the conjunction 'and' should not be interpreted as requiring the presence of every item in that group, but rather as 'and / or'. Likewise, unless explicitly stated otherwise, a group of items connected by the conjunction 'or' should not be interpreted as requiring mutual exclusion within that group, but rather as 'and / or'.

[0271] When providing a range of values, it should be understood that the implementation includes an upper and lower limit, as well as each intermediate value between the upper and lower limits of the range.

[0272] Regarding the use of virtually any plural and / or singular terms herein, those skilled in the art can convert from plural to singular and / or from singular to plural as appropriate for the context and / or application. For clarity, various singular / plural arrangements may be explicitly stated herein. The indefinite article “a” does not exclude plural. A single processor or other unit may perform the functions of several items listed in the claims. The mere fact that certain measures are listed in dissimilar dependent claims does not indicate that combinations of these measures cannot be advantageously used. Any reference marks in the claims should not be construed as limiting the scope.

[0273] Those skilled in the art will further understand that if a specific number of claims is intended to be introduced, such an intention will be explicitly stated in the claims, and if such a statement is absent, then no such intention exists. For example, as an aid to understanding, the appended claims may include the use of the introductory phrases “at least one” and “one or more” to introduce the claim recitation. However, the use of such phrases should not be construed as meaning that the indefinite article “a” introducing the claim recitation limits any particular claim containing such an introductory claim recitation to an embodiment containing only one such recitation, even when the same claim includes the introductory phrases “one or more” or “at least one” and an indefinite article (e.g., “a”) (e.g., “a” should generally be interpreted as meaning “at least one” or “one or more”); the same applies to the use of definite articles used to introduce the claim recitation. Furthermore, even if a specific number of claims is explicitly stated, those skilled in the art will recognize that such a statement should generally be interpreted as meaning at least a number (e.g., a simple statement like “two recitations” without other modifiers generally means at least two recitations or two or more recitations). Furthermore, in instances where a convention similar to "at least one of A, B, and C" is used, generally, such a construction is intended to make the meaning of this convention clear to those skilled in the art (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). In instances where a convention similar to "at least one of A, B, or C" is used, generally, such a construction is intended to make the meaning of this convention clear to those skilled in the art (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having only A, only B, only C, both A and B, both A and C, both B and C, and / or both A, B, and C). Those skilled in the art will further understand that any separate words and / or phrases presenting two or more alternative items, whether in the description, claims, or drawings, should be understood to contemplate the possibility of including one item, any item in the items, or both items. For example, the phrase “A or B” would be understood to include the possibilities of “A” or “B” or “A and B”.

[0274] All numerical values ​​used in the specification regarding the quantity of expressed components, reaction conditions, etc., shall be understood to be modified by the term 'approximately' in all instances. Therefore, unless otherwise indicated, the numerical parameters set forth herein are approximate values ​​that may vary depending on the desired properties sought to be obtained. At least, and without attempting to limit the application of the equivalence principle to the scope of any claim in any application claiming priority to this application, each numerical parameter shall be interpreted in accordance with the number of significant figures and ordinary rounding.

[0275] Furthermore, although the foregoing description has been presented in considerable detail with illustrations and examples for clarity and understanding, those skilled in the art will recognize that certain variations and modifications can be practiced. Therefore, the description and examples should not be construed as limiting the scope of the invention to the specific embodiments and examples described herein, but rather covering all modifications and substitutions falling within the true scope and spirit of the invention.

Claims

1. A method for remotely monitoring glucose concentrations of multiple hosts via any number of remote wireless mobile computing devices communicating with a remote server system, wherein the remote server system stores glucose concentration data for each of the multiple hosts, and the glucose concentration data for each host is obtained by measurement using a different glucose monitoring system, the method comprising: At the remote server system, a request from a first remote monitoring application installed on a first remote wireless computing device is authorized to receive glucose information from the first host; At the remote server system, a request from a second remote monitoring application installed on a second remote wireless computing device is authorized to receive glucose information from the second host; One or more first rules and one or more second rules are established on the remote server system. The one or more first rules are defined by the first host and can be modified by a first user using the first remote monitoring application. The one or more second rules are defined by the second host and can be modified by a second user using the second remote monitoring application. The one or more first rules include a first threshold associated with the glucose concentration of the first host. The one or more second rules include a second threshold associated with the glucose concentration of the second host. The first threshold is different from the second threshold. The remote server system determines that at least some glucose concentration data received from the glucose monitoring system of the first host, indicating the glucose concentration of the first host, are above or below the first threshold. The remote server system generates a first notification providing event information based on determining that at least some glucose concentration data indicating the glucose concentration of the first host exceeds or falls below the first threshold; The first notification is sent by the remote server system to the first remote wireless computing device, wherein the first remote wireless computing device is configured to display the first notification regardless of whether the first remote monitoring application is active or inactive on the first remote wireless computing device, and to activate the first remote monitoring application if the first remote monitoring application is inactive. The remote server system receives and confirms a first confirmation from the first remote monitoring application, the first confirmation indicating that the first user has received the first notification. Only after the first confirmation is confirmed does the remote server system provide the first remote monitoring application with additional glucose concentration data indicating the glucose concentration of the first user. The remote server system determines that at least some glucose concentration data received from the glucose monitoring system of the second host, indicating the glucose concentration of the second host, are above or below the second threshold. The remote server system generates a second notification providing event information based on determining that at least some glucose concentrations, which indicate the glucose concentration data of the second host, exceed or fall below the second threshold. The remote server system sends the second notification to the second remote wireless computing device, wherein the second remote wireless computing device is configured to display the second notification regardless of whether the second remote monitoring application is active or inactive on the second remote wireless computing device, and to activate the second remote monitoring application if the second remote monitoring application is inactive. and The remote server system receives and confirms a second confirmation from the second remote monitoring application, the second confirmation indicating that the second user has received the second notification. Only after the second confirmation is confirmed will the remote server system provide the second remote monitoring application with additional glucose concentration data indicating the glucose concentration of the second user.

2. The method as described in claim 1, characterized in that, The first remote wireless computing device and the second remote wireless computing device are smartphones.

3. The method as described in claim 1, characterized in that, The first notification is a text message.

4. The method as described in claim 1, characterized in that, The glucose monitoring system of the first host includes a continuous glucose sensor, a sensor electronics module attached to the glucose sensor, and a receiver that wirelessly communicates with the sensor electronics module, wherein the sensor electronics module transmits at least some glucose concentration data indicating the glucose concentration of the first host to the receiver; and the receiver transmits at least some glucose concentration data indicating the glucose concentration of the first host to the remote server.

5. The method as described in claim 4, characterized in that, The receiver is a smart mobile communication device, which has an application downloaded to receive sensor data from the transmitter and send the sensor data to the remote server.

6. The method as described in claim 5, characterized in that, The method further includes: the receiver applying multiple predefined thresholds to the sensor data; and triggering a user-perceptible alarm when the sensor data meets one or more of the multiple predefined thresholds.

7. The method as described in claim 1, characterized in that, The method further includes configuring one or more first rules based on configuration parameters received from the first remote monitoring application, the configuration parameters including the first threshold.

8. The method as described in claim 1, characterized in that, The one or more first rules additionally include data loss rules, and the method further includes: If the remote server system does not receive glucose concentration data indicating the glucose concentration of the first host from the glucose monitoring system of the first host within a predetermined time period, the remote server system shall determine whether the data loss rule is met. The remote server system sends a third notification indicating data loss from the glucose monitoring system of the first host to the first remote wireless computing device, the glucose monitoring system of the first host, or both the first remote wireless computing device and the glucose monitoring system of the first host.

9. The method as described in claim 1, characterized in that, The one or more first rules can be configured by the first remote wireless computing device but not by the second remote wireless computing device, and the one or more second rules can be configured by the second remote wireless computing device but not by the first remote wireless computing device.

10. The method as described in claim 1, characterized in that, The first threshold and the second threshold are hypoglycemia thresholds, wherein the hypoglycemia threshold of the first threshold is different from the hypoglycemia threshold of the second threshold.

11. The method as described in claim 1, characterized in that, The first threshold and the second threshold are hyperglycemia thresholds, wherein the hyperglycemia threshold of the first threshold is different from the hyperglycemia threshold of the second threshold.

12. The method as described in claim 1, characterized in that, Each of the first threshold and the second threshold includes a threshold selected from the group consisting of a low glucose threshold, a high glucose threshold, and a glucose change rate threshold.

13. The method as described in claim 1, characterized in that, Before authorizing a request from the first remote monitoring application installed on the first remote wireless computing device, the first remote wireless computing device is invited by the first host to remotely monitor the glucose information of the first host, and the first remote wireless computing device is invited by receiving an invitation generated by the remote server system.

14. The method as described in claim 13, characterized in that, The invitation generated by the remote server system includes code associated with both the first remote wireless computing device and the computing device of the first host communicating with the glucose monitoring system of the first host, and wherein authorization of a request from the first remote monitoring application depends at least in part on the remote server system receiving the code in communication from the first remote wireless computing device.

15. The method as described in claim 13, characterized in that, The invitation is associated with a set of recommended rule settings configured by the first host for the first remote wireless computing device using the receiver device of the first host's glucose monitoring system, wherein the recommended rule settings are provided to the first remote wireless computing device for accepting or modifying to establish one or more first rules corresponding to the first remote wireless computing device.

16. The method as described in claim 1, characterized in that, The first notification providing the event information, generated by the remote server system based on determining that at least some glucose concentration data indicating the glucose concentration of the first host exceeds or falls below the first threshold, includes: the first notification providing the event information being generated by the remote server system based on determining that at least some glucose concentration data indicating the glucose concentration of the first host exceeds or falls below the first threshold and satisfies another rule among one or more first rules.

17. The method as described in claim 1, characterized in that, The first notification indicates an emergency low glucose concentration, low glucose concentration, or high glucose concentration.

18. The method as described in claim 1, characterized in that, The first notification is sent to the first remote wireless computing device and the third remote wireless computing device.

19. The method as described in claim 1, characterized in that, The method further includes the remote server system providing the first remote wireless computing device with past glucose concentration data indicating the glucose concentration of the first host previously received from the glucose monitoring system of the first host, so that the first remote monitoring application can display a glucose trend graph of the glucose concentration data of the first host on the display of the first remote wireless computing device.

Images