Remote monitoring of specimen measurement

Abstract

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

Description

Technical Field

[0001] Cross-reference to related applications Any claim of priority identified in the present application datasheet, or any amendment thereto, is incorporated herein by reference under 37 CFR 1.57. This application claims the benefit of U.S. Provisional Application No. 61 / 747,717, filed on December 31, 2012, U.S. Application No. 13 / 842,679, filed on March 15, 2013, and U.S. Application No. 13 / 843,382, filed on March 15, 2013, the disclosures of which are hereby expressly incorporated by reference in their entirety and made a part of this application.

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

Background Art

[0003] True diabetes is a disease in which the pancreas cannot produce sufficient insulin, such as type 1 diabetes, and / or insulin is not effective, such as type 2 diabetes. In diabetes, patients suffer from hyperglycemia, which causes various physiological disorders associated with the deterioration of capillaries, such as renal failure, skin ulcers, or bleeding into the vitreous of the eye. Hypoglycemic reactions, such as hypoglycemia, may be induced by accidental over-intake of insulin, or after normal administration of insulin or glucose-lowering drugs simultaneously with excessive exercise or insufficient food intake.

[0004] Diabetic patients can carry a blood glucose self-monitoring (SMBG) monitor that typically requires an uncomfortable finger-pricking method. Due to the lack of comfort and convenience, diabetic patients typically measure their glucose levels only 2 to 4 times a day. Unfortunately, these time intervals are too far apart, so diabetic patients are likely to discover hyperglycemia or hypoglycemia too late, sometimes resulting in dangerous side effects. In fact, not only is it less likely for diabetic patients to obtain SMBG values in a timely manner, but also diabetic patients do not know whether their blood glucose levels are high or low based on conventional methods. Thus, various non-invasive transdermal (e.g., transcutaneous) and / or implantable electrochemical sensors have been developed to continuously detect and / or quantify blood glucose levels. These, as well as other types of devices, generally transmit unprocessed or minimally processed data for subsequent analysis on a remote device, which may include a display to enable presentation of information to the user hosting the sensor.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Patent Document 2

Patent Document 3

Patent Document 4

Patent Document 5

Summary of the Invention

Means for Solving the Problems

[0006] A method and apparatus are provided, including a computer program product, for remote monitoring of specimen data. In some implementations, a method is provided. The method includes receiving, at a remote monitor, a notification message representing an event detected by a server from specimen sensor data obtained from a receiver that monitors a host's specimen status; presenting, at the remote monitor, a notification message for enabling the remote monitor, where the remote monitor is configured to receive a notification message from the server for enhancing a receiver that monitors the host's specimen status; accessing, by the remote monitor, the server in response to the presentation of the notification message; and receiving, in response to the access, information including at least the specimen sensor data.

[0007] In some implementation examples, the above aspect can further include additional features described herein, including one or more of the following. The notification message may be received from at least a first wireless connection between the remote monitor and a notification service connected to the server, and the additional information may be received from at least a second wireless connection between the remote monitor and the server. The first wireless connection can include a persistent encrypted connection configured to carry short messages pushed by the notification service to a notification message center in the remote monitor, and the second wireless connection can include an established temporary encrypted connection in response to access to provide additional information including at least additional analyte sensor data. The presentation can further include blocking access to one or more applications on the remote monitor until it is detected that the operation on the remote monitor indicates receipt of the notification message, and the remote monitor can further include a monitoring application. The notification message may be presented as a temporary message on the display of the remote monitor without blocking access. At least one of the remote monitor and the receiver can include one or more of a mobile station, a wireless terminal, a tablet, a smartphone, a multimode wireless device, and a computer. The server is configured to receive analyte sensor data from the receiver, process the analyte sensor data to detect an event, and map the event to a remote monitor designated to receive a notification message for the detected event based on one or more rules, and transfer the notification message to the remote monitor. The event may be detected at the server based on a first set of rules, and the first set of rules used to generate the notification message may be different from a second set of rules used to detect a warning transmitted to a receiver connected to the sensor system at the host. The receiver may include or be connected to a gateway that interfaces a public land mobile communication network and a wireless connection to the server.A plurality of remote monitors may be configured, at least one of the plurality of remote monitors may be designated as a primary monitor, and at least one of the plurality of remote monitors may be designated as a secondary monitor. The remote monitor can configure at least one rule representing a trigger for causing the server to send a warning to the receiver. The remote monitor can configure one or more invitations to be sent to one or more devices to invite the one or more devices to monitor the receiver. The server can send a message to confirm receipt of the notification message. The notification message can include at least one of an indication of the need to calibrate the sensor and at least one of the confirmation messages indicating at least one of the actions or confirmations sent by the receiver in response to the warning sent to the receiver. Activation of the remote monitor can include opening a monitoring application. A connection may be established between the remote monitor and the server to enable receipt of information including analyte sensor data. The server can register at least one of the remote monitor, the receiver, and the analyte sensor coupled to the receiver, and the registration can include a code provided by a healthcare provider. The method may be implemented on a device comprising at least one processor and at least one memory including code that, when executed by the at least one processor, causes the device to provide the method. The computer-readable storage medium can include code that, when executed by at least one processor, causes the method to occur.

[0008] In another aspect, a method is provided. The method includes receiving, at a remote monitor, an invitation to access a secure server and data associated with a receiver that monitors an analyte state of a host, and modifying, by the remote monitor, a rule that defines a warning representing an event associated with the analyte state of the host, wherein the warning, when triggered, causes a message to be sent to the remote monitor to notify the remote monitor of the event.

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

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

Brief Description of the Drawings

[0011] In the drawings,

[0012]

Figure 1

Figure 2A

Figure 2B

Figure 2C

Figure 3

Figure 4A

Figure 4B

Figure 5

Figure 6

Figure 7A

Figure 7B

Figure 8

Figure 9

Figure 10

Figure 11A

Figure 11B

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18A

Figure 18B

Figure 19

DETAILED DESCRIPTION OF THE INVENTION

[0013] The implementation examples described in this specification can include a system for one or more caregivers (e.g., parents, spouses, or healthcare workers) to remotely monitor the health characteristics of one or more hosts. The health characteristics can include the concentration of a host's analyte such as glucose, or physical functions such as heart rate, blood pressure, or body temperature. Additionally, other characteristics of the host, such as the geographical location of the host, the state of the host (e.g., exercise, sleep, or labor), etc., can be monitored to facilitate the care of the host. The health characteristics and other characteristics can be collected using a computing device such as a smartphone, and a host monitoring system incorporating one or more sensors such as a continuous glucose sensor, a heart rate monitor, a GPS device, etc. Additionally, the host can manually input information such as dietary information, the frequency and amount of drug administration, etc., into the computing device. The information collected by the host monitoring system can then be transmitted to one or more remote monitors used by the caregiver. The caregiver(s) can then use the remote monitoring system to receive information regarding the health status of the host. In some implementation examples, the host monitoring system can directly transmit information to one or more remote monitors, and / or the host monitoring system can first transmit the information to a remote server, and the remote server can then transmit the information to the host monitor.

[0014] For illustrative purposes only, the following example is a non-limiting, exemplary environment in which the implementations of the remote monitoring system described in this specification can be used.

[0015] In this exemplary environment, a host who is a diabetic patient is monitored by several different caregivers. The host has a continuous glucose monitoring system such as the DexCom G4 (registered trademark) Platinum continuous glucose monitoring system commercially available from DexCom, Inc., and the system provides measurements of the host's glucose levels on a display device such as the DexCom G4 (registered trademark) Platinum Receiver, also commercially available from DexCom, Inc.

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

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

[0018] As described above, the remote monitor can be used by a caregiver to monitor the health characteristics of a host, which in this exemplary environment is the host's glucose concentration level. Similar to the host monitoring system, the remote monitoring system can consist of a smartphone such as an iPhone (registered trademark) 4S or iPhone (registered trademark) 5, and a remote monitoring software application that includes instructions configured to function the smartphone as a remote monitoring system. The remote monitoring software application can be in the form of a so-called "app" downloaded from the Apple App Store operated by Apple, Inc. The remote monitoring system can receive notifications from the server when a threshold is exceeded and notify the caregiver using the remote monitoring system of the host's status. The remote monitoring system can also be used to display past information regarding the monitored glucose levels of the host and to change notification rules such as the threshold levels that trigger notifications.

[0019] The following provides more details of a specific implementation example, which may or may not include the functions shown in the above-described exemplary environment.

[0020] Figure 1 represents the system architecture at a higher level of the implementation of the remote monitoring system 100. Here, the remote monitoring system 100 includes a plurality of host monitoring systems 198A - 198N connected to a plurality of remote monitors 114A - 114M via a network 118. Each host monitoring system 198 may be one or more health monitoring devices that collect health - related data associated with a host and can transmit the health - related data via a network 108. Implementation examples of the health monitoring systems 198A - 198N will be described in more detail in other parts of this disclosure. In some implementation examples, they include one or more sensors and a computing device operably coupled to the sensors, and can collect, process, and transmit health - related data. The network 108 can 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. The network 108 also includes one or more servers 110, which can process health - related data received from one or more remote monitors 114A - 114M, either automatically or in response to a request from a remote monitor, and can notify and transmit data to one or more remote monitors 114A - 114M.

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

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

[0023] Using the remote monitoring system 100 of FIG. 1, one or more remote monitors 114A - 114M can monitor one or more host monitoring systems 198A - 198N. As an example, host monitoring system 198A can be monitored by remote monitors 114A and 114B, and at the same time, remote monitor 114A can also monitor host monitoring system 198B. As will be described in more detail below according to the present disclosure, various permissions and invitations can be used to limit the remote monitors 114A - 114M that can monitor the host monitoring systems 198A - 198N.

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

[0025] Figure 2A represents an example of a system 100 for monitoring information related to the health of host 199 according to some implementation examples. Here, the remote system 100 includes a continuous specimen monitoring system 8 that includes a sensor electronic module 12 and a continuous specimen sensor 10. The system 100 may also include a drug delivery pump 2 (e.g., an insulin or glucagon pump), a glucose meter 4 (e.g., a fingertip puncture blood glucose meter), and any other devices and / or sensors such as any other devices and / or sensors. The continuous specimen sensor 10 may be physically connected to the sensor electronic module 12, integrated with (e.g., non-removably attached to) the continuous specimen sensor 10, or removably attached.

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

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

[0028] For purposes of illustration as an example, host 199 may access receiver 102 to display data from, or control the manner of, continuous analyte sensor 10, delivery pump 2, and / or glucose meter 4. However, another entity such as a parent, caregiver, healthcare worker, school nurse, etc. may cause remote monitor 114 to receive a notification message representing a predetermined event determined based on sensor data from receiver 102, continuous analyte sensor 10, delivery pump 2, and / or glucose meter 4, and display past and substantially real-time sensor data. For example, the event may include one or more of a measured analyte sensor value that exceeds or is less than a predetermined threshold, a rate of change or level of a glucose measurement value that exceeds a predetermined threshold, a predicted (or predicted to reach) glucose value that has reached a predicted threshold, host 199 that does not respond to a prompt, or a warning displayed on receiver 102, and / or any other event detected by secure server 110 and / or receiver 102. In the example of FIG. 2A, remote monitor 114 represents a notification message 132 indicating a low glucose level of host 199. Thus, an entity having remote monitor 114 can assist host 199 by providing an additional layer of monitoring and supervision of host 199, as well as receiver 102, continuous analyte sensor 10, delivery pump 2, glucose meter 4, etc.

[0029] In some implementation examples, the remote monitor 114 can include a processor, a non-transitory computer-readable storage medium (e.g., memory, storage, etc.), a radio access mechanism (e.g., a modem, etc.), and / or a user interface. The computer-readable medium can 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 specimen sensor 10, the delivery pump 2, the glucose meter 4, etc. In some implementation examples, the remote monitor 114 is an iPhone (registered trademark) mobile phone from Apple, Inc., and the application is an application downloaded from the Internet using an app store service operated by Apple, Inc.

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

[0031] In some implementation examples, the warning rules of the receiver 102 may be different from those of the remote monitor 114. For example, compared to a set of rules used to trigger a notification to the remote monitor 114, a different set of rules can define when a warning is sent and / or triggered by the receiver 102. Further, the receiver 102 can trigger a warning on its own (e.g., by applying a threshold to sensor data received from the sensor system 8), receive a warning from the sensor system 8, or receive a warning directly from the secure server 110, while the remote monitor 114 may be configured to receive messages such as short messages, text messages, etc. from the notification service 112, and these messages can function to enable the remote monitor 114, such as enabling the remote monitor application of the remote monitor. For example, the remote monitor 114 can close the remote monitor application session (as well as the proximity network connection 109 to the secure server 110) if the remote monitor application is not being effectively used by the remote monitor to conserve power. In such a case, the notification service 112 can send a message from the network connection 111 to enable the remote monitor 114 and / or the remote monitor application (further, this enabling can be automatic or under the control of the user of the remote monitor 114).

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

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

[0034] In some implementations, the secure server 110 can register and / or configure one or more of the receiver 102, the continuous analyte sensor 10, the delivery pump 2, the glucose meter 4, and the host 199 before process 197 is initiated, although the registration and / or configuration can occur at other times. The registration process may be performed to register the receiver 102, the continuous analyte sensor 10, the delivery pump 2, the glucose meter 4, the remote monitor 114, and / or the host 199 with the secure server 110. Additionally, the configuration process may be performed to configure the system 100 including the identification of one or more remote monitors used to monitor the receiver 102, to configure one or more rules used to trigger notification messages to the remote monitor, to configure one or more rules for designating primary and secondary remote monitors, to configure one or more rules for establishing schedules for the primary and secondary monitors, to configure one or more rules for defining a reporting sequence representing the timing for reporting events to the primary or secondary monitor, and the like.

[0035] At 180, the receiver 102 can transmit sensor data, such as analyte data from the sensor system 8, etc., to the gateway 104, and the gateway 104 then transfers the sensor data to the secure server 110 at 182. For example, the receiver 102 can be coupled to the gateway 104 via a wired or wireless connection, and the gateway 104 can be coupled to the secure server 110 via the network 108A. The gateway 104 can be configured to pull the most recent and / or past data from the receiver 102, either on its own or in response to a request from the secure server 110.

[0036] At 186, the secure server 110 can determine whether to send a notification message regarding an event to one or more of the remote monitors 114A to 114M, such as the remote monitor 114A. The secure server 110 can determine whether to send a notification message to the remote monitor 114 based on an event being triggered (or a rule being satisfied) at the secure server and the received sensor data (as well as any other data available at the secure server). For example, at 182, after receiving the sensor data, the secure server 110 can then process only the received sensor data or the received sensor data together with other data (such as past data, data from other information sources of patient information, etc.) to determine whether to send a notification message warning of the event to the remote monitor 114. The secure server 110 can also receive information from other systems, such as a health management system or a system of medical staff, and this information may be used to trigger a notification message to the remote monitor. In addition, the secure server 110 can send a notification message to confirm whether the remote monitor is still effectively monitoring the host 199.

[0037] To illustrate by way of example, the receiver 102 can receive sensor data from the host 199 and transmit the sensor data to the secure server 110 via the gateway 104 and the network 108A. The secure server 110 can process the sensor data and determine a glucose level event by comparing the latest glucose level data to a predetermined low glucose threshold. However, other events described herein may also be detected. The secure server 110 can include one or more rules that define events such as a low level of glucose that exceeds the threshold, and can include rules that define the identification of a remote monitor that receives a notification message indicating a low level of glucose at the host 199. For example, the rule can define that when a low level of glucose is detected at a predetermined host, a predetermined remote monitor should receive a notification message. The notification message can include an indication of the low level of glucose (e.g., a glucose value), the time of the event, and other information such as a graph of the latest and past glucose levels, host information (e.g., name), and / or any other information related to the host.

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

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

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

[0041] At 187, the secure server 110 can send a warning to the receiver 102 and / or the gateway 104. The warning may be triggered based on the same or different events as the rules used to trigger an event of a notification message to the remote monitor 114. Moreover, the secure server 110 can include a delay between when the warning is sent at 187 and when the notification message is sent at 188 - 190. For example, since the receiver may also have a set of rules that are the same as or different from the receiver rules stored in the secure server, the delay can enable the receiver 102 to perform a check or an operation before sending a message at 188 - 190. That is, the receiver 102 may trigger a warning based on rules existing inside the receiver, and the receiver may receive a warning from the secure server based on a different set of rules stored in the secure server. The delay before the secure server 110 sends a notification to the receiver 102 may be varied by the secure server based on the severity or type of the event, and the delay may be configured by the user and / or programmatically. For example, a first delay may be used for a first low analyte threshold, but no delay may be used for a lower glucose threshold where the second severity is higher.

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

[0043] In an implementation example using a push notification service, the notification service 112 can receive a notification message from the secure server 110. The notification message can include a destination address such as the phone number or IP address of the remote monitor 114, and a payload such as the content of the notification message. Returning to the previous example regarding a low glucose level, the notification message can include the phone number of the remote monitor 114 and a short text message such as a low glucose level value, the time of measurement of the value, and / or the identification of the host. The notification message may be limited to 256 bytes, but messages of other sizes may also be used. In any case, the notification service 112 pushes the notification message to the remote monitor 114 via a connection such as an Internet Protocol (IP) connection between the notification service server 112 and the notification message center of the remote monitor 114. When the notification message center of the remote monitor 114 receives the notification message, the notification message center can display the notification message and generate a sound, vibration, or other indication for the user of the remote monitor 114. Further, in some implementation examples, the notification message center or the user of the remote monitor can enable the remote monitoring application of the remote monitor 114 when the remote monitoring application of the remote monitor 114 is not being effectively used. In an implementation example where the remote monitor 114 exists on a device such as a smartphone, a notification service 112 that puts the remote monitor 114 or its application into an idle or inactive mode may be used to conserve power or reduce signal transmission to / from the network.

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

[0045] At 192, when a notification message is received, the remote monitor 114 or the remote monitoring application inside it may be activated if it is in the idle mode or the invalid mode. When activated (either programmatically or potentially under the user's control), the remote monitor 114 can attempt to establish a connection to the secure server 110. For example, the remote monitoring application may not be in active use (e.g., in the idle mode, sleep mode, power off, background mode, etc.). To activate the remote monitoring application, the remote monitoring application may be activated, for example, by selecting and expanding the remote monitoring application to open it, by entering values to effectively use the remote monitoring application, by selecting elements of the user interface of the remote monitoring application, etc. Moreover, the remote monitor and / or the remote monitoring application may be activated in other ways. For example, the activation may be triggered by the movement of the remote monitor detected by the motion sensor and / or by enabling the display on the remote monitor or increasing the brightness of the display.

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

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

[0048] More specifically, when the remote monitor 114 receives a notification message, the notification can cause a message 132 to appear on the display screen of the remote monitor 114 as shown in FIG. 2A. From the message 132, the remote monitoring application can be enabled either spontaneously or under the command of the user and / or the notification message center. The remote monitoring application then accesses the secure server 110 at 192 and can programmatically receive any additional information associated with the event or other data since the last connection to the secure server 110. For example, when the notification message is confirmed at the access of 194 or with a confirmation message, the secure server 110 can automatically respond with a page having a trend graph of the latest glucose status and information indicating the severity of the event (or any other information available at the secure sensor 110). Instead, the secure server 110 may respond with a subset of the data, in which case the secure server 110 may automatically respond with new data since the last connection to the secure server 110, and the remote monitor can generate a page including a trend graph showing the glucose levels for the past three hours. In either case, the remote monitor may be configured to automatically present a page showing related event information, such as a trend graph covering the specified time of the host (e.g., the glucose levels for the past three hours), when the message 196 is received. Exemplary pages that may be automatically presented are illustrated in FIG. 19 and will be discussed in more detail elsewhere in the present disclosure.

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

[0050] Figures 4A and 4B each represent an example of a notification message 170 and 172. In the example of the notification message 170, the notification message 170 may be presented on the remote monitor 114 as a window that requests user interaction when the remote monitor 114 receives the notification message. For example, user interaction can include pressing a button on the remote monitor 114, touching the screen of the remote monitor in an area associated with a part of the message 170, or enabling the remote monitoring application of the remote monitor 114 (e.g., running, opening, etc.). In some cases, the notification message 170 can display that another application of the remote monitor 114 is being effectively used. In this case, user interaction can include touching the screen in an area associated with a part of the message 170 to confirm receipt of the notification message 170 before the user can restart another application, but the user's action may prevent the startup of another application and make the remote monitoring application the active application displayed on the remote monitor. Moreover, the determination of whether to prevent the startup of another application or restart another application may be pre-determined based on the severity level of the event such that relatively more severe events prevent the startup of another application while less severe events do not.

[0051] In the example of the notification message 172, the notification message 172 may be presented on the remote monitor 114 as a message displayed on the user interface as an information message that does not require user intervention. Moreover, when the notification message 172 is displayed while another application is being used on the remote monitor 114, the notification message 172 does not require the user to confirm the notification message 172 or even enable the remote monitoring application (which may be in an idle or inactive state on the remote monitor 114), and for this reason, the user can continue to use other applications.

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

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

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

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

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

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

[0058] Referring again to FIGS. 2A - 2C, the sensor electronic module 12 can include, in some implementation examples, electronic circuitry associated with measuring and processing data generated by the continuous analyte sensor 10. This generated continuous analyte sensor data can also include algorithms that can be used to process and calibrate the continuous analyte sensor data, although these algorithms may be provided in other ways. The sensor electronic module 12 can include hardware, firmware, software, or combinations thereof to provide measurements of analyte levels via a continuous analyte sensor such as a continuous glucose sensor. An implementation example of the sensor electronic module 12 will now be described in detail with reference to FIG. 5 here.

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

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

[0061] FIGS. 2A and 2B depict an implementation example of the receiver 102 as a handheld display device, but other forms of elements may also be used, such as relatively small key fob-like, dongle-like display devices, mobile phones (e.g., smartphones, tablets, etc.), personal computers 20, and / or any other user devices configured to present at least information (e.g., drug delivery information, individual self-monitoring glucose measurements, heart rate monitor, calorie intake monitor, etc.).

[0062] In some implementation examples, the continuous analyte sensor 10 includes a sensor for detecting and / or measuring an analyte, and the continuous analyte sensor 10 may be configured to continuously detect and / or measure the analyte as a non-invasive device, a subcutaneous device, a transcutaneous device, and / or an intravascular device. In some implementation examples, the continuous analyte sensor 10 can analyze a plurality of intermittent blood samples, but other analytes may also be used.

[0063] In some implementation examples, the continuous analyte sensor 10 can include a glucose sensor configured to measure glucose in the blood using one or more measurement techniques such as enzymatic, chemical, physical, electrochemical, spectroscopic, polarimetric, calorimetric, electrophoretic, radiometric, immunochemical, etc. In an implementation example where the continuous analyte sensor 10 includes a glucose sensor, the glucose sensor can include any device capable of measuring the concentration of glucose, and can use various glucose measurement techniques including invasive, minimally invasive, and non-invasive techniques (e.g., fluorescence monitoring) to provide data such as a data stream indicating the concentration of glucose in the host. The data stream may be an unprocessed data signal, and is converted into a calibrated and / or filtered data stream used to provide glucose values to a user such as the host or a caregiver (e.g., a parent, family member, guardian, teacher, doctor, nurse, or any other individual interested in the health status of the host). Moreover, the continuous analyte sensor 10 may be implanted as at least one of an implantable glucose sensor, a transcutaneous glucose sensor implanted intravascularly or extracorporeally in the host, a subcutaneous sensor, a refillable subcutaneous sensor, and an intravascular sensor.

[0064] The description in this specification refers to several implementation examples that include a continuous analyte sensor 10 with a glucose sensor, but the continuous analyte sensor 10 can also include other types of analyte sensors. Moreover, several implementation examples refer to the glucose sensor as an implantable glucose sensor, but other types of devices that are capable of detecting the concentration of glucose and providing an output signal representing the glucose concentration may also be used. Further, the description in this specification refers to glucose as the analyte being measured, processed, etc., but instead of or in addition to that, other analytes may be used, including, for example, ketone bodies (e.g., acetone, acetoacetic acid, and beta-hydroxybutyric acid, lactate, etc.), glucagon, acetyl CoA, triglycerides, fatty acids, intermediates of the citric acid cycle, choline, insulin, cortisol, testosterone, etc. In some implementation examples, in addition to or instead of the analyte monitoring described in this specification, other health characteristics of the host are monitored, including but not limited to heart rate, blood pressure level, blood oxygen concentration, body temperature, calorie intake, drug delivery, etc.

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

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

[0067] In some implementation examples, the sensor electronic module 12 may be configured to calibrate sensor data, and the data storage memory 220 can store the calibrated sensor data points. Additionally, the sensor electronic module 12 may be configured to wirelessly receive calibration information from a device such as the receiver 102 in some implementation examples to enable calibration of the sensor data. Further, the sensor electronic module 12 may be configured to perform additional algorithm processing (e.g., configured and / or filtered data, and / or other sensor information) on the sensor data, and the data storage memory 220 may be configured to store the transformed sensor data and / or sensor diagnostic information associated with the algorithm.

[0068] In some implementation examples, the sensor electronic module 12 can include an application specific integrated circuit (ASIC) 205 coupled to a user interface 122. The ASIC 205 can further include a low potential electrolysis device 210, a telemetry module 232 for transmitting data from the sensor electronic module 12 to one or more devices such as the receiver 102, and / or other components for signal processing and data storage (e.g., a processor module 214 and a data store 220). FIG. 2 depicts the ASIC 205, but other types of circuits can be used including a field programmable gate array (FPGA), one or more microprocessors configured to provide some (but not all) of the processing performed by the sensor electronic module 12, analog circuits, digital circuits, or combinations thereof.

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

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

[0071] The remote measurement module 232 may be operably connected to the processor module 214 and can provide hardware, firmware, and / or software that enables wireless communication between the sensor electronic module 12 and one or more other devices such as a receiver 102, a display device, a processor, a network access device / gateway, etc. A variety of wireless radio technologies that can be implemented by the remote measurement module 232 include Bluetooth (registered trademark), Bluetooth (registered trademark) Low-Energy, ANT protocol, NFC (Near Field Communication), ZigBee, IEEE802.11, IEEE802.16, cellular radio access technology, radio frequency (RF), infrared (IR), paging network communication, magnetic induction, satellite data communication, spread spectrum communication, frequency hopping communication, short-range communication, etc. In some implementation examples, the remote measurement module 232 includes a Bluetooth (registered trademark) chip, but the Bluetooth (registered trademark) technology may also be implemented in the combination of the remote measurement module 232 and the processor module 214. Further, in FIG. 2, the remote measurement module is represented as part of the ASIC 205, but in other implementation examples, some or all of the remote measurement module can be separate from the ASIC.

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

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

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

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

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

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

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

[0079] The user interface 222 can include various interfaces such as one or more buttons 224, a liquid crystal display (LCD) 226, a vibrator 228, an audio transducer (e.g., a speaker) 230, a backlight, etc. The components with the user interface 222 can provide control for interacting with a user (e.g., a host). The one or more buttons 224 can enable, for example, toggling, menu selection, option selection, status selection, yes / no responses to on-screen questions, an "off" function (e.g., for warnings), a "snooze" function (e.g., for warnings), reset, and / or the like. The LCD 226 provides the user with, for example, a visual data output. The audio transducer 230 (e.g., a speaker) can provide an audible signal in response to a trigger of a predetermined warning such as a current and / or predicted hyperglycemic and hypoglycemic state. In some implementations, the audible signal may be distinguished by tone, volume, duty cycle, pattern, duration, etc. In some implementations, the audible signal can be configured to be muted (e.g., snoozed or turned off) by pressing one or more buttons 224 of the sensor electronic module and / or by signaling the sensor electronic module using a button or selection on a display device (e.g., a key fob, a mobile phone, etc.).

[0080] Although the audio and vibration warnings have been described with reference to FIG. 2, other warning mechanisms may also be used. For example, in some implementations, a tactile warning including a prodding mechanism configured to "prod" the patient in response to one or more warning states is provided.

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

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

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

[0084] In some continuous analyte sensor systems, the on-skin portion of the sensor electronics may be simplified to minimize the complexity and / or size of the on-skin electronics. For example, only unprocessed, calibrated, and / or filtered data is provided to a display device such as receiver 102 configured to perform the calibration and other algorithms described above with respect to sensor electronics module 12. However, sensor electronics module 12 may be implemented to perform the expected algorithms used to generate the converted sensor data and / or displayable sensor information, such as algorithms for evaluating the reference and / or clinical acceptability of the sensor data, evaluating calibration data for optimal calibration based on clinical conditions, evaluating the quality of calibration, comparing the estimated analyte value to the measured analyte value over time, analyzing the variability of the estimated analyte value, evaluating the stability of the sensor and / or sensor data, detecting signal artifacts (noise), replacing signal artifacts, determining the rate of change and / or trend of the sensor data, performing dynamic and advanced analyte value estimation, performing a diagnosis regarding the sensor and / or sensor data, setting the mode of operation, evaluating data anomalies, and the like.

[0085] FIG. 5 shows an individual data storage device and program memory, although various configurations may also be used. For example, one or more memories may be used in sensor electronics module 12 to provide storage space to support data processing and storage requirements.

[0086] Some of the examples described refer to the continuous analyte sensor 10, glucose meter 4, and pump 2 in communication with the sensor electronics module 12 and / or receiver 102, although other devices may be used. For example, the sensor electronics module 12 and / or receiver 102 can be coupled (either via a wired and / or wireless link) to other sensors including, for example, a glucose sensor, altimeter, accelerometer, temperature sensor, location module (e.g., a global positioning system processor or other source of location information), heart rate monitor, blood pressure monitor, oxygen concentration meter, calorie intake monitor, drug delivery device, and the like.

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

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

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

[0090] FIG. 6 is a block diagram of an implementation example of the gateway 104. The gateway 104 can include a power module 302 for charging the receiver 102 when connected to the gateway 104, a wireless network interface 304 that can provide a wired connection to the network 108A by the gateway 104 but enables wireless access to the network 108A using various network access technologies, and a computer memory in which a processor 314 stores instructions for executing the functions of the gateway 104 and stores health-related information received from the receiver 102.

[0091] Furthermore, in an implementation example where the receiver is separated from the gateway and the gateway does not include the intermediate docking station 103, the gateway 104 can include a receiver interface 306 that provides a wired and / or wireless interface to the receiver 102. For example, the receiver interface 306 may include a universal serial bus interface through which the receiver 102 can communicate with the gateway, the secure server 110, etc. The universal serial bus can also provide a physical connection for charging the receiver 102, although wireless charging may also be used. Additionally, the receiver interface 306 can include a wireless interface such as Bluetooth (registered trademark), Bluetooth (registered trademark) low energy, Zig-bee, Atom, and any other wireless technologies through which the receiver 102 can communicate with the gateway 104, the secure server 110, etc. The gateway 104 can also include a user interface 310 such as a display, a touch screen display, a keypad, a speaker, a light-emitting diode, etc. For example, one or more light-emitting diodes may be used to indicate whether the gateway 104 is properly connected to the receiver 102, the network 108A, the secure server 110, etc., whether the gateway 104 is connected to a power source (e.g., an outlet), or whether the battery is charged. The display can also enable the presentation of sensor data, warnings, notifications, etc. For example, the user interface such as the display and the light-emitting diode can provide an indication such as a specific color light-emitting diode, a message, etc., indicating that a connection such as an Internet protocol connection or a secure tunnel has been established between the gateway 104 and the secure server 110, so that the user of the gateway 104 can recognize that the receiver is connected to the so-called "cloud" including the secure server 110.

[0092] As described above, in some implementation examples, the gateway 104 can include a smartphone having a host monitoring application stored thereon that configures the smartphone to perform the functions of the gateway 104 described herein.

[0093] Figures 7A and 7B depict an example of a docking station 700 that can be the docking station 103 described with reference to Figure 2C. Figure 7A shows a perspective view of the docking station 700 with the receiver 102 not physically connected to the docking station, and Figure 7B shows a front view of the docking station with the receiver 102 physically connected to the docking station. The docking station 700 can have a cavity 710 that allows the receiver 102 to be slidably inserted into and removably held within the docking station. The docking station 700 can also include a mechanical mechanism (not shown) for removably securing the receiver 102 to the docking station. This mechanism can be a latch assembly or the like. The docking station can be electrically coupled to the receiver 102 via an electronic connector such as a universal serial bus connector and / or a wireless interface such as Bluetooth (registered trademark), Bluetooth (registered trademark) low-energy, Wi-Fi, and any other wireless technology, and can use the electronic connector and / or Bluetooth (registered trademark), Bluetooth (registered trademark) low-energy, Wi-Fi, and any other wireless technology to transmit data received from the receiver 102 to the host communication device 105, the secure server 110, or the remote monitor 114.

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

[0095] In some implementation examples, the docking station 700 can trigger a warning by physically sensing the warning from the receiver 102. For example, the docking station can include vibration and / or audio sensors that can sense vibrations or audio emitted from the receiver 102, respectively. In this way, the docking station 103 can trigger a warning when it detects that the receiver 102 is triggering a warning while the receiver is docked to the docking station.

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

[0097] In addition to or as an alternative to this, in some implementations, the docking station 700 delays triggering a warning triggered by the receiver 102 in order to allow time for the host to resolve the warning before the docking station triggers the warning. If the host resolves the warning before the expiration of the delay, the docking station 700 does not trigger the warning.

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

[0099] FIG. 8 depicts another implementation example of the gateway 104. In the example of FIG. 8, the gateway 104 is configured as a dongle such as a universal serial bus dongle, and includes a universal serial bus connector 392 for connecting to the receiver 102, access to the network 108A, a user interface such as a button 394 for performing a Bluetooth (registered trademark) pairing directly to another device such as the host device 105 or to the network 108A from the Wi-Fi or cellular communication channel. The gateway / dongle may be configured for Bluetooth (registered trademark) pairing, but the gateway / dongle may also support establishing connections to other devices using other radio access technologies such as Bluetooth (registered trademark) low energy, Wi-Fi, Atom, Zig-bee, NFC, etc. The gateway / dongle shown in FIG. 8 may also include a light emitting diode 396 for providing an indication of the status of the gateway 104 or the receiver 102 (e.g., battery level, glucose level status, whether the user is in a low or high blood sugar state, network connection status, secure server connection status, etc.). In some implementation examples, the gateway of FIG. 8 may include its own rechargeable battery to power the gateway and / or the receiver 102, but may also rely on the receiver 102 as a power source.

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

[0101] In some implementation examples, the gateway 104, the receiver 102, the sensor system 8, and the remote monitor 114 may be preconfigured such that when the sensor system 8 and the receiver 102 are communicatively coupled to the gateway 104, the gateway 104 recognizes the sensor system / receiver, and / or its user. Further, the remote monitor 114 may also be recognized by the server 110 such that remote monitoring of the receiver 102 occurs with little or no configuration by the end user / host of the receiver 102 (if any). For example, the secure server 110, the gateway 104, the receiver 102, the sensor system 8, and the remote monitor 114 may be preconfigured and pre-registered with little or no effort for configuration or registration on the host side.

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

[0103] The secure server 110 can receive the specimen sensor data, store the specimen sensor data, process the specimen sensor data to detect an event, thereby enabling the generation of a notification to the remote monitor 114 and / or the generation of an alert to the receiver 102 and / or the gateway 104, generating a page or report for display at the remote monitor 114, the receiver 102, and / or the gateway 104, and enabling the registration and / or configuration of the host 199, the sensor system 8, the receiver 102, the gateway 104, and the remote monitor 114.

[0104] In some implementation examples, one or more entities may have remote monitors 114A to 114M. For example, the secure server 110 can register the identifiers of the users of the remote monitors 114A to 114M and the schedule for each entity to perform monitoring. Moreover, one or more of the entities may be configured by the secure server 110 as a primary monitor for receiving notifications, while other entities may be configured as backup secondary monitors for receiving notifications when the primary monitor does not check or act on the notification messages sent to the remote monitors 114 according to one or more predefined rules. Further, the secure server 110 can include one or more rules that define cases where an event results in a notification to one or more of the remote monitors 114.

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

[0106] In some implementation examples, the secure server 110 can check for errors related to the transmission of received data, data formats, error codes related to devices, data verification, duplicate data points, and / or other aspects of the data. Further, if out-of-range data points or device errors are detected, the secure server 110 can identify these data points, for example, by flagging them, and then have the identified data points corrected by a program or a system administrator and store the corrected data points. Additionally, the secure server 110 can be configured to perform additional data processing steps, such as by a user, such as a clinician, a doctor, etc., for modifying time, date, and analyzing data by specific cohort, group, and relationship (e.g., age, municipality, prefecture, gender, race, type 1 diabetes, type 2 diabetes, age at diabetes diagnosis, test results, prescribed medications used, patient self-reported medical conditions, patient diagnosed medical conditions, answers to questions asked of the patient, and any other metadata representing the host / patient). When the secure server 110 performs the first data processing (e.g., checking, cleaning, and analyzing), the processed data and / or the unprocessed data may be stored in a repository coupled to the secure server 110.

[0107] Processing at the secure server 110 can also include associating metadata with the data received from the device and / or sensor. Examples of metadata include patient information, keys used for encrypting the data, patient accelerometer data, location data (e.g., the location of the patient or the location of the patient's hospital), time, date, the type of device used to generate the associated sensor data, etc. Examples of patient information can include any information related to past health, such as the patient's age, weight, gender, home address, and / or whether the patient has been diagnosed with type 1 or type 2 diabetes, hypertension, or any other medical condition.

[0108] The process can also include determining one or more descriptive measurements, detecting or predicting events (e.g., hypoglycemia, hyperglycemia, and / or any other features detected in the sensor data), applying a pattern detector to the received sensor data, and generating a report based on the received information such as the sensor data, and can include one or more of the descriptive measurements of the information including the sensor data. Descriptive measurements can include statistics (e.g., median, in and out of the interquartile range, mean, sum, n, standard deviation, and coefficient of variation). In some implementations, the secure server 110 also associates metadata with the data received from the device, sensor, source system, and / or receiver, determines one or more descriptive measurements such as statistics (e.g., median, in and out of the interquartile range, mean, sum, n, standard deviation, and coefficient of variation), generates a report including the descriptive measurements, authenticates and verifies the integrity of the data received from the device, sensor, source system, and / or receiver, processes the received data based on the metadata (e.g., to select a given patient, device, medical condition, type of diabetes, etc.), and / or correlates the data received from the device, sensor, source system, and / or receiver, so that the data can be compared and combined for processing including analysis. Further, the results of any process performed by the secure server 110 may be used to generate one or more reports such as graphs, bar graphs, static charts, charts, etc. Moreover, the reports and other outputs generated by the secure server 110 may be provided to the receiver 102, the remote monitor 114, and any other processor via one or more distribution mechanisms.

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

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

[0111] Moreover, the pattern detector can detect patterns of data / sensor data backward over a predefined period defined by the system 100 and / or the user. For example, the pattern detector can receive input data from a repository connected to the secure server 110, and the input data can include sensor data representing glucose concentration data, specimens, and other data (e.g., insulin pump data, carbohydrate intake data, histograms, and / or counts, data from a continuous glucose monitor (CGM data), time, amount of carbohydrates, other food-related information, exercise, wake / sleep time intervals, ingested medications, etc.). Moreover, the input data can include past data acquired over a time frame such as 8 hours, 1 day, 2 days, 7 days, 30 days, and / or any other period. For example, the input data can include counts representing monitored specimen detection levels (e.g., glucose concentration levels) received and stored in the system 100 over a period covering a four-week time frame.

[0112] To further explain the pattern detector, a pattern can be recognized based on one or more predefined triggers (also called conditions, rules, and filters). Further, one or more of the predefined triggers may be programmatically variable and adjustable based on user input and / or based on one or more rules in the secure server 110. And some types of patterns may be selected, enabled and disabled, and / or changed by the user, the user's physician, or the user's caregiver, although the system 100 may programmatically select, adjust, and / or otherwise change the triggers.

[0113] Some examples of the types of relationships within the input data that can be considered patterns are glucose levels above a target glucose range (which may be defined by the user, a healthcare provider, the secure server 110, or a combination thereof), glucose levels below a target glucose range, rapid changes in glucose levels from low to high (or vice versa), the times at which low, high, a range, or rapid glucose level events occur, the days on which low, high, a range, or rapid glucose level events occur, hyperglycemic patterns, hypoglycemic patterns, patterns associated with times or days of the week, weighting scores for different patterns based on frequency, sequence, and severity, the user's custom sensitivity, transitions from hypoglycemic to hyperglycemic patterns, the amount of time spent on critical events, combinations of glucose change and time information, and / or one or more of patterns of high variability in glucose data. Further, the pattern may be based on a combination of previous pattern data and the currently detected situation, thereby generating a warning for which the combined information is predicted.

[0114] The hypoglycemia pattern by time may be detected based on the events detected by the secure server 110. For example, a pattern may be identified in which the user has a low glucose concentration at approximately the same time of day. Another type of pattern that may be identified is the "hyper-rebound" situation. For example, hyper-rebound may be defined as a hyperglycemic event when the user over-corrects a hypoglycemic event by excessively increasing glucose intake. These events may be detected based on one or more predefined triggers.

[0115] To further explain an example of a pattern, the basic pattern may be configured to enable searching for a predetermined pattern of data, such as values within a range, a high coefficient of variation, etc. Each pattern can have one aspect, such as within a range, another pattern can specifically detect less than the range, and another can detect a low coefficient of variation, etc. Each pattern may be based on statistics and use standard descriptive statistics in pattern matching applications. Each pattern may be assigned scores for various rules encoded in each pattern, such as plus, minus, and the degree of importance of the consideration. Each pattern may also be assigned a possible set of data ranges to which the pattern is applicable. For example, counting the number of times a low value less than the range follows a high glucose value is a pattern that applies only to the entire range. However, detecting a high level of variation can be applied to one month, one week, one day, during the day, every two hours, every hour, and combinations thereof. For every pattern, a minimum acceptable score may be assigned before considering the display or generation of a warning sent to the receiver 102 (or host 199) or a notification message sent to the remote monitor 114. Each pattern (and any associated trigger / rule) may be processed for a set of data within a predetermined time frame. If the pattern is applied and meets the predetermined minimum requirements, the pattern is ranked according to significance. Thus, each ranked pattern can correspond to a warning sent to the receiver 102 (or host 199) and / or a notification message sent to the remote monitor 114 (or a primary monitor or secondary monitor accessing the remote monitor 114).

[0116] Referring further to FIG. 1, the host monitoring system 198A can have a single remote monitor 114A or a plurality of remote monitors 114A - 114M, and the rules associated with the timing at which a remote monitor receives a warning and the type of warning to be sent may be stored in the secure server 110. For example, the first remote monitor 114A can receive notification messages during the day, while the second remote monitor 114B can receive notification messages at night, although other schedules may also be used. In addition to, or as an alternative to, this, the first remote monitor 114A can receive notifications only when the server identifies that the host system 198 is in a predefined geographical location, such as a school (e.g., using geographical location information provided by the host system 198), while the second remote monitor 114B receives notifications regardless of the geographical information of the host. As another example, the first remote monitor 114A can have high and low thresholds that trigger warnings to the remote monitor 114A, and these thresholds can be different from one or both of the high and low thresholds that trigger warnings to the remote monitor 114B. Further, one or more rules can define the first remote monitor 114A as a primary monitor, while the second remote monitor 114B may be defined as a backup or secondary monitor.

[0117] The remote monitor 114, at 194 (Figure 3), can confirm the received notification message by enabling a remote monitoring application (e.g., opening, interacting with, accessing, selecting, etc.) that causes a message to be sent to the secure server 110 or responds to a message presented in the user interface of the remote monitor. If the secure server 110 does not receive some form of confirmation that the user has viewed or otherwise acknowledged the notification message on the remote monitor after a predetermined amount of time (which may depend on the severity or type of event), the secure server 110 can re-send the notification to the remote monitor 114. In some implementations, the secure server 110 can receive from the notification service 112 a message that the remote monitor 114A is malfunctioning or otherwise unreachable, in which case the secure server 110 can re-send the notification message to a different remote monitor 114B. The delay used by the secure server to re-send the notification message may be configurable based on the severity or type of the event, and the secure server can also include rules that define a default number of failed re-sends before escalating to another primary monitor, secondary / backup monitor, emergency medical service, etc., or a predetermined amount of time. And this default number of failed re-sends may also be configured in the secure server to vary based on the severity or type of the event or user configuration.

[0118] In some implementation examples, referring to FIG. 1, the remote monitor 114 can receive notification messages for a single host monitoring system 198A or multiple host monitoring systems 198A-198N. Moreover, after a page is generated by the secure server 110, it may then be transmitted to one or more remote monitors for presentation at the user interface of each remote monitor. However, instead, the secure server 110 may transmit data to the remote monitor 114 to enable page generation at the remote monitor 114. The page can include text and / or graphic indications of the status of one or more monitored hosts. To explain, a school nurse can have a remote monitor 114, and the page represents each of the host monitoring systems 198A that the remote monitor is monitoring. Each remote monitoring system 198A-198N may be associated with one student. In this example, the page can have each student's status information, each student's most recent notification message, a graph or text indication that the student is within limits, or an indication that the student is exceeding limits, etc. Each student may be associated with one cell (a defined space on the display). In this way, the nurse can quickly display the user interface and view the status of each monitored student. The graphic indication may be used to visually convey the overall status of each student within each student's cell. For example, a so-called "smiley" face icon can indicate that the student's glucose level is within limits, and a so-called "sad" face icon can indicate that the host's glucose level is a cause for concern because it exceeds the threshold. Moreover, in some implementation examples, this page may be presented on the display such that additional information is provided to the remote monitor by selection of a cell, notification, or face icon (e.g., touching the touch screen, mouse over, click, etc.).For example, when a student's cell is selected, the remote monitor 114 accesses the secure server 110 and then receives additional information such as one or more of the latest or previous glucose levels, patient information, etc., and updates the display page or moves to a new display page that more details the information about the selected student (e.g., displays a trend graph of the student's glucose levels over the past three hours). The foregoing example refers to glucose levels as well as certain types of messages and icons, but other types of events, messages, and icons contemplated herein may be used to convey the status of the host. Dashboard

[0119] In some implementation examples, the above-described page may be configured as a so-called "dashboard" that includes dynamic content. For example, the icons of the host patients that require the most care or attention (e.g., patients with very high or low glycemic levels) may be placed in the top row of the page so that the remote monitor can quickly check the status of the higher-risk host patients. The foregoing arrangement has been described using the top row of the page to distinguish a portion of the so-called higher-risk host patients, but other distinguishing schemes may be used (e.g., different colors, intensities, and / or locations on the page). Moreover, the patients distinguished for extra attention may change over time, and since the page comes to represent different icons for different patients in the distinguished top row of the page, the page can be considered dynamic. Examples of dashboards are examined in detail with reference to FIGS. 18A and 18B. Designation of remote monitor

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

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

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

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

[0124] In addition, if the user does not confirm the warning within a predetermined amount of time with the receiver 102, an escalation sequence may also be implemented. For example, referring to FIG. 2A, if the secure server 110 requests confirmation of a warning, it can determine (e.g., by monitoring sensor data received from the receiver 102 and knowing the threshold values on the receiver) that the receiver 102 has warned (or should have warned) the host 199. The confirmation can be in the form of the user responding to a message presented on the user interface 122 of the receiver 102, or other actions that can be measured by a device associated with the host user, etc. (e.g., a drug pump 2 indicating that insulin has been administered to the user, a specimen measurement value indicating that the cause of the warning is no longer a problem because the measured level or trend has moved in the desired direction beyond the threshold). In this example, if the secure server 110 does not receive an indication that some form of confirmation and / or the underlying event that triggered the warning has been resolved after waiting for a predetermined amount of time, the secure server 110 can re - send the warning and / or send a notification message to a primary remote monitor (e.g., 114A), a secondary remote monitor (e.g., 114B), and / or emergency medical services. And this escalation can be configured at the secure server 110 to vary based on the severity and / or type of the event triggering the warning, including retries and delays. Reminder

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

[0126] Furthermore, in some implementation examples, the secure server 110 can resend the notification to the remote monitor 114 and / or the receiver 102 repeatedly (e.g., every 5 minutes or any other time) until the receipt of the notification message is confirmed. In some implementation examples, since each resend is sent to the receiving device (e.g., the remote monitor 114 or the receiver 102), different warning types triggered by the receiving device can be configured (e.g., continuously increasing the volume, brightness, or vibration each time it repeats, dismissing the confirmation of the notification message, or triggering a vibration warning for the first reminder and a vibration warning for the second reminder, etc.). Opening the message from the secure server 110 on the receiving device can serve as a confirmation and as other actions detectable by the secure server.

[0127] In some implementation examples, the user designated as the primary monitor can notify the secure server 110 that, for example, using remote monitor 114A or workstation 22, monitoring cannot be provided by sending a message to the secure server 110 and / or receiver 102. In this case, the secure server 110 can demote the primary monitor to secondary (or backup monitor) and promote one of the secondary monitors to primary monitor. The secure server can have rules that define whether any of the secondary monitors may be promoted or whether each of the secondary monitors may be polled to evaluate its availability to serve as the primary remote monitor. Then, the secure server 110 can send a message (and also send a message corresponding to the further demoted primary monitor) to the secondary monitor promoted to the primary monitor designated as the primary monitor (e.g., via a notification service).

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

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

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

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

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

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

[0134] In some implementations, in order to register the remote monitor 114 invited to the secure server 110, the remote monitor and the receiver 102 each enter values such as a code, a shared secret, a link (e.g., a Uniform Resource Locator), a password, or a combination thereof, receive a notification message of an event associated with the receiver 102, and can have access to the sensor data and reports at the secure server 110. Further, a user such as the host 199 can access the Internet browser using the workstation 22 of FIG. 1, for example, to access the secure server 110, log in, and view and manage one or more devices granted remote monitoring permissions.

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

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

[0137] In some implementation examples, since the secure server 110 can have configuration information that defines the identification of the receiver 102 and the remote monitor 114, after a user such as the host 199 accesses the secure server 110, one or more devices such as the receiver 102 and the remote monitor 114 can then be added to the user's system. The remote monitor 114 can query the secure server 110 to obtain information regarding the host (or receiver) that the remote monitor can monitor, and the secure server can configure the remote monitor 114 accordingly. In some implementation examples, the notification messages sent to the remote monitor may be configured to suit the needs of a given remote monitor user, and these needs may be different from the needs of the host patient. Thus, the rules that govern the sending of notification messages to the remote monitor 114 may be different from the rules for triggering alerts to the receiver 102 used by the host patient.

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

[0139] The following provides another illustrative example of host patient management treatment, where in this case the host patient or caregiver may not desire a high degree of supervision of the host patient. In this regard, the caregiver desires that the remote monitor 114 allows for patient host time to operate with respect to a warning in order to correct or confirm an event before the warning is sent to the caregiver, while the host patient first receives the warning. As an example, a warning triggered by the receiver 102 can indicate a hypoglycemic or hyperglycemic event, and if the host patient does not perform one or more predefined actions to correct the event after a predetermined time (e.g., as evidenced by subsequent glucose measurements indicating the same or a worsening patient condition), the caregiver can receive a notification message at the remote monitor 114 in response to this event. That is, if the patient host using the receiver 102 does not respond or confirm a warning in a predefined manner, the caregiver can receive a notification message at the remote monitor 114. The caregiver can thus, at the remote monitor 114, receive a notification message if the host patient neglects to respond or confirm a predetermined real-time event such as a low glucose event etc. (which may be considered serious as the host patient may not be functioning properly or may not be aware of the event, and notification to the remote monitor is desired). However, the secure server 110 either delays sending a reminder in response to the notification message or stops sending the reminder when one or more predefined occurrences are identified by the secure server. The one or more predefined occurrences can correct the underlying event triggering the warning, confirm the warning, or take a predefined action such as administration of insulin.

[0140] Furthermore, the secure server 110 may be configured to include a delay for waiting for confirmation or operation before notifying the remote monitor 114, and this delay may vary based on the type and / or severity of the condition that is generating the warning, and may also vary depending on the default or user-configured settings of the remote monitor. In addition to this, the secure server 110 may also be configured to monitor the data from the receiver 102 even after a confirmation message has been received from the receiver 102 in response to a warning. For example, the secure server 110 may be able to receive a confirmation message (which may be a message transmitted by the receiver 102), but the secure server 110 may wait for a predetermined time 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 is generating the warning.

[0141] Another exemplary illustration of host patient administration treatment is provided below, where in this case the host patient is very independent, so the remote monitor may only be triggered in case of an emergency. For example, the secure server 110 may include rules for triggering the remote monitor in case of an emergency such as a severe hypoglycemic event occurring at night. In this scenario, since the host patient may not be able to respond to a warning of the event, if the glucose drops to an extremely low level for a certain period of time, or if the user does not respond to a very low glucose warning transmitted to the receiver 102 after a certain time, the secure server 110 may be able to trigger a notification message. And this period may vary based on the type and / or severity of the condition that is generating the warning.

[0142] Provided below is another illustrative example of a host patient who is highly independent but does not recognize hypoglycemia and has no reliable information source for an emergency response. In this case, the host patient can select a remote monitor 114 associated with an emergency medical service to automatically notify the service in the event of a severe hypoglycemic event if the glucose drops to extremely low levels for a certain period or if the user does not respond to very low glucose triggered by the receiver 102 after a certain period. Management of remote monitor warning settings

[0143] In some implementations, the user can manage the warnings of each of the remote monitors 114A - 114M that are monitoring the host 199. For example, the host 199 can use the host monitoring system 198A to invite the remote monitor 114A to be monitored and use the receiver 102, the gateway 104 (including the host communication device), or the workstation 22 to configure the permissions at the secure server 114. The permissions can be global in the sense that they are specific to one or more predetermined warnings or all warnings of the remote monitor 114A may be manipulated by the user. Although the above example described that the permissions are set by the user, the permissions may also be determined programmatically.

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

[0145] In addition, the above description with reference to FIG. 6 refers to managing the warnings of the remote monitor 114, but a similar page can be used by the receiver 102, the gateway 104, or the host communication device 105 to manage the warnings triggered by the host communication device in the implementation examples of FIGS. 2A - 2C. As an example, the host communication device 105 can display a page 600 for managing warnings by the host communication device independently of the receiver 102. In this way, the host communication device 105 can function as a secondary warning device for the host 199.

[0146] In some implementation examples, the user can change one or more rules that define warnings representing events associated with the host's specimen status. The user can use a computing device such as the remote monitor 114, the receiver 102, the gateway 104, the host communication device 105, or the workstation 22 to change the warning settings of the host monitoring system 198, such as the low glucose level threshold. In this way, for example, a parent can change the settings of the remote monitoring system 198 of their child.

[0147] The foregoing example referred to modifying the low glucose warning, but the modification can include varying the first threshold associated with the host's low glucose level, varying the second threshold associated with the host's high glucose level, varying the delay between when a message is triggered by the receiver 102, varying the time value between when a reminder message is sent, and can include any other warnings that may be triggered by the host monitoring system 198 or the remote monitor 114.

[0148] In addition, the secure server 110 can conform to a set of rules associated with host 199. For example, a set of rules for a remote monitor that monitors host 199 may be predetermined based on some basic host patient demographics. After the initial use of the remote monitoring system 100, the secure server 110 can programmatically adjust the thresholds used to trigger some or all events. These adjustments may be made for a variety of reasons. For example, thresholds such as glucose levels, rate of change of glucose, etc., used to determine when to trigger an event, may be adjusted to reduce the frequency of some warnings and / or notifications, as the remote monitor 114 that is receiving too many messages may decide to ignore the messages. The thresholds may also be adjusted to narrow the range of the patient's glucose variation during the day in order to reduce the variation in the host's daily glucose variability.

[0149] In some implementation examples, the data management tool and CGM analysis may be used to assist in improving the patient's diabetes management or to support the physician in strengthening recommendations. Glucose data (and / or other specimen data) may be provided to the secure server 110 in near real-time so that the data may be used by a case manager in a payer system and / or a healthcare system to enhance current diabetes management. However, it may not be practical for a diabetes case manager to review the resulting so-called "big data." Thus, filters may be used to facilitate the efficient use of the case manager's time, to enable exceptions, and to identify specific problems, based on the use or reported glycemic patterns. In this regard, one or more patterns may be defined at the secure server to identify problems that require the attention of the case manager. The patterns can include vertical analysis or comparison over time. These patterns can also identify high-risk patients, such as those with frequent or severe lows, frequent or severe highs, and / or notable glucose variability. This may be considered particularly important for use in patients on intensive insulin therapy, such as those who do not recognize hypoglycemia, have poor management, or are not insulin-naive. The patterns can also identify non-responders to treatment, suggest non-responsiveness or worsening management, such as in patients with persistent hyperglycemia, identify non-compliance, disease progression, or emerging resistance, and suggest non-responders to treatment. This may be considered particularly useful when new medications are added or therapies are optimized. The patterns can also identify responders or non-responders associated with diabetes education or by a particular provider or consultant.

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

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

[0152] Furthermore, the tracking of the sensor system by the secure server can include tracking the performance of the receiving wireless interface. For example, when a hardware error (or any detected error state) occurs, information related to the error may be transmitted to the secure server 110. The transmitted data may also be used to track feature utilization and can include warning settings, number of screen visits, etc. Additionally, this data may be used to collect and manage data during clinical trials. Further, the sensor data transmitted to the secure server 110 may also be extended for tracking patient performance in glycemic management. In this case, the performance metrics can include "time spent" in different glucose ranges, magnitude of glycemic excursions, insulin dosing information, etc. For example, during a continuous glucose monitoring (CGM) session, the data may be automatically transmitted to a connected repository accessible to the secure server 110 and / or the host patient and / or the patient's clinical care provider. Thus, the automatic tracking of the above product performance and failure mode classifications can, in some implementations, provide more accurate information regarding product performance, facilitate the resolution of sensor problems experienced by the patient, and automate product replacement (or shipment) when the sensor performance is considered ready for replacement.

[0153] In some implementation examples, the secure server 110 can provide a closed control loop. Specifically, the secure server 110 can send a message to the receiver 102, and the receiver responds to the secure server 110. Moreover, the secure server 110 can send a message to the remote monitor 114, and the remote monitor 114 responds to the secure server 110. Therefore, when the operation is completed, the secure server 110 can request the operation from the receiver 102 and / or the remote monitor 114, and can receive confirmation from the receiver 102 and / or the remote monitor 114, thereby forming a closed loop. The receiver 102 can include one or more aspects of the functions provided by the remote monitor 114, and the remote monitor 114 can include one or more aspects of the functions provided by the receiver 102. Exemplary host monitoring system setting process 1000

[0154] FIG. 10 is a flowchart showing a process 1000 for setting up a host monitoring system 198 according to some implementation examples. For illustrative purposes, the setup process 1000 is discussed with reference to the remote monitoring system architecture shown in FIG. 2C, but the setup process 1000 can be applied to the architectures of FIGS. 2A or 2B, including variations to accommodate different architectures.

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

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

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

[0158] FIG. 9 illustrates an exemplary page 900 that the host monitoring application can display to the user in the account settings block 1012 to send the input of the serial number of the receiver 102 or other unique identifier. Here, page 900 is an illustration of the location of the serial number to assist the user in detecting the input serial number. Page 900 also provides an alphanumeric input field where the user can select and manually enter the serial number. In addition, page 900 provides selectable icons 902 and 904 that allow the user to take a photo of the serial number using the camera of the host communication device 105 and scan the serial number using the barcode scanner of the host communication device 105, respectively, for the input of the serial number.

[0159] In block 1014, the user uses a host monitoring application to manage the warning settings of the host communication device 105. The host application can first present default warning settings, and the user can change the default user settings using the user interface of the host communication device 105. In some implementation examples, the warning settings include repeating one or more warnings on the receiver 102. In this way, the host communication device can amplify (e.g., trigger a different type of warning than the receiver, such as a louder warning) and / or echo (e.g., if the event triggering the warning on the receiver is not resolved, emit only the warning sound after a default amount of time from the receiver's warning) the receiver's warning. The warning settings can also include enabling or disabling warnings for various events.

[0160] In block 1016, the user pairs the host communication device 105 with the docking station 103. In some implementation examples, to pair the host communication device 105 with the docking station 103, the user turns on the power of the docking station and connects the receiver 102 to the docking station. At this point, the host communication device 105 and the docking station 103 start the pairing and authentication procedures.

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

[0162] The following pairing and authentication procedures may be used in some implementation examples. In response to the receiver 102 being docked to the docking station 103, the docking station derives an authentication token from the serial number of the receiver (which the receiver transmits to the docking station) and places it in a Generic Attribute Profile (GATT) characteristic. The docking station 103 then broadcasts and couples a generic advertisement. The host communication device 105 device searches for the advertisement. After detecting the docking station 103, the host communication device 105 connects and performs service detection. The host communication device 105 then attempts to read the aforementioned GATT characteristic. The docking station 103 responds with an insufficient authentication message (pairing and encryption are required). The host communication device 105 then prompts the user to pair with the docking station 103. Both the docking station 103 and the host communication device 105 compromise a long-term key to use for encryption and then pair. The host communication device 105 then reads the token from the aforementioned characteristic and uses this characteristic to verify the authentication of the docking station 103. The host communication device 105 had previously derived its own token from the serial number of the receiver previously entered into the host communication device at block 1012 and writes this token to the GATT characteristic of the docking station 103. The docking station 103 then uses this token to verify the authentication of the host communication device and, if authenticated, enters a persistent coupled state.

[0163] In some implementation examples, using the pairing and authentication processes described above, if the connection between these two devices (receiver 102 and docking station 103) is disconnected at any point, the docking station 103 commands an advertisement for connection.

[0164] In block 1018, the user uses an application on host device 105 to invite remote monitor 114. Here, the application can prompt the user to identify information about potential users of the remote monitor, including names and email addresses accessible from a device that can be the remote monitor 114, such as a mobile smartphone or tablet computer. In addition, the application can prompt the user for permissions the user desires to have on the remote monitor 114, such as the permission to view trend graph data, and warning settings the user desires to have on the remote monitor 114. When finished, the application sends the invitation to the remote monitor 114, including information within the invitation, such as identifying information, permissions, and warning settings stored on secure server 110. The user can use the invitation procedure described above to invite additional remote monitors. In some implementations, the application can include a page that enumerates the status of all invitations sent by the user.

[0165] Note that process 1000 can be implemented using a setup wizard implemented by a host monitoring application on host monitoring device 105 to guide the user through setup process 1000. Example of remote monitor setting process 1600

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

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

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

[0169] In some implementations, in a given implementation, note that since the secure server has the user's account information since the invitation was formed at block 1012 of process 1000 (FIG. 10), the user of remote monitor 114 does not need to register with the secure server.

[0170] In block 1630, the user manages the warning settings using the remote monitoring application downloaded to a computing device (here considered as the remote monitor 114). In some implementation examples, the warning settings can initially be set to the recommended warning settings (or default settings if the person sending the invitation did not enter any recommended settings at all) set by the person who sent the invitation in step 1012 of process 1000. The user of the remote monitor 114 can then change either the recommended or default settings. The settings can include when to trigger a warning to the remote monitor, delays, reminders, and threshold settings for warnings without data, which are discussed in detail elsewhere in this specification. The remote monitor 114 then transmits the settings of the remote monitor to a secure store for storage and can be used when triggering warnings associated with the remote monitor.

[0171] In block 1640, the remote monitor 114 monitors the host's analyte level upon permission. The monitoring can include monitoring multiple hosts using the remote monitor as described in detail with reference to FIG. 1. The monitoring can be triggered by the secure server 110 and can include receiving notifications sent via the notification service 112 and displaying sensor data accessible from the secure server. For example, in some implementation examples, the user can enable the remote monitoring application on the remote monitor 114 to display a dashboard page of the glucose levels of multiple hosts. Example of invitation to become a remote monitor

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

[0173] In some implementation examples, accepting the invitation automatically sets up a remote monitoring account on server 110. That is, at the time of invitation generation, since the host provides the recipient's account creation information (recipient name, email, phone number, etc.), the recipient does not need to log in to create an account. Further, the host can include a photo of the host during the invitation creation process, so the identity can include the photo of the host in the invitation sent to the recipient (which can help the recipient know that the invitation is valid), and the photo of the host can be used as the photo of the host on the remote monitor (refer to FIGS. 18A and 18B and as discussed elsewhere, such as on the dashboard).

[0174] In some implementation examples, the invitation can include a one-time token that the invitee can use to accept the invitation without being required to log in to the remote monitoring system. The token can be in the form of a GUID (Globally Unique Identifier). The invitation may also include a timestamp of the time when the invitation was sent and the time when the invitation expires. System status display

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

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

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

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

[0179] As shown in FIGS. 11A and 11B, the host monitoring application can also display a status tab 1124 on the status page 1100 and any other page displayed by the host monitoring application. The status tab can be part of a menu that includes a plurality of different selectable tabs associated with different display pages of the host monitoring application that, when selected, display the associated display page. The tabs in FIGS. 11A and 11B additionally include a follower tab 1126, an account tab 1128, and a details tab 1130. That is, the status tab can always display an indication of the connection status of the system, and when the system is operating, it is displayed including a green check mark as shown in FIG. 11A, and when the system is not operating, it is displayed including a red X as shown in FIG. 11B. Since the status bar can be displayed regardless of the currently displayed page, it thereby provides the user with an indication of the status of the system regardless of the page being displayed.

[0180] In some implementations, the host monitoring system 198 may be configured to periodically send messages to the server 110. When the server detects the absence of a message from the host communication system 198 for a predetermined time, the server can trigger a notification to be sent to the host monitoring system (such as the receiver 102, the gateway 104, or the host communication device 105, etc.), notify the host of the absence of a message, and enable the host to confirm whether the host monitoring system is operating using, for example, the exemplary status page 1100. Host monitoring control page

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

[0182] FIG. 14 illustrates a summary page 1400 according to some implementation examples. The summary page can include a plurality of cells 1402a-1402e, and each cell can be associated with a remote monitor or a potential remote monitor. Each cell can include names 1410a-1410e associated with the remote monitor for identification purposes. The cells 1402a-1402e can also be displayed according to the status of the remote monitor. For example, cell 1402a is grouped under the deletion status 1404a by a remote monitor (referred to as a follower in FIG. 14), cell 1402b is grouped under the invitation expiration status 1404b, cell 1402c is grouped under the valid status 1404c, cell 1402d is grouped under the invited status 1404d, and cell 1402e is grouped under the do not share status 1404e. Note that multiple cells can be displayed under each group, and FIG. 14 only illustrates one cell per grouping to facilitate the explanation of different groupings.

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

[0184] The icon can also be displayed in a cell indicating the permissions and / or valid functions associated with the remote monitor. For example, icons 1412 and 1414 indicate that the notifications of the remote monitor associated with cell 1402c are valid and that it has the permission to display trend graph information associated with the monitored host, respectively. In contrast, if the remote monitor does not have the permission for a specific function such as the display of the host's trend graph, the corresponding icon can either not be displayed in the cell or, instead, provide a different icon indicating the lack of permission.

[0185] Each cell can also provide selectable tabs. For example, FIG. 14 illustrates delete tabs 1408a and 1408b that, when selected by the user, delete the cell from that page. Arrow tabs 1416c - 1416e can also be used to provide detailed information regarding the remote monitor associated with that cell. For example, when a selectable arrow 1416 is selected, the host monitoring application moves to the display page settings that provide details regarding the associated remote monitor and the settings of the remote monitor.

[0186] An exemplary settings display page 1500 according to some implementation examples is illustrated in FIG. 15. The settings display page 1500 can include identification information such as a name 1502 and an email address 1504 associated with the remote monitor, the permissions of the remote monitor, and the notification settings of the remote monitor. In the example of FIG. 15, the permissions can include a trend graph permission 1504 tab that a user can use to switch between allowing and denying the permission to display a graph. If allowed, the remote monitoring system 100 enables the remote monitor to display the trend graph information of host 199, and if denied, the remote monitor cannot display the trend graph information of the host. The notification settings enable a user of the host monitoring application to view the current notification settings of the associated remote monitor. The notification settings can include an emergency low notification warning 1506, a low notification warning 1508, a high notification warning 1509, and a no data notification warning 1510, and each warning is associated with a status (e.g., associated with a threshold and whether the warning is inactive or active). In some implementation examples, a user using the host monitoring application can change the settings of the remote monitor using, for example, page 1500, but in other implementation examples, some or all of the settings can only be changed by the remote monitor, as shown in FIG. 15.

[0187] The display page 1500 also enables the user of the host monitoring application to pause and resume the function of the remote monitor 114A that is monitoring host 199. The pause / resume control button 1514 can selectively pause and restart the remote monitoring function of the remote monitor, such as sending a notification to the remote monitor and / or stopping and starting the permission of the remote monitor to display the host's sensor data. Such a function can be useful when the host does not necessarily want the remote monitor to monitor the host. As a specific example, it can include a babysitter as the remote monitor. For the babysitter, when taking care of the child being monitored by the host monitoring system, it has a remote monitoring function, but when the babysitter is no longer taking care of the child, it may be desirable to stop the remote monitoring. In this way, in order to selectively control the monitoring by the babysitter, it is not necessary to send a new invitation to the babysitter every time the babysitter takes care of the child.

[0188] The remote monitor deletion control button 1516 can be used to delete a remote monitor from the list of remote monitors that can monitor the host. In contrast to the pause / resume control 1514, in some implementation examples, when deleting a remote monitor using the deletion control 1516, the host needs to re-invite the person who will become the remote monitor. As described elsewhere in this specification, since the remote monitoring system 100 may have a default limit on the number of remote monitors that can monitor a host, in some implementation examples, the host may need to delete a remote monitor in order to add another remote monitor.

[0189] In some implementation examples, the remote monitoring system 100 sends a notification message to a remote monitor whose permissions or settings have been changed, or has been paused, resumed, or deactivated, by the associated host system. In this way, the remote monitor is notified of the change and does not depend on the previous configuration.

[0190] In addition, each of the pause, resume, and restart functions may be configured globally across all remote monitors associated with the host, instead of or in addition to the individual monitors as described above. In the case of global functions, for example, global control buttons can be provided on page 1400 (not shown in FIG. 14) to implement the respective functions globally across all remote monitors monitoring the host when, for example, a global control button is pressed. Remote monitoring dashboard display

[0191] As described elsewhere in this specification, the remote monitor 114 can provide a so-called dashboard display of the monitored host implemented on top of the remote monitoring device. FIGS. 18A and 18B are dashboard pages 1800 of two different implementation examples according to some implementation examples. The dashboard 1800 can include a plurality of cells 1802a to 1802d, each associated with a different host. Each cell 1802 can include an identifier of the host, such as the default name of the host, and a photo of the hosts 1804a to 1804d provided in the invitation.

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

[0193] In the implementation example of FIG. 18B, cells 1802 can be grouped on page 1800 according to the status of the cells, such as deletion 1814 by the host (referred to as the Sharer in FIG. 18B), active 1818 (i.e., the system is connected and providing the data of the associated host to the remote monitor), disconnected 1824 (i.e., for example, the system is not connected because the receiver 102 is not in the docking station in the implementation example of FIG. 2B), and unshared 1826 (i.e., the host has paused the remote monitor). Further, the cells within a group can be ordered according to the severity of the monitored state or other conditions as discussed elsewhere in this specification.

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

[0195] Referring again to FIG. 18B, cells 1802 within the active group 1818 can also include information regarding the monitored health state. For example, cell 1802 can display the latest specimen concentration value 1806a provided to the remote monitor and a trend arrow 1808a indicating the measured rate of change of the specimen. Further information such as the time 1812a associated with the measurement of the displayed specimen concentration, or that the data has not been received from the host monitoring system, can also be provided to the cell.

[0196] When the user selects cell 1802, the remote monitor display can also be moved to another display page that provides additional information about the host associated with that cell. For example, the remote monitor can move to a trend graph display (FIG. 19) associated with that host, or a settings page (FIG. 17) associated with that host. The arrow ">" can indicate whether there is detailed information in the cell. Trend graph display

[0197] FIG. 19 is an exemplary page that provides a trend graph 914 of the monitored analyte concentration of a host according to some implementation examples. The trend graph can display a trend line 1916 of the measured analyte concentration, as well as a low threshold 1918 and a high threshold 1920 that are used to alert either the remote monitor 114 or the host monitoring system 198. The trend graph page can also include a user-selectable slider bar that enables the user to select different time frames of sensor data to display, such as displays of 3, 6, 12, and 24 hours. If the remote monitor is monitoring a plurality of different hosts, the remote monitor can also provide a photo 1904 of the host and a name 1902 of the host so as not to misidentify the individual being monitored.

[0198] In some implementation examples, as described elsewhere herein, the page of FIG. 19 can be automatically displayed when the remote monitoring application is first opened in response to the user directly opening the application and / or when the user opens a remote monitoring notification on the remote monitor 114 that is sent by the server 110 or the notification service 112. To explain, when the notification is received by the remote monitor 114, the remote monitor can display the notification on the lock or home screen. The user can select the notification (e.g., using a predefined gesture), and the recognition by the remote monitoring device 114 causes the remote monitoring device to display the trend graph of the host associated with the notification. Remote monitor setting page

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

[0200] In some implementation examples, when glucose data reaches the server 110, the receiver 102 needs to be associated with the host 199 so that the data can be associated with the host. Thus, the remote monitoring system 100 can assign the receiver to the host. This can be done initially through the pairing process described above with respect to block 1016 of FIG. 10. When a host receives a new receiver, for a preferred user experience and to prevent errors, the host monitoring application can check that a different serial number is being used to confirm whether this is a new receiver or whether this receiver is already owned by another host by checking with the server 110 and, via the communication device 105, asking whether this is that receiver, giving an error that allows ownership or indicates that it is already owned.

[0201] Thus, an exemplary detection process for a new receiver can be as follows. First, the host communication device 105 verifies with the server whether the receiver is owned by someone else (e.g., by comparing the serial number of the receiver with a database) to confirm whether a new receiver is being used. If the server determines that no one owns the receiver, the host monitoring application asks the user if they wish to claim the receiver as their own. If so, the receiver and the data from the receiver are associated with that host. Data loss warning

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

[0203] In some implementation examples, when determining whether to send a notification message and / or when determining the destination of the notification message, the secure server 110 may use the locations of the receiver 102, the gateway 104, the host 199, and / or the remote monitor 114. For example, when the monitored host is present at a first location and moves to a second location, the secure server 110 can select a first remote monitor 114A near the first location based on the record, and when the host moves to the second location, it can select a second remote monitor 114B located near the second location. Location may also be used to vary warnings and notifications. For example, the secure server 110 can vary the rules used to trigger a warning or notification based on the location of the host. Location may be used in combination with time, and the secure server 110 can vary the thresholds associated with warnings and notifications based on location and / or time. Confirmation notice

[0204] In some implementation examples, the receiver 102 or the gateway 104 can present a prompt (e.g., a message, a window, etc.) to the user interface that requests the user to confirm a warning triggered by the host and / or indicate a corrective action taken in response to the warning. The prompt can include a pre - entered list of options (e.g., insulin administered, carbohydrates ingested, etc.) that the user can select to indicate the corrective action taken. The notification message can be sent directly to one or more remote monitors 114 so that the remote monitor recognizes that the patient has confirmed the warning and / or a corrective action has been taken (and / or an explanation of the corrective action), or it can be sent to the remote monitor through the secure server 110 and / or the notification service 112.

[0205] In addition, the remote monitor 114 can enable a user to select from a plurality of pre - entered messages for transmission to the host monitoring system. The user can select a notification, at which time the remote monitor displays a list of pre - entered text messages that the user can select to transmit to the host monitoring system. The messages can be selected by the remote monitor to be related to the underlying cause that triggered the notification message. For example, if the notification message is triggered by a low glucose level of the host, the message can be something like "Are you not feeling well?", "You might want to drink some orange juice", etc., which are sentences related to the low glucose level. Each message can be made user - selectable, and when selected, the remote monitor causes a message for display on the host monitoring system to be sent to the host monitoring system 198 either directly from the remote monitor 114 or indirectly, for example, through the server 110. In addition, when a notification is selected, a prompt to call the host can be automatically displayed, and when the user selects the prompt, the remote monitor 114 makes a call to the phone number associated with the host (e.g., a smartphone that is part of the host monitoring system 198). Support message

[0206] In some implementations, the warning and / or notification messages sent to the receiver 102 can include a cheering concept. For example, if the host patient has minimized the rate of change of the glycemic level, the secure server may send a warning to the receiver 102 such as "The treatment is going well. Keep it up!" and / or a notification message to the remote monitor 114. These cheering concepts can actively encourage the user to continue with the treatment program. In some implementations, the secure server 110 can include one or more events mapped to the cheering concept, so that when an event is triggered, it causes a message including the cheering concept to be sent to the receiver 102 and / or the remote monitor 114.

[0207] In some implementation examples, the secure server 110 can use patterns to predict the treatment modalities of the patient host as described above. For example, a certain pattern can detect glycemic changes at a predetermined time of day from a previously established pattern, and then trigger rules for sending a warning to the receiver 102 asking "Did you skip lunch?" and a notification to the receiver 114. These simple, non-technical inquiry messages can obtain better responses from the host patient to maintain treatment compared to simply providing measurement data or statistics to the host patient or remote monitor. In some implementation examples, the secure server 110 can include one or more events mapped to simple messages, so when an event is triggered, it causes a message containing the simple message to be sent to the receiver 102 and / or the remote monitor 114. Audit trail

[0208] The secure server 110 can also provide an audit trail. For example, the secure server 110 can store relevant information when a notification is pushed to the remote monitor 114 using, for example, the notification service 112, and when the remote monitor confirms the notification. The secure server 110 can also generate one or more reports to determine a timeline and / or identify the effects of the remote monitor 114 (which can be used to more effectively monitor the host 199 and / or select settings of the system 100 such as the remote monitor and / or warning settings). Timestamp

[0209] In some implementation examples, the specimen levels provided to the remote monitor 114 may not be in real time. For example, although it may be desired to provide specimen values to the remote monitor in real time, there may be a time delay between when the specimen value is measured by the specimen sensor system 8 and when the specimen level is provided to the remote monitor 114 and / or the secure server 110. The delay may be due to, for example, the sensor system 8 that only periodically transmits values to the receiver 102, the receiver 102 that only periodically transfers values to the gateway 104, a gateway with difficult connection to the secure server 110, and a secure server with difficult connection to the remote monitor 114. For this reason, in some implementation examples, the glucose value transmitted to the remote monitor 114 is displayed on the remote monitor including the time indicating the corresponding time when the specimen value that triggered the notification (e.g., the specimen value that reached or exceeded the threshold that triggered the notification) occurred. The time may be the time when the specimen value was measured (e.g., 2:10 PM Pacific Standard Time), or may be the time difference since the specimen value was measured (e.g., 2 minutes ago, 30 minutes ago, 4 hours ago, etc.).

[0210] In addition, due to the time delay, the secure server 110 may send a notification to the remote monitor 114 based on the specimen value with a delay. In such a case, the notification can include the time associated with the warning that triggered the notification, such as "Mike's blood glucose level dropped below 70 mg / dl at 2:10 PM Pacific Standard Time" or "Mike's blood glucose level dropped below 70 mg / dl 25 minutes ago". Further, since the notification may not be immediately displayed on the remote monitoring device, the remote monitoring device 114 can automatically update any time associated with the notification until the notification is confirmed.

[0211] To accommodate differences in time zones between the host and the remote monitor, in accordance with some implementation examples, a remote monitoring system can use Coordinated Universal Time (UTC) to convert UTC to the time zone of the remote monitor. That is, the timestamp of the sensor data value generated by the host monitoring system 198 and provided to the secure server 110 can be in Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT), and is provided to the remote monitor 114 in the same standard time, whereby the remote monitor converts the common time to the time zone where the remote monitor is located as indicated by the remote monitoring device.

[0212] In some implementation examples, due to the time difference and potential time zone differences between the host monitoring system 198 and the remote monitor 114 that can cause errors and make it difficult to display the time, the notifications sent to the remote monitor 114 do not display the time. To remedy the lack of time indication, some implementation examples automatically open the remote monitoring application on the remote monitor 114, and when the user confirms the notification, display the user's monitored health status information. The host's monitored health status information that is first displayed when the application is opened can include an indication of the host's latest status, such as the latest specimen value and / or a trend graph showing the measured specimen levels of the host for the past three hours, such as the trend graph page illustrated in FIG. 19. Loss of data transmission

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

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

[0215] Furthermore, even when data transmission losses occur over an extended period of time, it may be desirable not to send a data loss notification every time a data transmission loss occurs. For example, in the implementation example of FIG. 2C, the docking station 103 may be fixed. Therefore, the host may be able to transmit health measurement values only when the host places the receiver 102 on the docking station and the host is sufficiently close to the receiver and the docking station for data transmission. However, the host may need to remove its receiver from the docking station 103, for example, when going to work. Since this may not be considered a sufficiently important event, it may not be desirable to trigger a notification to the remote monitor 114 when the host removes the receiver from the docking station 103.

[0216] Accordingly, in some implementation examples, the remote monitoring system 100 can determine that, for some reason, the host monitoring system 198 is not functioning properly and that the receiver has been removed from the docking station 103, rather than the host monitoring system not providing sensor data to the secure server. In one implementation example, the remote monitoring system 100 monitors transmissions from the docking station to determine that the receiver is not placed on the docking station 103. For example, a transmission from the docking station 103 that includes information generated by the receiver 102 indicates that the receiver is placed, and a transmission from the docking station 103 that does not include information generated by the receiver indicates that the receiver has been removed from the docking station. Eyewear display device

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

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

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

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

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

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

[0223] Some variations have been described above, but other changes are possible. For example, the description of certain implementations of the subject matter contemplates sample applications, but the subject matter is applicable to other kinds of software and data service access. Further, although the above refers to specific products, other products may be used. Additionally, the logical flows represented in the accompanying figures and described herein do not require the particular order, or sequence, shown to achieve the desired result. Further, as used herein, the term “set” includes zero or more items, and the term “based on” can be used in the same sense as the phrase “at least based on” (unless otherwise specifically stated). Other implementations are within the scope of the following claims.

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

[0225] All references cited in this specification are hereby incorporated by reference in their entirety into this specification. To the extent that any incorporated literature and patents or patent specifications conflict with the disclosure contained herein, this specification is intended to take precedence over and / or to claim priority from any such conflicting literature.

[0226] Unless otherwise specifically defined, all terms (including technical and scientific terms) are to be given their ordinary and customary meaning to those of ordinary skill in the art and are not to be limited to special or customized meanings unless expressly so defined herein. The use of a particular term when describing a given feature or aspect of the present disclosure should not be construed as implying that the term is redefined to be limited to any particular feature of the feature or aspect of the present disclosure as contained in the specification in which the term is associated. It should be noted that the terms and phrases used herein, and variations thereof, are to be construed as non-limiting and unrestricted, unless otherwise expressly stated in the appended claims. As an example of the foregoing, the term "comprising" must be construed to mean "including, without limitation," "including but not limited to," etc., and when used herein, the term "comprising" is synonymous with "including," "containing," or "characterized by," without limitation or exclusion of additional recited elements or method steps, the term "having" must be construed to mean "having at least," the term "including" must be construed to mean "including but not limited to," the term "example" is used to provide illustrative instances of the items described, not an exclusive or limiting list thereof, and adjectives such as "well-known," "ordinary," "standard," and terms of similar meaning are not to be construed as limiting the items described for a given period of time or available at a given time, but rather as referring to well-known, ordinary, or standard techniques that may be available or well-known at any present or future time, and the use of terms such as "preferably," "preferred," "desired," or "desirable" and words of similar meaning should not be understood as implying that a given feature is essential, indispensable, or even more important to the structure or function of the invention, but rather as merely intended to highlight alternative or additional features that may or may not be utilized in a particular embodiment of the invention.Similarly, a group of items connected by the conjunction "and" should not be construed as requiring each and every one of those items to be present in the group; rather, unless otherwise explicitly stated, it should be construed as "and / or." Similarly, a group of items connected by the conjunction "or" should not be construed as requiring mutual exclusivity among the items in the group; rather, unless otherwise explicitly stated, it should be construed as "and / or."

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

[0228] Regarding the use of substantially any plural and / or singular terms herein, one of ordinary skill in the art can convert plural to singular and / or singular to plural as appropriate for the context and / or application. Various singular / plural substitutions may be explicitly recited herein for clarity. The indefinite article "a" or "an" does not exclude a plurality. A single processor or other device can perform the functions of several items recited in the claims. The fact that a given measurement is recited in mutually different dependent claims does not indicate that combinations of these measurements cannot be used to obtain an advantage. No reference sign in any claim should be construed as limiting the scope.

[0229] Furthermore, if the description of a particular numbered introduced claim is intended, such intent is explicitly described within the claim, and if such description is lacking, one of ordinary skill in the art will understand that no such intent exists. For example, for the sake of assistance in understanding, the following appended claims may include the use of introductory phrases such as "at least one" and "one or more" to introduce the description of the claim. However, the use of such phrases should not be construed to imply that the introduction of a claim description by an indefinite article such as "one" ("a" or "an"), even if the same claim includes an introductory phrase such as "one or more" or "at least one" and an indefinite article such as "one" ("a" or "an"), limits any claim that includes the claim description so introduced to embodiments that include only one such description. The same applies to the use of a definite article used to introduce the description of a claim. In addition, even if the description of a particular numbered introduced claim is explicitly stated, one of ordinary skill in the art should typically interpret such statement to mean at least the stated number (i.e., without other modifiers, a statement of "only two descriptions" typically means at least two descriptions, or two or more descriptions). Furthermore, when similar rules are used for "at least one of A, B, and C, etc.", generally, such a construction is intended in the sense that one of ordinary skill in the art will understand the rules (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, a system having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together). When similar rules are used for "at least one of A, B, or C, etc.", generally, such a construction is intended in the sense that one of ordinary skill in the art will understand the rules (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, a system having A alone, B alone, C alone, A and B together, A and C together, B and C together, and / or A, B, and C together).Furthermore, it should be understood by those skilled in the art that almost any disjunctive and / or phrase presenting two or more alternative terms may cover one of the terms, any of the terms, or both terms, regardless of whether in the description, claims, or drawings. For example, the phrase "A or B" is understood to cover the possibilities of "A" or "B" or "A and B".

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

[0231] Furthermore, for purposes of clarity and understanding, some details have been explained by way of illustration and example above, but it will be apparent to those skilled in the art that certain changes and modifications may be practiced. Accordingly, the description and examples should not be construed as limiting the scope of the invention to the particular embodiments and examples described herein, but rather, the true scope and spirit of the invention, along with all modifications and alternatives thereto, should be construed to be covered.

Description of Reference Numerals

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

Claims

【Claim 1】 Receiving, from a remote monitor, a notification message representing an event detected by a server from specimen sensor data obtained from a receiver that monitors the specimen state of a host; presenting, by the remote monitor, the notification message for enabling the remote monitor, wherein the server is configured to cause the remote monitor to receive the notification message for enhancing the monitoring ability of the receiver that monitors the specimen state of the host, and the enabling of the remote monitor includes opening a monitoring application; accessing, by the remote monitor, the server in response to the presentation of the notification message; receiving, in response to the access, information including at least the specimen sensor data. A method comprising the above steps.

Images