Systems and methods for patient monitoring using HCP-specific device

Abstract

To provide methods for involving Health Care Professionals (HCPs) in an initial patient system setup such that data received is truly transformative to allow a patient to understand not only what all of various numbers mean but also how the data can be used.SOLUTION: In one implementation, a CGM device is configured for use by an HCP, and includes a housing and a circuit that is configured to receive a signal from a transmitter coupled to an indwelling glucose sensor. A calibration module converts the received signal into clinical units. A user interface is provided that is configured to display a measured glucose concentration in the clinical units. The user interface is further configured to receive input data about a patient level, where the input data about the patient level causes the device to operate in a mode appropriate to the patient level.SELECTED DRAWING: Figure 1A

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) Any and all priority claims identified in the Application Data Sheet, or any correction thereto, are incorporated herein by reference pursuant to 37 CFR 1.57. This application is a continuation of U.S. Patent No. 62 / 439,342, filed December 27, 2016. The foregoing application is incorporated herein by reference in its entirety and expressly made a part hereof.

[0002] The present disclosure relates generally to continuous monitoring of analyte values received from an analyte sensor system. More particularly, the present disclosure relates to systems, methods, apparatus, and devices for enabling healthcare provider participation in patient setup and subsequent use of the analyte sensor system. [Background technology]

[0003] Diabetes mellitus is a disorder in which the pancreas cannot produce enough insulin (T-1 or insulin-dependent) and / or insulin is ineffective (type 2 or non-insulin-dependent). In the diabetic state, patients suffer from hyperglycemia, which leads to a number of physiological abnormalities associated with microvascular deterioration (renal failure, skin ulcers, or bleeding into the vitreous of the eye). A hypoglycemic reaction (hypoglycemia) can be triggered by inadvertent overdose of insulin, or by extreme exercise or inadequate food intake after regular administration of insulin or glucose-lowering drugs.

[0004] Traditionally, diabetics carry self-monitoring blood glucose (SMBG) monitors, which typically require an uncomfortable finger-prick method. Due to a lack of comfort and convenience, diabetics typically only measure their blood glucose levels two to four times per day. Unfortunately, these time intervals are spread so far apart that it may be too late to alert the diabetics to a hyperglycemic or hypoglycemic state, sometimes resulting in dangerous side effects. In fact, not only may diabetics miss timely SMBG readings, but diabetics may also not know whether their blood glucose levels are rising (higher) or falling (lower) due to the limitations of traditional methods.

[0005] As a result, a variety of noninvasive, transcutaneous (e.g., transdermal), and / or implantable electrochemical sensors have been developed for continuously detecting and / or quantifying blood glucose levels. Continuous glucose monitors have become increasingly popular as a simple method for monitoring blood glucose levels. Traditionally, patients sample their blood glucose levels several times throughout the day, such as in the morning, around lunchtime, and in the evening. Blood glucose levels can be measured by having the patient take a small blood sample and measuring the blood glucose level with a test strip or blood glucose meter. However, this technology has drawbacks because patients prefer not to have to take blood samples and users do not know what their blood glucose levels are like between samples throughout the day.

[0006] One potentially dangerous time frame is overnight, as a patient's blood glucose levels can drop dangerously while they sleep. As a result, continuous glucose monitors have gained popularity by providing sensors that continuously measure a patient's blood glucose levels and wirelessly transmit the measured blood glucose levels to a display. This allows the patient or their caregiver to monitor the patient's blood glucose levels throughout the day and even set alerts for when blood glucose levels reach predetermined levels or experience defined changes.

[0007] There are approximately 30 million people with diabetes in the United States. 86 million have prediabetes. However, 9 in 10 people are unaware that they have prediabetes. Currently, 1 in 3 people will develop type 2 (T-2) diabetes in their lifetime. T-2 can be prevented, but once it develops, patients must manage the disease. According to the Centers for Disease Control (CDC), one way to manage all forms of diabetes is to work very closely with a healthcare professional (HCP).

[0008] Patients and HCPs agree that diabetes is a challenging disease that is managed with varying degrees of success. It is often difficult to manage on a day-to-day basis, and remaining vigilant in the face of the disease can be physically and mentally exhausting. Success often depends on the patient's motivation to incorporate lifestyle changes into their daily routine.

[0009] This Background is provided to introduce a brief description of the Summary and Detailed Description that follow. This Background is not intended to aid in determining the scope of the claimed subject matter, nor is it intended to limit the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above. Summary of the Invention [Problem to be solved by the invention]

[0010] Systems and methods according to the present principles, depending on their implementation, address many of the above problems. More particularly, the systems and methods provide a way for HCPs to be involved in the initial patient system setup so that the data received is truly transformative. Patients not only understand what the various numbers mean, but also how they can use the data. Better educated patients significantly improve health outcomes and significantly lower healthcare costs.

[0011] In this regard, it should first be noted that continuous glucose monitors wirelessly transmit data related to blood glucose levels to a dedicated display device. A dedicated display device is a medical device designed to display blood glucose levels, trend patterns, and other information about the user. However, with the increasing popularity of smartphones and software applications (apps) that run on smartphones, some users prefer not to have to carry a dedicated display device. Instead, some users prefer to monitor their blood glucose levels using dedicated software applications that run on mobile computing devices such as smartphones, tablets, or wearable devices like smart watches or smart glasses.

[0012] T-2 patients could benefit greatly from CGM technology, but this market is difficult to address due to the highly heterogeneous nature of both patients and caregivers. For example, a newly diagnosed individual is very different from someone who has attempted many conventional treatment efforts, such as drug therapy. New users differ significantly from older users. Newly diagnosed patients may be highly motivated to control their disease, whereas those who have attempted and failed control can become frustrated. In some cases, patients are poorly managed for several years before drug therapy is initiated, and such patients often suffer from numerous comorbidities and complications. Patients also have a wide range of levels of compliance with treatment.

[0013] Patient and clinician attitudes can vary widely, and their goals can differ. There is often a significant gap between physicians and patients with uncontrolled T2 diabetes in how they define control and their perceptions of diabetes control, including impaired control in the impact of uncontrolled T2 diabetes. Compared with patients with uncontrolled T2 diabetes, physicians generally have a more focused, clinical perspective on diabetes management, focusing on factors such as HbA1c levels, the frequency and severity of hypoglycemia, and medical complications of diabetes. Patients with uncontrolled T2 diabetes often have a broader perspective, considering everyday factors such as energy levels and how much they need to think about their diabetes in addition to clinical measures. [Means for solving the problem]

[0014] A first aspect is directed to a continuous glucose monitoring device configured for use by a healthcare professional (HCP), the continuous glucose monitoring device including: a housing; circuitry configured to receive a signal from a transmitter coupled to an indwelling glucose sensor; a calibration module configured to convert the received signal into clinical units; and a user interface configured to display the measured glucose concentration in clinical units, the user interface further configured to receive input data related to a patient level, the input data related to the patient level causing the device to operate in a mode appropriate for the patient level.

[0015] Implementations of aspects and embodiments may include one or more of the following: The patient level may correspond to the user's technical skill level or the user's type of diabetes. The user interface may be further configured to prompt the HCP to input data regarding whether the user is a TI diabetic, a T-II diabetic, or a pre-diabetic. The device may further include a memory for storing the glucose concentration value in clinical units and may be further configured to store the input data. The device may further include an output circuit configured to transmit the stored glucose concentration value. The transmission may be configured to occur over a period of less than five seconds. The transmission may be configured to occur using near-field communication or Bluetooth® low energy. The transmitter may be configured to store the measured glucose concentration value. The device may further include an output circuit configured to transmit the stored glucose concentration value. The transmission may be configured to occur using near-field communication or Bluetooth® low energy.

[0016] A second aspect is directed to a method of configuring a continuous glucose monitoring device, the method including: displaying a user interface on an HCP device; displaying a prompt on the user interface for the HCP to input data related to the patient; and operating the continuous glucose monitoring device, including an indwelling sensor and a signal coupling transmitter in signal communication with the HCP device, in a mode based on the input data.

[0017] Implementations of aspects and embodiments may include one or more of the following: The data may be about whether the patient has TI diabetes, T-II diabetes, or prediabetes, or may be about the user's technical skill level. The method may further include storing the glucose concentration value in clinical units and the input data. The method may further include transmitting the stored glucose concentration value from the transmitter to the HCP device upon receiving or triggered by an interrogation signal. The interrogation signal may be received by the transmitter from a near-field communication device or a Bluetooth low energy device coupled to the HCP device. The continuous glucose monitoring device may be configured to download an application configured to control the continuous glucose monitoring.

[0018] The mode can be a blind mode such that an application running on the continuous glucose monitoring device is configured to receive and store but not display glucose concentration data. The application can be further configured to receive input data corresponding to event data, where the event data corresponds to medication data, meal data, or exercise data. The mode can be a non-blind mode such that the continuous glucose monitoring device is configured to receive, store, and display glucose concentration data. The mode can be configured to begin in a blind mode and switch to a non-blind mode a predetermined time after the sensor session begins. The mode can be configured to begin in a blind mode and switch to a non-blind mode upon the occurrence of a trigger event. The trigger event can correspond to a patient parameter meeting a predetermined threshold criterion. The mode can be configured to begin in a blind mode and switch to a non-blind mode upon receiving a trigger signal from an external device. The patient data can include a transmitter serial number, the transmitter serial number having a plurality of extensions selectable by the HCP, the extensions selected as appropriate for the patient, the serial number extension specifying the mode in which the continuous glucose monitoring device should operate. The mode can be a real-time blind mode such that an application running on the continuous glucose monitoring device is configured to receive and store but not display real-time glucose concentration data and to display non-real-time historical glucose concentration data. The method can further include operating a diagnostic application on the HCP device, the diagnostic application allowing the HCP to view and set CGM parameters without altering the course of treatment. The parameters can include sensor time remaining, sensor status, and current time of the session. The mode can be a blind mode and the transmitter can be configured to store data measured by the indwelling sensor.

[0019] A third aspect is directed to a method of configuring a continuous glucose monitoring device for use by a patient, the configuration being performed by an HCP, the method including establishing a communication session associated with an HCP account between an HCP client device and a server; prompting the HCP to enter patient data on a user interface associated with the HCP client device; and prompting the HCP to enter identification data corresponding to a transmitter and / or sensor associated with the continuous glucose monitoring device on a user interface associated with the client device; receiving the entered patient data and sensor identification data; and transmitting the entered patient data and identification data to the server for storage and association with the patient account.

[0020] Implementations of aspects and embodiments may include one or more of the following: The identification data may be identification data related to the transmitter. The method may further include receiving an output from the server in response to transmitting the entered patient data and identification data to the server, the received output including a code configured to be used by the patient smart device to download an application for use in continuous glucose monitoring. The code may be received by email or text, and the method may further include transmitting the configuration information to the continuous glucose monitoring device. The transmission may be by near field communication or Bluetooth low energy.

[0021] A fourth aspect is directed to a method of configuring a continuous glucose monitoring device for use by a patient, the configuration being performed by an HCP, the method including establishing a first communication session associated with an HCP account between an HCP client device and a server; prompting the HCP to enter patient data on a user interface associated with the HCP client device; establishing a second communication session between the HCP client device and a transmitter associated with the glucose monitoring device, whereby the transmitter and / or sensor associated with the continuous glucose monitoring device can be identified to the HCP client device; receiving the entered patient data and identification data; and transmitting the entered patient data and identification data to the server for storage and association with the patient account.

[0022] Implementations of aspects and embodiments may include one or more of the following: The second communication session may transmit transmitter identification data to the HCP client device.

[0023] The method may further include receiving an output from the server in response to transmitting the entered patient data and sensor identification data to the server, the received output including a code configured to be used by the patient smart device to download an application for use with continuous glucose monitoring. The code may be received by email or text, and the method may further include transmitting configuration information to the continuous glucose monitoring device. The transmission may be via near field communication or Bluetooth® low energy.

[0024] A fifth aspect is directed to a reader configured for use by a HCP, the reader including a housing, a first circuit configured to receive a first signal from a transmitter associated with an indwelling glucose sensor, and a second circuit configured to transmit a second signal to a computing environment.

[0025] Implementations of aspects and embodiments may include one or more of the following: The device, which may be configured to receive the first signal, is configured to receive the first signal using a wired or wireless communication protocol; The device, which may be configured to receive the first signal, is activated by an interrogation signal from the transmitter; The device, which may be configured to receive the first signal, activates the transmitter using the interrogation signal; After activation, the circuitry can extract stored glucose concentration data from the transmitter; The communication protocol may be wireless and may be selected from the group consisting of Bluetooth® low energy communication or near field communication; The device may further include a third circuit configured to measure one or more operating parameters of the transmitter and provide an output based on the measured one or more operating parameters, thereby enabling a state of operation of the transmitter to be determined.

[0026] A sixth aspect is directed to a reader configured for use by an HCP to determine proper functioning of a transmitter associated with a continuous glucose monitor, the reader including circuitry configured to measure one or more operating parameters of the transmitter and provide an output based on the measured one or more operating parameters, thereby determining an operational status of the transmitter.

[0027] A seventh aspect is directed to a method of determining proper activation of a transmitter, the transmitter associated with a continuous glucose monitor, comprising detecting insertion of a sensor at the transmitter and, upon detection, transitioning the transmitter from an inactive state to an active state, wherein in the active state the transmitter transmits a signal encoded with data corresponding to a reading received from the sensor.

[0028] Implementations of aspects and embodiments may include one or more of the following: In an active state, the transmitter may transmit a signal using Bluetooth® low energy. The method may further include receiving the transmitted signal at the HCP device, and the method may further include receiving the transmitted signal at the patient device. The patient device may be a smartphone or a smartwatch. The method may further include transmitting a signal from the transmitter to the HCP device upon receiving an acknowledgment signal from the patient device by the transmitter, thereby providing the HCP device with confirmation that the patient device is operating properly with the patient sensor and transmitter. The method may further include collecting data from the transmitter over a period of time from the transmitter measured by the sensor. The extracting may include interrogating the transmitter using the HCP device, and the interrogation may be performed using near-field communication or Bluetooth® low energy. The method may further include transmitting a signal from the transmitter, the signal encoded with data indicating that sensor insertion has occurred.

[0029] An eighth aspect is directed to a method of quickly activating a transmitter configured to store for a predetermined period of time and physically engage with an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to a mobile device, the method comprising sending a wake-up command from an HCP device to the transmitter, the wake-up command transitioning the transmitter from an inactive state to an active state.

[0030] Implementations of aspects and embodiments may include one or more of the following: Sending the wake-up command may be performed using near-field communication or Bluetooth low energy; Sending the wake-up command may be performed at least in part by communicating a signal to a wake-up pin on a processor operating a transmitter; Sending the wake-up command may be performed in response to detecting a signal measured by an indwelling glucose sensor.

[0031] A ninth aspect is directed to a method of rapidly activating a transmitter configured to store for a predetermined period of time and physically engage with an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to a mobile device, the method including detecting, at the transmitter, a signal from the connected sensor, and transitioning the transmitter from an inactive state to an active state if the detected signal is determined to have an amplitude above a predetermined threshold.

[0032] A tenth aspect is directed to a method for rapidly activating a transmitter configured to store for a predetermined period of time and physically engage with an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to a mobile device, the method including periodically activating the transmitter configured to receive a signal from the glucose sensor upon activation, deactivating the transmitter if the transmitter is activated and does not receive a signal from the glucose sensor within the predetermined period, and permanently activating the transmitter if the transmitter is activated and receives a signal from the glucose sensor within the predetermined period, whereby the transmitter can be periodically activated to determine if a connection has been made to the indwelling glucose sensor.

[0033] In one implementation, the periodic basis may be between every 5 and 15 minutes.

[0034] An eleventh aspect is directed to a method of rapidly activating a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device, the method including, upon activation of the transmitter, the transmitter being coupled to the sensor and adhered to a patient by a patch, the transmitter receiving a measurement signal from the sensor, and the activation causing the transmitter to emit a signal based on a signal representative of the measurement signal and rendering an indication of activation in the transmitter, the sensor, or the patch, thereby allowing a user to be notified of the activation without having to use another device.

[0035] In one implementation, the rendered instructions may be in visual or audio form.

[0036] A twelfth aspect is directed to a method of rapidly activating a transmitter configured to physically engage with an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device, the method including, upon activation of the transmitter, the transmitter coupled to the sensor and adhered to a patient by a patch, the transmitter receiving a measurement signal from the sensor, the activation causing the transmitter to emit a signal based on the signal representative of the measurement signal and transmitting from the transmitter to an external device, the external device rendering an indication of the activation whereby a user may be notified of the activation.

[0037] A thirteenth aspect is directed to a method for quickly starting a CGM system including a transmitter configured to physically engage an indwelling glucose sensor, the transmitter configured to transmit a signal representative of a measured glucose concentration value to a patient's mobile device, the method including downloading an application to the patient's mobile device upon wireless connection between the patient's mobile device and the transmitter, and further establishing a communication session associated with a user account between the patient's mobile device and a server upon wireless connection and downloading of the application.

[0038] Implementations of aspects and embodiments may include one or more of the following: The wireless connection may include a connection using near field communication or Bluetooth® low energy. The application may be downloaded from the transmitter or server to the patient's mobile device. The method may further include causing the transmitter to initiate transmission of a signal from the sensor, the signal indicative of a glucose measurement measured by the sensor.

[0039] A fourteenth aspect is directed to a system for rapidly activating a transmitter configured to physically engage with an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device, the system including an applicator configured to install the indwelling sensor, the applicator further configured to install the transmitter to physically engage with the indwelling sensor, the transmitter having a switch that, upon activation, places the transmitter in an active state, wherein in the active state the transmitter receives signals from the sensor and transmits signals representative of the measured glucose concentration value to a mobile device, the switch being configured to be activated when the transmitter physically engages with the indwelling sensor.

[0040] A fifteenth aspect is directed to a transmitter further configured to physically engage with an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device, and configured to be rapidly activated, the transmitter including: a housing including means for physically engaging with a glucose sensor configured to be at least partially indwelled within a patient's body; a light sensor disposed within the housing and optically exposed to an exterior of the housing through a window; and a cover applied to the window and configured to block exposure of the light sensor to light prior to use of the transmitter, wherein a user removes the cover prior to use to expose the light sensor to light, which transitions the transmitter to an active state when activated, thereby allowing the transmitter to be activated by removing the cover.

[0041] In one implementation, the cover can be glued to the window.

[0042] A sixteenth aspect is directed to a transmitter configured to physically engage with an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to a mobile device, the transmitter comprising: a housing including means for physically engaging with a glucose sensor configured to be at least partially indwelled within a patient's body; circuitry configured to receive timestamp information from an external source; and a memory configured to store the timestamp information from the external source.

[0043] Implementations of aspects and embodiments may include one or more of the following: The memory may be further configured to associate timestamp information with one or more received data packets related to the signal from the sensor. The circuit may be a near-field communication circuit or a Bluetooth® low energy circuit. The circuit may be a Bluetooth® low energy circuit, and the circuit may be configured to periodically poll nearby Bluetooth® devices for timestamp information. The circuit may be configured to receive timestamp information from an HCP device. The circuit may be configured to receive timestamp information from a patient's mobile device. The circuit may further include a processor in signal communication with the memory, the processor configured to compensate for time drift or time lag. The processor may be configured to compensate for time drift or time lag by causing periodic or irregular synchronization.

[0044] A seventeenth aspect is directed to a kit for pairing a patient's mobile device including a continuous glucose monitoring application with a transmitter configured to transmit a signal representative of a measured glucose concentration value to the mobile device, the kit including: the transmitter including means for physically engaging a glucose sensor; and an identification component including a flexible electronic device and configured to be scanned by the patient's mobile device to receive identification information related to the transmitter stored on the flexible electronic device, wherein upon receiving the identification information, the patient's mobile device is configured to pair with the transmitter, the pairing enabling the patient's mobile device to receive the signal representative of the measured glucose concentration value transmitted by the transmitter.

[0045] Implementations of aspects and embodiments may include one or more of the following: The identification component may include a sticker and may further include calibration information. Pairing may also be between a glucose monitoring application and a transmitter and may be performed based on identified RSSI signal strength. The identification component may be incorporated as part of a sensor adhesive patch, and the application may be configured to verify that the sensor is within a proper operating range by determining whether the received counts are within a predetermined range for a predetermined period of time.

[0046] An eighteenth aspect is directed to a method of pairing a patient's mobile device including a continuous glucose monitoring application with a transmitter configured to transmit a signal representative of a measured glucose concentration value to the mobile device, the method including receiving an input at a user interface of the mobile device indicating that the mobile device should be paired with the transmitter, detecting a motion artifact in an accelerometer in the mobile device, and upon detection, transmitting a signal to place the transmitter in pairing mode, and pairing the transmitter with the mobile device.

[0047] Implementations of aspects and embodiments may include one or more of the following: The method may further include indicating a desired motion artifact on a user interface, such as when the motion artifact includes a swaying motion of a predetermined number of taps or a predetermined threshold duration.

[0048] A nineteenth aspect is directed to a method of pairing a patient's mobile device including a continuous glucose monitoring application with a transmitter configured to transmit a signal representative of a measured glucose concentration value to the mobile device, the method including: receiving input at a user interface of the mobile device indicating that the mobile device should be paired with the transmitter; detecting a signal from the transmitter; determining whether an RSSI measurement of the detected signal exceeds a predetermined threshold; and generating pairing between the mobile device and the transmitter based on a determination that the detected signal exceeds the predetermined threshold.

[0049] In one implementation, the determining step may include confirming the identity or availability of the user-identifying transmitter based on selection criteria that includes continuous detection of at least one of information regarding the strength of a signal detected from the selected transmitter for a predetermined period of time and information regarding the quality of a signal detected from the selected transmitter for a predetermined period of time.

[0050] A twentieth aspect is directed to a reader configured for use by an HCP and configured to configure a transmitter associated with a continuous glucose monitor, the reader including circuitry configured to receive and transmit one or more operating parameters of the transmitter for display on a user interface of the HCP device, the reader further configured to receive changed transmitter parameters from the user interface and store the changed transmitter parameters in the transmitter.

[0051] A twenty-first aspect is directed to a method of activating a transmitter for use in a sensor session, configured to physically engage with an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device, the transmitter configured to transition from an active state to an inactive state following a predetermined period of the sensor session, the method including sending a wake-up command from an external device to the transmitter, the wake-up command causing the transmitter to transition from the inactive state to the active state.

[0052] Implementations of aspects and embodiments may include one or more of the following: Sending the wake-up command may be performed using near field communication or Bluetooth low energy. The method may further include downloading data stored in the transmitter to the external device. The wake-up command may be sent using a near field communication protocol. The download may be performed using a near field communication protocol or Bluetooth low energy protocol. The external device may be an HCP device, and the HCP device may be an HCP reader or controller or an HCP smartphone. The external device may be a patient device, such as a patient's smartphone.

[0053] A twenty-second aspect is directed to a method of reducing noise in signal transmission between a mobile device and a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to the mobile device using a short-range communication protocol, the method including: upon detecting a signal having energy above a predetermined threshold level on short-range wireless communication circuitry in the transmitter, setting a first flag and associating the first flag with corresponding data; upon detecting short-range wireless communication signaling between the transmitter and an external device, setting a second flag and associating the second flag with the corresponding data; transmitting the glucose concentration data from the transmitter to the external device; storing the transmitted data at the external device; and adjusting, correcting, or ignoring data for which both the first and second flags are set in calculations involving the transmitted data.

[0054] A twenty-third aspect is directed to a method of reducing noise in signal transmission between a mobile device and a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to the mobile device using a near-field communication protocol, the method including: upon detection at the transmitter of a signal having energy greater than a predetermined threshold level on the near-field communication circuitry, setting a first flag and associating the first flag with corresponding data; upon detection of near-field communication signaling between the transmitter and an external device, setting a second flag and associating the second flag with corresponding data; transmitting the glucose concentration data from the transmitter to the external device; storing the transmitted data at the external device; and in calculations involving the transmitted data, associating data for which both the first and second flags are set with a lower weighting than data for which neither flag is set.

[0055] A twenty-fourth aspect is directed to a method of reducing noise in signal transmission between a mobile device and a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to the mobile device using a near-field communication protocol, the method including: upon detecting at the transmitter a signal having energy greater than a predetermined threshold level on the near-field communication circuitry, setting a first flag and associating the first flag with corresponding data; upon detecting near-field wireless communication signaling between the transmitter and the external device, setting a second flag and associating the second flag with the corresponding data; transmitting the glucose concentration data from the transmitter to the external device; storing the transmitted data at the external device; and ignoring the data for which the first flag is set in calculations involving the transmitted data.

[0056] A twenty-fifth aspect is directed to a transmitter configured to reduce noise in signal transmission to a mobile device, the transmitter including: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; a near-field communication circuit disposed within the housing and configured to transmit a signal to an external device; and a threshold detector coupled to the near-field communication circuit and configured to detect signal energy of energy captured by the near-field communication circuit, wherein if the threshold detector detects a signal with energy greater than a predetermined threshold, the threshold detector deactivates the near-field communication circuit.

[0057] In one implementation, the threshold detector can cause an antenna associated with the near field communications circuitry to be disabled.

[0058] A twenty-sixth aspect is directed to a transmitter configured to reduce noise in signal transmission to a mobile device, the transmitter comprising: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; a wireless communication circuit disposed within the housing and configured to transmit a signal to an external device; and a detector coupled to the wireless communication circuit and configured to detect whether a signal corresponding to a wake-up command corresponding to a wake-up process is captured by the wireless communication circuit; wherein if the detector detects the wake-up signal, the detector causes the wireless communication circuit to be deactivated after completion of the wake-up process.

[0059] In one implementation, the wireless communication circuitry can be a near field communication circuitry.

[0060] A twenty-seventh aspect is directed to a transmitter configured to extend battery life and further configured for transmitting signals to a mobile device, the transmitter including: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; a wireless communication circuit disposed within the housing and configured to transmit signals to an external device; a battery configured to power the wireless communication circuit to enable measurements by the glucose sensor; a power-down circuit configured to transition the transmitter from an active state to an inactive state after completion of a sensor session; and a wake-up circuit configured to transition the transmitter from an inactive state to an active state after completion of the sensor session so that data stored in the transmitter can be transmitted to the external device, the power-down circuit being activated in part by a wake-up pin, the wake-up circuit further configured to connect the battery to the wireless communication circuit in the active state and configured to disable the wake-up pin when the wake-up circuit transitions to the inactive state.

[0061] A twenty-eighth aspect is directed to a transmitter configured to extend battery life and further configured for transmitting signals to a mobile device, the transmitter including: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; wireless communication circuitry disposed within the housing and configured to transmit signals to an external device; a battery configured to power the wireless communication circuitry to enable measurements by the glucose sensor; a power-down circuit configured to transition the transmitter from an active state to an inactive state after completion of a sensor session; and a wake-up circuit configured to transition the transmitter from an inactive state to an active state after completion of the sensor session so that data stored in the transmitter can be transmitted to the external device, the wake-up circuit being partially activated by a wake-up pin, and further configured to connect the battery to the wireless communication circuitry in the active state, the wake-up pin being hardened against EMI.

[0062] Implementations of aspects and embodiments may include one or more of the following: The hardening may be through the use of strong pull-up / down resistors and / or even through the use of capacitors. Hardening may also be through mechanically shorting the wake-up pin to a disabled polarity.

[0063] A twenty-ninth aspect is directed to a transmitter configured to extend battery life and further configured for transmitting signals to a mobile device, the transmitter including: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; a wireless communication circuit disposed within the housing and configured to transmit signals to an external device; a battery configured to power the wireless communication circuit to enable measurements by the glucose sensor; a power-down circuit configured to transition the transmitter from an active state to an inactive state after completion of a sensor session; and a wake-up circuit configured to transition the transmitter from an inactive state to an active state after completion of the sensor session so that data stored in the transmitter can be transmitted to the external device, the wake-up circuit being activated in part by a wake-up pin and further configured to connect the battery to the wireless communication circuit in the active state and configured to disable the wake-up circuit when the wake-up circuit transitions to the inactive state.

[0064] A thirtieth aspect is directed to a transmitter configured for enhanced data storage and further configured for transmitting signals to a mobile device, the transmitter including: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; a wireless communication circuit disposed within the housing and configured to transmit signals to an external device; a battery configured to power the wireless communication circuit to enable measurements by the glucose sensor; a memory configured to store data representing glucose values measured by the glucose sensor; and a processor configured to perform data processing on the data stored in the memory, wherein the processor is configured to periodically compress the data stored in the memory such that the data occupies less memory than before compression.

[0065] Implementations of aspects and embodiments may include one or more of the following: The processor may be configured to compress the data to the minimum number of data points necessary to accurately indicate the patient's glycemic exposure. The data points may include those corresponding to maxima, minima, and inflection points, along with corresponding abscissa time values. The processor may be configured to compress the data by eliminating data points that represent stable values, where stable values are within a range of stability. The processor may be configured to compress the data using a lossy or lossless compression technique. The lossy or lossless compression technique may include one or more selected from the group consisting of Lempel-Ziv compression, Huffman coding, or algorithmic coding. The processor may be configured to compress the data by storing only data whose variance exceeds a defined amount, and data between such points is interpolated. The processor may be configured to compress the data by removing artifacts.

[0066] A thirty-first aspect is directed to a method of operating a transmitter configured to transmit signals from an indwelling glucose sensor to a mobile device for enhanced data storage, the method including receiving signals over time from the indwelling glucose sensor, storing data representative of the received signals in a memory, and performing data processing on the stored data, wherein the data processing includes periodically or aperiodically compressing the data stored in the memory such that the data occupies less memory than before compression.

[0067] Implementations of aspects and embodiments may include one or more of the following: Compression may compress data to the minimum number of data points necessary to accurately represent a patient's glycemic exposure. Data points may include those corresponding to maxima, minima, and inflection points along with corresponding abscissa time values. Compression may compress data by eliminating data points representing stable values, where stable values are within a range of stability. Compression may compress data using lossy or lossless compression techniques, where lossless or lossless compression techniques may include one or more selected from the group consisting of Lempel-Ziv compression, Huffman coding, or algorithmic coding. Compression may compress data by storing only data whose variation exceeds a defined amount, and data between such points is interpolated. Compression may compress data by removing artifacts.

[0068] A thirty-second aspect is directed to a method of operating a transmitter configured to transmit signals from an indwelling glucose sensor to a mobile device to improve data accuracy, the method including receiving signals over time from the indwelling glucose sensor, storing data representative of the received signals in a memory, and performing data processing on the stored data, the data processing including periodically or aperiodically post-processing the data stored in the memory such that the accuracy of the data or of calculations based on the data is improved.

[0069] Implementations of aspects and embodiments may include one or more of the following: Periodically post-processing the data may include post-processing the data every 24 hours or every 48 hours Periodically post-processing the data may include smoothing the data periodically.

[0070] A thirty-third aspect is directed to a method of operating a continuous glucose monitor, the method including receiving at a transmitter a signal from an indwelling glucose sensor and receiving at the transmitter an external signal from an external sensor, the sensor signal and the external signal being stored based on absolute or relative time of receipt.

[0071] Implementations of aspects and embodiments may include one or more of the following: The external sensor may be an ambient noise sensor, and the method may further conclude calculating a sleep or exercise event based on a signal from the noise sensor. The external sensor may be an accelerometer, and the method may further conclude calculating a sleep or exercise event based on a signal from the accelerometer. The external sensor may also be a GPS receiver, and the method may further include calculating a sleep or exercise or meal event based on a signal from the GPS receiver.

[0072] A thirty-fourth aspect is directed to a method of operating a continuous glucose monitor, the method including receiving at a mobile device a signal from a transmitter measured by an indwelling glucose sensor, receiving at the mobile device an external signal from an external sensor, and storing the sensor signal and the external signal at the mobile device based on absolute or relative time of receipt.

[0073] A thirty-fifth aspect is directed to a transmitter configured to physically engage an indwelling glucose sensor and transmit a signal representing a measured glucose concentration value to a mobile device, the transmitter including: a housing configured to physically engage with a glucose sensor configured to be at least partially placed within a patient's body; a first communication circuit configured to communicate with the mobile device using a short-range wireless protocol; a second communication circuit configured to communicate with the mobile device using an encrypted wireless protocol; and a memory for storing information received from the glucose sensor.

[0074] Implementations of aspects and embodiments may include one or more of the following: the first communication circuit may be a near field communication (NFC) circuit; the second communication circuit may be a Bluetooth® low energy circuit, and the mobile device may be an HCP device; the transmitter may further include a feedback indicator that facilitates physical alignment by a user between an antenna of the het NFC circuit and an antenna of the mobile device.

[0075] A thirty-sixth aspect is directed to a method of communication between a mobile device and a transmitter configured to physically engage a continuous glucose sensor and transmit a signal representing a measured glucose concentration value to the mobile device, the method including receiving a data extraction command at the transmitter from the mobile device using a short-range wireless protocol; in response to the data extraction command, causing the transmitter to enter a data extraction operational mode; transmitting an advertising message according to the encrypted wireless protocol and initiating a connection with the mobile device over the encrypted wireless protocol; and upon establishing the connection with the mobile device over the encrypted wireless protocol, transmitting an estimated glucose value to the mobile device over the connection.

[0076] Implementations of aspects and embodiments may include one or more of the following: receiving a query command at the transmitter using a short-range wireless protocol prior to receiving the data extraction command; transmitting an encrypted identifier of the transmitter using the short-range wireless protocol in response to the query command, wherein the query command can be issued after the glucose sensor is inserted into the patient and can be issued while at the HCP office; and transmitting operational status information specifying one or more operational statuses of the transmitter in response to the query command.

[0077] A thirty-seventh aspect is directed to a continuous glucose monitoring device configured for use by a healthcare professional (HCP), the continuous glucose monitoring device including a housing, a first communication circuit configured to communicate with the continuous glucose monitoring device including a transmitter coupled to an indwelling glucose sensor using a short-range wireless protocol, a second communication circuit configured to communicate with the transmitter using an encrypted wireless protocol, and a user interface for entering an operational mode in which the continuous glucose monitoring device will operate.

[0078] A thirty-eighth aspect is directed to a method for pairing a patient's mobile device including a continuous glucose monitoring application with a transmitter configured to transmit a signal representative of a measured glucose concentration value to the patient's mobile device, the method including: detecting insertion of the transmitter in a glucose sensor housing; and in response to the detection, automatically transitioning the transmitter from an inactive state to an active state wherein the transmitter can transmit a signal encoded with data corresponding to a reading received from the sensor; broadcasting an advertising message according to a first wireless protocol; and in response to the broadcast, opening the application on the patient's mobile device; having the patient's mobile device enter a security code and pairing the transmitter with the patient's mobile device using the first wireless protocol; if the security code is correct, pairing the transmitter with the patient's mobile device using the first wireless protocol; and in response to pairing, initiating a sensor session.

[0079] A thirty-ninth aspect is directed to a method of rapidly activating a transmitter configured to store for a predetermined period of time and physically engage with an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to a mobile device, the method including detecting a signal indicative of an acceleration event at the transmitter stored in a package, and transitioning the transmitter from an inactive state to an active state if the detected signal is determined to indicate that the acceleration event resulted from acceleration within a specified range.

[0080] A fortieth aspect is directed to a method of communication between a mobile device and a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to the mobile device, the method including: receiving, at the transmitter, a data extraction command from the mobile device using a short-range wireless protocol; in response to the data extraction command, causing the transmitter to enter a data extraction operational mode; transmitting an advertising message according to the encrypted wireless protocol and initiating a connection with the mobile device over the encrypted wireless protocol; and upon establishing the connection with the mobile device over the encrypted wireless protocol, transmitting operational status information specifying at least one operational state of the transmitter, wherein the at least one operational state of the transmitter includes a sensor session completion status indicating that the session is complete and data is available for download.

[0081] A forty-first aspect is directed to a method of communication between an HCP reader and a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representing a measured glucose concentration value to the HCP reader, the method including: receiving, at the transmitter, a data extraction command from the HCP reader using a short-range wireless protocol, the data extraction command including an encrypted version of an identifier of the transmitter; in response to the data extraction command, if the transmitter determines that the identifier included in the data extraction command is correct, causing the transmitter to enter a data extraction operational mode; transmitting an advertising message according to the encrypted wireless protocol to initiate a connection with the HCP reader via the encrypted wireless protocol, the advertising message including information causing the HCP reader to connect in preference to other devices; and upon establishing the connection with the HCP reader via the encrypted wireless protocol, transmitting sensor data to the HCP reader via the connection.

[0082] In further aspects and embodiments, the above method features of various aspects are described in terms of systems, such as those in various aspects, configured to implement the method features. Any of the features of any of the embodiments of the aspects, including but not limited to any of the embodiments of any of the above-mentioned aspects 1-34, are applicable to all other aspects and embodiments identified herein, including but not limited to any of the embodiments of any of the above-mentioned aspects 1-34. Furthermore, any of the features of the embodiments of various aspects, including but not limited to any of the embodiments of any of the above-mentioned aspects 1-34, can be independently combined in any way, partially or in whole, with other embodiments described herein; for example, one, two, or more embodiments may be combined in whole or in part. Furthermore, any of the features of the embodiments of various aspects, including but not limited to any of the embodiments of any of the above-mentioned aspects 1-34, can be made optional with respect to other aspects or embodiments. Any aspect or embodiment of the method may be performed by a system or apparatus of another aspect or embodiment, and any aspect or embodiment of the system or apparatus may be configured to perform a method of another aspect or embodiment, including, but not limited to, any embodiment of any of the first to thirty-fourth aspects referred to above.

[0083] Advantages of aspects may, in certain embodiments, include one or more of the following: Systems and methods according to the present principles can provide a valuable educational tool, enhancing communication between HCPs and patients and enabling better education of users about, and treatment of, their diseases; HCPs and patients are provided with more useful information for making decision-making, treatment, and behavioral decisions; HCPs can have more meaningful discussions with patients; HCPs are advantageously provided with pre-downloadable data prior to patient appointments, making patient consultations more useful and informative; Other advantages will be understood from the following description, including the drawings and claims.

[0084] This summary is provided to introduce a selection of concepts in a simplified form. These concepts are further described in the Detailed Description section. Elements or steps other than those described in this summary are possible, and no element or step is required. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended for use as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

[0085] Further aspects of the present disclosure will be more readily appreciated upon consideration of the detailed description of various disclosed embodiments set forth below, when taken in conjunction with the accompanying drawings. [Brief explanation of the drawings]

[0086] [Figure 1A] FIG. 1 illustrates aspects of an exemplary system that can be used in connection with the implementation of embodiments of the present disclosure. [Figure 1B] FIG. 1 illustrates aspects of an exemplary system that can be used in connection with the implementation of embodiments of the present disclosure. [Figure 2A] FIG. 1 is a perspective view of an exemplary housing that can be used in connection with the implementation of an analyte sensor system. [Figure 2B] FIG. 1 is a side view of an exemplary housing that can be used in connection with implementing an analyte sensor system. [Figure 3A] FIG. 1 illustrates aspects of an exemplary system that can be used in connection with the implementation of embodiments of the present disclosure. [Figure 3B] FIG. 1 illustrates aspects of an exemplary system that can be used in connection with the implementation of embodiments of the present disclosure. [Figure 4] The system is shown in the context of an HCP office, and the system incorporates various elements for use by HCPs and / or users. [Figure 5] 1 shows the logical organization of various parts of a system according to the present principles. [Figure 6] 1 shows a flowchart of a method according to an implementation of the present principles. [Figure 7] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 8] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 9] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 10] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 11] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 12] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 13] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 14] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 15] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 16] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 17] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 18] 1 shows a transmitter according to an implementation of the present principles. [Figure 19] 1 shows a transmitter according to an implementation of the present principles. [Figure 20] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 21] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 22] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 23] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 24]1 shows a flowchart of a method according to another implementation of the present principles. [Figure 25] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 26A] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 26B] 10 shows a chart of power usage versus time in a mode specifically configured for low battery consumption. [Figure 27] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 28] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 29] 1 shows a logic diagram of an arrangement according to the present principles. [Figure 30] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 31] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 32] 1 shows a logic diagram of an arrangement according to the present principles. [Figure 33] 1 shows a logic diagram of an arrangement according to the present principles. [Figure 34] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 35] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 36A] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 36B] 1 shows a schematic of a transmitter chip including a wake-up pin. [Figure 37] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 38] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 39] 1 shows a flowchart of a method according to another implementation of the present principles. [Figure 40] 1 shows a logic diagram of an arrangement according to the present principles. [Figure 41] 1 shows a flowchart of a method according to another implementation of the present principles. DETAILED DESCRIPTION OF THE INVENTION

[0087] The figures are described in more detail below in the description and examples and are provided for illustrative purposes only and merely represent typical or exemplary embodiments of the present disclosure. The figures are not intended to be exhaustive or to limit the disclosure to the precise form disclosed. It should also be understood that the present disclosure may be practiced with modification or alteration and that the disclosure may be limited only by the claims and their equivalents.

[0088] Embodiments of the present disclosure relate to systems, methods, and apparatus for HCP configuration of analyte monitoring systems, as well as supporting technology and functionality. In various implementations and configurations described herein, the analyte data is glucose data generated by an analyte sensor system configured to connect to a receiver, such as a display device and the like. As described in detail herein, embodiments of the present disclosure can include communication protocols and methods for configuring an analyte monitoring system as well as downloading data therefrom. Additionally, embodiments of the present disclosure can relate to systems and methods for conserving battery life in such systems, as such systems constitute wearable devices and battery capacity as well as circuit real estate are at a premium.

[0089] Details of several exemplary embodiments of the systems, methods, and devices of the present disclosure are set forth within this description, and in some cases, elsewhere in this disclosure. Other features, objects, and advantages of the present disclosure will become apparent to those skilled in the art upon review of the disclosure, description, drawings, examples, and claims. All such additional systems, methods, devices, features, and advantages are intended to be included (explicitly or by reference) in this description, be within the scope of the present disclosure, and be protected by one or more of the accompanying claims.

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

[0091] For ease of explanation and illustration, in some instances, the detailed description describes exemplary systems and methods in terms of a continuous glucose monitoring environment, but it should be understood that the scope of the invention is not limited to that particular environment, and those skilled in the art will appreciate that the systems and methods described herein may be embodied in a variety of forms. Accordingly, any structural and / or functional details disclosed herein should not be construed as limiting the systems and methods, but rather are provided as attributes of representative embodiments and / or arrangements to teach those skilled in the art one or more ways to implement the systems and methods that may be advantageous in other contexts.

[0092] For example, without limitation, the described monitoring systems and methods may include sensors that measure the concentration of one or more analytes (e.g., glucose, lactate, potassium, pH, cholesterol, isoprene, and / or hemoglobin) and / or other blood or bodily fluids of or associated with a host and / or another party.

[0093] By way of example, and not limitation, embodiments of the monitoring systems and methods described herein may include fingerstick blood sampling, blood analyte test strips, non-invasive sensors, wearable monitors (e.g., smart bracelets, smart watches, smart rings, smart necklaces or pendants, movement monitors, fitness monitors, health and / or medical monitors, clip-on monitors, and the like), adhesive sensors, smart textiles and / or garment-embedded sensors, sensors, transdermal (i.e., transcutaneous) sensors, and / or shoe inserts and / or insoles containing swallowed, inhaled, or implantable sensors.

[0094] In some embodiments, without limitation, the monitoring systems and methods may comprise other sensors instead of or in addition to the sensors described herein, such as inertial measurement units including accelerometers, gyroscopes, magnetometers, and / or barometers, movement, altitude, position, and / or location sensors, biometric sensors, such as optical sensors including optical heart rate monitors, photoplethysmography (PPG) / pulse oximeters, fluorescence monitors, and cameras, wearable electrodes, electrocardiogram (EKG or ECG) sensors, electroencephalogram (EEG) sensors, and / or electromyogram (EMG) sensors, chemical sensors, such as flexible sensors for measuring extension, displacement, pressure, weight, or impact, galvanometric sensors, capacitive sensors, electric field sensors, temperature / heat sensors, microphones, vibration sensors, ultrasonic sensors, piezoelectric / piezoresistive sensors, and / or transducers, for measuring information of or related to the host and / or another party.

[0095] As used herein, the term "analyte" is a broad term and should be given its ordinary and customary meaning to those of skill in the art (and should not be limited to any special or customized meaning), and further refers to, without limitation, a substance or chemical constituent in a biological fluid (e.g., blood, interstitial fluid, cerebrospinal fluid, lymphatic fluid, urine, sweat, saliva, etc.) that can be analyzed. Analytes can include naturally occurring substances, man-made substances, metabolites, and / or reaction products. In some implementations, the analyte for measurement by a method or device is glucose. However, examples of antibodies that may be used include, but are not limited to: acarboxyprothrombin; acetoacetate; acetone; acetyl-CoA; acylcarnitines; adenine phosphoribosyltransferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acid profile (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan); andrenostenenedione; antipyrine; arabinitol enantiomers; arginase; benzoylecgonine (cocaine); biotinidase; biopterin; c-reactive protein; carnitine; carnosinase; CD4; ceruloplasmin; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-beta hydroxycholic acid; cortisol; creatine kinase; creatinine Enzyme MM isoenzymes; cyclosporine A; d-penicillamine; deethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetyltransferase polymorphisms, alcohol dehydrogenase, alpha-1-antitrypsin, cystic fibrosis, Duchenne / Becker muscular dystrophy, glucose-6-phosphate dehydrogenase, hemoglobin A, hemoglobin S, hemoglobin C, hemoglobin D, hemoglobin E, hemoglobin F, D-Punjab, beta-thalassemia, hepatitis B virus, HCMV, HIV-1, HTLV-1, Leber hereditary optic neuropathy, MCAD, RNA, PKU, Plasmodium vivax, gonadal differentiation, 21-deoxycortisol); desbutylhalofantrine; dihydropteridine reductase; diphtheria / tetanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin;Esterase D; Fatty acids / acylglycines; Triglycerides; Glycerol; Free β-human chorionic gonadotropin; Free erythrocyte porphyrins; Free thyroxine (FT4); Free triiodothyronine (FT3); Fumarylacetoacetase; Galactose / Gal-1-phosphate; Galactose-1-phosphate uridyltransferase; Gentamicin; Glucose-6-phosphate dehydrogenase; Glutathione; Glutathione peroxidase; Glycocholate; Glycosylated hemoglobin; Halofantrine; Hemoglobin variants; Hexosaminidase idase A; human erythrocyte carbonic anhydrase I; 17-alpha-hydroxyprogesterone; hypoxanthine phosphoribosyltransferase; immunoreactive trypsin; ketone bodies; lactate; lead; lipoproteins ((a), B / A-1, β); lysozyme; mefloquine; netilmicin; phenobarbitone; phenytoin; phytanic acid / pristanic acid; progesterone; prolactin; prolidase; purine nucleoside phosphorylase; quinine; reverse triiodothyronine (rT3); selenium; serum pancreatic lipase; sisomicin; somatomedin C; specific antibodies (adenovirus, antinuclear antibody, anti-zeta antibody, arbovirus, Aujeszky's disease virus, Guinea worm, Echinococcus granulosus, Entamoeba histolytica, enterovirus, Giardia lamblia, Helicobacter pylori, hepatitis B virus, herpes virus, HIV-1, IgE (atopic disease), influenza virus, isoprene (2-methyl-1,3-butadiene), Leishmania donovani, Leptospira, measles / mumps / rubella, Mycobacterium leprae, Mycoplasma pneumoniae, myoglobin, Onchocerca volvulus, parainfluenza virus, Plasmodium falciparum, poliovirus, Pseudomonas aeruginosa, respiratory syncytial virus, rickettsia (scrub typhus), Schistosoma mansoni, Toxoplasma gondii, Treponema pallidum, Trypanosoma cruzi / Langer's, vesicular stomatitis virus, bancroftian filariasis, flavivirus (e.g., deer tick, dengue, Powassan, West Nile, yellow fever, or Zika virus); specific antigens (hepatitis B virus, HIV-1), succinylacetone, sulfadoxine, theophylline, thyrotropin (TSH), thyroxine (T4), thyroxine-binding globulin, trace elements, transferrin;Other analytes are contemplated as well, including UDP-galactose-4-epimerase; urea; uroporphyrinogen I synthase; vitamin A; leukocytes; and zinc protoporphyrin. Salts, sugars, proteins, fats, vitamins, and hormones naturally occurring in blood or interstitial fluid may also constitute analytes in certain implementations. Analytes may be naturally present in biological fluids, such as metabolites, hormones, antigens, antibodies, etc. Alternatively, the analyte may be internal or exogenous, such as, for example, an imaging contrast agent, a radioisotope, a chemical agent, a fluorocarbon-based synthetic blood, or a compound such as, but not limited to, insulin; glucagon, ethanol; cannabis (marijuana, tetrahydrocannabinol, hashish); inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorohydrocarbons, hydrocarbons); cocaine (crack cocaine); stimulants (amphetamine, methamphetamine, Ritalin, Silica, Preludin, Direx, Prestate, Boranil, Sandrex, Pregeen); depressants (barbiturates, methaqualone, barbiturates, Drugs or pharmaceutical compositions may be incorporated into the assay, including tranquilizers such as benzodiazepine, benzocaine, benzodiazepine ... Analytes such as neurochemicals and other chemicals produced in the body, such as ascorbic acid, uric acid, dopamine, noradrenaline, 3-methoxytyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), 5-hydroxytryptamine (5HT), and 5-hydroxyindoleacetic acid (FHIAA), as well as intermediates in the citric acid cycle, can also be analyzed;

[0096] Alerts In certain embodiments, one or more alerts are associated with the sensor electronics module. For example, each alert may include one or more alert conditions that indicate when the respective alert was triggered. For example, a hypoglycemia alert may include an alert condition that indicates a minimum blood glucose level. Alert conditions may also be based on transformed sensor data, such as trend data, and / or sensor data from multiple different sensors (e.g., an alert may be based on sensor data from both a glucose sensor and a temperature sensor). For example, a hypoglycemia alert may include an alert condition that indicates a minimum required trend in the host's blood glucose levels that must exist before triggering the alert. The term "trend," as used herein, generally refers to data that indicates some attribute of data acquired over time, such as calibrated or filtered data from a continuous glucose sensor. Trends may indicate the amplitude, rate of change, acceleration, direction, etc. of data, such as sensor data, including transformed or raw sensor data.

[0097] In certain embodiments, each alert is associated with one or more actions to be taken in response to triggering the alert. Alert actions may include, for example, activating an alarm, such as displaying information on a display of the sensor electronics module or activating an audible or vibratory alarm coupled to the sensor electronics module, and / or transmitting data to one or more display devices external to the sensor electronics module. For a delivery action associated with a triggered alert, one or more delivery options define the content and / or format of the data to be transmitted, the devices to which the data should be transmitted, when the data should be transmitted, and / or the communication protocol for delivering the data.

[0098] In particular embodiments, multiple delivery actions (each with respective delivery options) can be associated with a single alert, such that displayable sensor information having different content and formatting is transmitted to respective display devices, for example, in response to the triggering of a single alert. For example, a mobile phone can receive a data package containing minimal displayable sensor information (specifically formatted for display on the mobile phone), while a desktop computer can receive a data package containing most (or all) of the displayable sensor information generated by the sensor electronics module in response to triggering a common alert. Advantageously, the sensor electronics module is not tied to a single display device, but rather is configured to communicate with multiple different display devices directly, systematically, simultaneously (e.g., via broadcasting), regularly, periodically, randomly, on-demand, in response to a query, based on an alert or alarm, and / or the like.

[0099] In some embodiments, clinical risk alerts are provided that include intelligent, dynamic estimation algorithms for estimating current or predicted danger, combined with alert conditions that combine greater accuracy, timeliness in detecting impending danger, avoidance of false alarms, and reduced patient discomfort. Generally, clinical risk alerts include dynamic, intelligent estimation algorithms based on analyte values, rates of change, accelerations, clinical risks, statistical probabilities, known physiological constraints, and / or individual physiological patterns, thereby providing more appropriate, clinically safe, and patient-friendly alarms. U.S. Patent Application Publication No. 2007 / 0208246, incorporated herein by reference in its entirety, describes several systems and methods associated with the clinical risk alerts (or alarms) described herein. In some embodiments, clinical risk alerts can be triggered for a predetermined period of time to allow users to pay attention to their condition. Additionally, clinical risk alerts can be stopped when the patient exits a clinical risk zone, preventing the patient from being annoyed by repeated clinical alarms (e.g., visual, auditory, or vibrational) as the patient's condition improves. In some embodiments, the dynamic intelligent assessment determines the likelihood that the patient will avoid the clinical risk based on the analyte concentration, rate of change, and other aspects of the dynamic intelligent assessment algorithm. If there is minimal or no likelihood of avoiding the clinical risk, a clinical risk alert will be triggered. However, if there is a likelihood of avoiding the clinical risk, the system is configured to wait a predetermined amount of time and reanalyze the likelihood of avoiding the clinical risk. In some embodiments, if there is a likelihood of avoiding the clinical risk, the system is further configured to provide goals, treatment recommendations, or other information that can assist the patient in proactively avoiding the clinical risk.

[0100] In some embodiments, the sensor electronics module is configured to search for one or more display devices within communication range of the sensor electronics module and wirelessly communicate sensor information (e.g., a data package including displayable sensor information, one or more alarm conditions, and / or other alarm information) to the display device. Thus, the display device is configured to display at least some of the sensor information and / or alarms to the host (and / or caregiver), and the alarm mechanism is located on the display device.

[0101] In some embodiments, the sensor electronics module is configured to provide one or more different alarms, via the sensor electronics module and / or via transmission of a data package, indicating that an alarm should be initiated (e.g., sequentially and / or simultaneously) by one or more display devices. In certain embodiments, the sensor electronics module simply provides a data field indicating the existence of an alarm condition, and the display device can determine to trigger an alarm upon reading the data field indicating the existence of the alarm condition. In some embodiments, the sensor electronics module determines which of one or more alerts to trigger based on the one or more alerts being triggered. For example, when an alert trigger indicates severe hypoglycemia, the sensor electronics module can take a number of actions, such as activating an alarm on the sensor electronics module, transmitting a data package to a monitoring device indicating the activation of an alarm on a display, and transmitting the data package as a text message to a care provider. As an example, a text message containing displayable sensor information indicating the host's condition (e.g., "severe hypoglycemia") can appear on a custom monitoring device, a cell phone, a pager device, and / or the like.

[0102] In some embodiments, the sensor electronics module is configured to wait a period of time for the host to respond to a triggered alert (e.g., by pressing or selecting a snooze and / or off function and / or button on the sensor electronics module and / or display device), and then trigger additional alerts (e.g., in an escalating manner) until one or more alerts have been responded to. In some embodiments, the sensor electronics module is configured to send a control signal (e.g., a stop signal) to a medical device, such as an insulin pump, associated with the alarm condition (e.g., hypoglycemia), where the stop alert triggers the cessation of insulin delivery via the pump.

[0103] In some embodiments, the sensor electronics module is configured to transmit alert information directly, systematically, simultaneously (e.g., via broadcasting), regularly, periodically, randomly, on-demand, in response to a query (from the display device), based on an alert or alarm, and / or the like. In some embodiments, the system further includes a repeater configured to repeat wireless communications from the sensor electronics module to a display device located remotely from the sensor electronics, so that the wireless communication range of the sensor electronics module can be increased to, for example, 10, 20, 30, 50, 75, 100, 150, or 200 meters or more. The repeater may be useful for families with children with diabetes. For example, it allows parents to carry the display device or place it in a fixed location, such as in a large house where parents sleep far from their children.

[0104] Display device In some embodiments, the sensor electronics module is configured to search for a display device from a list of display devices and / or attempt wireless communication with the display device. In some embodiments, the sensor electronics module is configured to search for a display device from a list of display devices and / or attempt wireless communication with the display device in a predetermined and / or programmable order (e.g., ranked and / or escalating), e.g., a failed attempt to communicate with and / or alarm a first display device triggers an attempt to communicate with and / or alarm a second display device, etc. In one exemplary embodiment, the sensor electronics module is configured to search for and attempt to alarm a host or caregiver sequentially using a list of display devices, such as: (1) a default display device or custom analyte monitoring device; (2) a cell phone via audio and / or visual methods, such as a text message to the host and / or caregiver, a voice message to the host and / or caregiver, and / or 911; (3) a tablet; (4) a smartwatch or bracelet; and / or (5) smart glasses or other wearable display device.

[0105] Depending on the embodiment, one or more display devices that receive the data package from the sensor electronics module are “dummy displays” that display the displayable sensor information received from the sensor electronics module without additional processing (e.g., predictive algorithm processing necessary for real-time display of sensor information). In some embodiments, the displayable sensor information includes transformed sensor data that does not require processing by the display device before displaying the displayable sensor information. Some display devices can include software including display instructions configured to enable the displayable sensor information to be displayed thereon (software programming including instructions configured to display the displayable sensor information and, optionally, query the sensor electronics module to obtain the displayable sensor information). In some embodiments, the display device is programmed with the display instructions at the manufacturer and can also include security and / or authentication to prevent theft of the display device. In some embodiments, the display device is configured to display the displayable sensor information via a downloadable program (e.g., Java Script® downloadable via the internet), such that any display device that supports downloading programs (e.g., any display device that supports Java® applets) can be configured to thereby display the displayable sensor information (e.g., cell phones, tablets, PDAs, PCs, and the like).

[0106] In some embodiments, a particular display device may wirelessly communicate directly with the sensor electronics module, although intermediate network hardware, firmware, and / or software may be included in the direct wireless communication. In some embodiments, a repeater (e.g., a Bluetooth® repeater) may be used to retransmit the transmitted displayable sensor information to locations far from the immediate range of the sensor electronics module's telemetry module, the repeater enabling direct wireless communication when no substantial processing of the displayable sensor information occurs. In some embodiments, a receiver (e.g., a Bluetooth® receiver) may be used to retransmit the transmitted displayable sensor information, possibly in a different format, such as a text message to a TV screen, the receiver enabling direct wireless communication when no substantial processing of the sensor information occurs. In certain embodiments, the sensor electronics module wirelessly transmits displayable sensor information directly to one or more display devices, such that the displayable sensor information transmitted from the sensor electronics module is received by the display device without intermediate processing of the displayable sensor information.

[0107] In certain embodiments, one or more display devices include a built-in authentication mechanism, and communication between the sensor electronics module and the display device requires authentication. In some embodiments, a challenge-response protocol, such as password authentication, is provided to authenticate data communication between the sensor electronics module and the display device, where the challenge is a request for a password and a valid response is the correct password, such that pairing of the sensor electronics module and the display device can be achieved by a user and / or manufacturer via the password. This may be referred to in some instances as two-way authentication. In some embodiments, biometric authentication may also be employed.

[0108] In some embodiments, one or more display devices are configured to query the sensor electronics module for displayable sensor information, and the display device acts as a master device that requests sensor information on demand from the sensor electronics module (e.g., a slave device), e.g., in response to a query. In some embodiments, the sensor electronics module is configured to transmit sensor information to one or more display devices periodically, systematically, periodically, and / or periodically (e.g., every 1, 2, 5, or 10 minutes or more). In some embodiments, the sensor electronics module is configured to transmit data packages associated with triggered alerts (e.g., triggered by one or more alert conditions). However, any combination of the above-described data transmission statuses can be implemented with any combination of paired sensor electronics modules and display device(s). For example, one or more display devices can be configured to query the sensor electronics module's database and to receive alarm information triggered by meeting one or more alarm conditions. Additionally, the sensor electronics module can be configured to periodically transmit sensor information to one or more display devices (the same or different display devices as described in the previous examples), thereby allowing the system to include display devices that function differently with respect to how they obtain sensor information.

[0109] In some embodiments, the display device is configured to query the data storage memory in the sensor electronics module for specific types of data content, including direct queries to and / or requests for configured or configurable packages of data content from a database in the sensor electronics module's memory; i.e., data stored in the sensor electronics module can be configured, queried, predetermined, and / or pre-packaged based on the display device with which the sensor electronics module is in communication. In some additional or alternative embodiments, the sensor electronics module generates displayable sensor information based on its knowledge of which display device will receive a particular transmission. Additionally, some display devices can obtain calibration information and transmit the calibration information wirelessly to the sensor electronics module, such as through manual entry of calibration information, automatic delivery of calibration information, and / or an integrated reference analyte monitor built into the display device. U.S. Patent Application Publication Nos. 2006 / 0222566, 2007 / 0203966, 2007 / 0208245, and 2005 / 0154271 (all of which are incorporated herein by reference in their entirety) describe systems and methods for providing an integrated reference analyte monitor incorporated into a display device and / or other calibration methods that can be implemented by embodiments disclosed herein.

[0110] In general, a number of display devices (e.g., custom analyte monitoring devices (which may also be referred to as analyte display devices), mobile phones, tablets, smartwatches, reference analyte monitors, drug delivery devices, medical devices, and personal computers) can be configured to wirelessly communicate with the sensor electronics module. The multiple display devices can be configured to display at least a portion of the displayable sensor information wirelessly communicated from the sensor electronics module. The displayable sensor information can include sensor data, such as raw and / or converted sensor data, such as analyte concentration values, rate of change information, trend information, alert information, sensor diagnostic information, and / or calibration information.

[0111] Analyte Sensor 1A , in some embodiments, the analyte sensor 10 comprises a continuous analyte sensor, such as a subcutaneous, transcutaneous (e.g., transdermal), or intravascular device. In some embodiments, such a sensor or device can analyze multiple intermittent blood samples. While the present disclosure includes glucose sensor embodiments, such embodiments may be used for other analytes as well. The glucose sensor may use any glucose measurement method, including enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, iontophoretic, radiometric, immunochemical, and the like.

[0112] The glucose sensor can provide a data stream indicative of the concentration of glucose in the host using any known method, including invasive, minimally invasive, and non-invasive sensing techniques (e.g., fluorescence monitoring). The data stream is typically a raw data signal that is converted into a calibrated and / or filtered data stream that is used to provide useful glucose values to a user, such as a patient or caregiver (e.g., a patient, relative, guardian, teacher, doctor, nurse, or any other individual interested in the health status of the host).

[0113] The glucose sensor can be any device capable of measuring the concentration of glucose. According to one exemplary embodiment described below, an implantable glucose sensor can be used. However, it should be understood that the devices and methods described herein can be applied to any device capable of detecting the concentration of glucose and providing an output signal representative of the concentration of glucose (e.g., in the form of analyte data).

[0114] In certain embodiments, analyte sensor 10 is an implantable glucose sensor such as those described with reference to U.S. Patent No. 6,001,067 and U.S. Patent Application Publication No. 2005 / 0027463-A1. In embodiments, analyte sensor 10 is a transcutaneous glucose sensor such as those described with reference to U.S. Patent Application Publication No. 2006 / 0020187-A1. In an embodiment, the analyte sensor 10 is configured for implantation within a host's blood vessel or externally, as described in U.S. Patent Application Publication No. 2007 / 0027385-A1, co-pending U.S. Patent Application Publication No. 2008 / 0119703-A1, filed October 4, 2006, U.S. Patent Application Publication No. 2008 / 0108942-A1, filed March 26, 2007, and U.S. Patent Application No. 2007 / 0197890-A1, filed February 14, 2007. In an embodiment, the continuous glucose sensor comprises a transcutaneous sensor, for example, as described in U.S. Patent No. 6,565,509 to Say et al. In embodiments, the analyte sensor 10 is a continuous glucose sensor, including a subcutaneous sensor, such as those described with reference to U.S. Pat. No. 6,579,690 to Bonnecaze et al. or U.S. Pat. No. 6,484,046 to Say et al. In embodiments, the continuous glucose sensor includes a refillable subcutaneous sensor, such as those described with reference to U.S. Pat. No. 6,512,939 to Colvin et al. The continuous glucose sensor can include an intravascular sensor, such as those described with reference to U.S. Pat. No. 6,477,395 to Schulman et al. The continuous glucose sensor can include an intravascular sensor, such as those described with reference to U.S. Pat. No. 6,424,847 to Mastrototaro et al.

[0115] 2A and 2B are perspective and side views of a housing 200 that can be used in connection with implementing embodiments of an analyte sensor system 8 according to certain aspects of the present disclosure. The housing 200 includes a mounting unit 214 and a sensor electronics module 12 attached thereto in certain embodiments. The housing 200 is shown in a functional position, with the mounting unit 214 and the sensor electronics module 12 matingly engaged within the housing. In some embodiments, the mounting unit 214, also referred to as a housing or sensor pod, includes a base 234 adapted to fasten to the skin of a host or user. The base 234 can be formed from a variety of rigid or flexible materials and can include a low profile to minimize protrusion of the device from the host during use. In some embodiments, the base 234 is at least partially formed from a flexible material, which can provide numerous advantages over other transcutaneous sensors that, unfortunately, can suffer from motion-related artifacts associated with host movement when the host is using the device. The mounting unit 214 and / or sensor electronics module 12 may be positioned over the sensor insertion site to protect the site and / or provide a minimal footprint (utilization of the surface area of the host's skin).

[0116] In some embodiments, a removable connection between the mounting unit 214 and the sensor electronics module 12 is provided, which allows for improved manufacturability; i.e., the potentially relatively inexpensive mounting unit 214 can be discarded when upgrading or maintaining the analyte sensor system 8, while the relatively expensive sensor electronics module 12 can be reused with multiple sensor systems. In some embodiments, the sensor electronics module 12 is configured with signal processing (programming) configured to, for example, filter, calibrate, and / or execute other algorithms useful for calibrating and / or displaying sensor information. However, an integrated (non-removable) sensor electronics module can be configured.

[0117] In some embodiments, the contacts 238 are mounted on or within a subassembly, hereinafter referred to as the contact subassembly 236, configured to fit within the base 234 of the mounting unit 214 and a hinge 248 that allows the contact subassembly 236 to pivot relative to the mounting unit 214 between a first position (insertion) and a second position (use). The term "hinge," as used herein, is a broad term and includes reference to any of a variety of pivots, articulations, and / or hinging mechanisms, such as, but not limited to, adhesive hinges, sliding joints, and the like; the term hinge does not necessarily imply a fulcrum or fixed point about which articulation occurs. In some embodiments, the contacts 238 are formed from a conductive elastomeric material, such as a carbon black elastomer, through which the sensor 10 extends.

[0118] 2A and 2B, in certain embodiments, the mounting unit 214 includes an adhesive pad 208 disposed on the rear surface of the mounting unit and including a releasable backing layer. Thus, the backing layer can be removed and at least a portion of the base 234 of the mounting unit 214 pressed against the host's skin to adhere the mounting unit 214 to the host's skin. Additionally or alternatively, an adhesive pad can be placed over some or all of the sensor system 8 and / or 10 after sensor insertion is complete to ensure adhesion and, optionally, an airtight or watertight seal around the wound exit site (or sensor insertion site) (not shown). A suitable adhesive pad can be selected and designed to stretch, expand, conform, and / or ventilate the area (e.g., the host's skin). The embodiments described with reference to FIGS. 2A and 2B are described in more detail with reference to U.S. Pat. No. 7,310,544, the entire contents of which are incorporated herein by reference. The configuration and arrangement can provide water-resistant, waterproof, and / or sealed properties associated with the mounting unit / sensor electronics module embodiments described herein.

[0119] Various methods and devices suitable for use in conjunction with aspects of some embodiments are disclosed in U.S. Patent Application Publication No. 2009 / 0240120-A1, which is hereby incorporated by reference in its entirety for all purposes.

[0120] Exemplary Configurations Referring again to FIG. 1A , system 100 is depicted that can be used in connection with implementing aspects of an analyte sensor system. In some instances, system 100 can be used to implement various systems described herein. System 100 of an embodiment includes an analyte sensor system 8 and display devices 110, 120, 130, and 140, according to certain aspects of the present disclosure. Analyte sensor system 8, in the illustrated embodiment, includes a sensor electronics module 12 and a continuous analyte sensor 10 associated with sensor electronics module 12. Sensor electronics module 12 can wirelessly communicate (e.g., directly or indirectly) with one or more of display devices 110, 120, 130, and 140. In an embodiment, system 100 also includes a medical device 136 and a server system 134. Sensor electronics module 12 can also wirelessly communicate (e.g., directly or indirectly) with medical device 136 and server system 134. In some examples, the display devices 110 - 140 may also communicate wirelessly with the server system 134 and / or the medical device 136 .

[0121] In certain embodiments, the sensor electronics module 12 includes electronic circuitry associated with measuring and processing continuous analyte sensor data, including predictive algorithms associated with processing and calibrating the sensor data. The sensor electronics module 12 can be physically connected to the continuous analyte sensor 10 and can be integral with (non-releasably attached thereto) or releasably attached thereto. The sensor electronics module 12 can include hardware, firmware, and / or software that enable measurement of analyte levels via a glucose sensor. For example, the sensor electronics module 12 can include a potentiostat, a power supply for powering the sensor, other components useful for signal processing and data storage, and a telemetry module for transmitting data from the sensor electronics module to one or more display devices. The electronics can be affixed to a printed circuit board (PCB) or the like and can take a variety of forms. For example, the electronics can take the form of an integrated circuit (IC), such as an application-specific integrated circuit (ASIC), a microcontroller, and / or a processor.

[0122] Sensor electronics module 12 may include sensor electronics configured to process sensor information, such as sensor data, and generate transformed sensor data and displayable sensor information. Examples of systems and methods for processing sensor analyte data are described in further detail herein, as well as in U.S. Pat. Nos. 7,310,544 and 6,931,327, and U.S. Patent Application Publication Nos. 2005 / 0043598, 2007 / 0032706, 2007 / 0016381, 2008 / 0033254, 2005 / 0203360, 2005 / 0154271, 2005 / 0192557, 2006 / 0222566, 2007 / 0203966, and 2007 / 0208245, all of which are incorporated by reference in their entirety for all purposes.

[0123] 1A , display devices 110, 120, 130, and / or 140 are configured to display (and / or alarm) displayable sensor information that may be transmitted by sensor electronics module 12 (e.g., in customized data packages transmitted to the display devices based on respective preferences). Each of display devices 110, 120, 130, or 140 may include a display, such as touchscreen display 112, 122, 132, / or 142, for displaying sensor information and / or analyte data to a user and / or receiving input from a user. For example, a graphical user interface may be presented to the user for such purposes. In some implementations, the display device may include other types of user interfaces, such as a voice user interface, instead of or in addition to a touchscreen display, for communicating sensor information to a user of the display device and / or receiving user input. In some embodiments, one, some, or all of the display devices can be configured to display or otherwise communicate sensor information as it is communicated from the sensor electronics module (e.g., in a data package transmitted to the respective display device) without any additional predictive processing required for calibration and real-time display of the sensor information.

[0124] It should be noted that in some cases, using wired or wireless RF telemetry to communicate with sensors and user devices can be complicated, particularly with respect to damage, infection, and electrical noise. In some cases, the body's electrical conductivity can be used to enable wireless communication with implanted devices. Such methods include, for example, capacitive body-to-body communication, which enables surface-based communication between a transmitter and a receiver placed on or near the skin. Electrical body-to-body communication, which has the particular advantage of low power requirements, can also be employed. In one specific implementation, galvanic coupling can be employed to transmit signals from an implanted device to electrodes on the skin. Galvanic coupling can also be employed to communicate between devices attached to the skin.

[0125] Returning to the description of FIG. 1A , medical device 136 may be a passive device in an exemplary embodiment of the present disclosure. For example, medical device 136 may be an insulin pump for administering insulin to a user, as shown in FIG. 1B . For various reasons, it may be desirable for such an insulin pump to receive and track glucose values transmitted from analyte sensor system 8. One reason is to provide the insulin pump with the ability to stop or activate insulin administration when the glucose value falls below a threshold. One solution for allowing a passive device (e.g., medical device 136) to receive analyte data (e.g., glucose values) without being coupled to analyte sensor system 8 is to include the analyte data in an advertising message transmitted from analyte sensor system 8. The data included in the advertising message may be encoded such that only a device having an identity associated with analyte sensor system 8 can decode the analyte data. In some embodiments, the medical device 136 includes a sensor device 136b that is attachable or wearable, for example, by a user, in wired or wireless communication with a dedicated monitor or display device 136a to process sensor data and / or display data from the sensor device 136b and / or receive input for the operation of the sensor device and / or data processing.

[0126] 1A , the plurality of display devices can include custom display devices specifically designed to display particular types of displayable sensor information (e.g., in some embodiments, numbers and arrows) associated with analyte values received from sensor electronics module 12. Analyte display device 110 is an example of such a custom device. In some embodiments, one of the plurality of display devices is a smartphone, such as a mobile phone 120 based on an Android, iOS, or other operating system, and is configured to display a graphical representation of continuous sensor data (e.g., including current and historical data). Other display devices can include other handheld devices, such as a tablet 130, a smartwatch 140, a medical device 136 (e.g., an insulin delivery device or a blood glucose meter), and / or a desktop or laptop computer.

[0127] Because different display devices provide different user interfaces, the contents of the data package (e.g., the amount, format, and / or type of data displayed, alarms, and the like) can be customized (e.g., programmed differently by the manufacturer and / or by the end user) for each particular display device. Thus, in the embodiment of FIG. 1A, multiple different display devices can wirelessly communicate directly with the sensor electronics module (e.g., the on-skin sensor electronics module 12 physically connected to the continuous analyte sensor 10) during a sensor session to enable multiple different types and / or levels of displays and / or functionality associated with displayable sensor information, as described in more detail elsewhere herein.

[0128] 1A , system 100 may also include a wireless access point (WAP) 138, which may be used to couple to one or more of analyte sensor system 8, the plurality of display devices, server system 134, and medical device 136. For example, WAP 138 may provide Wi-Fi and / or cellular connectivity within system 100. Near field communication (NFC) may also be used between devices in system 100. Server system 134 may be used to collect analyte data from analyte sensor system 8 and / or the plurality of display devices, for example, to analyze the analyte data, generate generic or personalized models for blood glucose levels and profiles, etc.

[0129] Referring now to Figure 3A, a system 300 is depicted. System 300 may be used in connection with implementing embodiments of the disclosed systems, methods, and devices. By way of example, the various underlying components of Figure 3A may be used to provide wireless communication of glucose data between an analyte sensor system, such as that shown in Figure 1A, and multiple display devices, medical devices, servers, etc.

[0130] 3A, system 300 can include an analyte sensor system 308 and one or more display devices 310. Additionally, in the illustrated embodiment, system 300 includes a server system 334, which in turn includes a server 334a coupled to a processor 334c and a storage device 334b. Analyte sensor system 308 can be coupled to display device 310 and / or server system 334 via a communication medium 305.

[0131] As described in detail herein below, the analyte sensor system 308 and the display device 310 can exchange messaging via a communication medium 305, which can also be used to deliver analyte data to the display device 310 and / or the server system 334. As alluded to above, the display device 310 can include various electronic computing devices, such as, for example, smartphones, tablets, laptops, wearable devices, and the like. The display device 310 can also include the analyte display device 110 and the medical device 136. It will be noted here that the GUI of the display device 310 can perform functions upon receiving user input and display menus as well as information derived from the analyte data. The GUI can be provided by various operating systems known in the art, such as, for example, iOS, Android, Windows Mobile, Windows, Mac OS, Chrome OS, Linux, Unix, and gaming platform operating systems (e.g., Xbox, PlayStation, Wii). In various embodiments, the communication medium 305 may be based on one or more wireless communication protocols such as Bluetooth®, Bluetooth® Low Energy (BLE), ZigBee, Wi-Fi, 802.11 protocols, infrared (IR), radio frequency (RF), 2G, 3G, 4G, etc., and / or wired protocols and media.

[0132] In various embodiments, elements of system 300 can be used to perform the various processes described herein and / or to perform the various operations described herein with respect to one or more of the disclosed systems and methods. Upon studying this disclosure, one skilled in the art will recognize that system 300 can include multiple analyte sensor systems, communication media 305, and / or server system 334.

[0133] As mentioned above, the communication medium 305 can be used to connect or communicatively couple the analyte sensor system 308, the display device 310, and / or the server system 334 to one another or to a network, and the communication medium 305 can be implemented in various forms. For example, the communication medium 305 can include an Internet connection, such as a local area network (LAN), a wide area network (WAN), an optical fiber network, the Internet over power lines, a hardwired connection (e.g., a bus), and the like, or any other type of network connection. The communication medium 305 can be implemented using any combination of routers, cables, modems, switches, optical fibers, wires, wireless (e.g., microwave / RF links), and the like. Furthermore, the communication medium 305 can be implemented using various wireless standards, such as Bluetooth®, BLE, Wi-Fi, 3GPP® standards (e.g., 2G GSM® / GPRS / EDGE, 3G UMTS / CDMA2000, or 4G LTE / LTE-U), etc. After reading this disclosure, one of ordinary skill in the art will recognize other ways to implement the communication medium 305 for communication purposes.

[0134] Server 334a may receive, collect, or monitor information, including analyte data and related information, from analyte sensor system 308 and / or display device 310, such as input responsive to analyte data or input received in connection with an analyte monitoring application operating on analyte sensor system or display device 310. In such cases, server 334a may be configured to receive such information via communication medium 305. This information may be stored in storage device 334b and processed by processor 334c. For example, processor 334c may include an analysis engine that may perform analysis of information collected, received, or otherwise processed by server 334a via communication medium 305. In embodiments, server 334a, storage device 334b, and / or processor 334c may be implemented as a distributed computing network, such as a Hadoop® network, or as a relational database or the like.

[0135] The server 334a can include, for example, an internet server, a router, a desktop or laptop computer, a smartphone, a tablet, a processor, a module, or the like, and can be implemented in various forms, including, for example, an integrated circuit or assembly thereof, a printed circuit board or assembly thereof, or in a separate enclosure / package / rack, or a combination thereof. In an embodiment, the server 334a is at least partially responsible for communications occurring over the communication medium 305. Such communications include delivery and / or messaging (e.g., advertisements, commands, or other messaging) and analyte data. For example, the server 334a can process and exchange messages related to frequency bands, timing of transmissions, security, alarms, and the like between the analyte sensor system 308 and the display device 310. The server 334a can update information stored in the analyte sensor system 308 and / or the display device 310, for example, by delivering applications thereto. The server 334a can send / receive information to / from the analyte sensor system 308 and / or the display device 310 in real time or sporadically. Additionally, the server 334a may implement cloud computing capabilities for the analyte sensor system 308 and / or the display device 310.

[0136] FIG. 3B depicts a system 302, including examples of additional aspects of the present disclosure that can be used in connection to implement an analyte sensor system. As illustrated, system 302 can include an analyte sensor system 308. As shown, analyte sensor system 308 can include an analyte sensor 375 (e.g., which may be designated by the numeral 10 in FIG. 1A ) coupled to a sensor measurement circuit 370 for processing and managing sensor data. Sensor measurement circuit 370 can be coupled to a processor / microprocessor 380 (e.g., which may be part of item 12 in FIG. 1A ). In some embodiments, processor 380 can perform some or all of the functions of sensor measurement circuit 370 for obtaining and processing sensor measurements from sensor 375. Processor 380 can further be coupled to a wireless unit or transceiver 320 (e.g., which may be part of item 12 in FIG. 1A ) for transmitting sensor data and for receiving requests and commands from an external device, such as a display device 310, which can be used to display or otherwise provide the sensor data (or analyte data) to a user. As used herein, the terms "wireless unit" and "transceiver" are used interchangeably and generally refer to a device capable of transmitting and receiving data wirelessly. The analyte sensor system 308 may further include a memory device 365 (which may be part of item 12 in FIG. 1A, for example) and a real-time clock (RTC) 380 (which may be part of item 12 in FIG. 1A, for example) for storing and tracking sensor data.

[0137] As alluded to above, a wireless communication protocol can be used to transmit and receive data between the analyte sensor system 308 and the display device 310 over the communication medium 305. Such a wireless protocol can be designed for use in a wireless network (e.g., a personal area network (PAN)) optimized for periodic, small-scale data transfers (which can be transmitted at lower speeds, if necessary) to a large number of devices over short distances. For example, one such protocol can be optimized for periodic data transfers, where the transceiver can be configured to transmit data for short intervals and then enter a low-power mode for longer intervals. The protocol can have low overhead requirements for both normal data transfers and initial setup of the communication channel to reduce power consumption (e.g., by reducing overhead). In some embodiments, a burst broadcasting scheme (e.g., one-way communication) can be used. This can eliminate the overhead required for acknowledgment signals and allow for periodic transmissions that consume little power.

[0138] The protocol can be further configured to establish communication channels with multiple devices while implementing an interference avoidance scheme. In some embodiments, the protocol can use an adaptive isochronous network topology that defines various time slots and frequency bands for communication with multiple devices. Thus, the protocol can modify transmission windows and frequencies in response to interference and to support communication with multiple devices. Thus, the wireless protocol can use a scheme based on time and frequency division multiplexing (TDMA). The wireless protocol may also use direct sequence spread spectrum (DSSS) and frequency-hopping spread spectrum techniques. Various network topologies can be used to support short-range and / or low-power wireless communications, such as peer-to-peer, start, tree, or mesh network topologies, such as Wi-Fi, Bluetooth, and Bluetooth Low Energy (BLE). The wireless protocol can operate in various frequency bands, such as the open ISM band, such as 2.4 GHz. Furthermore, to reduce power usage, the wireless protocol can adaptively configure data rates according to power consumption.

[0139] With further reference to FIG. 3B , the system 302 may include a display device 310 communicatively coupled to the analyte sensor system 308 via a communication medium 305. In the illustrated embodiment, the display device 310 includes a connectivity interface 315 (which in turn includes a transceiver 320), a memory device 325 (which in turn stores the analyte sensor application 330 and / or additional applications), a processor / microprocessor 335, a graphical user interface (GUI) 340 that can be presented using a display 345 of the display device 310, and a real-time clock (RTC) 350. A bus (not shown) may be used to interconnect the various elements of the display device 310 and transfer data between these elements. Wireless communication between elements, such as wireless communication between the display device 310 and the analyte sensor 308, may also be employed. In certain embodiments, NFC may be employed as such a wireless communication scheme. Further details of communication techniques between the sensor electronics and the receiver or display device are described below in conjunction with FIG. 4 et seq.

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

[0141] In some embodiments, when a standardized communication protocol is used, commercially available transceiver circuitry can be utilized that incorporates processing circuitry to handle low-level data communication functions such as managing data encoding, transmission frequency, handshaking protocols, and the like. In these embodiments, the processor 335, 380 need not manage these activities, but rather provides the desired data values for transmission and also manages higher-level functions such as raising or lowering power, setting the rate at which messages are transmitted, and the like. Instructions and data values for performing these high-level functions can be provided to the transceiver circuitry via a data bus and transfer protocol established by the manufacturer of the transceiver 320, 360.

[0142] Components of the analyte sensor system 308 may require periodic replacement. For example, the analyte sensor system 308 may include an implantable sensor 375 that can be attached to a sensor electronics module, which includes a sensor measurement circuit 370, a processor 380, a memory device 365, a transceiver 360, and a battery (not shown). The sensor 375 may require periodic replacement (e.g., every 7-30 days). The sensor electronics module can be configured to power and operate for a much longer period of time than the sensor 375 (e.g., 3-6 months or longer) before the battery needs to be replaced. Replacing these components can be difficult and may require the assistance of trained personnel. Reducing the need to replace such components, particularly the battery, significantly improves the convenience and cost of using the analyte sensor system 308, including for the user. In some embodiments, the sensor electronics module can connect to the sensor 375 and establish a sensor session upon first use (or, in some cases, upon restarting after a battery replacement). As described further below, when the module is used for the first time or restarted (e.g., after a battery change), there may initially be a process to establish communication between the display device 310 and the sensor electronics module. Once the display device 310 and the sensor electronics module have established communication, they may communicate periodically and / or continuously throughout the life of the sensors 375, until, for example, the battery needs to be changed. A new sensor session may be established each time a sensor 375 is changed. A new sensor session may be initiated through a process completed using the display device 310, which may be triggered by notification of a new sensor via communication between the sensor electronics module and the display device 310, which may persist for the entire sensor session.

[0143] The analyte sensor system 308 typically collects analyte data from the sensor 375 and transmits it to the display device 310. Data points regarding the analyte value can be collected and transmitted throughout the life of the sensor 375 (e.g., ranging from 1 to 30 days or more). New measurements can often be transmitted sufficiently to adequately monitor blood glucose levels. Rather than having the transmitting and receiving circuitry of each of the analyte sensor system 308 and the display device 310 communicate continuously, the analyte sensor system 308 and the display device 310 can regularly and / or periodically establish a communication channel between them. Thus, the analyte sensor system 308 can, in some cases, communicate via wireless transmission with the display device 310 (e.g., a handheld computing device, a medical device, or a dedicated device) at predetermined time intervals. The duration of the predetermined time interval can be selected to be long enough so that the analyte sensor system 308 does not consume excessive power by transmitting data more frequently than necessary, yet frequent enough to provide substantially real-time sensor information (e.g., measured glucose values or analyte data) to the display device 310 for output to the user (e.g., via the display 345). In some embodiments, the predetermined time interval is every 5 minutes, although it will be appreciated that this time interval can be varied to be any desired time.

[0144] 3B , as shown, connectivity interface 315 interfaces display device 310 to communication medium 305, such that display device 310 can be communicatively coupled to analyte sensor system 308 via communication medium 305. Transceiver 320 of connectivity interface 315 can include multiple transceiver modules capable of operating with different wireless standards. Transceiver 320 can be used to receive analyte data and associated commands and messages from analyte sensor system 308. Additionally, connectivity interface 315, in some cases, can include additional components for controlling wireless and / or wired connections, such as baseband and / or Ethernet modems, audio / video codecs, and others.

[0145] The storage device 325 can include volatile memory (e.g., RAM) and / or non-volatile memory (e.g., flash storage), and can include any of EPROM, EEPROM, cache, or some combination / variation thereof. In various embodiments, the storage device 325 can store user input data and / or other data collected by the display device 310 (e.g., input from other users collected via the analyte sensor application 330). The storage device 325 can also be used to store large amounts of analyte data received from the analyte sensor system 308 for later retrieval and use, for example, to determine trends and trigger alerts. In addition, as described in more detail herein below, the storage device 325 can store the analyte sensor application 330, which, when executed using the processor 335, can, for example, receive input (e.g., via conventional hard / soft keys or a touch screen, voice detection, or other input mechanisms) and allow a user to interact with the analyte data and associated content via the GUI 340.

[0146] In various embodiments, a user can interact with the analyte sensor application 330 via a GUI 340, which can be provided by a display 345 of the display device 310. As an example, the display 345 can be a touchscreen display that accepts various hand gestures as input. The application 330 can process and / or present analyte-related data received by the display device 310 and present such data via the display 345 according to various operations described herein. Additionally, the application 330 can be used to obtain, access, display, control, and / or interface with analyte data and related messaging and processes associated with the analyte sensor system 308, as described in further detail herein.

[0147] The application 330 can be downloaded, installed, and initially configured / set up on the display device 310. For example, the display device 310 can obtain the application 330 from the server system 334 or from another source accessed through a communication medium (e.g., the communication medium 305), such as an application store or the like. Following installation and configuration, the application 330 can be used to access and / or interface with analyte data (e.g., whether stored on the server system 334, stored locally from the storage device 325, or stored from the analyte sensor system 308). Illustratively, the application 330 can present a menu including various controls or commands that can be executed in connection with the operation of the analyte sensor system 308 and one or more display devices 310. The application 330 may also be used to interface with or control other display devices 310, e.g., to distribute or make available analyte data, including, e.g., by receiving / transmitting analyte data directly to the other display devices 310 and / or by transmitting instructions to the analyte sensor system 308 and other display devices 310 to be connected, as described herein. In some implementations, the application 330 may interact with other application(s) on the display device to retrieve or provide related data, e.g., other health data.

[0148] The analyte sensor application 330 can include various code / functional modules, such as a display module, a menu module, a list module, and the like, as will become apparent in light of the description of various functions herein (e.g., in relation to the disclosed methods). These modules can be implemented separately or in combination. Each module can include a computer-readable medium and can have computer-executable code stored thereon, such that the code is operatively coupled to and / or executed by the processor 335 (e.g., which can include circuitry for such execution) to perform a particular function (e.g., as described herein with respect to various operations and flowcharts) related to interfacing with analyte data and performing tasks related thereto. As described further below, the display module can present various screens to the user (e.g., via the display 345), which include graphical representations of information provided by the application 330. In further embodiments, the application 330 can be used to display to the user various display devices that may be connectable to the analyte sensor system 308, as well as an environment for viewing and interacting with the analyte sensor system 308 itself. The sensor application 330 may include a native application modified by a software design kit (eg, operating system dependent) to perform the functions / features described herein.

[0149] 3B , the display device 310 also includes a processor 335. The processor 335 can include processor sub-modules, including, by way of example, an application processor that interfaces with and / or controls other elements of the display device 310 (e.g., the connectivity interface 315, the applications 330, the GUI 340, the display 345, the RTC 350, etc.). The processor 335 can include a controller and / or microcontroller that provides various controls (e.g., interfaces with buttons and switches) related to device management, such as, for example, a list of available or previously paired devices, information related to measurements, information related to network conditions (e.g., link quality, and the like), information related to the timing, type, and / or structure of messaging exchanged between the analyte sensor system 308 and the display device 310, etc. Additionally, the controller can include various controls related to user input, such as a user fingerprint (e.g., for granting user access to data or for use in authorizing / encrypting data including analyte data), as well as the collection of analyte data.

[0150] The processor 335 may include circuitry such as logic for peripheral and audio components, memory, battery and power circuits, and other circuit drivers. The processor 335 and any sub-processors may include logic for receiving, processing, and / or storing data received and / or input to the display device 310, as well as data transmitted or delivered by the display device 310. The processor 335 may be coupled to the display 345, as well as to the connectivity interface 315 and the storage device 325 (including the application 330) by a bus. Thus, the processor 335 receives and processes electrical signals generated by these respective elements and thus can perform various functions. As an example, the processor 335 may access stored content from the storage device 325 at the direction of the application 330, process the stored content, and display and / or output it via the display 345. Additionally, the processor 335 may process and transmit the stored content to other display devices 310, the analyte sensor system 308, or the server system 334 via the connectivity interface 315 and the communication medium 305. Display device 310 may include other peripheral components not shown in detail in FIG. 3B.

[0151] In further embodiments, processor 335 may further acquire, detect, calculate, and / or store data input by a user via display 345 or GUI 340 or data received from analyte sensor system 308 (e.g., analyte sensor data or associated messaging) over a period of time. Processor 335 may use this input to measure the user's physical and / or mental response to the data and / or other factors (e.g., time of day, location, etc.). In various embodiments, as described in further detail herein below, the user's response or other factors may indicate preferences regarding the use of a particular display device 310 under particular circumstances and / or the use of a particular connection / transmission scheme under various conditions.

[0152] At this point, it should be noted that like-named elements between the display device 310 and the analyte sensor system 308 may include the same features, structures, and / or capabilities. Thus, with respect to such elements, the description of the display device 310 above may, in some instances, be applicable to the analyte sensor system 308.

[0153] Enabling HCPs to monitor and collect patient diabetes information, while simultaneously assisting patients in managing their disease, can be challenging due to a lack of user-friendly and cost-effective products (for both HCPs and patients). Even when such devices are provided, significant HCP involvement in their setup is generally desirable, especially for patients unfamiliar with such procedures. These goals are complicated by the proliferation of user mobile devices, which offer significant user / patient convenience, but make it difficult for HCPs to become familiar with all such products and all such applications installed on such devices.

[0154] In one implementation, referring to the system 400 in FIG. 4 , which is intended to illustrate the placement of equipment in an HCP office, a low-cost, programmable, and easy-to-use product, referred to herein as a “professional product” 402, may be provided. This product is then provided on loan to the patient, who can return it at the end of the sensor session. The professional product 402 may include functionality similar to other mobile devices, such as a smartphone, and may include the ability to communicate with the transmitter 404 via an appropriate communication protocol. The professional product 402 provided to the HCP will be familiar to the HCP, so the HCP does not need to learn an entirely new device. In one implementation, the professional product 402 may also be embodied by an HCP device, such as an HCP computer 406 running an HCP application 429 or a mobile device (e.g., a smartphone) configured to run an HCP application. In this implementation, patients are not provided with a device to provide data display during their session, or they use their smartphone, such as when appropriate communications are enabled (see below). In some examples, the HCP device / HCP smartphone or HCP specialty product can be a locked-down smartphone (e.g., a dedicated smartphone) provided to the HCP by a diabetes management / medical device company and operated by the HCP or one or more personnel in the HCP's office. In such examples, the HCP device can have a dedicated application pre-installed on the HCP device that can be operated by the HCP to perform specific operations, such as performing transmitter and / or sensor validation, user or patient account setup, downloading data from a transmitter, etc., as described herein. Alternatively, the HCP can download the dedicated application from a server. The application can provide guidance to the HCP on how to operate the HCP device to perform operations (e.g., user / patient account setup, sensor and / or transmitter validation, downloading data from a transmitter, etc.).As further described herein, the HCP device may be equipped with NFC and BLE wireless technologies to perform operations.

[0155] While any desired wireless method may be employed to enable communication between the transmitter and the specialty product 402, it may be convenient to employ technologies such as Near Field Communication (NFC), Bluetooth®, including Bluetooth® Low Energy (BLE), etc. However, it will be appreciated that other modes of communication are possible, including the use of cellular technology, Wi-Fi technology, etc., so long as appropriate security measures are taken for secure communication, including encryption.

[0156] If a separate specialty product mobile device is employed, the HCP device 406 may employ one or more devices that enable communication with the specialty product 402, such as a reader 420, which may possibly be embodied in a dongle 426. Because technologies like NFC require particular proximity between the reader and the specialty product, a target 422 may be displayed on the reader 420 to indicate the location of the antenna. A similar target may be placed on the specialty product 402, or if the HCP uses their smartphone or other mobile device, the HCP may know, or become aware of, where the NFC antenna is located. Furthermore, in some implementations, the dongle or reader may include both NFC and BLE radios.

[0157] For example, using such a reader 420 instead of an HCP smartphone offers various advantages: it is generally lower cost, does not require charging because it is wired to the HCP device, and can have a larger coil for NFC pairing. It is often preferred by HCPs as a device that is less likely to be lost, has a longer lifespan, is conveniently configurable to provide confirmation of sensor functionality, and does not require a separate pairing action because it is wired to the HCP device.

[0158] The use of an HCP reader can also provide other advantages: for example, if the user-patient lacks a smartphone or otherwise lacks a smartphone compatible with the analyte monitoring system, the HCP reader 420 or HCP user device 402 can be employed to configure the transmitter 404 to initiate or activate the patient's device, as well as to download data from the user's device at the end of a session.

[0159] The HCP device 406 or HCP user device 402 can access an HCP portal 429, which can be a web application, in this case generally a portal in communication with a server where the user has a user account related to their disease management. The HCP device 406 or HCP user device 402 can also execute a standalone application (HCP application) in network communication with a server that communicates with the user's mobile phone and / or transmitter 404. The term "HCP application" is used herein to describe both the HCP portal, which can be a web application, as well as standalone applications.

[0160] The HCP application may be used to enter data into fields for setting up a user account and may further be employed for diagnostic functions, including verifying that a sensor is operational, e.g., that the sensor and transmitter are delivering counts to a professional product (e.g., HCP professional product 402) or other device, or that the sensor and transmitter are receiving a predetermined number of counts over a predetermined period of time. Details of such functions are provided below. The HCP application may further verify that the sensor is operational, e.g., within minutes of application to the patient, via a visual indicator and / or an audible beep on the application. The HCP application may also be employed to extract data from the sensor. For example, the HCP application may interface with an HCP device (e.g., HCP professional product 402) or HCP reader to pair with the sensor / transmitter and extract data within seconds or minutes. A visual indicator and / or an audible beep may be provided upon completion of data transfer. The HCP application may then upload the data to a server and provide an indication that the data upload was successful. As an additional function, the HCP application may cause patient data to be deleted from the transmitter once it is securely stored on the HCP device or server. The HCP application can store data for multiple patients at a time. In some cases, the HCP application may incorporate limited patient data viewing capabilities, and its primary purpose may be to collect data, upload it, and delete it after upload. The HCP application may have various main icons or pages for account setup, sensor operation verification, data extraction, and patient data status listing.

[0161] The transmitter 404 has been described above, but for purposes of this discussion, it should be noted that the same generally includes a processor 408 and memory (or other storage) 410. The transmitter 404 includes circuitry 412 configured to couple to the sensor wires. The circuitry 412 generally includes contacts that electrically couple to the two wires that form the sensor when the transmitter is inserted into the sensor housing. In one implementation, these two wires are coaxial; in another, they are side-by-side. The transmitter further includes communication circuitry 414 through which the transmitter can communicate with other devices, including, for example, the HCP device 406, the professional product 402, or other user devices such as a personal smartphone. The transmitter circuitry 414 may include equipment such as circuitry or an antenna 416 for NFC communication and circuitry or an antenna 418 for BLE communication. It will be understood that circuitry, including antennas, may be provided for other communication modes, both wired and wireless, as well.

[0162] The system 450 of FIG. 5 shows another view of the equipment, including the communication pathways, typically found in an HCP office. This view also shows other devices that may be employed in the system, including a patient's personal device 434, such as a smartphone. FIG. 5 shows a transmitter 404 in communication with an indwelling sensor 436 within the patient and flexible electronics 438. The flexible electronics can be provided, for example, as a sticker provided within (or with) the sensor and / or transmitter packaging, which can be conveniently used to provide an identification element for the transmitter. Such an identification element can include a sensor ID or can also include additional manufacturing information. The flexible electronics 438 can be scanned by the reader 420 and / or the specialty product 402 or patient device 434 so that the transmitter identification for that session can be associated with the patient's user account. It will be appreciated that other implementations can employ passive codes, such as barcodes, QR codes, etc., that can then be read by the reader 420 and / or the specialty product 402 or patient device 434.

[0163] Flexible electronics 438 may be conveniently employed to simplify the transmitter pairing process, for example, with a specialty product or patient device, for example, via a wireless link such as NFC or BLE, as described in more detail below.

[0164] If the flexible electronics are provided as a sticker, the transmitter pairing ID may be pre-programmed with the transmitter package, located in or on the transmitter package. Upon receipt, the patient can touch or tap their receiver or phone to the package, and the transmitter pairing ID is read and automatically entered into the pairing device. This may also enable background capture of patient data, including, for example, the date of transmitter activation. A similar concept can be implemented within the context of sensor patches. For example, each patch can include NFC electronics and be pre-populated with information such as lot or expiration date. Upon insertion into the housing, the transmitter can verify that the sensor is within a “safe-to-use” window and transmit this information to the cloud, for example, via one of the connected devices, such as the reader 420, the specialty product 402, the patient device 434, or even the HCP device 406. Such information allows technical support functions to access the information to streamline troubleshooting and monitor field failures by lot for use in process optimization.

[0165] The HCP device 406 may include, for example, a laptop or desktop computer used by the HCP for patient care, but may also include a mobile device used by the HCP for such purposes. Generally, the HCP device 406 may include some method of communicating with the transmitter 404.

[0166] The HCP reader device 420 may include various circuits 442-446 to enable communication with various types of devices, and more particularly, devices employing various types of communication schemes. For example, a first circuit may be a wireless USB circuit, a second circuit may be an NFC circuit, and a third circuit may be a BLE circuit.

[0167] FIG. 5 also shows an HCP beacon / proximity device 440 positioned to communicate with various devices. The device 440 can include a wireless device located in a fixed location, such as an HCP office, and broadcasting a fixed piece of data via BLE. When a patient arrives at the HCP office for a review, such as a CGM 14-day review, the transmitter 404, professional product 402, or patient device 434 can detect this beacon signal and trigger an automatic download of the accumulated stored analyte concentration data for access by the HCP via the HCP application 429. The HCP application 429 may also be included in the HCP professional device 402. In such a scenario, if necessary, the HCP beacon 40 can be paired with the transmitter during an initial setup phase. Furthermore, to initiate the download, the beacon device 440 may also need to be in communication with the HCP device 406 (or 402) and can provide a notification to this device when it detects that the transmitter has returned to the HCP office. 6 is a flowchart 500 illustrating an overall manner in which implementation of the present arrangement can be situated. This diagram provides an overview of what will be described in more detail throughout the remainder of this specification and with reference to elements of FIG.

[0168] In a first step, a sensor / transmitter is provided to the patient / user (step 452). Such are typically provided as kits, and often the transmitter is reusable, and therefore only the sensor is provided. However, as noted above, a flexible electronic circuit can be provided, such as by a sticker, to provide easily readable identification information about the sensor or transmitter, or both. Such information can also be provided as part of a barcode, QR code, or the like.

[0169] In the next step, if the user is unfamiliar with the setup, the HCP can configure the transmitter and also set up or enable a connection between the transmitter and a specialty product or a smartphone if the user wishes to use one (step 454). Details of this configuration are provided below in connection with Figures 4-20 and the accompanying text.

[0170] If the transmitter is currently in an inactive or "sleep" state, the transmitter is then "woke up" or otherwise transitioned from an inactive state to an active state (step 456). This step is optional, but is common because transmitters are often shipped in an inactive state to conserve battery power. Details of how to wake up or activate a transmitter are described below in connection with Figures 4-20, 28-31, and 33-36 and the accompanying text.

[0171] The patient then uses the device during a sensor session (step 458). The sensor session may be, for example, 7 days, 14 days, or as otherwise defined by the HCP. After the expiration of this period, the transmitter may be transitioned to an inactive state. The transmitter may be so triggered via expiration of the period, removal from the sensor housing, removal of the entire sensor patch from the patient, and other triggers.

[0172] At the next HCP visit, the patient returns (step 460), and the HCP can take action to "wake up" the transmitter if it transitions to an inactive state (step 462). The HCP can then download or extract sensor data from the transmitter (step 464). In some cases, the data can be transmitted intermittently or continuously to a server, or to a specialty product or user device, depending on the nature of the configuration.

[0173] Details of each of these above steps are described throughout the remainder of this specification.

[0174] First, the HCP setup steps are described.

[0175] Referring to flowchart 550 of FIG. 7, in the first step, a communication session is established between the HCP device and the server (step 472). This can be done in the typical manner where the HCP provides a username and password, as well as additional identifying information in some implementations. The HCP can then enter patient information on the HCP device (step 474) or via a specialist device. In some cases, especially if a new transmitter is being used, the HCP can enter transmitter data on the HCP device (step 482). This step can be employed, for example, using flexible electronic circuits, bar codes, QR codes, etc., as described above.

[0176] The data can then be communicated from the HCP device to the user device (step 476). The user device can then transition to a given mode depending on the entered data (step 478).

[0177] In another implementation, the HCP can enter the patient data directly into the user's mobile device (step 480).

[0178] Returning to step 478, the specialty product may enter one or more different modes depending on the data entered. Such modes can be based on entries including, for example, disease type (step 484), the user's technical knowledge (step 486), and the mode of operation (step 488). For example, the specialty product may have different modes for T-1 and T-2 patients, which typically vary by user interface. The modes may also vary depending on the user's technical knowledge or proficiency. By programming the product according to the user's technical skill level or disease type (T-1 or T-2 or pre-diabetes), the HCP can be confident that the appropriate UI is presented to the user for the measured blood glucose value.

[0179] The mode may also vary depending on the mode of operation. As will be discussed in more detail below, it should be noted here that, in many cases, to avoid user actions “contaminating” the initial glucose concentration data, the HCP may want the user to start in blind mode (step 490) to discourage the user from taking actions that will recursively affect their glucose data. While such actions are ultimately desired, many HCPs first want to see “where the user is” with respect to glucose control, and blind mode is particularly useful for such endeavors. The mode may also be made non-blind in different implementations (step 492) so that the user can view and act on their current data. Again, such is generally desired after the user has gained an idea of their current level of glycemic control. In some cases, a combination mode may be useful if the user starts in blind mode, and upon the occurrence of a trigger event or expiration of a time period (step 494), the system is configured to switch to non-blind mode. For example, the HCP may want the user to spend seven days in blind mode and seven days in non-blind mode. Alternatively, once the user reaches a current level of glycemic control, the system may automatically switch to non-blind mode, e.g., to control their glucose concentration within a predetermined target range. In either case, such trigger and duration-based switching may be automatic, and the system may be configured to provide such functionality.

[0180] The patient then uses the sensor, transmitter, and specialty product (or their own smart device) for the duration of the sensor session (step 496). The transmitter stores several weeks of data. In some cases, data may be automatically uploaded from the specialty product or patient device to a server associated with the patient's medical care or, for example, an electronic medical record (EMR) (step 498).

[0181] However, in many cases, the patient must return to the HCP's office for data extraction and analysis (step 502). The data can generally be extracted in a very short period of time, e.g., less than 5 or 10 seconds. The data can generally be extracted using wired or wireless communication following some type of interrogation signal by the HCP device (step 504). As part of this procedure, the transmitter can be woken up from an inactive state. Details of such wake-up techniques are provided below.

[0182] As part of the initial setup by the HCP, or as part of the data extraction, or even as part of the sensor session, various diagnostic routines can be run by the HCP device to verify proper operation of the sensors and transmitters. In one implementation, referring back to FIG. 4, such can be run by a diagnostic application 428 on the HCP device. Additionally, the HCP can set up user accounts as part of the initial setup or during the data extraction interview.

[0183] As described above, patient-users can obtain products at the HCP's office, but often do not know how to obtain an account or set up the product. In one implementation, referring to flowchart 600 of FIG. 8 , the HCP sets up a user account and a product for the user. The patient enters the HCP's office, and the HCP provides a transmitter package, for example, as described above. Such products may use a transmitter, e.g., flexible electronics, or include a transmitter ID on the product box or other part, or a specialty product, if desired. The HCP initiates a communication session and queries for patient information, including, for example, name, date of birth, email address, etc., to enter into the HCP application (step 505). The HCP may seek verbal consent from the patient to enter or use the patient's email address.

[0184] The HCP then enters the patient information into an application or server portal, e.g., an HCP portal, which may be, for example, a web application that provides access to a server. The server is typically a cloud server and is often also the recipient of patient data upon the patient's return after a sensor session. The HCP application may also provide functionality including verifying sensor operation, extracting data, providing timestamp data to the transmitter, etc. Whether in the HCP application or the HCP portal, the data is sent to the server (step 507). In some cases, the entered data may indicate the mode in which the transmitter should be placed, and this mode may be propagated to the specialty product or the patient's smart device.

[0185] As part of the above steps, the HCP may input data identifying the transmitter (step 509), which may also be communicated via wired or wireless communication after the establishment of an appropriate pairing relationship and communication session.

[0186] More specifically, the HCP can manually enter transmitter information along with patient information. The entered transmitter information can include a transmitter ID. By entering such information, a user account can be tied to a specific transmitter. If the HCP does not want to enter such information or does not want to enter it manually, the same can be entered in the manner described above, for example, by using a flexible electronic circuit that is scanned by the HCP receiving device, a QR code, a barcode, or the like. The HCP application running on the HCP device can also receive the transmitter ID by other means and communicate with the transmitter during the setup phase, for example, via BLE or NFC. In either case, the HCP application can retrieve the transmitter ID, e.g., a serial number, and have it transmitted to the server.

[0187] On the server side, the transmitter is associated with a patient account (or an account is created) using the transmitter identification information (step 511). Once the account is created, the system generates a unique code or token for the patient, through which the patient can receive applications for their smart device or their specific specialty product. More specifically, the HCP can provide instructions, such as a document or displayable file, to the patient (step 513), which includes the code or token. The HCP can further provide instructions on how to download monitoring or other related applications. The code can be scanned (or manually entered), thereby establishing an association between the patient and the downloaded application. That is, the code can provide data such that, after being entered into the smart device or specialty product, the application is automatically associated with the patient without the patient having to enter additional data. In an alternative implementation, the HCP can trigger the sending of an invitation to an email address provided by the patient. It will be understood that such an invitation can also be sent via text message, etc. The patient can then use the code to download the application (step 515). The application may also be automatically associated with the patient account using the code (step 517). Alternatively, the application can be downloaded with a code that is entered after installation. Either way, the transmitter is linked to the user's account.

[0188] The HCP portal then links the patient information with the application the patient downloaded. The HCP portal can also automatically generate another account for the patient, for example, an account that can be used for future purchases of sensor and transmitter products, etc. The opening of this other account may include another email or text invitation to the patient.

[0189] Flowchart 650 in Figure 9 illustrates the process flow within the HCP office for various use cases, with various levels of user-provided technology. As can be seen from the flowchart, having a data extraction step, such as may be provided by an HCP reader or similar device, provides HCP reassurance of reimbursement regardless of the outcome of the scenario.

[0190] Instructions for performing the series of steps shown in the following flowcharts may be provided to the HCP on the HCP reader or other HCP device. In this manner, the HCP can be guided step-by-step through the setup process. The instructions may be incorporated into the HCP application described above or may be included in a separate, dedicated application. Furthermore, it should be noted that the HCP reader or other HCP device may include additional applications dedicated to tutorials on any of the various aspects of system use and installation, and possibly on ancillary aspects such as rebate assistance.

[0191] In the first step, the HCP provides the patient with a sensor and transmitter (step 506). If the patient does not have a phone (step 508), a sensor session can begin (step 522), and after the sensor session is complete, the HCP extracts data from the sensor using a data extractor to perform steps including setting up an account and verifying that the sensor is functional (step 524).

[0192] If it is determined that the patient has a phone (step 510), the phone is determined to be compatible with the other components of the system (step 514), and the phone can be properly paired with the transmitter (step 518), the sensor session can simply proceed (step 522). In some cases, the data can be automatically uploaded to a server (step 526), and the data can be reviewed by an HCP on the server (step 528).

[0193] If the patient does not have a smartphone (step 508), the sensor session can still occur by collecting data with the transmitter and then retrieving it. Similarly, even if the phone is not capable (step 512), the sensor session can still occur because data can still be collected by the transmitter even if it is not immediately transmitted to the user device. Even if the patient's phone cannot pair with the transmitter (step 516), such data can still be collected and then retrieved. Finally, even if pairing is successful but data cannot be transmitted from the patient device for some reason (step 520), the data can still be stored for later retrieval.

[0194] In any case, after the sensor session is completed, the patient can return the transmitter to the HCP office for data extraction (step 524). Figure 10 is a flowchart 700 illustrating a more complex method according to the present principles. In a first step, a patient considering, or advised to consider, a CGM can meet with an HCP, who can also perform various measurements (step 532), such as A1C and lab tests, to determine whether the patient is suitable for and would benefit from a CGM (step 534). To determine whether the patient can monitor data from a CGM, the HCP can inquire as to whether the patient has a compatible smart device, such as a smartwatch, smartphone, tablet, etc. (step 536). Compatibility may be determined manually, e.g., by comparing the device type, such as the model number, with a list of compatible devices. Alternatively, the HCP can perform a compatibility check, for example, by using a test signal that provides a displayed result when the compatibility test is successful (or failed). In some cases, the test signal may be generated by an HCP reader and transmitted to the user device via NFC or BLE. If the patient has a compatible device, the patient may attempt to download the monitoring application at the HCP office (step 538). The HCP may apply the sensor and transmitter to the patient (step 540). The HCP may then verify that the sensor and transmitter are operational, e.g., by using NFC with an HCP reader (step 542) to exchange data with the transmitter over a wireless communication link, which may be implemented, e.g., via NFC or BLE. Details of such verification are provided elsewhere. The HCP may then enter patient information and the HCP application or HCP server portal (step 544). As described above, this step may include sending an email invitation that the patient can use to download the monitoring application and / or set up a patient account.The HCP may also enter patient information via the HCP reader device.

[0195] The HCP can then print patient handouts from the server portal and retrieve the transmitter ID from the kit. The transmitter ID may be embodied by flexible electronics, a barcode, a QR code, etc., as described above (step 546). Patient handouts and a disposal bag may be provided to the patient, and the HCP may explain subsequent steps (step 548). The patient may complete the setup wizard at the office or at home (step 552). If at home, a check may be provided as to whether the patient has completed the setup wizard (step 554). If so, the system may determine whether a specific access mode was selected by the HCP (step 556). If the HCP has not selected a specific access mode, or if the patient has not completed the setup wizard at home, the system may default to baseline mode (step 566). In some cases, the baseline mode corresponds to a blind mode. If the patient has completed the setup wizard and the HCP has selected an access mode, the wear period may begin according to the access mode (step 558). For example, access modes can include modes such as blind, non-blind, combination (e.g., start blind but convert to non-blind at some point), etc. In one implementation, the server can check if the setup wizard does not finish after a predetermined number of hours. A follow-up email can then be sent to the HCP or patient.

[0196] Following the wearing period, the patient can be instructed to remove the sensor and transmitter (step 560). If a smart device is paired with the sensor / transmitter, data transfer can have occurred during the wearing period, so a report can be automatically generated by the server and sent to the HCP and / or patient (step 562). The patient can then consult with the HCP in person or via telemedicine (step 564).

[0197] Returning to step 536 above, if the patient does not have a compatible smart device, the HCP may default the system to baseline mode, e.g., blind without pairing with a smartphone (step 568). The HCP may enter patient information into the HCP server clinic portal and again print the patient handout (step 570). The HCP may use a reader, e.g., with NFC, to verify that the sensor is functioning properly (step 572). Details of such a verification step are provided below with respect to flowchart 800. The HCP may then send the patient home with a disposal bag and instructions (step 574). Similarly, the wear period may begin (step 576). This step may also default to baseline mode following step 566.

[0198] The patient may return with the sensor / transmitter in a disposal bag (step 578), and the HCP may use a reader to extract data from the sensor / transmitter (step 580). After data extraction, the patient may consult with the HCP, either in person or via telemedicine (step 564).

[0199] Flowchart 750 in FIG. 11 summarizes many of the operations of the HCP setup procedure, particularly from the perspective of the HCP application. In a first step, the HCP sets up a patient account using the HCP application (step 590). The HCP can then use the application to provide pairing steps with the sensor transmitter (step 592), for example, if the pairing is performed by an HCP device, a professional product, or a user smart device. The HCP application can then transition the transmitter into HCP mode (step 594). In this mode, the HCP can verify proper operation of the sensor and transmitter using the HCP application (step 596). This mode can be enabled by enabling a communication protocol that allows only one connection, blocking other communication requests from other devices, etc. In either case, in this mode, the HCP application can be granted significantly greater permissions and privileges to allow configuration of the professional product or user smart device and subsequently allowing the device to return to a more typical mode, with such configuration details protected from user modification. After confirmation of proper operation, the transmitter is transitioned to normal mode (step 598). The term "normal mode" is used to indicate the mode in which the wearing period occurs, and the same can be used to encompass several other modes, e.g., blind, non-blind, etc.

[0200] After the wearing period, the patient returns to the HCP office (step 602), and the HCP uses the HCP application to extract the data from the transmitter (step 604). In some cases, the HCP can use the HCP application to upload the data to a server (step 606).

[0201] Variations on the above will also be appreciated, for example, using NFC on a mobile phone to scan the transmitter can cause the phone and transmitter to automatically configure the system, including downloading the CGM monitoring application to the phone and pairing the phone with the transmitter, as well as initiating sensor activation.

[0202] For example, in one implementation, the transmitter itself can store the application and transfer it directly to the paired smartphone during the pairing process. The advantage of this configuration is that it eliminates the need for a professional download of the actual application, which often lacks adequate or strong Wi-Fi or cellular connectivity and can raise privacy concerns if the download occurs over a public network. Thus, pairing can be initiated by an NFC connection, and the application can be transferred via NFC or BLE. If the application stored on the transmitter is not the latest version, it can be updated to the latest version when the user has a strong, secure connection. For example, in such a case, the application can communicate with a server to determine the latest version of the application. Alternatively, the server can push the latest version to the mobile device when it determines that the existing version is not the latest version.

[0203] FIG. 38 shows a flowchart illustrating one example of steps that may be included in establishing communication between an HCP device, such as an HCP reader (e.g., HCP reader 420 shown in FIG. 4 ), and a sensor / transmitter at an HCP office. For example, these steps may be used as part of steps 592, 596, and / or 604 of FIG. 11 , using an HCP application on the HCP device to pair the HCP device with the sensor / transmitter, verify proper sensor operation, and extract data from the transmitter. In this example, two different wireless protocols are employed. One of the wireless protocols is a short-range protocol, such as NFC or RFID. In some examples, the short-range wireless protocol used may not be encrypted at the protocol level (although, of course, encryption may still be used at the application level in these examples, if desired). The other protocol employed is an encrypted protocol that requires the use of an authentication procedure between the two devices. In one particular embodiment discussed for purposes of illustration, the short-range protocol used is NFC, and the encrypted protocol used is BLE. Thus, in this example, both the HCP reader and transmitter are provided with NFC transceiver circuitry and BLE transceiver circuitry.

[0204] In the first step, the sensor / transmitter is attached to the patient and configured for use (step 840). To verify that the system is configured and operating correctly, the HCP establishes communication between the HCP reader and the transmitter using NFC. The HCP accomplishes this by bringing the HCP reader close to the transmitter so that the two are within NFC range. Once the HCP reader and transmitter are within range, the HCP reader sends a query command to the transmitter using the NFC protocol (step 842). In response to receiving the query command, the transmitter transmits its ID in an encrypted format, for example, using public / private key encryption techniques (step 844). Furthermore, to extract the transmitter ID from the encrypted format, the HCP reader can use a decryption key that can be obtained from the transmitter (based on the query) or from another computing entity (e.g., a server). In one example, the HCP reader can receive a decryption key (e.g., an RSA key) for decrypting the transmitter ID upon providing the format of the transmitter ID or related information about the transmitter to the server.

[0205] In some embodiments, a single query command can also cause the transmitter to transmit additional information, such as its operating status.

[0206] Examples of transmitter states that can be communicated by the transmitter to the HCP reader include: (i) a remembered state (indicating that the transmitter is still in its package or has not started a session including collecting glucose data or is not performing sensor insertion verification); (ii) a sensor verification state (indicating that the transmitter is performing a sensor insertion verification operation and has not yet collected glucose data from the sensor or is waiting for data collection from the sensor to begin); further, when the transmitter is in the sensor verification state, information such as the total time to complete the verification and / or the time the verification took, the results of the verification, and when to check the verification results can also be provided; (iii) an in-session state (indicating that the sensor is collecting data (e.g., glucose data) during its normal operation); and (iv) a session completed state (indicating, for example, that the transmitter has finished performing a session; the data has been logged and is available for download).

[0207] Additional information that may be sent to the HCP reader in response to the query command may include, for example, how many attempts were made at sensor validation. In one example, this information may be useful to understand whether one or more erroneous sensor activations occurred (e.g., if one or more sensor validations were erroneously performed without the HCP performing or initiating the validation process).

[0208] Other additional information that may be sent to the HCP reader in response to the query command includes the time remaining until the sensor verification is complete (as described above. For example, if the HCP reader performs a query before the transmitter has finished the verification process, which may take, for example, 30 seconds, the transmitter may instruct the HCP reader to check or query again in the next few seconds, or may provide a specific time to obtain the results of the verification.

[0209] The additional information in response to the query may also include how long the currently in-use session has been running (e.g., when the sensor is in an active session). In one example, if the transmitter is in a memory state or a sensor validation state, the result for this query is zero.

[0210] Still other additional information in response to the query may include whether the transmitter is placed in a data extraction mode.

[0211] The additional information in response to the query may also include the type of BLE mode in which the transmitter resides and other information related to the mode. In one example, the additional information may include the type of BLE mode (e.g., normal BLE mode), the advertised rate for the normal BLE mode, and the transmitter ID used for the normal BLE mode. In another example, the additional information may include another type of BLE mode (e.g., HCP data extraction BLE mode), the advertised rate for the HCP data extraction BLE mode, and the transmitter ID used for the HCP data extraction BLE mode. It is contemplated that the advertised rate in the HCP data extraction BLE mode may be higher than in the normal BLE mode, and that the transmitter ID or the form of the transmitter ID used for the HCP data extraction mode may be different from that used for the normal BLE mode. It is contemplated that the transmitter may operate in normal BLE mode during the 14-day session period.

[0212] If the HCP verifies that the system is operating correctly and in-session based on the information received from the transmitter, the HCP completes the setup process by performing any additional steps necessary, such as transitioning the system to an operating mode (e.g., blind or non-blind), after which the patient can use the device during the session.

[0213] When the patient returns to the HCP office after the session is completed (e.g., after 14 days), the HCP uses the HCP reader to place the transmitter in data extraction mode. In some examples, it is contemplated that after the 14-day session is completed, one or more circuits in the transmitter can transition to a low-power mode, either automatically or upon receiving a command from the user via a user device. Because patient data is to be exchanged here (e.g., after the session is completed), an encrypted protocol requiring authentication, such as BLE, is used. To establish a BLE connection, the transmitter is first placed in data extraction mode using an NFC protocol. Specifically, the BLE connection is established by once again bringing the HCP reader near the transmitter and issuing a command to the NFC to transition to data extraction mode using a hashed or encrypted version of the transmitter ID as a parameter (e.g., the HCP reader acquired during the previous session (step 846)). If the transmitter verifies that the received hash is correct, an advertisement and connection protocol is initiated in which the transmitter advertises and connects to the HCP reader (step 848).

[0214] If the transmitter is currently communicating (or previously communicating) with a user / patient device when the command to transition to data extraction mode is invoked, the advertisement method begins after the user device disconnects. To prevent whitelisted user devices (such as a user's mobile device that has been communicating with the transmitter for 14 days) from connecting to the transmitter rather than the HCP reader, the transmitter can use a new BLE Generic Access Profile (GAP) address and / or a new Universal Unique Identifier (UUID) to ensure that the HCP reader prioritizes the connection attempt. In some examples, during extraction mode, the HCP reader can access information already stored in the HCP reader's memory or another computing entity (e.g., a server) to identify and determine the transmitter's identifier when it receives the initial communication request from the transmitter.

[0215] In one embodiment, the transmitter uses continuous advertising to ensure that the HCP reader recognizes the transmitter as quickly as possible. That is, instead of advertising in a periodic mode where advertising periods are separated by quiet periods, the transmitter can advertise without interruption. In some examples, the advertising rate during data extraction mode (to establish a connection with the HCP reader) is much faster than the advertising rate during normal communication mode (e.g., when the transmitter communicates with a user's mobile device). To facilitate the HCP reader quickly selecting and connecting to an appropriate transmitter from among multiple transmitters that may be present at the HCP office (because the reader knows the transmitter ID it is looking for), it is contemplated that a form of transmitter identification information (e.g., a portion of the transmitter ID or a hashed form thereof) may be included in the advertising packet. Furthermore, it is contemplated that once the HCP data extraction mode is cleared, the transmitter may return to normal advertising mode, in which previously connected user devices may again be able to communicate with the transmitter as normal.

[0216] 38, once communication between two devices (e.g., a transmitter and an HCP reader) is established, an authentication procedure may be performed as part of the data connection process (step 850). The authentication procedure may use existing standard and / or proprietary authentication techniques, such as those described in U.S. Patent Application No. 14 / 968,695, the entire contents of which are incorporated herein by reference. Once the authentication procedure is complete, including the exchange of a secret key and its authentication, the BLE connection is fully established (step 852).

[0217] Once authenticated, the transmitter can provide the HCP reader with data acquired during the current session (step 854). In particular, the transmitter can provide estimated glucose values obtained by the analyte sensor and possible additional data, including, for example, personal data (e.g., manufacturer-specific information regarding the health and status of the system, as well as data available from other sensors integrated into the system (e.g., motion data from an accelerometer). Note that glucose data can be transmitted within a predetermined time (e.g., within 15 seconds), whereas personal and motion data can be transmitted without a time budget.

[0218] As described above, during the data extraction mode, the transmitter retrieves all relevant details of the completed glucose session and communicates them exclusively to the HCP reader as a data stream. Once data extraction is complete, the transmitter is placed in a low-power or sleep state (i.e., the lowest possible storage mode) that can last for an extended period of time before depleting the transmitter's battery (step 856). Note that after being placed in storage mode, if the transmitter is to be used for further purposes (e.g., failure analysis, additional data extraction, etc.), the transmitter can be returned to the manufacturer and woken up via NFC. In the various scenarios described above, NFC is used as one of the communication protocols between the HCP reader and transmitter. Because NFC communication is a very short-range protocol that requires the NFC antennas of the HCP reader and transmitter to be substantially in contact with each other, the HCP must carefully align the two antennas when establishing communication. This can be difficult and cumbersome in some situations, especially as sensor systems continue to shrink in size and correspondingly shrinking antenna sizes. Furthermore, from an HCP perspective, it is important that the data extraction process be quick and easy to perform in order to minimize the time and effort required.

[0219] Thus, in some embodiments, it may be useful to provide the HCP with an auditory or tactile feedback mechanism that facilitates the alignment process between the HCP reader and the transmitter antenna. For example, in the case of auditory feedback, the HCP reader and / or transmitter may be equipped with an auditory transducer that emits a sound that increases in volume, pitch, and / or frequency at which discrete pulses are emitted, e.g., as the proximity between the two antennas increases (and vice versa). Similarly, in the case of tactile feedback, a vibration transducer or the like may be used within the HCP reader to provide feedback. Similarly, visual feedback may be provided instead of, or in addition to, auditory or tactile feedback. For example, a light source on the HCP reader or on the transmitter, such as an LED, may emit light pulses that increase in frequency as the proximity between the two antennas increases (and vice versa).

[0220] It should be noted that, in addition to the modes described above, modes can be configured to be particularly interesting for use by the patient, allowing for a degree of flexibility and "choose your own path" functionality. In this way, a user can view the use of the sensor and transmitter and accompanying patient monitoring application as a "journey" or "adventure" pursued over time, including the use of a transmitter with multiple sensors over multiple respective sensor sessions. As described in more detail below, the transmitter can incorporate a hibernation or inactivity state feature to conserve battery life for such multiple sessions, particularly when data extraction occurs, so that sufficient power remains in the transmitter to allow a signal to be sent from the transmitter to another device for storing the data, for example, using an HCP reader.

[0221] During the HCP setup procedure described above, it is important for the HCP to verify that the system is functioning, e.g., that the transmitter is properly receiving sensor counts from the sensors and transmitting counts when paired with smart devices, including the HCP device. Such verification also impacts billing and reimbursement.

[0222] Referring to FIG. 12 , the transmitter may be shipped and provided in a kit in an inactive state to conserve battery life, and therefore the transmitter may require a “wake-up” operation triggered by the HCP. Such an action can be performed in a variety of ways, such as via an HCP application and / or reader, or an HCP smart device. Details of the “wake-up” procedure by which the transmitter transitions from an inactive state to an active state are described below. In flowchart 800 of FIG. 12 , the purpose of this process is for the transmitter to undergo a transition from an inactive state to an active state, and proper operation is desired to be verified (step 612).

[0223] In one implementation, the HCP can verify two types of transmitter startup steps, both of which are required for proper operation. This method not only transitions the transmitter to an active state, but also makes the HCP application aware of the existence of the active transmitter state, thereby signaling proper operation of the HCP.

[0224] Thus, in flowchart 800, a first type of wake-up step involves detecting proper sensor insertion, and a second type involves detecting proper initiation of a sensor session. In the first type, the transmitter is woken up upon sensor insertion and, upon wake-up, begins communication with the HCP device or HCP reader (step 614). For example, the transmitter can begin advertising via BLE, and the HCP device can detect and therefore determine (step 616) that the transmitter is awake. In this case, in some implementations, the transmitter and HCP device must have previously paired. In other implementations, steps 614 or 616 can be used to initiate the pairing process. Detection by the HCP device can be by performing a visual inspection, followed by confirmation via a message back to the HCP device, prompting the HCP to detect the start of receiving a sensor count, as well as other methods. Alternatively, the transmitter can be configured to send a separate notification message to the HCP device via NFC or BLE that a sensor insertion has occurred. In either case, the HCP device detects the communication and detects that the first step has been performed (step 618).

[0225] In the next step, the HCP device monitors the count from the transmitter (step 620). The HCP device can further check as to whether the count is within a predetermined range for a predetermined time. In other words, the system starts automatically, negating the need in conventional systems for the user to initiate a sensor session using a display device.

[0226] If the count is measured to be greater than the threshold level for a predetermined time, then an indication of success is provided externally or via a signal on the HCP device (step 624). For example, if the threshold criteria are met, the HCP application can use a notification message to indicate so. Alternatively, if the sensor count criteria are met, an external device, such as an LED on the transmitter, can be activated. This can be particularly useful in the absence of an HCP device. In this case, the external device must have some ability to know the sensor count criteria, which may be implemented by an ASIC or other dedicated chip or electronic circuit, with the predetermined criteria loaded into the external device at the time of manufacture. If an external device is employed, the wearable itself can provide visual or audible notification of the appropriate operation. This can be implemented by a small flashing light or a beep. Pairing with a smartphone may occur later for the user. In other implementations of an external device, count monitoring may be performed on the transmitter. If an HCP device is provided, monitoring and determining that the threshold criteria are met can be performed on the transmitter, HCP device, reader, user smart device, or other connected device.

[0227] In the above steps, the described wireless communications can be performed using a wireless link including either NFC or BLE. In the case of NFC, the NFC antenna can be located anywhere on the phone, so the use of an HCP reader device implemented as a dongle can be particularly useful; such a dongle can include both NFC and BLE functionality.

[0228] An advantage of the method of Figure 12 and methods similar to those described below is that both steps must occur in order for the transmitter to be properly verified and transition to an active or operational state during the sensor wear period. Thus, false activations are generally avoided. Other methods for avoiding false activations, which can have a negative impact on battery life, are described below.

[0229] In the example described above, the information obtained from the transmitter confirms that the sensor is functioning properly. In an alternative approach, the applicator used to insert the sensor into the user's body can be equipped with communication capabilities (e.g., NFC, BLE) that allow the applicator to verify that the sensor is properly inserted and functioning properly. In one implementation, the transmitter can send a signal to the applicator (e.g., via NFC or BLE) indicating whether the sensor is functioning properly. After the applicator installs the sensor and the sensor indicates that it is functioning properly, the applicator can send a wireless signal to an HCP application and / or an application on the user device indicating that the sensor is operational. FIG. 40 shows an applicator 902 communicating with a transmitter / sensor 904. The transmitter / sensor 904 then communicates with a user device 906.

[0230] Another problem that is often encountered is that the user typically spends very little time with the HCP during a visit, so it is desirable for the transmitter to transition to the active state as quickly as possible. Various solutions are proposed below.

[0231] In one implementation, and with reference to flowchart 850 of Figure 13, the HCP device may cause the transmitter to wake up (step 628), and in particular may send a wake-up command to the transmitter over a wireless link, such as NFC or BLE (step 630). The remainder of Figure 13 is as described above with respect to Figure 12.

[0232] In another embodiment, referring to flowchart 900 of Figure 14, the transmitter activates itself (step 632) by monitoring the sensor signal and waking up if the signal exceeds a threshold (step 634). The remainder of Figure 14 is as described above with respect to Figure 12.

[0233] The above implementation is described as part of the binding process in flowchart 950 of FIG. 15. It will be appreciated that other wake-up methods can be combined with the overall process. As can be seen, it is expected that such a wake-up process can be completed in a short time, e.g., within five minutes. Two options here include automatic detection of the sensor signal and forced wake-up via NFC. In this process, the transmitter detects whether the current / sensor signal exceeds a threshold, and if so, the transmitter wakes up within a predetermined amount of time, e.g., two minutes, to initiate a sensor session.

[0234] In a first step, the transmitter starts in low power mode (step 632). If a sensor signal is detected, a test can be performed as to whether the current corresponding to that signal exceeds a threshold (step 634). If not, the transmitter can remain in low power mode (step 632). If so, the transmitter can be woken up (step 636). If the signal is determined to correspond to an NFC signal (step 638), the transmitter is woken up again (step 636). That is, an NFC signal can be used to wake up the sensor even if a sensor count has not been measured. In some cases, both of the above can be used and requested to wake up the transmitter. In other words, the measured current is requested to be above a threshold or within a target range, and a wake-up signal is requested via NFC to wake up the transmitter and maintain it in this mode for the duration of the sensor session.

[0235] In some implementations, an accelerator included in the transmitter can facilitate the wake-up process. For example, if the accelerometer detects motion (e.g., caused by a user), the processor can wake up sooner than a predetermined time interval, e.g., every two or five minutes, in step 634 (i.e., reduce the interval at which it checks the current). In one example, the transmitter can return to a low-power mode (e.g., step 632) if the current remains below a wake-up threshold and no motion is detected for a certain period of time.

[0236] After waking up, the transmitter may check the operation of the sensor (step 640). Such steps may include checking whether the detected current is within an appropriate range (step 642). If so, the system status is determined to be operational (step 644). If not, the system status is determined to have failed (step 646). In some cases, the current may be required to be within a predetermined range for at least a predetermined period of time to result in the transmitter waking up. Also, after waking up, if an external display device, such as a specialty product or user smart device, is used, a step may be performed to pair the transmitter with the display (step 648). If the system pairs successfully (step 652), the system status is again determined to be operational (step 644). If the system does not pair successfully, the pairing operation may be performed again (step 648).

[0237] In some implementations, an appropriate time measurement along with the count / current measurement can be utilized to determine the sensor insertion time. In one example, the transmitter can be in a normal operating mode (e.g., after step 636). In such an implementation, the transmitter can then measure a count / current within or above the sensor detection threshold level and further record the measurement time (e.g., time a). The transmitter can further monitor the measured count / current for subsequent measurements. If the measured count / current does not fall below the threshold in the subsequent measurement, the transmitter can determine and verify that the detected count / current measurement of the sensor detection threshold level was not the result of an error. Subsequently, the transmitter can receive a session start command from the display device at another time (e.g., time b), which provides the display device an opportunity to verify that time a is a valid sensor insertion time. The transmitter can then communicate to the display device that time a (not time b) is the correct sensor insertion / sensor session start time. Thus, a signal processing algorithm within the transmitter and / or appropriate entity can then adjust time-dependent variables (e.g., delay timing or start of display of EGV values based on the verified sensor insertion time (e.g., time a) rather than based on time b). In some implementations, it is contemplated that once the transmitter initially receives a sensor session command from the display device and further verifies that time a is the correct sensor insertion / sensor session start time, time b (i.e., the initial display of the sensor session start from the display device) can be overridden by time a.

[0238] In another example, when it is determined that the transmitter has indeed exited the low power state (e.g., from step 632), the transmitter can verify the transmitter's wake-up time (e.g., time c) as the sensor insertion time. Because the wake-up processing algorithm can introduce a delay time, wake-up time c can be recorded as the transmitter's exact wake-up time before the marked wake-up time (e.g., the wake-up time marked in step 636).

[0239] In yet another implementation, as illustrated by flowchart 1000 of FIG. 16, the transmitter may again wake itself up (step 654), but in this case, the transmitter may wake up periodically and determine whether a signal is being received from the sensor (step 656). If so, the transmitter may transition to an active state and begin recording data. In some implementations, the system may communicate such an event, particularly successful startup, for example, via a transmitted signal to a connected device or via an external indication such as an LED or an audible sound. The remainder of the method of FIG. 16 is as described above with respect to FIG. 12.

[0240] In yet another implementation, the transmitter may be woken up upon removal of the package (step 658), as shown by flowchart 1050 of FIG. 17. More specifically, the transmitter may be equipped with a sensor that is activated (or can be activated) upon removal from the package (step 660). For example, the transmitter may be activated by an activation device, such as an NFC-based device, or via audio or visual cues. The HCP may then simply instruct the patient to download and pair the application once data conductivity has been achieved or the necessary support has been obtained.

[0241] In one implementation, and as shown by device 1100 in Figures 18 and 19, wake-up trigger systems and techniques may be implemented by a light sensor 664 covered with an opaque sticker 662. The light sensor activates the transmitter by closing a circuit when light hits the sensor. By keeping the opaque sticker covering the sensor until it is peeled off by the user when ready to pair, light is prevented from hitting the sensor when inside the package.

[0242] The remainder of the description of flowchart 1050 is as described above with respect to FIG.

[0243] In another implementation, the sensor that wakes up the transmitter when the transmitter is removed from the package in step 658 can be an accelerometer. The accelerometer may be included in the transmitter electronics or may be integrated into the package. In either case, upon detecting an acceleration event (such as caused by opening the package or placement of the sensor or transmitter) by the accelerometer, the accelerometer generates a signal that wakes up the transmitter. In some cases, the wake-up signal can be generated only if the magnitude of the acceleration is within a specified window. For example, acceleration below a predetermined value may result from normal package shaking rather than opening the package. Similarly, acceleration above a predetermined value may result from dropping the package rather than opening it. In one alternative, the accelerometer can be replaced with a one-time event circuit, such as a shock sensor, that breaks in response to acceleration.

[0244] In yet another implementation, referring to flowchart 1150 of FIG. 20 , the transmitter may wake up when a user activates a switch or when a user inserts the transmitter into the sensor housing (step 668). In this implementation, a physical activation switch is embedded within the transmitter that can be activated by pressing the switch or otherwise prompting the user to activate it. Alternatively, the switch may be pressed by an applicator while the sensor is attached to the user's body. The embedded switch may be part of a flexible wearable, and when the switch is pressed, physical, e.g., metal-to-metal, contact is made and the device can be woken up from a low-power, inactive, or sleep mode. As before, at the end of the intended period, the system stops recording data and is ready to download the data. Furthermore, in some implementations, the system can communicate to an application or another device that it has successfully woken up.

[0245] The remainder of the flowchart 1150 is as described above with respect to FIG.

[0246] Other techniques can also be employed to trigger a wake-up of the transmitter. For example, referring to flowchart 1200 of FIG. 21 , the mobile device and transmitter can establish a communication session, e.g., which can communicate wirelessly as described above (step 672). An application for use by the patient, e.g., a CGM application or other type of analyte monitoring application, can be downloaded to the mobile device (step 674). Alternatively, the application can be downloaded from the transmitter to the mobile device (step 676). Once the application is on the mobile device, a communication session can be formed between the mobile device and a server in a secure manner and associated with the user account (step 678). The mobile application can also be used to wake up the transmitter (step 680).

[0247] In this regard, it should be noted that starting a sensor session a certain amount of time after the moment of insertion can adversely affect the accuracy of the measurement data. Systems and methods according to the present principles provide various ways to address this. In particular, with reference to flowchart 1250 of FIG. 22 , a user (or HCP) can indicate on a downloaded application that sensor insertion has occurred (step 682). The user then pairs the transmitter with the mobile device (step 684), after which the system can automatically begin from the moment the sensor was inserted (step 686).

[0248] Alternatively, a user can couple a transmitter to a sensor (step 688) and then pair the transmitter to a mobile device (step 690). The system can then automatically start when the first sensor signal arrives at the transmitter (step 692).

[0249] In any case, in subsequent sessions, the user can attach a transmitter to the sensor and the system can automatically start the session from the time the first sensor signal arrives at the transmitter.

[0250] In a variant, and referring to flowchart 1275 of FIG. 23 , systems and methods according to the present principles may address issues associated with a lack of glucose readings obtained during the warm-up period. For example, using low-cost or disposable transmitters, a patient may overlap the wearing of two transmitters / sensors (step 694). One or more displays may be paired with both transmitters and automatically switch to using the new transmitter once the warm-up period is complete (step 696). In a variant, indicators may be provided to show which transmitter / sensor is old or expired (step 698). In this way, the likelihood of accidentally removing a new sensor is reduced.

[0251] The indicator in step 698 may be provided by a visual indicator of an expired or new transmitter, such as an LED light. Physical indicators, such as vibration, may also be used. In another alternative, a display device, such as a specialty product or the user's smartphone, may use a proximity sensor to notify the user when the display device is near an expired or unexpired sensor. The resolution of a proximity sensor, i.e., its ability to distinguish one sensor from another, may be low if the sensors are widely separated, such as on opposite sides of the body, or if the sensors must be separated by user command. In some cases, such systems may require physical contact with the display device to distinguish between transmitters within inches of each other. Communication modes for such purposes may include very short-range electromagnetic signals, such as RF signals or magnetic fields, such as NFC. In another implementation, a custom USB or other cable may be used that plugs into the display device and has an adapter on the other end to read the transmitter. Devices specially configured for such purposes may be designed with a port into which a transmitter can be placed or connected, or otherwise have a contact point for transmitter contact. In one example, an extra low voltage power socket testing device can be used, which can include, for example, a small light that indicates whether a contacted transmitter is expired and should be removed.

[0252] In one variation, referring to the flowchart of FIG. 39, there is another technique that can be used to wake up the transmitter when a user first installs it. In this variation, a mechanism is provided that automatically wakes up the transmitter when the user installs it in the sensor bay / enclosure. This can be achieved in any of a variety of ways. For example, installation of the transmitter in the bay / enclosure could activate dedicated wake-up circuitry. As another example, a simple mechanical mechanism could be employed where insertion of the transmitter into the bay / enclosure engages a portion of the bay / enclosure, thereby actuating a mechanical switch on the transmitter, thereby waking up the transmitter.

[0253] Referring now to FIG. 39, after a user removes the transmitter from its packaging and places it in the sensor bay / enclosure, the transmitter automatically wakes up without user intervention (step 870). Typically, the transmitter can wake up in a few seconds. The transmitter then begins broadcasting BLE advertisements or beacons as part of the advertisement and connection protocol (step 872). If the user already has a dedicated software application installed on their user device (e.g., a smartphone), the application may automatically open and query the user whether they would like to pair the device in response to the advertisement (step 874). Assuming the user wishes to pair, the user enters a transmitter ID or other code that may be used for security purposes (step 876). In some cases, this may require the user to take a photo of a barcode placed on the transmitter. Alternatively, an NFC tag storing the appropriate transmitter ID or other code may be placed on the transmitter, which the user device can read when the user touches the transmitter to the user device. If the transmitter ID or other code is correct, the transmitter and user device are paired via BLE (step 878). The session can then begin automatically after a warm-up period, which can be indicated on the application with a countdown timer (step 880).

[0254] In the example shown in FIG. 39, once placed in the sensor bay / enclosure, the transmitter automatically drives the pairing and session initiation process without requiring any additional action on the part of the user, such as by initiating a session with a start button.

[0255] At the end of the session, the transmitter sends a signal to the application on the user device indicating that the session has ended, and the application notifies the user that the session is complete (step 882). The transmitter then goes into a low-power or sleep state, waking up periodically (e.g., every 5 minutes) to check whether the application needs to be updated with data from the previous session (step 884).

[0256] When a next session is initiated after the first session as described in Figure 39, the process is similar to that shown in Figure 39 but with fewer steps because the transmitter and user device are already paired. In this case, when a user inserts the transmitter into a new sensor bay / enclosure, the transmitter automatically wakes up from sleep mode and broadcasts a BLE advertisement that automatically launches a dedicated application running on the user device. The session then automatically starts after a warm-up period. The application can display a countdown timer indicating when the warm-up period is complete and the sensor session begins. If the transmitter determines that the sensor is a used or expired sensor during the warm-up period, the transmitter notifies the application of this condition and then transitions to a low-power or sleep mode.

[0257] In some embodiments, a countdown timer provided by the application may present a message such as "Your sensor session begins in 3 minutes." Generally, the timer may be set to err on the side of overestimating the time remaining rather than underestimating, as it is better to exceed a user's expectations than fail to meet them. In some cases, it may be desirable to initially query the user at the start of a session whether they would like to be notified when the warm-up period is complete. If so, the notification may be provided directly by the application using any suitable means, such as a visual or audio indicator, or a message may be provided through another application on the user device, such as a calendar application, which may be scheduled in a manner similar to other events.

[0258] In other variations, a mechanism may be provided that allows the transmitter to remove itself. For example, the transmitter may eject itself from the sensor bay / housing, but the user may still be required to manually remove the adhesive patch. In another variation, the transmitter may trigger a device that loosens the patch and / or causes the sensor to retract.

[0259] In another variation, and referring to flowchart 1300 of FIG. 24 , a common transmitter configured for use with overlapping sensor sessions may be employed (step 702). In one implementation, a cassette is used with multiple sensors that can be placed in signal communication with the transmitter (step 704), with at least two sensors simultaneously communicating with the transmitter via, for example, NFC or BLE. In such a system using a transmitter with multiple sensors, each sensor may be sequentially armed over time, with some overlap between the two sensors. A cassette or sensor drum may be used with an integrated arming mechanism. Alternatively, a separate arming mechanism may be used, such as an instrument that inserts a new sensor already in the cassette. The transmitter may have multiple spots, ports, or slots for sensors, but at the start of each new session, each sensor may be applied to or through the transmitter by a separate applicator tool. In a variation of this implementation, a reusable applicator may be used, which operates manually or automatically and can take an assembly consisting of a sensor, transmitter, and needle. Such a reusable applicator may be used repeatedly to attach multiple serial sensors.

[0260] The above describes the installation and, to some extent, pairing of the transmitter with a sensor and an HCP or other mobile device. In this regard, it should be noted that the transmitter does not have an actual source of absolute clock time. Even if the transmitter has been used before, if it is not paired with a phone or similar device, the transmitter generally is not in communication with a source of real-time clock data. Instead, the transmitter only measures or times how long it has been running since initiation. For example, this can be problematic if a user sensor session ends after 14 days of use, but the user only returns the transmitter to the HCP 17 days later. In such a scenario, the transmitter does not have absolute data about how long it has been running since initiation, especially if it was in low-power mode for part of that time. Furthermore, the HCP may wish to perform analytics on the data based on the actual date and time of the sensor data, for example, for individual analysis or for matching with other event data, such as meals or exercise.

[0261] One solution is to actively provide data from the HCP device, e.g., from an HCP application, to the Transmitter, e.g., using the real time of a clock on the HCP device. For example, referring to flowchart 1350 of FIG. 25, during the first visit, the HCP device can be paired with the Transmitter (step 706). Subsequently, the HCP device, e.g., an HCP application, can provide a timestamp to the Transmitter, e.g., using a reader in NFC mode (step 708). The Transmitter can then use this time information to further timestamp the sensor data collected by the Transmitter during the wearing period. In this way, the Transmitter receives a communication or reference time (e.g., July 1st, 2:00 PM, with 0 seconds corresponding to the time), which can be valid for both blind and non-blind modes of the Transmitter. Thus, in some cases, the HCP can provide a timestamp, and the patient can go home and synchronize with their phone to obtain another timestamp. The Transmitter then uses this time information to further timestamp the sensor data collected by the Transmitter during the wearing period (e.g., 14 days).

[0262] Alternatively, the transmitter may periodically look for or scan for timestamps from Bluetooth® devices that may be within range of the transmitter. The transmitter may request a "current" timestamp from one of the Bluetooth® devices.

[0263] This implementation is illustrated by flowchart 1400 in Figure 26A. In this figure, a transmitter may currently be in use in a sensor session (step 710). If a timestamp has not yet been obtained or if it is desired to recalibrate according to a new timestamp, the transmitter may intermittently or periodically scan for neighboring devices, e.g., neighboring Bluetooth® devices (step 712). In this manner, the transmitter may request and subsequently obtain timestamps from nearby Bluetooth® devices (step 714).

[0264] If there is a time drift in the transmitter / sensor data during a sensor session, the HCP can download the time-shifted data after the sensor session and perform data reconciliation via a software application. In one implementation, the user can synchronize the time at the beginning and end of the session to compensate for such drift and time lag.

[0265] In a variation, the user may pair with the transmitter when they return home following the HCP visit, and the transmitter may receive a timestamp as part of this pairing process. In this case, the user's professional product or the user's smartphone provides time synchronization, where time synchronization refers to providing the transmitter with a timestamp. In this way, the transmitter can periodically synchronize with real-world time via the user's smartphone. In a related variation, if the transmitter is installed in the HCP office but the user does not synchronize the transmitter with their application until five hours later, real time is only available at the five-hour point. However, if the transmitter is used to receive data during this time, such data can be retroactively timestamped so that it can still be used as timestamp data in subsequent analyses.

[0266] As noted above, one mode choice the HCP has is to blind (or not blind) the patient to the display of measured analyte values. In this regard, it should be noted that patients may adversely affect, for example, their normal daily activities or behaviors if they are allowed to monitor their glucose data. This may mislead or prevent the HCP from accurately interpreting the patient's glucose data.

[0267] If it is desired that the patient be completely blinded as to the data, this generally reduces the need for specialized products or the user's smartphone unless used for data backup. When no smart device application is involved, this is referred to as "extreme blind" mode.

[0268] In a specific embodiment of the extreme blind mode, the blind mode can be implemented by turning off the BLE radio after a predetermined or specific period of time so that the transmitter does not provide EGV values to the phone / receiver. This embodiment can be particularly useful for patients who do not have smartphones. The BLE radio can be turned off (by the transmitter) when the transmitter determines that it is not paired with any phone or device after a predetermined time (and after the HCP places the transmitter on the user). In this example, the HCP does not provide a timestamp to the transmitter or confirm the insertion of the sensor during the setup phase. Instead, the HCP simply places the transmitter on the user, and the user leaves the HCP office.

[0269] However, because the HCP does not provide a timestamp to the transmitter, the transmitter has no basis for determining the absolute start time when the sensor session began. However, the transmitter circuitry can still keep time by maintaining a counter that would be started during the initial HCP setup phase. The counter can continue to track "time" even after the sensor session has ended (e.g., after 10 or 14 days), even if the sensor is operating in low-power mode. By leaving the counter running even after the sensor session has ended, the transmitter can provide information about how long it has been "awake" since initialization. Thus, when the user returns to the HCP (e.g., after 14 days), the HCP reader or software can determine (based on the counter information) when data was collected and for how long.

[0270] In certain implementations, a user can place the transmitter anywhere, which may include the HCP's office, home, their car, or other location. In this case, sensor insertion or activation need not be or cannot be confirmed (by the HCP). As noted above, a time reference, e.g., a UTC time reference, is not provided to the transmitter. Because the mode has not been changed by any means, e.g., by the HCP using an HCP device, specialty product, reader, dongle, etc., the transmitter starts up in a default mode, which may be a blind mode. Because no Bluetooth® pairing has occurred, the transmitter can automatically turn off its Bluetooth® radio after a period of time, e.g., 1 to 12 hours.

[0271] In one implementation, the session simply ends after a predetermined sensor period, e.g., 15 days. The transmitter goes into a very low-power "time mode." In this mode, the transmitter can wake up periodically, e.g., every 5 minutes, 30 minutes, etc., to update the corresponding counter. In some cases, the transmitter can go into or avoid a "deep sleep mode" that requires NFC to wake up.

[0272] In yet another variation of this system, the timed mode ends after a predetermined period, for example 15 days. This time can also be set to be variable and based on the remaining battery power. This "timed mode" conserves energy by not displaying Bluetooth® advertisements in blind mode.

[0273] In either case, the user returns to the HCP office and the HCP reader communicates with the device: for example, the HCP reader can wake up the device via NFC, enable Bluetooth® low energy communication, download data via it, and then terminate the session.

[0274] A graph of the remaining (or available) power over time is shown in Figure 26B. As can be seen, in the initial storage mode, the power, indicated by "A," slowly decreases while the time, indicated by B, increases. However, in this mode, the time measurement has not yet begun.

[0275] At the start of a session, various steps can occur. In one case, the HCP provides a UTC time reference at the start of the session and then "locks" the session to a specific absolute start time. This locking is indicated by Y, and the transmitter then keeps time according to line G.

[0276] In other cases, the HCP does not provide a time reference, such as when a user installs a transmitter themselves in their home or car. During the period indicated by Z, BLE advertisements may occur to allow potential communication to occur. For example, in non-blind mode, where data from the transmitter is sent to another device for display, following line C, the power is reduced more rapidly. In blind mode, indicated by line D, following the initial BLE advertisement, BLE is turned off and the power is reduced more gradually.

[0277] The next segment shows post-session activity. Line E indicates timekeeping power mode, in which the transmitter continues to monitor the passage of time. Line F shows post-session activity when BLE advertising occurs during the session. Because measurement data was relative to absolute timestamps during this period, line F can indicate extremely low power consumption, or "deep sleep" mode, because even timekeeping is no longer required. In Figure 26B, the line appears essentially flat. In either of these cases, a visit to the HCP office and subsequent download of measurement data can provide a UTC time reference for the data. In some cases, this is the initially received time reference, and the measured data may be subsequently associated with various time references based on the provided UTC time reference. In some cases, for example, when BLE advertising and data communication occurs on a smartphone, the UTC time reference received during a post-session HCP visit can provide a corroborating time reference, e.g., a second time reference that verifies the accuracy of the initial time reference. However, if the device following line F is used, the time period indicated by line F is unknown (no time data is recorded), so the time reference provided at the HCP visit will not confirm the initial time.

[0278] In certain implementations of the above-described system, it is advantageous if Bluetooth® advertising, and indeed all energy usage in the way of communication, is turned off in blind mode. Blind mode should normally be the default mode, but may be disabled by the HCP if the session is not blind. In this case, the disabling can occur via Bluetooth® low energy. Bluetooth® low energy advertising may be configured to be initiated via an NFC command at the HCP. In unambiguous cases, it is generally already on.

[0279] An advantage of such an embodiment is that the BLE radio is off for the duration of the sensor session, thereby significantly reducing battery power consumption. Furthermore, such an implementation further significantly reduces the time required for the HCP to configure the transmitter. Data extraction can be as described above, e.g., via NFC / Bluetooth.

[0280] As described above, to enable such modes during setup, the HCP programs the transmitter, or a specialty product or smartphone application, with various modes depending on the user's needs / conditions and skill level. The HCP also programs the transmitter to be in blind or non-blind mode.

[0281] In one exemplary method for achieving programming, the transmitter can be provided with multiple serial number extensions, each defining how an application or other connected device will behave when paired with the transmitter. For example, a first extension may correspond to a blind professional mode. When this serial number extension is used, the device will only display the sensor's operational status when paired with the device. A second extension may correspond to a semi-blind professional mode. When this serial number extension is used, the device will only display the sensor's operational status and predefined alerts when paired with the device. A third extension may correspond to real-time personal and professional modes. When this serial number extension is used, the device can be configured to display alerts, glucose values, trend graphs, etc. when paired with the device.

[0282] Generally, the selection of the blinding mode can only be configured by the HCP. However, either the transmitter or the mobile display device may achieve blinding. The transmitter may achieve blinding by not transmitting data continuously during a sensor session, or by transmitting the data with an appropriate flag indicating that the data will not be displayed on the smart device's user interface.

[0283] When a user downloads the application but does not view analyte data, this is referred to as "semi-blind mode." In this mode, the user can receive alerts and calibration information, and in some cases, can further input data regarding medications taken, medications eaten, and exercise performed. In this way, alerts can be employed to mitigate serious adverse events. For example, the transmitter can change color, vibrate, or raise its temperature; alternatively, a connected transmitter can generate an alert on the user's smartphone without providing glucose trends or figures. Such functionality allows the user to trigger an action, such as a touch of a finger, to help address potential concerns identified by the sensor in the alert.

[0284] If the user is allowed to view analyte data, trend graphs, etc., it is called "non-blind mode."

[0285] In some cases, switching between blind and non-blind modes may occur. Referring to the general overview flowchart 1500 shown in Figure 27, upon a first visit, the HCP may initiate blind mode (step 720). A trigger event may occur (step 722), and the transmitter and / or mobile device may switch to non-blind mode (step 724). In this manner, the transmitter may be configurable for switching based on HCP preferences in addition to the occurrence of one or more events.

[0286] For example, one implementation may allow a physician to start a patient on a blinded CGM system that will collect glucose data. The physician can set triggers that automatically switch the system to unblinded mode, for example, based on time or the occurrence of an event, allowing the patient access to alerts and real-time data. In one implementation, the data becomes unblinded after 14 days so the user can view their data. In another implementation, the data may be unblinded if the user achieves an exercise or dietary goal. In yet another implementation, the data may be blinded for seven days and then unblinded for another seven days. Other variations will also be understood.

[0287] In either case, physicians can then compare the two data sets to provide actionable insights and treatment adjustments for patients.

[0288] In other variations, "real-time blinding" can be utilized to provide further insight. It should be noted that in blinding mode, the user cannot see glucose data or receive glucose alerts. This helps prevent the user from seeing changes in blood glucose levels and taking immediate action, which could affect the medical plan the HCP may prescribe for the patient. On the other hand, allowing the patient to see the data also helps the patient understand the impact of lifestyle events on glucose levels. In this way, "real-time blinding" provides a middle ground and achieves both objectives. In particular, real-time blinding configures the system so that the patient cannot immediately see the data. However, the patient would be able to see older data—for example, data from the previous day or data older than a few hours.

[0289] The time length can be configurable, for example, by the HCP, or a range can be defined by the HCP within which the user can set the period. In one implementation, the corresponding UI of the application does not include the usual trend screen, but only incorporates a reflective view, avoiding confusion that can be introduced into the user by interpreting old data as current data.

[0290] As shown in FIG. 4, a diagnostic application 428 may be employed, particularly advantageously as a secure application for blind-mode diagnosis. In this regard, it should be noted that the user cannot use a standard CGM application to view data during a diagnostic session. Thus, the diagnostic application allows the HCP to set alerts without changing treatment. For example, in addition to receiving real-time alerts to mitigate potential adverse events, the user can view the diagnostic application to see the sensor status, e.g., time remaining, error messages, etc. In using the diagnostic application, alerts can be static for episode data, i.e., not continuous, and do not show the glucose profile or history. Low glucose alerts simply display a number and trend arrow, or simply a number, or a threshold value. In this way, the user is still required to manage their diabetes in the same way as previously used with just a finger stick. By hiding the glucose profile information, the user cannot make dramatic therapeutic changes to their current treatment, so such knowledge does not change the outcome of the diagnostic session.

[0291] One aspect of the HCP setup process described above involves pairing the transmitter with a professional product or other smart device. For example, referring to flowchart 1450 of FIG. 28 , after the transmitter wakes up from an inactive state and transitions to an active state (step 716), the transmitter is paired with a device, such as a professional product, a mobile device, or an HCP device (step 718). However, pairing a transmitter using a traditional manual process can sometimes be cumbersome. Such a process involves entering a transmitter ID or identifying the transmitter to the device to be paired. Such a cumbersome and time-consuming process can prevent HCPs from setting up the transmitter for their patients.

[0292] Therefore, in one implementation, a user-friendly and quick method can be employed to identify a transmitter using an HCP device.

[0293] For example, referring to the schematic diagram of Figure 29, in one implementation, a system 1550 can be configured to include one or more processors 726, where at least one of the processors can be configured to execute a software application or command to initiate communication between at least one receiving device 728 and at least one transmitting device 730. Here, the term "receiving device" is used to refer to any device with which a transmitter can be paired and which can signal and communicate with, for example, an HCP device, a specialty product, a user device such as a smartphone, etc.

[0294] 30 , initiating communication may include at least one of identifying the transmitter and / or receiving device, authenticating the transmitter and / or receiving device, or binding and pairing the devices (step 732). For example, without limitation, binding or pairing may include communicatively connecting the receiver and transmitter, including one or more of transmitting a communication key such as an identity resolution key (IRK) (step 734), transmitting transmitter identification information, secure and simple pairing, barcode scanning, user entry of a code, biometric authentication, etc. In some embodiments, communication may include transmitting data via at least one radio frequency (RF) protocol.

[0295] In some implementations, an application key may be used to ensure secure communication between devices. The system may be configured to generate the application key, for example, by either the receiver or the transmitter, or by a central or cloud server associated with the software application. The system may be further configured to encrypt information, such as data related to analyte levels, using the application key. The system may be further configured to operate in at least one of a mode in which the transmitter and receiver are continuously connected in communication and a mode in which communication is initiated intermittently. The system may be further configured to operate the receiving device as a gateway to communicate with one or more other receiving devices.

[0296] One scenario in which pairing a transmitter and a receiving device in a fast and user-friendly manner can be particularly important occurs when a user is undergoing a medical emergency and hospital personnel or first responders need access to the latest analyte sensor data. In this situation, it is helpful to avoid typical authentication techniques that might otherwise be used when pairing a transmitter to a receiving device. Of course, security and privacy issues must be addressed to avoid potential vulnerabilities. Thus, for example, an emergency responder could be equipped with a receiving device with an application that allows them to access a communication key or other credential from a server with a portal that is made available only to pre-approved individuals or entities (e.g., a hospital or other emergency medical facility). The communication key or other credential obtained from the server could enable secure communications to be established between the transmitter and the receiving device. As another example, the transmitter could be configured to expose a dedicated wireless interface that is made available only to emergency responders.

[0297] In some embodiments, the system may be configured to operate in a mode in which the transmitter and receiver are continuously communicatively connected. For example, continuously connected mode may refer to a connection model in which the connected receiver and transmitter maintain the connection for as long as possible until an error or out-of-range condition occurs.

[0298] In some embodiments, the system may be configured to operate in a mode in which communication is initiated intermittently. For example, the system may transmit data periodically (e.g., if the transmission period is 1 minute, 5 minutes, or 10 minutes, etc.) and during a transmission window of less than the entire period, and terminate communication during the remaining period. The system may further be configured to vary the periodicity or interval of the intermittent communication based on factors such as the time of day, the nature or trend of the analyte data, battery life, etc. In this way, for example, a single transmitter can be configured to communicate with multiple receivers during different transmission windows, or vice versa. Power savings may advantageously result from intermittent rather than continuous operation of at least one of the transmitter and receiver devices.

[0299] In some embodiments, the system is configured to switch between a first mode in which the receiver and transmitter are continuously communicatively coupled and a second mode in which communication between the transmitter and receiver is initiated intermittently. Switching between the continuous and intermittent modes can be initiated, for example, in response to a user input, in response to a command from either the transmitter or receiver device, and / or can be based on various criteria including the type or class of device (e.g., phone, medical equipment, proprietary receiver or transmitter device, etc.), power capacity or constraints (e.g., remaining battery life), signal quality measurements, time of day, aspects of the analyte data (including trends or statistical measures), etc.

[0300] In some embodiments, communication may be initiated based on information or statistical measures about the detected signal (step 736). For example, without limitation, the receiver may be configured to identify a transmitter transmitting a signal based on at least one of information about the strength of the signal and information about the quality of the signal, such as at least one of a bit error rate (BER) or a signal-to-noise ratio (SNR).

[0301] As a non-limiting example, a received signal strength indication (RSSI) is a measure of information about the strength of a detected signal. RSSI is determined from the power being received by an antenna. RSSI is a relative (percentage) measurement defined differently by different chip manufacturers, and therefore its value for a given power level at the antenna cannot be accurately or uniquely identified. While it is theoretically possible to determine the distance from a transmitter in free space from the RSSI value, reliable distance estimation is often impractical, especially in indoor environments, due to the effects of objects, walls, reflections, multipath interference, etc. However, in the environment associated with a particular receiver / transmitter pair, the trend observed in the RSSI is generally a reliable indicator of whether the distance between the receiver and transmitter is increasing or decreasing.

[0302] In some embodiments, the receiving device may be configured to detect the presence of one or more transmitter signals. The receiving device may be configured to monitor detected transmitter signals and identify a transmitter based on selection criteria such as at least one of ongoing signal detection, information or statistical measures of signal strength such as RSSI, and signal quality from an identified transmitter for a predetermined period of time. If the signal from an identified transmitter does not meet the selection criteria during or after the predetermined period of time, the system may be configured to continue monitoring detected transmitter device signals and select a transmitter for initiation of communication, or to use an alternative method of identifying or selecting a transmitter. The system may further be configured to initiate communication between the receiving device and the selected transmitter.

[0303] In some embodiments, at least one system component, such as, but not limited to, a receiver or display device, can be configured to display a list of detected transmitters to a user via a user interface. The system can be configured to prompt the user to select a transmitter with which to initiate communication from the displayed list of detected transmitters. The list can be sorted or prioritized by, for example, at least one of signal strength-related information such as RSSI, signal quality-related information, signal detection duration, and other prioritization criteria. For example, the list can be filtered by threshold criteria to include signals for which at least one of the aforementioned criteria meets a predetermined threshold requirement. In some embodiments, the list can be limited to a predetermined number of detected transmitters based on at least one prioritization criterion, for example, 10 or fewer transmitters associated with the highest RSSI values.

[0304] In some implementations, the user may be prompted to enter information identifying the transmitter (step 738), for example, via a user interface or using a camera or barcode scanner. The information identifying the transmitter may be obtained, for example, from the transmitter or its packaging. In some implementations, the transmitter identification information may be encoded in a manner that is invisible to the naked eye, for example, in an invisible code detectable by a barcode scanner.

[0305] The system may be further configured to confirm the identification or availability of the user-identifying transmitter based on selection criteria such as continuous detection of at least one of information regarding the strength of a signal detected from the selected transmitter over a predetermined period of time (e.g., RSSI) and information regarding the quality of a signal detected from the selected transmitter over a predetermined period of time. In some embodiments, the selection criteria may include a threshold value for at least one of information regarding the detected signal strength and information regarding the detected signal quality. If the signal from the user-identifying transmitter does not satisfy the selection criteria during or after the predetermined period of time, the system may be configured to repeat the confirmation of the identification or availability of the user-selected transmitter based on the selection criteria and display an updated list of detected transmitters for user identification or selection. In some embodiments, the system may be configured to employ an alternative method of transmitter identification or selection before or after a predetermined number of iterations.

[0306] In some embodiments, the receiver device can be configured to identify or select transmitters by detecting RSSI or other signal-related information from one or more transmitters. For example, without limitation, the transmitter module of a sensor electronics device can be identified or selected based on at least one of: one or more extreme (maximum or minimum) thresholds of RSSI; one or more extreme thresholds of an average other than one RSSI from the same device; the difference between maximum, minimum, or average RSSI values from each of multiple detected devices; selection of the maximum peak or average RSSI of all devices discovered within a predetermined time interval; a statistical measure such as the difference (e.g., delta, variance, or trend) of RSSI values received from each of one or more discovered devices; a standard deviation or mean average deviation (MAD) in RSSI values from each of one or more devices; and a filter based on device type or class.

[0307] In some embodiments, the one or more detected signals can originate from at least one of a sensor electronics device and a transmitter module configured to transmit at least one of an advertising signal, a beacon, and a signal related to an analyte level. In some implementations, the receiver device can be incorporated into a mobile phone or other electronic device. For example, without limitation, the transmitter module of the sensor electronics can be configured to transmit an advertising signal when it is operably coupled to an analyte sensor, when the analyte sensor is transcutaneously placed, or when both of the aforementioned conditions are met. Upon detecting the advertising signal, the receiver device can be configured to associate or pair with the transmitter and prompt a user to move the receiver closer to or further away from the sensor electronics, or vice versa. The receiver can be configured to identify or select a transmitter based on a value derived from an RSSI associated with the advertising signal, including the RSSI itself.

[0308] In some embodiments, the receiver can be further configured to provide an indication to the user that the transmitter has been identified. The indication can include, for example, feedback from the identified transmitter (e.g., a light, a beep or other auditory signal, or tactile feedback), or a notification to the user via a user interface on the mobile phone or other electronic device that can include information identifying the transmitter. The user can be prompted to select or verify the identity of the transmitter.

[0309] In some embodiments, if the detected RSSI or other signal-related parameter or statistical measure exceeds a predetermined maximum threshold, for example, when the transmitter and receiver are in close proximity, the receiver can be configured to prompt the user to move the receiver device farther away from the sensor electronics so that the sensor electronics can be identified based on changes in RSSI or other information regarding signal strength or quality. The receiver can further be configured to prompt the user to later move the receiver closer to the sensor electronics, if necessary, to further determine or verify the identity of the transmitter. For example, without limitation, the receiver can be configured to initially prompt the user to move the receiver device away from the sensor electronics when the RSSI exceeds a predetermined maximum threshold, and subsequently prompt the user to move the receiver closer to the sensor electronics after the RSSI falls below a predetermined minimum threshold.

[0310] In some embodiments, the transmitting device may further include an accelerometer, a light or infrared detector, a microphone, or other sensor to help identify the transmitter. For example, without limitation, the transmitting device of the sensor electronics module may be configured to begin transmitting an advertising signal when a user causes the accelerometer to generate a signal, such as by tapping the sensor electronics module. Alternatively, upon detecting the advertising signal, the receiving device may be configured to prompt the user to touch or tap the sensor electronics module. When the user touches or taps the sensor electronics in response to the prompt, the resulting accelerometer or other sensor signal may be transmitted to a receiver, which may be configured to receive the accelerometer or other sensor signal. The accelerometer or other sensor signal may be used to identify or select the transmitter. In some embodiments, touching or tapping the transmitter may be used as a verification step, such as to confirm that the transmitter has been identified or selected, or that communication has begun.

[0311] Similarly, referring to flowchart 1650 of FIG. 31 , an input indicating a desire to pair the mobile device with the transmitter can be received on the UI of the mobile device (step 740). A user-induced motion change or artifact can then be detected in the accelerometer on the transmitter (step 742). Data corresponding to the artifact can be transmitted to the mobile device (step 744). If the artifact matches one of a set of signal patterns, the transmitter can then be paired with the mobile device (step 746). Such motion artifacts can include, for example, tapping three times, shaking the transmitter for five seconds, jumping up and down three times, etc. Alternatively, a motion artifact at the transmitter can automatically put the transmitter into pairing mode without the need to compare waveforms or signal patterns. In this implementation, the transmitter ID appears on the phone / receiver to automatically pair or for the user to confirm their intent to pair.

[0312] In some embodiments, the transmitting device can be configured to detect the presence of a receiver signal. The transmitting device can be configured to monitor detected receiver signals and identify a receiver based on selection criteria such as at least one of ongoing signal detection, information or statistical measures of signal strength such as RSSI, and signal quality from the identified receiver over a predetermined period of time. If the signal from the identified receiver does not meet the selection criteria during or after the predetermined period of time, the system can be configured to continue monitoring detected receiver signals and select a receiver for communication initiation, or to use an alternative method of receiver identification or selection. The system can further be configured to initiate communication between the transmitting device and the selected receiver.

[0313] As a non-limiting example, the transmitter can be configured to transmit information regarding the strength of the signal from the receiver, such as RSSI, to the receiving device. In some embodiments, the receiver and / or transmitter can be identified or selected using RSSI or other signal-related information from one or both of the transmitter or receiver modules according to methods described herein.

[0314] In some embodiments, the transmitting device can be configured to identify or select receivers by detecting RSSI or other signal-related information from one or more receivers. For example, without limitation, sensor electronics devices can be identified or selected based on at least one of the following: one or more extreme (maximum or minimum) thresholds of RSSI; one or more extreme thresholds of an average other than one RSSI from the same device; the difference between maximum, minimum, or average RSSI values from each of multiple detected devices; selection of the maximum peak or average RSSI of all devices discovered within a predetermined time interval; the difference, derivative, acceleration, or rate of change of RSSI values received from each of one or more discovered devices, such as delta, variance, or trend; statistical measures such as the standard deviation or mean average deviation (MAD) in RSSI values from each of one or more devices; and a filter based on device type or class.

[0315] In some embodiments, the system can be configured to provide an indication to the user that the receiver has been identified. The indication can include, for example, feedback from the transmitter or identified receiver (e.g., a light, beep or other auditory signal, or tactile feedback), or notification to the user via a user interface on the mobile phone or other electronic device that can include information identifying the receiving and / or transmitting device. The user can be prompted to select a device for communication or to verify the identification.

[0316] In some embodiments, the receiver can be configured to transmit information regarding the RSSI of the transmitter, or other signal-related information, to the transmitter. The receiver can be identified or selected using the RSSI or other signal-related information from either or both the transmitter or receiver module according to methods described herein.

[0317] The foregoing embodiments are included by way of example only. Those skilled in the art will readily appreciate that implementation of the systems and methods disclosed herein is not limited to the described embodiments. For example, but not limited to, various methods can be implemented by one or more of a receiving device, a transmitting device, sensor electronics, a display device, a mobile phone, a tablet, a computer, a wearable monitor (e.g., a smart bracelet, a smart watch, a smart ring, a smart necklace or pendant, a workout monitor, a fitness monitor, a health or medical monitor, a clip-on monitor, etc.), an adhesive sensor, a smart textile or garment incorporating a sensor, a transdermal (i.e., transcutaneous) sensor, a shoe insert or insole including a swallowable, inhalable, or implantable sensor, or other electronic device, and various systems can include any device or devices that can be configured to implement a given method described herein. Similarly, one or more of any indication of signal strength or quality, or any information or statistical measure derived therefrom, can be used in place of RSSI.

[0318] In the systems and methods described above, and with reference to the system 1700 shown in FIG. 32 , an HCP uses an HCP device 760 running an HCP application 748 to access a server 752 to which patient data is communicated. In addition, a patient device 754 may also communicate with the server 752, where the patient device may be, for example, a specialty product, a patient smart device, etc. The patient device 754 may be running a patient / user application 756, where the application may be, for example, a CGM monitoring application, etc. The application 756 may further enable communication with a transmitter.

[0319] Because the application 756 is closely related to the patient's health, it is generally a highly regulated Class III medical device. However, the server 752 is typically used for various types of retrospective analysis, for example, using the portal 740, and therefore the server may be classified as a less regulated, for example, Class II medical device. However, the HCP application 748 configures the patient application 756 and / or the patient device 754 via the server 752. This configuration may consequently affect the classification of the server 752.

[0320] Therefore, to address these issues, a controller module 758 can be implemented within the server 752. The controller module 758 is used by the HCP application 748 to configure the patient application 756 (and other necessary functionality) on the patient device 754. In this way, the HCP settings portion related to application configuration is separated from the retrospective analysis portion of the server functionality. In this case, the controller module is classified as a Class III medical device, and the server maintains its classification as a Class II medical device.

[0321] Battery saving and transmitter wake-up after session including data extraction As mentioned above, most HCPs do not have significant time to configure a Transmitter for a patient at the beginning of a session or to extract data from the Transmitter at the end of a session. Therefore, a quick and convenient way to perform such tasks is highly desirable. Referring again to FIG. 4, a reader device 420 in combination with an HCP application 429 can provide a particularly convenient and simple way to perform the necessary steps.

[0322] In one implementation, the HCP application is an application that runs on an HCP device, such as an HCP computer. In another implementation, the HCP application runs on a mobile device and can incorporate the functionality of an HCP desktop application. Such features generally include, for example, providing a timestamp to the transmitter, verifying sensor insertion and proper activation, providing an interface through which the HCP can enter patient information, and downloading data from the transmitter and uploading it to a server. Suitable devices may include, for example, Android phones, iPhones, and other mobile devices.

[0323] For example, one category of device that may be employed is a smartphone, e.g., a user smart device, or a phone dedicated to this purpose, e.g., a specialized HCP product. Alternatively, a device with RF wireless communication capability may be permanently connected to an HCP device, e.g., an HCP computer. For example, a dongle 426 may be provided that is permanently connected and may include multiple antennas, e.g., one antenna for NFC and one antenna for BLE. The two antennas may be provided in a single housing or in separate housings.

[0324] Advantages of BLE communication include the transmitter not needing to be in close proximity to the computer or dongle (unlike NFC) to perform various steps, including configuring the transmitter during the initial stages after the sensor is inserted and further waking up the transmitter.

[0325] However, an NFC-enabled dongle can also be used to upload data to the dongle after a sensor session, which also serves the purpose of waking up the transmitter before downloading data from it. Advantages of using a dongle include the ability to generally include a larger NFC antenna that is easier to use than the small NFC antennas found on mobile devices. The dongle can also be an active NFC device rather than a passive NFC device. Some communications can be performed via BLE, while other communications can be performed via NFC. Factors determining which wireless protocol is desirable can include, for example, the time it takes to download or upload data, the distance between devices, etc.

[0326] In addition to using the dongle, the transmitter can function in one or more different modes. For example, in one implementation, a dongle (e.g., using NFC) operated by commands from an HCP application causes the transmitter to function in two modes. The first mode is HCP mode. In HCP mode, the HCP can be enabled to perform functions such as transferring timestamps and verifying operation. HCP mode lasts for a predetermined amount of time, e.g., 10 minutes, after which it can automatically transition to a default "normal" mode, e.g., due to periodic wear during a sensor session. An advantage of HCP mode is security; for example, in HCP mode, the transmitter can be configured so that no other communication can occur. In this way, no information can be obtained from the transmitter except through the dongle. BLE communication can also be enabled during this predetermined period in HCP mode. Upon returning to normal mode, regular communication can occur as usual.

[0327] In one implementation, waking up the transmitter, particularly for data extraction, may occur via NFC, but data transfer may occur via BLE since BLE is generally much faster than NFC. In some implementations, the dongle may include a suitable ASIC or program processor to provide some intelligence in the decision making and determination that is configured to calculate, for example, the dongle may consider other factors at the receiver and transmitter to determine the best way to transfer data, for example, whether it is better to transfer data via NFC or BLE. Also, as shown in FIG. 4, the dongle may have a target 422 located on it so that the user knows where to place the transmitter for NFC communication.

[0328] After a sensor session has ended, various steps may be taken to conserve transmitter battery power so that the transmitter can be woken up for data extraction. For example, the transmitter's battery can be temporarily disconnected. In another implementation, the transmitter can transition to an inactive mode, sometimes referred to as "hibernation," sleep mode, or simply "inactive mode." The transmitter may be adapted to transition to such a mode after a timed termination of the sensor session, e.g., after 7 days, 14 days, etc. Various techniques disclosed below can be employed to wake the transmitter from such a mode so that data can be extracted therefrom.

[0329] For example, in one implementation, a wake-up circuit can be employed in the transmitter electronics that can immediately wake up the transmitter and speed up the startup process. More specifically, the wake-up circuit includes functionality to wake up the wireless transmitter after it has been turned off or placed in a low-power state after one or more measurements have been taken for a predetermined period of time, thereby conserving battery life. The wake-up circuit activates the transmitter and wirelessly transmits one or more measurements to a dedicated display or other smart device, e.g., a specialty product. When using a wake-up circuit, the sensor electronics module or transmitter can be configured to remain in a low-power or storage mode until just before the completion of the manufacturing process, e.g., before shipping by the manufacturer or distributor, so that the sensor electronics module does not consume power during storage at the manufacturer or distributor. Similarly, the sensor electronics module can also be configured to remain in a low-power or storage mode during predetermined inactive periods, e.g., between wireless communication sessions, e.g., during T inactive During this period, the sensor electronics module may transition to a "low power" or "no power" mode. It should be noted that in some embodiments, one or more components comprising the sensor electronics module, such as the transceiver, may wake up or shut down while one or more other components remain in a low power / sleep mode. In other embodiments, all components comprising the sensor electronics module may wake up or transition to a low power / sleep mode. Such components within the sensor electronics module or transmitter may include a power down module that can transition the transmitter from an active state to an inactive state using hardware, software, or firmware.

[0330] In one embodiment, the sensor electronics module wakes up and powers up (e.g., T inactiveTransitioning the sensor electronics module to an active or operational mode (e.g., for a period of time) can occur when a sensor reading above a predetermined threshold is detected; for example, the predetermined threshold can be specified in terms of counts or through other means, e.g., by use of a potentiostat, A / D converter, etc. In some implementations, the processor of the sensor electronics module (or other controller chip or device of the sensor electronics module) can wake up periodically (e.g., every 5 minutes) to monitor the counts. If the received count number falls below the predetermined count threshold, the processor or controller can return to a low-power mode. If the received count number exceeds the predetermined count threshold, the processor or controller wakes up and processes and / or forwards the sensor information to a telemetry module for distribution to one or more display devices. Also, in some implementations, the processor or other controller of the sensor electronics module can remain in an operational mode monitoring the counts to determine whether the sensor electronics module should begin receiving / acquiring and / or processing sensor information from the continuous analyte sensor; such continually occurring periodic monitoring checks can be performed several or more times.

[0331] Systems and methods according to present principles may incorporate features to avoid potential problems with the wake-up circuitry, particularly false or missed wake-ups. For example, some embodiments rely on a benchmark count threshold of approximately X counts (e.g., 9000 counts) that would typically be received over approximately Y seconds or minutes (e.g., 300 seconds or 5 minutes) of current application. In yet other embodiments, the benchmark count threshold can be monitored in the context of a persistent condition, where, for example, a persistent condition includes a consistent count frequency over a subset of Y periods.

[0332] In an implementation of the above method, an initial determination can be made whether the received count meets or exceeds a benchmark count threshold, after which another determination can be made to determine whether the received count meets or exceeds a second benchmark count threshold (U) for a second period of time (V). For example, the processor, or the sensor electronics module in general, will not wake up unless the second benchmark count threshold U is met or exceeded for the second period of time V.

[0333] The operations may further include determining that a second benchmark count threshold U is met or exceeded for a second period V over a plurality of intervals (n). This method may be used to check persistence, i.e., as a verification step to ensure that the sensor electronics module is actually intended to wake up from a low-power storage mode due to insertion of a continuous analyte sensor, as opposed to a false wake-up due to, for example, inadvertent contact with the sensor electronics module by a user. This implementation can ensure that counts indicative of actual sensor data are generated, rather than counts from electrostatic discharge (ESI)-based data, which tend to be bursty.

[0334] The various embodiments described above can address scenarios for conserving battery power, for example, in situations where the sensor electronics module is in a low power or storage mode. For example, the sensor electronics module may be in a low power or storage mode for a period of inactivity T, such as between wireless communication sessions. inactive However, in scenarios where the sensor electronics module must wake up to send or receive sensor information, it would be problematic if the sensor electronics module failed to wake up.

[0335] Accordingly, some embodiments implement a mechanism to ensure that the sensor electronics module wakes up when warranted. In particular, some embodiments utilize a watchdog timer. A watchdog timer is a hardware feature of an electronic component or circuit that includes a countdown timer. A watchdog timer can be used to detect and recover from system anomalies or malfunctions. For example, if the countdown timer reaches zero, the chip will reset. Because the watchdog is hardware and not controlled by software, software errors cannot prevent its operation.

[0336] Further details of such wake-up circuits are described in U.S. Patent Application No. 62 / 270,485, filed December 21, 2015, entitled "Continuous Analyte Monitoring System Power Conservation," which is owned by the assignee of the present application and is incorporated herein by reference in its entirety.

[0337] In another embodiment, system 1750 of FIG. 33 illustrates an exemplary wake-up circuit that can be used within the transmitter electronics to immediately wake up the transmitter and speed the startup process. For example, the wake-up circuit can be used to wake the transmitter from storage mode, and data extraction can be further initiated by the wake-up circuit. For example, when an operator / HCP removes the transmitter from the sensor and connects it to a fixture, such as a reader, the transmitter can be configured to begin advertising, and the pairing and extraction process can begin. This can include a challenge value for Bluetooth pairing, including a hashtag, and forming a secure link.

[0338] More specifically, FIG. 33 shows transmitter electronics 764 stationary adjacent to an HCP fixture, such as a reader 771, which may be implemented as a dongle attached to the HCP device. The transmitter electronics 764 includes an ASIC 766 and memory 768. A transmitter 770 is configured within the transmitter electronics to communicate with an external device, which may include an NFC circuit 774 and a BLE circuit 776. A calibration module 752 is shown, which can perform sensor calibration within the transmitter electronics. Alternatively, such calibration can be performed on a smart device in signal communication with the transmitter. The sensor coupling circuit 772 enables conductive communication with a wire from the indwelling analyte sensor. A wake-up circuit 778 is provided to accomplish the functions of the wake-up circuit described above. As shown, the wake-up circuit 778 may include a wake-up pin 780, which allows convenient access during debugging, i.e., so that wake-up can be performed quickly. For example, a properly configured wake-up circuit may apply a "high" level potential to such a wake-up pin 780, which may initiate a routine that results in the transmitter waking up. Alternatively, a logically low level potential may be applied. The rest of the time, the pin may be left floating.

[0339] In addition to flowchart 1800 of FIG. 34, one way to wake up the transmitter after the sensor session has ended is to probe it for an NFC signal (step 782), e.g., to initiate a query to the transmitter for on-demand information. Data can then be transferred using NFC or other means, e.g., BLE (step 784). In this regard, it should be noted that NFC can also be used to transfer data, and BLE can also be used for the wake-up signal. Generally, NFC is well-suited for wake-up due to its speed and low power consumption. However, the security of NFC generally relies on proximity.

[0340] However, problems that arise with these devices include false wake-ups. For example, energy captured by the NFC antenna can lead to false wake-ups and data corruption. If the wake-up circuitry includes a wake-up pin, electromagnetic energy can couple to the pin, causing similar harmful wake-ups, data corruption, and battery drain (e.g., it is generally desirable to maintain 10% of battery charge for data extraction). In certain instances, energy captured by the NFC antenna can couple to the sensor circuitry or power circuits, such as the power rails connected to the ASIC or rectifier. The coupled energy can introduce noise into the sensor data and adversely affect the transmitter electronics. Therefore, it is important to know when to consider sensor data during various intentional and unintentional NFC operations and when to ignore it.

[0341] An exemplary method for doing so is provided by flowchart 1850 of FIG. 35. In this method, interrupt flags are used to identify specific relevant key points in the data transfer. A feedback mechanism is used to identify when the circuitry is harvesting energy and flag the time-corresponding sensor data appropriately. For example, interrupt flags may be used as follows: A first flag, FLAG_1, may be set when it is determined that energy harvesting is occurring by the NFC antenna / circuitry (step 786). Similarly, a second flag, FLAG_2, may be set when it is determined that valid NFC communication is occurring between the transmitter and receiver, e.g., a smart device (step 788). For example, FLAG_2 is set during valid data exchange between the transmitter and receiver.

[0342] A test is performed as to whether both FLAG_1 and FLAG_2 are set (step 790). If the test result is positive, it can be determined that intentional data is being exchanged via NFC. In this case, in one implementation, sample data corresponding to such periods can be processed to compensate accordingly. For example, the processor can first flag sensor data measured or sampled during NFC operation, and then either retain (step 792) or adjust (step 794) the data. Other options include weighting the data differently, filtering the data, etc.

[0343] On the other hand, if only FLAG_1 is set and FLAG_2 is not set, it can be determined that unintended data is being captured via NFC, e.g., random noise is being captured from other RFID sources. While various steps can be taken, in one implementation, such data can be removed, deleted, or ignored from future calculations (step 796).

[0344] In other embodiments, an adjustable sampling rate may be employed when using NFC. For example, adjustable sampling may be used to identify whether NFC is affecting the signal. In this case, the sampling rate may be changed based on, for example, whether FLAG_1 is set.

[0345] 36A, a hardware approach may also be employed to address this issue. In particular, following the termination of the session (step 802), such a hardware approach may include actions taken to disrupt operation of the wake-up pin or turn off the NFC antenna or circuitry (step 810).

[0346] Note that in the former approach, the wake-up pin is typically floating via a pull-up / pull-down resistor, which may be, for example, a resistor extending between the wake-up pin and ground. See, for example, FIG. 36B, where a transmitter system 817 includes a transmitter chip 819 having a wake-up pin 827 connected to ground 823 via resistor 821. When no current is flowing, the wake-up pin is at the same voltage as ground; e.g., the voltage V at point 825 is the same as ground. However, sufficient electromagnetic induction (EMI) can cause a false transition on this pin, resulting in the voltage at point 825 being different from ground and causing a false wake-up. Typically, EMI is intermittent. However, multiple false wake-ups caused by EMI can begin to have a significant negative impact on battery life. During a wake-up event, the battery automatically connects to the processor, consuming additional current compared to the current consumed in storage mode. This results in a reduced service life.

[0347] Thus, in one implementation, the wake-up pin can be shorted (step 804). For example, a jumper 829 can be used to connect the wake-up pin to ground (see FIG. 36B). Alternatively, the wake-up pin can be hardened or otherwise made more robust against EMI (step 806). For example, strong pull-up / down resistors, and even capacitors if necessary, can be used. Finally, the wake-up pin can be effectively disabled before entering the memory mode (step 808), for example, by providing instructions to the wake-up pin via an ASIC.

[0348] In the latter approach, one implementation is to use a threshold detector (step 812). For example, a detector mechanism can be implemented to identify energy captured by the NFC antenna, and such captured energy can be monitored and compared to a threshold. If the threshold is met or exceeded, the NFC circuitry and / or the NFC antenna can be shut off by a switch.

[0349] In other embodiments, a wake-up switch interrupt can be used (step 814). For example, if it is determined that the NFC antenna or circuitry is only being used to wake the transmitter from sleep mode, the NFC antenna / circuitry can be disabled after the wake-up process is complete. In this way, the NFC antenna will no longer pick up random signals.

[0350] In yet another implementation, a ground plane may be employed (step 816). In this implementation, an additional ground plane may be employed to vent excess energy captured by the NFC antenna. In yet another implementation, the captured excess NFC energy may be used as a flag to operate a DC-DC converter (step 818).

[0351] The wake-up circuit described above is highly beneficial by providing a convenient method for activating the transmitter. However, the same is not without its drawbacks. For example, some use cases require the patient to remove the entire sensor / transmitter / adhesive patch assembly after a sensor session and place it in a disposal bag. However, in such cases, especially if the environment in which the transmitter is placed is such that a conductive path is periodically created between the sensor leads, erroneous current may pass between the sensor leads, causing false activation and draining the transmitter battery. Therefore, battery power can be conserved in the transmitter by disabling the wake-up circuit. This can be done as follows:

[0352] One way to effectively disable the wake-up circuitry is to increase the threshold potential required to be measured for processor verification of sensor operation, for example, by increasing the benchmark count threshold described above. In this way, an accidental wake-up may be falsely noticed at least until the next threshold measurement, e.g., measured at multiple intervals as described above, and thus the system will transition back into storage mode more quickly.

[0353] Another approach to improving consumer health is to make sensors and transmitters smaller and potentially disposable, as well as extending the lifespan of sensor sessions by taking battery consumption into account. For example, some users may want to purchase such devices at a store and use the same device over a two-week period to get an idea of their blood glucose fluctuations, even if the device does not provide real-time data. Such disposable CGMs may simply collect data and enable periodic data transfer. To reduce costs and streamline data transfer, disposable CGMs may collect data and periodically downsample it, accordingly retaining only the small number of points necessary to accurately describe blood glucose exposure. For example, the CGM and transmitter may retain only data related to maximum values, minimum values, and specific inflection points.

[0354] 37, during a sensor session, the transmitter may receive count data from the sensor (step 820). The transmitter may store the count data along with a timestamp (step 822). For example, the timestamp may be an absolute timestamp indicating the date and time, or the timestamp may be relative, indicating that the transmitter has been in use for, for example, 1000 minutes during this sensor session.

[0355] The transmitter can include various methods for compressing the data (step 824). As described above, the transmitter can compress the data (step 826), and such compression can include using timestamp data. Stable or other linear data, or data that can be expressed functionally, may be deleted and replaced with just endpoint data or functional data. For example, stable data can be deleted by only storing and transmitting data points between inflection points. For example, if glucose stabilizes at 90 mg per DL for two hours and then slowly reaches 95 mg per DL, the data in between can be eliminated and only the endpoints can be stored and / or transmitted. Alternatively, only data that changes more than a predetermined amount, e.g., 5 or 10 mg / dL, can be recorded and / or transmitted, with the data in between interpolated.

[0356] Other standard data compression techniques may also be employed (step 828). Such data compression techniques may include Lempel-Ziv compression, Huffman coding, or algorithmic coding. It is expected that using such techniques, the data transfer rate may be high enough to transfer an entire sensor session's worth of data in just a few seconds.

[0357] Alternatively, a CGM that is disposable in this manner need not necessarily have or include calibration or conversion algorithms: such processing can be provided elsewhere, for example, on the display device or in the cloud.

[0358] Because its use is retrospective, certain artifacts can be completely removed to avoid potential misinterpretation. These include artifacts such as "dip and recovery" disturbances and PSD-type artifacts. Such data segments may be blocked on the display as "glucose data unavailable" or similar. If the artifact's duration is short enough, the simplified glucose trace need not be affected at all.

[0359] The download or extraction of data can be as described above, or in a particularly simple implementation, a Wi-Fi hub or the like can be provided. Such a data hub can be used for the capture / transfer of all remote health data as part of a healthcare subscription, including not only CGM but also data such as heart rate, weight, blood pressure, etc.

[0360] Benefits include cost and data transfer time. In particular, costs are reduced by avoiding data transmission and by opting for passive communication techniques. Memory storage time and costs are reduced by intelligently downsampling hundreds of daily data points to a much smaller number, e.g., 10-20 points, and by incorporating lossless data compression methods.

[0361] To further improve accuracy, the data may be post-processed within the transmitter, e.g., undergo steps such as smoothing to improve accuracy (step 830 of Figure G5). Post-processing can occur, for example, after each CGM session, e.g., for a 1-week period, a 10-day period, a 14-day period, etc. In this way, the need for an external software application to perform such raw data post-processing may be eliminated. In another implementation, data may be post-processed at the end of each 24-hour period. Smoothing, as well as lessons learned and insights gained, can be applied proactively while the user is still wearing the device, maximizing potential overall accuracy after an entire CGM sensor session. As a result of such retrospective processing, the range bars of glucose data on the trend graph may narrow over time as additional data is acquired through retrospective processing.

[0362] Contextual awareness can also be employed to provide further insight and a degree of "calibration." For example, rapid changes are expected during mealtimes. Such contextual data can be gathered through temporal data, including an analysis of historical patterns, e.g., the time a user typically eats lunch. Contextual data can also be gathered from geolocation data, for example, if the user is in the same location as a restaurant known to be frequented. Based on the contextual information and reference timeframes, in addition to historical patterns of the user's activity, the sensitivity of key algorithms can be increased or decreased during these mealtime periods. In this case, timestamp data can also be used.

[0363] As a further method for improving data accuracy and reliability, the transmitter can use available external data to provide one or more insights (step 832). For example, if the transmitter uses an accelerometer or other activity measurement method, or if the transmitter is in signal communication with a display device that includes an accelerometer, accelerometer data can be used to determine various insights. For example, such insights can include the reason for particularly noisy data and whether such noise is due to user exercise or signal impairment. For example, long periods of activity and / or short periods of intense activity, as measured by an accelerometer, will increase the sensitivity of algorithms used to predict or measure glucose. If sustained exercise activity is subsequently measured, the confidence level of the rate of change can increase. In other words, if the transmitter or application knows that the user is exercising, the noisy data is maintained because it has increased confidence that it is not caused by noise in the data.

[0364] Ambient noise sensors can be used as well. For example, such ambient noise sensors can be used to identify sleep or other periods when significant ambient noise reduction over an extended period is identified. Such can also be correlated with time of day to more accurately identify sleep intervals.

[0365] Using all such collected data, a statistical analysis is performed at the end of the diagnostic session, giving users indications about their performance and a convenient overall "score" for clinician use after the CGM period. Key statistics may include "% time in target range" or "% time in hypoglycemia," indicators of hypoglycemia risk, etc. This overall "score" can be used to "triage" high-risk patients, triggering workflow to help clinicians focus on these individuals first when reviewing the data. This can serve as a prelude to detailed statistical reports or more formal clinical decision support software.

[0366] For example, a large diabetes center or large diagnostic lab may process diagnostic CGM data from 100 patients in a day and generate 100 individual reports. Results and corresponding patients can be triaged based on the overall "risk score" provided, allowing clinicians to contact high-risk patients first and address ongoing concerns identified in the CGM data.

[0367] example In one particular exemplary implementation, a small, single-use, disposable sensor product can be provided with a "smart" transmitter, i.e., a transmitter that provides one or more processing functions, such as the smoothing described above, and can be configured to push data to a receiver, such as a specialized product or the user's smart device. After use, the entire system, i.e., the transmitter and sensor, and adhesive patch, can be returned to the HCP for data extraction and analysis. In some cases, data extraction will already be performed by the connection between the transmitter and receiver. Such devices may be calibrated only once or may be provided with a factory calibration. Existing applicator technology can be used to install the sensor on the user, and in some cases, the transmitter can be snapped onto the sensor housing. Such technology is described, for example, in U.S. Patent Application No. 15 / 298,721, filed October 20, 2016, entitled "Transdermal Analyte Sensor, Applicator Therefor, and Related Methods," which is owned by the assignee of the present application and is incorporated herein by reference in its entirety.

[0368] In another specific exemplary implementation, a small, single-use, disposable sensor product may be equipped with a "smart" transmitter, as described above, that can be used primarily for non-auxiliary purposes. Data from such a smart transmitter, even during a sensor session, may be shared with third parties, including, for example, payers. Such devices may be factory-calibrated and may even be available without a prescription. An outfitting system may be provided for installing them in the patient.

[0369] Implementation of systems and methods in accordance with the present principles can include providing functionality such as target ranges, creating soft alarms or notifications that provide education to the user after the fact, for example, providing event entry but not necessarily in real time to enable targeted medication adherence input, providing appropriate APIs for setting event entry from a meal application or from a user interface directly by the user, providing appropriate APIs for setting event entry from a health kit, etc.

[0370] Other implementations include HCP offices communicating with patients using their encrypted email system. Such information can be provided "all in one place," for example, as part of the electronic medical record. Files corresponding to the 14-day (or other sensor session duration) report may be uploaded directly to the EMR and provided in a printable format.

[0371] In some implementations, a home screen can be provided on the receiving device showing trends, blood glucose levels, an indication of whether the patient is "in range" or "out of range," and such thresholds for such ranges can be set by the HCP as part of the HCP configuration. Events can be indicated using date / timestamps. Statistics may be provided that allow the user or HCP to compare one day to another. Patients can use such data to learn "cause and effect" based on what is displayed on the home screen, and in this way be enabled or empowered to educate themselves on such aspects.

[0372] The patient application can provide color coding to indicate whether blood glucose levels are high, low, or on target. Smartphone notifications can be configured as well, indicating to the user whether they are high or low based on the configured alerts.

[0373] In some implementations, during a sensor session, if a connected receiver is employed, it can inform the HCP if the patient remains high or experiences a hypoglycemic event.

[0374] The HCP application may be configured to provide the HCP with reports containing data such as average blood glucose, average A1c, frequency of hypoglycemic events, percentage of time above and below target range, and so on. The application may overlay results to illustrate trends. The application may post events, including those related to nutrition, stress, activity, illness, infection, sleep patterns, and so on. Such applications may be available for HCP review at least immediately prior to a patient visit to better inform the patient's consultation, and the application may highlight specific important information to enable the HCP to better formulate a treatment plan for the patient. Highlighting specific important information may include comparing detected or determined patterns to criteria stored in a database to detect particularly risky patterns. In many cases, the HCP application can be configured to enable the HCP to break down desired changes into small steps that tend to be most effective for the patient, promoting a positive reinforcement loop.

[0375] In one implementation, patients can learn which variables affect their health by performing daily tasks and learning from an application, such as application 403, how their body responds to various activities. In this way, patients can gain a deeper understanding of cause and effect and remove some of the guesswork from treating their illnesses. For example, exemplary tasks could be eating their favorite meal at their favorite restaurant, drinking orange juice with breakfast, or taking a 30-minute walk. The patient application can provide an overview of how these activities affected their health, at least in terms of glycemic response. If such sensors are also available, patients can learn how such activities affected their blood glucose levels, cholesterol levels, blood pressure, etc. The patient application can also be configured to prompt patients to take medications and remind them of which medications to take. Smartphone reminders and notifications can also be set for taking vitamins, measuring blood pressure, etc.

[0376] The application can be configured to allow users to select goals that are important to them and provide customized education, behaviors, and milestones for that goal or challenge. For example, the application can be configured to allow users to input goals they want to master, with a specific priority. Challenges could include, for example, "I want to wear my favorite high school jeans again" or "I want to make healthy food choices near my work." A challenge could last, for example, two weeks. Once accomplished, patients can move on to the next step, selected by their priority. The application can provide daily progress reports that can be shared with others. The application can also display successful people and those struggling with the same goal. For example, the app could say, "The goal you selected was also selected by 85% of other people your age. They reported that portion control and exercise were key to their success."

[0377] In one exemplary implementation, a Certified Diabetes Educator (CDE) can assist a new patient using the following steps: The CDE can inquire as to whether the patient has a smartphone, and if so, the CDE can help the patient download the patient application onto the smartphone. The CDE can then insert the sensor into the patient's abdomen and then fit the transmitter into the sensor pod. At this point, the application can be configured. Various user accounts can be set up, which may include appropriate disclosures and verifications to ensure compliance with HIPAA and other legal requirements. Patient information can be entered, including their name, email address, username, password, and password confirmation. The patient can then be asked or prompted to read and follow various safety statements, such as not wearing the device while undergoing an MRI. The patient can then confirm their understanding and agreement to the various statements.

[0378] The CDE can then set the patient's glucose threshold and, therefore, the patient's target range. The CDE can explain that the patient's smartphone will be notified when their glucose concentration rises above or falls below the threshold. The CDE can then assist the patient in pairing the sensor and transmitter to the application. Various methods for performing such pairing are described above. The CDE can then instruct the patient on how to mark events, such as eating carbohydrates or engaging in physical activity, and provide the patient with such event entry techniques. The CDE can then provide a booklet or other information on how the user can obtain additional information, if needed or desired. The CDE can explain to the patient that the sensor has been verified and validated to be working, e.g., receiving the appropriate number of counts, but that usable glucose concentration data will not be available for several hours.

[0379] After the sensor session ends, for example, after 14 days, a message appears: "Congratulations, your session is over. Swipe for sensor removal instructions." If data was uploaded during the session, the patient can dispose of the sensor and transmitter in an appropriate manner. If not, the user can keep the same, or just the transmitter, and provide it to the doctor for data extraction at their next visit. Reviewing the data using the HCP application allows the doctor to provide various insights and suggestions to the patient.

[0380] In some of the examples described above, the patient sets up a user account and associates it with an application on the patient's mobile device. In other examples, such as that shown in FIG. 8, the HCP assists the patient in this task. In an alternative implementation, the user account can be set up on the patient's behalf before the patient is provided with a kit including the sensor, transmitter, and applicator. In one particular implementation, the kit can also include a mobile device (e.g., an Android phone, an iPhone, etc.) with the application pre-installed for the patient. In another implementation, the patient can use their own mobile device on which the application can be installed.

[0381] FIG. 41 shows an example of how a patient's user account can be set up on a server so that the patient can automatically log in using an application on their mobile device after entering minimal information.

[0382] In step 886, prior to providing the kit to the patient, a patient account is set up on behalf of the patient in a database maintained on the server. Among other things assigned to the patient account, such as the patient name, date of birth (DOB), etc., the patient account is assigned a unique identifier for the mobile device included in the kit that will be provided to the patient. For example, the identifier can be the International Mobile Equipment Identity (IMEI) of the mobile device. If the mobile device used is provided by the user and is not part of the kit, a different mobile device identifier can be assigned and used as the unique identifier.

[0383] In step 888, the patient is provided with a kit including the mobile device. In step 890, the user launches an application that establishes communication with the server and automatically transmits the mobile device's unique identifier. The application also transmits patient information pre-assigned in the patient record that is used to associate the patient with the mobile device. This information may include, for example, one or more of the following: the patient's email address, date of birth, phone number, etc.

[0384] In step 892, the server attempts to match the mobile device's unique identifier and patient information with patient records stored in its database. If the match is successful, in step 894, the server sends the application the credentials necessary to log in or otherwise access the matching patient record in the database. Then, in step 896, the application uses the credentials to access the patient record.

[0385] The automatic login procedure described above is described for a new patient, for which a user record must be created. This procedure can also be used for existing patients. For example, if an existing patient is provided with a new transmitter instead of providing a kit to a new patient in step 888, instead of creating a new patient account, an identifier for the new transmitter is entered into the patient's existing record in step 886. Thus, in this manner, the process shown in FIG. 41 allows both new and existing patients to automatically log in and access their patient account records with minimal effort.

[0386] It should be noted that in some cases the functionality of the server used in the automatic login procedure described above can be distributed among multiple servers that may or may not be controlled by the same entity. For example, in one particular example, one or more servers may be controlled and operated by an equipment manufacturer, and one or more additional servers may be controlled and operated by a database provider.

[0387] For ease of explanation and illustration, in some instances, the detailed description describes exemplary systems and methods in terms of a continuous glucose monitoring environment, but it should be understood that the scope of the invention is not limited to that particular environment, and those skilled in the art will appreciate that the systems and methods described herein may be embodied in a variety of forms. Accordingly, any structural and / or functional details disclosed herein should not be construed as limiting the systems and methods, but rather are provided as attributes of representative embodiments and / or arrangements to teach those skilled in the art one or more ways to implement the systems and methods that may be advantageous in other contexts.

[0388] For example, without limitation, the described monitoring systems and methods may include sensors that measure the concentration of one or more analytes (e.g., glucose, lactate, potassium, pH, cholesterol, isoprene, and / or hemoglobin) and / or other blood or bodily fluids of or associated with a host and / or another party.

[0389] By way of example, and not limitation, embodiments of the monitoring systems and methods described herein may include fingerstick blood sampling, blood analyte test strips, non-invasive sensors, wearable monitors (e.g., smart bracelets, smart watches, smart rings, smart necklaces or pendants, movement monitors, fitness monitors, health and / or medical monitors, clip-on monitors, and the like), adhesive sensors, smart textiles and / or garment-embedded sensors, sensors, transdermal (i.e., transcutaneous) sensors, and / or shoe inserts and / or insoles containing swallowed, inhaled, or implantable sensors.

[0390] In some embodiments, without limitation, the monitoring systems and methods may comprise other sensors instead of or in addition to the sensors described herein, such as inertial measurement units including accelerometers, gyroscopes, magnetometers, and / or barometers, movement, altitude, position, and / or location sensors, biometric sensors, such as optical sensors including optical heart rate monitors, photoplethysmography (PPG) / pulse oximeters, fluorescence monitors, and cameras, wearable electrodes, electrocardiogram (EKG or ECG) sensors, electroencephalogram (EEG) sensors, and / or electromyogram (EMG) sensors, chemical sensors, such as flexible sensors for measuring extension, displacement, pressure, weight, or impact, galvanometric sensors, capacitive sensors, electric field sensors, temperature / heat sensors, microphones, vibration sensors, ultrasonic sensors, piezoelectric / piezoresistive sensors, and / or transducers, for measuring information of or related to the host and / or another party.

[0391] As used herein, the terms “computer program medium” and “computer usable medium” and “computer readable medium,” as well as variations thereof, generally refer to transitory or non-transitory media, such as, for example, main memory, storage unit interfaces, removable storage media, and / or channels. These and other various forms of computer program medium or computer usable / readable media may be involved in carrying one or more sequences of one or more instructions to a processing device for execution. Such instructions embodied on a medium may generally be referred to as “computer program code” or “computer program product” or “instructions” (which may be grouped in the form of a computer program or other grouping). When executed, such instructions may enable a computing module or its processor or processors connected thereto to perform the features or functions of the present disclosure as discussed herein.

[0392] Various embodiments have been described with reference to specific exemplary features thereof. It will be apparent, however, that various modifications and changes may be made thereto without departing from the broader spirit and scope of the various embodiments as set forth in the appended claims. The specification and drawings are, therefore, to be regarded in an illustrative rather than a restrictive sense.

[0393] Although described above in terms of various exemplary embodiments and implementations, it should be understood that the various features, aspects, and functions described in one or more of the individual embodiments are not limited in their applicability to the particular embodiment(s) for which they are described, but instead may be applied alone or in various combinations to one or more of the other embodiments of the present application, whether or not such embodiment(s) are described, and whether or not such features are presented as part of a described embodiment. Thus, the breadth and scope of the present application should not be limited by any of the exemplary embodiments described above.

[0394] Terms and phrases used in this application, and variations thereof, unless expressly stated otherwise, should be considered open-ended as opposed to limiting. As examples of the foregoing, the term "including" should be read to mean "including but not limited to," etc.; the term "examples" is used to provide illustrative examples of the items under discussion, not an exhaustive or limiting list thereof; the term "one" or "one" should be read to mean "at least one," "one or more," etc.; and adjectives such as "conventional," "traditional," "usual," "standard," "known," and similar terms should not be construed to limit the described items to items available in a given period or with respect to a given time, but instead should be read to encompass conventional, conventional, usual, or standard technology that may be available or known now or at any time in the future. Similarly, when this document refers to technology that is apparent or known to those of ordinary skill in the art, such technology encompasses technology that is apparent or known to those of ordinary skill in the art now or at any time in the future.

[0395] The presence of a broader term or phrase, such as "one or more," "at least," "but not limited to," or in some instances other similar phrases, should not be read to imply that a narrower case is intended or required when such broader term is not present. The use of the term "module" does not imply that the components or functionality described or claimed as part of the module are all configured in a common package. Indeed, any or all of the various components of a module, whether control logic or other components, may be combined in a single package or maintained separately, and may even be distributed in multiple groupings or packages or at multiple locations.

[0396] All numbers expressing quantities of ingredients, reaction conditions, and so forth used herein should be understood to be modified in all instances by the term "about." Accordingly, unless otherwise indicated, the numerical parameters set forth herein are approximations and 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 the claims in any application claiming priority to this application, each numerical parameter should be construed in light of the number of significant digits and ordinary rounding approaches.

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

[0398] Unless otherwise defined, all terms (including technical and scientific terms) are to be given their ordinary and customary meanings to those of ordinary skill in the art and are not limited to any special or customized meaning unless expressly defined herein. The use of a ...

Claims

1. 1. A continuous glucose monitoring device configured for use by a healthcare professional (HCP), comprising: The housing and a circuit configured to receive a signal from a transmitter coupled to the indwelling glucose sensor; a calibration module configured to convert the received signals into clinical units; a user interface configured to display the measured glucose concentration on the clinical unit; the user interface is further configured to receive input data related to a patient level; The device, wherein the input data regarding the patient level causes the device to operate in a mode based at least in part on one or more patient characteristics.

2. The device of claim 1 , wherein the one or more patient characteristics include a technical skill level of a user.

3. Item 11. The device of any one of the preceding items, wherein the one or more patient characteristics include the user's type of diabetes.

4. 4. The device of claim 3, wherein the user interface is further configured to prompt the HCP to input data regarding whether the user has T-1 diabetes, T-2 diabetes, or pre-diabetes.

5. Item 11. The device of any one of the preceding items, further comprising a memory for storing glucose concentration values in clinical units, the memory further configured to store the input data.

6. The device of claim 5 , further comprising an output circuit configured to transmit the stored glucose concentration value.

7. 7. The apparatus of claim 6, wherein the transmission is configured to occur over a period of less than five seconds.

8. 7. The device of claim 6, wherein the transmission is configured to occur using near field communication or Bluetooth low energy.

9. Item 11. The device of any one of the preceding items, wherein the transmitter is configured to store measured glucose concentration values.

10. 10. The device of claim 9, further comprising an output circuit configured to transmit the stored glucose concentration value.

11. 11. The device of claim 10, wherein the transmission is configured to occur using near field communication or Bluetooth low energy.

12. 1. A method of configuring a continuous glucose monitoring device, comprising: Displaying a user interface on the HCP device; prompting the HCP to enter data regarding the patient on the user interface; and operating a continuous glucose monitoring device including an indwelling sensor and a signal coupling transmitter in signal communication with the HCP device in a mode based on the input data.

13. 13. The method of claim 12, wherein the data is about whether the patient has T-1 diabetes, T-2 diabetes, or pre-diabetes.

14. The method of any one of claims 12 to 13, wherein the data is about the technical skill level of the user.

15. The method of any one of claims 12 to 14, further comprising storing glucose concentration values in clinical units and said input data.

16. 16. The method of claim 15, further comprising transmitting the stored glucose concentration value from the transmitter to the HCP device upon receiving or triggered by an interrogation signal.

17. 17. The method of claim 16, wherein the interrogation signal is received by the transmitter from a near field communication device or a Bluetooth low energy device coupled to the HCP device.

18. The method of any one of claims 12 to 17, wherein the continuous glucose monitoring device is configured to download an application configured to control the continuous glucose monitoring.

19. 20. The method of claim 18, wherein the mode is a blind mode such that the application running on the continuous glucose monitoring device is configured to receive and store, but not display, glucose concentration data.

20. 20. The method of claim 19, wherein the application is further configured to receive input data corresponding to event data, the event data corresponding to medication data, dietary data, or exercise data.

21. 20. The method of claim 18, wherein the mode is a non-blind mode such that the continuous glucose monitoring device is configured to receive, store, and display glucose concentration data.

22. 20. The method of claim 18, wherein the mode is configured to start in a blind mode and switch to a non-blind mode a predetermined time after the sensor session begins.

23. 20. The method of claim 18, wherein the mode is configured to start in a blind mode and switch to a non-blind mode upon the occurrence of a trigger event.

24. 24. The method of claim 23, wherein the trigger event corresponds to a patient parameter that meets a predetermined threshold criterion.

25. 20. The method of claim 18, wherein the mode is configured to start in a blind mode and switch to a non-blind mode upon receiving a trigger signal from an external device.

26. 26. The method of any one of claims 12-25, wherein the patient data includes a transmitter serial number, the transmitter serial number having a plurality of extensions selectable by the HCP, the extensions selected to be appropriate for the patient, and the serial number extensions specify a mode in which the continuous glucose monitoring device should operate.

27. 20. The method of claim 18, wherein the mode is a real-time blind mode such that an application running on the continuous glucose monitoring device is configured to receive and store but not display real-time glucose concentration data, while displaying non-real-time historical glucose concentration data.

28. 28. The method of any one of claims 12 to 27, further comprising running a diagnostic application on the HCP device, the diagnostic application enabling an HCP to view and set CGM parameters without altering the course of treatment.

29. 29. The method of claim 28, wherein the parameters include a time remaining on the sensor, a state of the sensor, and a current time of the session.

30. The method of any one of claims 12 to 29, wherein the mode is a blind mode and the transmitter is configured to store data measured by the indwelling sensor.

31. 1. A method for configuring a continuous glucose monitoring device for use by a patient, said configuration being performed by a HCP, comprising: Establishing a communication session associated with an HCP account between an HCP client device and a server; prompting an HCP to enter patient data on a user interface associated with said HCP client device; and prompting the HCP on the user interface associated with the client device to input identification data corresponding to a transmitter and / or sensor associated with the continuous glucose monitoring device; receiving the entered patient data and the sensor identification data; and transmitting the entered patient data and the identification data to the server for storage and association with a patient account.

32. 32. The method of claim 31, wherein the identification data is identification data relating to a transmitter.

33. 33. The method of any one of claims 31-32, further comprising receiving an output from the server in response to transmitting the entered patient data and the identification data to the server, the received output including code configured to be used by a patient smart device to download an application for use in continuous glucose monitoring.

34. 34. The method of claim 33, wherein the code is received by email or text.

35. The method of any one of claims 31 to 34, further comprising transmitting configuration information to the continuous glucose monitoring device.

36. 36. The method of claim 35, wherein the transmission is by short-range wireless communication or Bluetooth low energy.

37. 1. A method for configuring a continuous glucose monitoring device for use by a patient, said configuration being performed by a HCP, comprising: Establishing a first communication session associated with an HCP account between an HCP client device and a server; prompting an HCP to enter patient data on a user interface associated with said HCP client device; establishing a second communication session between the HCP client device and a transmitter associated with the glucose monitoring device, whereby the transmitter and / or sensor associated with the continuous glucose monitoring device can be identified to the HCP client device; A method comprising: receiving the entered patient data and the identification data; and transmitting the entered patient data and the identification data to the server for storage and association with a patient account.

38. 38. The method of claim 37, wherein the second communication session transmits transmitter identification data to the HCP client device.

39. 39. The method of any one of claims 37-38, further comprising receiving an output from the server in response to transmitting the entered patient data and sensor identification data to the server, the received output including code configured to be used by a patient smart device to download an application for use in continuous glucose monitoring.

40. 40. The method of claim 39, wherein the code is received by email or text.

41. The method of any one of claims 37 to 40, further comprising transmitting configuration information to the continuous glucose monitoring device.

42. 42. The method of claim 41, wherein the transmitting is by short-range wireless communication or Bluetooth low energy.

43. 1. A reader configured for use by a HCP, comprising: The housing and a first circuit configured to receive a first signal from a transmitter associated with the indwelling glucose sensor; a second circuit configured to transmit a second signal to the computing environment.

44. 44. The apparatus of claim 43, wherein the circuitry configured to receive a first signal is configured to receive the first signal using a wired or wireless communication protocol.

45. 45. The apparatus of claim 44, wherein the circuitry configured to receive a first signal is activated by an interrogation signal from the transmitter.

46. 45. The apparatus of claim 44, wherein the circuitry configured to receive a first signal activates the transmitter using an interrogation signal.

47. 47. The device of claim 46, wherein after activation, the circuitry extracts stored glucose concentration data from the transmitter.

48. 45. The device of claim 44, wherein the communication protocol is wireless and is selected from the group consisting of Bluetooth low energy communication or near field communication.

49. 49. The apparatus of any one of claims 43 to 48, further comprising a third circuit configured to measure one or more operating parameters of the transmitter and to provide an output based on the measured one or more operating parameters, whereby a state of operation of the transmitter can be determined.

50. 1. A reading device configured for use by a HCP, the reading device being configured to determine proper functioning of a transmitter associated with a continuous glucose monitor, the reading device comprising circuitry configured to measure one or more operating parameters of the transmitter and provide an output based on the measured one or more operating parameters, thereby determining an operational status of the transmitter.

51. 1. A method for determining proper activation of a transmitter, the transmitter being associated with a continuous glucose monitor; Detecting insertion of the sensor at the transmitter; and upon said detection, transitioning said transmitter from an inactive state to an active state, wherein in said active state said transmitter transmits a signal encoded with data corresponding to a reading received from said sensor.

52. 52. The method of claim 51, wherein in the active state, the transmitter transmits signals using Bluetooth low energy.

53. The method of any one of claims 51 to 52, further comprising receiving the transmitted signal at an HCP device.

54. 54. The method of any one of claims 51 to 53, further comprising receiving the transmitted signal at a patient device.

55. 55. The method of claim 54, wherein the patient device is a smartphone or a smartwatch.

56. 56. The method of claim 55, further comprising transmitting a signal from the transmitter to an HCP device upon receipt of an acknowledgment signal from the patient device by the transmitter, thereby providing confirmation to the HCP device that the patient device is operating properly with the patient sensor and transmitter.

57. 56. The method of claim 55, further comprising collecting data from the transmitter over a period of time from the transmitter measured by the sensor.

58. 58. The method of claim 57, wherein said extracting comprises interrogating said transmitter using said HCP device.

59. 59. The method of claim 58, wherein the interrogation is performed using near field communication or Bluetooth low energy.

60. 60. The method of any one of claims 51 to 59, further comprising transmitting a signal from the transmitter, the signal encoded with data indicating that sensor insertion has occurred.

61. 1. A method for rapidly activating a transmitter that is stored for a predetermined period of time and configured to physically engage an indwelling glucose sensor and that is configured to transmit a signal representative of a measured glucose concentration value to a mobile device, comprising: transmitting a wake-up command from the HCP device to the transmitter; The method, wherein the wake-up command transitions the transmitter from an inactive state to an active state.

62. 62. The method of claim 61, wherein sending the wake-up command is performed using near field communication or Bluetooth low energy.

63. 63. The method of any one of claims 61 to 62, wherein sending the wake-up command is performed at least in part by communicating a signal to a wake-up pin on a processor operating the transmitter.

64. 64. The method of any one of claims 61 to 63, wherein sending the wake-up command is performed in response to the detection of a signal measured by the indwelling glucose sensor.

65. 1. A method for rapidly activating a transmitter that is stored for a predetermined period of time and configured to physically engage an indwelling glucose sensor and that is configured to transmit a signal representative of a measured glucose concentration value to a mobile device, comprising: detecting, at the transmitter, a signal from a connected sensor; transitioning the transmitter from an inactive state to an active state if the detected signal is determined to have an amplitude above a predetermined threshold.

66. 1. A method for rapidly activating a transmitter that is stored for a predetermined period of time and configured to physically engage an indwelling glucose sensor and that is configured to transmit a signal representative of a measured glucose concentration value to a mobile device, comprising: periodically activating a transmitter configured to receive a signal from the glucose sensor upon activation; deactivating the transmitter if it does not receive a signal from the glucose sensor within a predetermined period of time after activation; If the transmitter is activated and receives a signal from the glucose sensor within a predetermined period of time, the transmitter is permanently activated, whereby the transmitter is periodically activated to determine whether the connection has been made to the indwelling glucose sensor.

67. 66. The method of claim 65, wherein the periodic basis is between every 5 minutes and every 15 minutes.

68. 1. A method for rapidly activating a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device, the method comprising: upon activation of the transmitter, the transmitter is coupled to the sensor and adhered to a patient by a patch; the transmitter receives a measurement signal from the sensor; and the activation causes the transmitter to emit a signal representative of and based on the measurement signal, and renders an indication of the activation on the transmitter, the sensor, or the patch, thereby allowing a user to be notified of the activation without having to use another device.

69. 68. The method of claim 67, wherein the rendered indication is in visual or auditory form.

70. 1. A method for rapidly activating a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device, the method comprising: upon activation of the transmitter, the transmitter is coupled to the sensor and adhered to a patient by a patch; the transmitter receives a measurement signal from the sensor; the activation causes the transmitter to emit a signal representative of and based on the measurement signal; and transmitting a signal from the transmitter to an external device, the external device rendering an indication of the activation, whereby a user may be notified of the activation.

71. 1. A method of rapidly activating a CGM system including a transmitter configured to physically engage an indwelling glucose sensor, the transmitter configured to transmit a signal representative of a measured glucose concentration value to a patient's mobile device, the method comprising: downloading an application to the patient's mobile device upon wireless connection between the patient's mobile device and the transmitter; The method further comprising wirelessly connecting and establishing a communication session associated with a user account between the patient's mobile device and a server upon said downloading of said application.

72. 72. The method of claim 71, wherein the wireless connection comprises a connection using near field communication or Bluetooth low energy.

73. A method according to any one of claims 71 to 72, wherein the application is downloaded from the transmitter to the patient's mobile device.

74. The method of any one of claims 71 to 73, wherein the application is downloaded to the patient's mobile device from a server.

75. 75. The method of any one of claims 71 to 74, further comprising causing the transmitter to initiate transmission of a signal from the sensor, the signal indicative of a glucose measurement measured by the sensor.

76. 1. A system for rapidly activating a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device, comprising: an applicator configured to place the indwelling sensor; the applicator is further configured to position a transmitter in physical engagement with the indwelling sensor, the transmitter having a switch that, upon activation, places the transmitter in an active state, wherein the transmitter receives signals from the sensor and transmits signals representing a measured glucose concentration value to a mobile device; The system is configured such that the switch is activated when the transmitter is physically engaged with the indwelling sensor.

77. a transmitter further configured to physically engage the indwelling glucose sensor, configured to transmit a signal representative of the measured glucose concentration value to a mobile device, and configured to be rapidly activated; a housing including means for physically engaging a glucose sensor configured for placement at least partially within a patient's body; an optical sensor disposed within the housing and optically exposed to an exterior of the housing through a window; a cover adapted to be applied to the window and configured to prevent exposure of the light sensor to light prior to use of the transmitter; A transmitter in which, before use, a user removes the cover to expose the light sensor to light, and the light sensor, when activated, transitions the transmitter to an active state, thereby enabling the transmitter to be woken up by removing the cover.

78. 78. The transmitter of claim 77, wherein the cover is adhered to the window.

79. a transmitter configured to physically engage the indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device; a housing including means for physically engaging a glucose sensor configured for placement at least partially within a patient's body; a circuit configured to receive timestamp information from an external source; a memory configured to store the timestamp information from the external source.

80. 80. The transmitter of claim 79, wherein the memory is further configured to associate the timestamp information with one or more received data packets associated with a signal from the sensor.

81. A transmitter according to any one of claims 79 to 80, wherein the circuit is a short-range wireless communication circuit or a Bluetooth low energy circuit.

82. 82. The transmitter of claim 81 , wherein the circuitry is Bluetooth® low energy circuitry, the circuitry configured to periodically poll nearby Bluetooth® devices for timestamp information.

83. 82. The transmitter of claim 81, wherein the circuitry is configured to receive timestamp information from an HCP device.

84. 82. The transmitter of claim 81, wherein the circuitry is configured to receive timestamp information from a patient's mobile device.

85. The transmitter of any one of claims 79 to 84, further comprising a processor in signal communication with the memory, the processor configured to correct for time drift or time lag.

86. 86. The transmitter of claim 85, wherein the processor is configured to correct time drift or time lag by inducing periodic or irregular synchronization.

87. 1. A kit for pairing a patient's mobile device with a continuous glucose monitoring application having a transmitter configured to transmit a signal representative of a measured glucose concentration value to the mobile device, the kit comprising: a transmitter including means for physically engaging the glucose sensor; an identification component including a flexible electronic device and configured to be scanned by a patient's mobile device to receive identification information related to the transmitter stored on the flexible electronic device; Upon receiving the identification information, the patient's mobile device is configured to pair with the transmitter, the pairing enabling the patient's mobile device to receive a signal representing a measured glucose concentration value transmitted by the transmitter.

88. 88. The kit of claim 87, wherein the identification component comprises a sticker.

89. 89. The kit of any one of claims 87 to 88, wherein the identification information comprises calibration information.

90. The kit of any one of claims 87 to 89, wherein the pairing is further between the glucose monitoring application and the transmitter.

91. 91. The kit of claim 90, wherein the pairing is performed based on identified RSSI signal strength.

92. 92. The kit of any one of claims 87 to 91, wherein the identification component is incorporated as part of a sensor adhesive patch.

93. 93. The kit of any one of claims 87 to 92, wherein the application is configured to verify that the sensor is within a proper operating range by determining whether received counts are within a predetermined range for a predetermined period of time.

94. 1. A method of pairing a patient's mobile device including a continuous glucose monitoring application having a transmitter configured to transmit a signal representative of a measured glucose concentration value to the mobile device, the method comprising: receiving an input at a user interface of the mobile device indicating that the mobile device should be paired with a transmitter; detecting motion artifacts in an accelerometer within the mobile device; Upon said detection, transmitting a signal to place said transmitter into pairing mode; and pairing the transmitter with the mobile device.

95. 95. The method of claim 94, further comprising indicating a desired motion artifact on the user interface.

96. A method according to any one of claims 94 to 95, wherein the motion artifact comprises a predetermined number of taps.

97. A method according to any one of claims 94 to 96, wherein the motion artefact comprises a swaying movement of a predetermined threshold duration.

98. 1. A method of pairing a patient's mobile device including a continuous glucose monitoring application having a transmitter configured to transmit a signal representative of a measured glucose concentration value to the mobile device, the method comprising: receiving input at a user interface of the mobile device indicating that the mobile device should be paired with a transmitter; detecting a signal from the transmitter; determining whether an RSSI measurement of the detected signal exceeds a predetermined threshold; generating pairing between the mobile device and the transmitter based on the determination that the detected signal exceeds the predetermined threshold.

99. 99. The method of claim 98, wherein said determining step comprises confirming the identity or availability of a user-identifying transmitter based on selection criteria including continuous detection of at least one of information regarding the strength of the signal detected from the selected transmitter for a predetermined period of time and information regarding the quality of the signal detected from the selected transmitter for a predetermined period of time.

100. 1. A reading device configured for use by a HCP and configured to configure a transmitter associated with a continuous glucose monitor, the reading device comprising: circuitry configured to receive and transmit one or more operating parameters of the transmitter for display on a user interface of the HCP device, the reading device further configured to receive changed transmitter parameters from the user interface and store the changed transmitter parameters in the transmitter.

101. 1. A method of activating a transmitter for use in a sensor session, the transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to a mobile device, the transmitter configured to transition from an active state to an inactive state following a predetermined period of the sensor session, comprising: transmitting a wake-up command from an external device to the transmitter; The method, wherein the wake-up command transitions the transmitter from an inactive state to an active state.

102. 102. The method of claim 101, wherein sending the wake-up command is performed using near field communication or Bluetooth low energy.

103. The method of any one of claims 101 to 102, further comprising downloading data stored in the transmitter to the external device.

104. 104. The method of claim 103, wherein the wake-up command is transmitted using a near field communication protocol.

105. 105. The method of claim 104, wherein the downloading is performed using a near field communication protocol.

106. 105. The method of claim 104, wherein the downloading is performed using the Bluetooth Low Energy protocol.

107. 104. The method of claim 103, wherein the external device is the HCP device.

108. 108. The method of claim 107, wherein the HCP device is an HCP reader or controller or an HCP smartphone.

109. 104. The method of claim 103, wherein the external device is a patient device.

110. 110. The method of claim 109, wherein the patient device is a patient's smartphone.

111. 1. A method for reducing noise in signal transmission between a mobile device and a transmitter configured to physically engage an indwelling glucose sensor and to transmit a signal representative of a measured glucose concentration value to the mobile device using a near field communication protocol, the method comprising: setting a first flag and associating the first flag with corresponding data upon detecting a signal having energy above a predetermined threshold level on a short-range wireless communication circuit within the transmitter; setting a second flag and associating the second flag with corresponding data upon the detection of near field communication signaling between the transmitter and an external device; transmitting glucose concentration data from the transmitter to an external device; storing the transmitted data in the external device; adjusting, correcting, or ignoring data for which both the first and second flags are set in calculations involving the transmitted data.

112. 1. A method for reducing noise in signal transmission between a mobile device and a transmitter configured to physically engage an indwelling glucose sensor and to transmit a signal representative of a measured glucose concentration value to the mobile device using a near field communication protocol, the method comprising: setting a first flag and associating the first flag with corresponding data when the transmitter detects a signal having energy greater than a predetermined threshold level on the short-range wireless communication circuit; setting a second flag and associating the second flag with corresponding data upon the detection of near field communication signaling between the transmitter and an external device; transmitting glucose concentration data from the transmitter to an external device; storing the transmitted data in the external device; and in calculations involving the transmitted data, associating data for which both the first and second flags are set with a lower weighting than data for which neither flag is set.

113. 1. A method for reducing noise in signal transmission between a mobile device and a transmitter configured to physically engage an indwelling glucose sensor and to transmit a signal representative of a measured glucose concentration value to the mobile device using a near field communication protocol, the method comprising: setting a first flag and associating the first flag with corresponding data when the transmitter detects a signal having energy greater than a predetermined threshold level on the short-range wireless communication circuit; setting a second flag and associating the second flag with corresponding data upon the detection of near field communication signaling between the transmitter and an external device; transmitting glucose concentration data from the transmitter to an external device; storing the transmitted data in the external device; and ignoring data for which the first flag is set in calculations involving the transmitted data.

114. 1. A transmitter configured to reduce noise in a signal transmission to a mobile device, comprising: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; a near field communication circuit disposed within the housing and configured to transmit a signal to an external device; a threshold detector coupled to the short-range wireless communication circuit and configured to detect signal energy of energy captured by the short-range wireless communication circuit; The transmitter, wherein the threshold detector deactivates the near field communication circuitry when the threshold detector detects a signal with energy greater than a predetermined threshold.

115. 115. The transmitter of claim 114, wherein the threshold detector disables an antenna associated with the near field communication circuitry.

116. 1. A transmitter configured to reduce noise in a signal transmission to a mobile device, comprising: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; wireless communication circuitry disposed within the housing and configured to transmit signals to an external device; a detector coupled to the wireless communication circuit and configured to detect whether a signal corresponding to a wake-up command corresponding to a wake-up process is captured by the wireless communication circuit; If the detector detects a wake-up signal, the detector causes the wireless communication circuitry to be deactivated after a wake-up process is completed.

117. 117. The transmitter of claim 116, wherein the wireless communication circuit is a short-range wireless communication circuit.

118. 1. A transmitter configured to extend battery life and further configured for transmitting signals to a mobile device, comprising: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; wireless communication circuitry disposed within the housing and configured to transmit signals to an external device; a battery configured to power the wireless communication circuitry to enable measurements by the glucose sensor; a power-down circuit configured to transition the transmitter from an active state to an inactive state after a sensor session is completed; a wake-up circuit configured to transition the transmitter from an inactive state to an active state after completion of the sensor session so that data stored in the transmitter can be transmitted to the external device, the wake-up circuit being activated in part by a wake-up pin, the wake-up circuit being further configured to connect the battery to the wireless communication circuit in the active state, and to disable the wake-up pin when the wake-up circuit transitions to the inactive state.

119. 1. A transmitter configured to extend battery life and further configured for transmitting signals to a mobile device, comprising: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; wireless communication circuitry disposed within the housing and configured to transmit signals to an external device; a battery configured to power the wireless communication circuitry to enable measurements by the glucose sensor; a power-down circuit configured to transition the transmitter from an active state to an inactive state after a sensor session is completed; a wake-up circuit configured to transition the transmitter from an inactive state to an active state after completion of the sensor session so that data stored in the transmitter can be transmitted to the external device, the wake-up circuit being partially activated by a wake-up pin, and further configured to connect the battery to the wireless communication circuit in the active state, the wake-up pin being hardened against EMI.

120. 120. The transmitter of claim 119, wherein the enhancement is through the use of strong pull-up / down resistors.

121. 121. The transmitter of claim 120, wherein the enhancement is further due to the use of a capacitor.

122. A transmitter according to any one of claims 119 to 121, wherein the strengthening is by mechanically shorting the wake-up pin to a neutral polarity.

123. 1. A transmitter configured to extend battery life and further configured for transmitting signals to a mobile device, comprising: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; wireless communication circuitry disposed within the housing and configured to transmit signals to an external device; a battery configured to power the wireless communication circuitry to enable measurements by the glucose sensor; a power-down circuit configured to transition the transmitter from an active state to an inactive state after a sensor session is completed; a wake-up circuit configured to transition the transmitter from an inactive state to an active state after completion of the sensor session so that data stored in the transmitter can be transmitted to the external device, the wake-up circuit being activated in part by a wake-up pin, the wake-up circuit being further configured to connect the battery to the wireless communication circuit in the active state, and the wake-up circuit being configured to disable the wake-up circuit when it transitions to the inactive state.

124. 1. A transmitter configured to enhance data storage and further configured for transmitting a signal to a mobile device, comprising: a housing including means for physically engaging a glucose sensor configured to be at least partially placed within a patient's body; wireless communication circuitry disposed within the housing and configured to transmit signals to an external device; a battery configured to power the wireless communication circuitry to enable measurements by the glucose sensor; a memory configured to store data representing glucose values measured by the glucose sensor; a processor configured to perform data processing on the data stored in the memory, the processor configured to periodically compress the data stored in the memory so that the data occupies less memory than before compression.

125. 125. The transmitter of claim 124, wherein the processor is configured to compress data to the minimum number of data points required to accurately indicate the patient's glycemic exposure.

126. 126. The transmitter of claim 125, wherein the data points include those corresponding to maxima, minima, and inflection points along with corresponding abscissa time values.

127. A transmitter as described in any one of claims 124 to 126, wherein the processor is configured to compress the data by eliminating data points that represent stable values, the stable values being within a range of stability.

128. A transmitter according to any one of claims 124 to 127, wherein the processor is configured to compress data using lossy or lossless compression techniques.

129. 129. The transmitter of claim 128, wherein the lossy or lossless compression techniques include one or more selected from the group consisting of Lempel-Ziv compression, Huffman coding, or algorithmic coding.

130. A transmitter as claimed in any one of claims 124 to 129, wherein the processor is configured to compress data by storing only data where the change exceeds a defined amount, and data between such points is interpolated.

131. The transmitter of any one of claims 124 to 130, wherein the processor is configured to compress data by removing artifacts.

132. 1. A method of operating a transmitter configured to transmit a signal from an indwelling glucose sensor to a mobile device for enhanced data storage, comprising: receiving a signal over time from an indwelling glucose sensor; storing data representative of the received signal in a memory; and performing data processing on the stored data, wherein the data processing includes periodically or aperiodically compressing the data stored in the memory so that the data occupies less memory than before compression.

133. 133. The method of claim 132, wherein said compressing compresses said data to the minimum number of data points necessary to accurately represent said patient's glycemic exposure.

134. 134. The method of claim 133, wherein the data points include those corresponding to maxima, minima, and inflection points along with corresponding abscissa time values.

135. 135. A method according to any one of claims 132 to 134, wherein said compression compresses the data by eliminating data points that represent stable values, stable values being those within a range of stability.

136. The method of any one of claims 132 to 135, wherein said compressing compresses said data using a lossy or lossless compression technique.

137. 137. The method of claim 136, wherein the lossy or lossless compression techniques include one or more selected from the group consisting of Lempel-Ziv compression, Huffman coding, or algorithmic coding.

138. A method according to any one of claims 132 to 137, wherein said compressing compresses the data by storing only data where the change exceeds a defined amount, and data between such points is interpolated.

139. A method according to any of claims 132 to 138, wherein said compressing compresses said data by removing artifacts.

140. 1. A method of operating a transmitter configured to transmit a signal from an indwelling glucose sensor to a mobile device to improve data accuracy, comprising: receiving a signal over time from an indwelling glucose sensor; storing data representative of the received signal in a memory; and performing data processing on the stored data, wherein the data processing includes periodically or aperiodically post-processing the data stored in the memory so as to improve the accuracy of the data or calculations based on the data.

141. 141. The method of claim 140, wherein periodically post-processing the data comprises post-processing the data every 24 hours or every 48 hours.

142. A method according to any one of claims 140 to 141, wherein periodically post-processing the data comprises periodically smoothing the data.

143. 1. A method of operating a continuous glucose monitor, comprising: receiving a signal from the indwelling glucose sensor at a transmitter; receiving an external signal from an external sensor at the transmitter; A method wherein the sensor signal and the external signal are stored based on absolute or relative time of receipt.

144. 144. The method of claim 143, wherein the external sensor is an ambient noise sensor.

145. 145. The method of claim 144, further comprising calculating sleep or movement events based on the signal from the noise sensor.

146. 146. The method of any one of claims 143 to 145, wherein the external sensor is an accelerometer.

147. 147. The method of claim 146, further comprising calculating sleep or movement events based on the signals from the accelerometer.

148. A method according to any one of claims 143 to 147, wherein the external sensor is a GPS receiver.

149. 149. The method of claim 148, further comprising calculating sleep or exercise or meal events based on the signals from the GPS receiver.

150. 1. A method of operating a continuous glucose monitor, comprising: receiving at the mobile device a signal from the transmitter measured by the indwelling glucose sensor; receiving an external signal at the mobile device from an external sensor; storing the sensor signal and the external signal at the mobile device based on absolute or relative time of receipt.

151. a transmitter configured to physically engage the indwelling glucose sensor and transmit a signal representative of a measured glucose concentration value to a mobile device; a housing configured to physically engage a glucose sensor configured to be at least partially placed within a patient's body; a first communication circuit configured to communicate with the mobile device using a short-range wireless protocol; a second communication circuit configured to communicate with the mobile device using an encrypted wireless protocol; a memory for storing information received from the glucose sensor.

152. 152. The transmitter of claim 151, wherein the first communication circuit is a near field communication (NFC) circuit.

153. 153. The transmitter of claim 152, wherein the second communication circuit is a Bluetooth low energy circuit.

154. 152. The transmitter of claim 151, wherein the second communication circuit is a Bluetooth low energy circuit.

155. 152. The transmitter of claim 151, wherein the mobile device is a HCP device.

156. 153. The transmitter of claim 152, further comprising a feedback indicator that facilitates a user's physical alignment between an antenna of the head NFC circuit and an antenna of the mobile device.

157. 157. The transmitter of claim 156, wherein the feedback indicator comprises an auditory, tactile, or visual indicator.

158. 1. A method of communication between a mobile device and a transmitter configured to physically engage a continuous glucose sensor and transmit a signal representative of a measured glucose concentration value to the mobile device, comprising: receiving at the transmitter a data retrieval command from the mobile device using a short-range wireless protocol; causing the transmitter to enter a data extraction mode of operation in response to the data extraction command; transmitting an advertisement message according to an encrypted wireless protocol and initiating a connection with the mobile device over the encrypted wireless protocol; and upon establishing a connection with the mobile device via the encrypted wireless protocol, transmitting the estimated glucose value to the mobile device via the connection.

159. 159. The method of claim 158, further comprising receiving, at the transmitter, a query command using the short-range wireless protocol before receiving the data extraction command, and transmitting an encrypted identifier of the transmitter using the short-range wireless protocol in response to the query command.

160. 160. The method of claim 159, wherein the query command is issued after the glucose sensor is inserted into the patient.

161. 161. The method of claim 160, wherein the query command is issued while at an HCP office.

162. 161. The method of claim 160, further comprising transmitting, in response to the query command, operational state information specifying one or more operational states of the transmitter.

163. 163. The method of claim 162, wherein the operating state information is selected from the group consisting of a transmitter storage state, a sensor confirmation state, an in-session state, and a session complete state.

164. 159. The method of claim 158, wherein establishing the connection includes having the transmitter authenticated by the mobile device.

165. 159. The method of claim 158, wherein the advertising message includes information identifying the transmitter.

166. 159. The method of claim 158, wherein sending the advertising message includes periodically sending the advertising message.

167. 159. The method of claim 158, wherein transmitting the advertising message comprises continuously transmitting the advertising message.

168. 159. The method of claim 158, further comprising communicating only with the mobile device with which the connection was established while in the data extraction mode and not with any other mobile device.

169. 159. The method of claim 158, further comprising obtaining a decryption key for decrypting the encrypted identifier of the transmitter from a server via a communications network.

170. 159. The method of claim 158, further comprising powering off the transmitter after transmission of the estimated glucose value is completed.

171. 159. The method of claim 158, wherein transmitting the estimated glucose value comprises transmitting the estimated glucose value within a specified period of time.

172. 172. The method of claim 171, wherein the specified period is 15 seconds.

173. 159. The method of claim 158, wherein the encrypted wireless protocol is a BLE protocol having at least two modes of operation, and further comprising switching from a first BLE mode of operation to a data extraction mode of operation before transmitting the advertisement message.

174. 174. The method of claim 173, wherein the data extraction mode of operation has a rate at which advertising messages are transmitted greater than in the first BLE mode of operation.

175. 175. The method of claim 174, further comprising using different identifiers for the transmitter when operating in the first BLE mode and the data extraction mode.

176. 163. The method of claim 162, wherein the operational state information is selected from the group consisting of a transmitter storage state indicating that the transmitter remains packaged, a sensor verification state indicating that the transmitter is performing a sensor insertion verification operation, an in-session state indicating that the sensor is collecting data, and a session complete state indicating that the session is complete and the data is available for download.

177. 177. The method of claim 176, wherein the operational status information for the sensor verification status further includes information indicating the time remaining to complete sensor insertion verification and confirmation of sensor verification.

178. 178. The method of claim 177, wherein the operational status information for the sensor verification status further includes information indicating the number of sensor insertion verification attempts that have been performed.

179. 177. The method of claim 176, wherein the operational state information further includes the duration of a currently active session.

180. 1. A continuous glucose monitoring device configured for use by a healthcare professional (HCP), comprising: The housing and a first communication circuit configured to communicate with a continuous glucose monitoring device including a transmitter coupled to an indwelling glucose sensor using a short-range wireless protocol; a second communication circuit configured to communicate with the transmitter using an encrypted wireless protocol; a user interface for entering an operational mode in which the continuous glucose monitoring device will operate.

181. 1. A method for pairing a patient's mobile device including a continuous glucose monitoring application with a transmitter configured to transmit a signal representative of a measured glucose concentration value to the patient's mobile device, comprising: detecting insertion of the transmitter in a glucose sensor housing; in response to said detection, automatically transitioning said transmitter from an inactive state to an active state in which said transmitter is capable of transmitting a signal encoded with data corresponding to a reading received from said sensor; broadcasting an advertisement message according to a first wireless protocol; opening an application on the patient's mobile device in response to the broadcast; having the patient's mobile device enter a security code and pairing the transmitter with the patient's mobile device using the first wireless protocol; If the security code is correct, pairing the transmitter with the patient's mobile device using the first wireless protocol; and initiating a sensor session in response to the pairing.

182. 182. The method of claim 181, wherein the application automatically opens without user intervention in response to the broadcast.

183. 182. The method of claim 181, wherein entering the security code comprises manually entering the security code via a user interface of the patient's mobile device.

184. 182. The method of claim 181, wherein inputting the security code includes receiving a signal at the patient's mobile device that includes the security code, the signal being transmitted by the transmitter using a second wireless protocol.

185. 185. The method of claim 184, wherein the second wireless protocol is NFC.

186. 182. The method of claim 181, wherein the first wireless protocol is BLE.

187. 186. The method of claim 185, wherein the first wireless protocol is BLE.

188. 182. The method of claim 181, wherein the session starts after a sensor warm-up period, and further comprising causing the application to indicate via a user interface on the patient's mobile device approximately when the sensor session has started after the warm-up period.

189. 1. A method for rapidly activating a transmitter that is stored for a predetermined period of time and configured to physically engage an indwelling glucose sensor and that is configured to transmit a signal representative of a measured glucose concentration value to a mobile device, comprising: detecting a signal indicative of an acceleration event in a transmitter stored in the package; and transitioning the transmitter from an inactive state to an active state if the detected signal is determined to indicate that the acceleration event resulted from an acceleration within a specified range.

190. 1. A method of communication between a mobile device and a transmitter configured to physically engage an indwelling glucose sensor and configured to transmit a signal representative of a measured glucose concentration value to the mobile device, comprising: receiving, at the transmitter, a data retrieval command from the mobile device using a short-range wireless protocol; causing the transmitter to enter a data extraction mode of operation in response to the data extraction command; transmitting an advertisement message according to an encrypted wireless protocol and initiating a connection with the mobile device over the encrypted wireless protocol; and upon establishing a connection with the mobile device via the encrypted wireless protocol, transmitting operational state information specifying at least one operational state of the transmitter, wherein the at least one operational state of the transmitter includes a sensor session completion state indicating that a session is complete and the data is available for download.

191. 191. The method of claim 190, further comprising, upon receiving the data extraction command, transmitting an encrypted identifier of the transmitter using the short-range wireless protocol.

192. 192. The method of claim 191, wherein the query command is issued while at an HCP office.

193. 191. The method of claim 190, wherein establishing the connection includes having the transmitter authenticated by the mobile device.

194. 191. The method of claim 190, wherein the advertising message includes information identifying the transmitter.

195. 200. The method of claim 194, wherein sending the advertising message includes periodically sending the advertising message.

196. 200. The method of claim 194, wherein transmitting the advertising message comprises continuously transmitting the advertising message.

197. 195. The method of claim 194, wherein the short-range wireless protocol is NFC and the encrypted wireless protocol is BLE.

198. 1. A method of communication between a HCP reader and a transmitter configured to physically engage an indwelling glucose sensor and to transmit a signal representative of a measured glucose concentration value to the HCP reader, comprising: receiving, at the transmitter, a data extraction command from the HCP reader using a short-range wireless protocol, the data extraction command including an encrypted version of the transmitter's identifier; in response to the data extraction command, if the transmitter determines that the identifier included in the data extraction command is correct, causing the transmitter to enter a data extraction operating mode; sending an advertisement message according to an encrypted wireless protocol to initiate a connection with the HCP reader via the encrypted wireless protocol, the advertisement message including information that causes the HCP reader to connect in preference to other devices; and upon establishing a connection with the HCP reader via the encrypted wireless protocol, transmitting sensor data to the HCP reader via the connection.

199. 200. The method of claim 198, wherein the encrypted wireless protocol is BLE.

200. 200. The method of claim 198, wherein the information that causes the HCP reader to connect in preference to other devices includes a BLE GAP address.

201. 200. The method of claim 198, wherein the advertising message includes at least a portion of an identifier of the transmitter.

202. 200. The method of claim 198, wherein sending the advertising message includes periodically sending the advertising message.

203. 200. The method of claim 198, wherein transmitting the advertising message comprises continuously transmitting the advertising message.

204. 200. The method of claim 198, wherein the short-range wireless protocol is NFC.

205. 200. The method of claim 199, wherein the sensor data transmitted to the HCP reader includes an estimated glucose value.

Images