Systems and methods for patient monitoring using HCP native devices

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 corrections thereto, are hereby incorporated by reference into this specification in accordance with the provisions of 37 C.F.R. § 1.57. This application claims the benefit of U.S. Patent Application No. 62 / 439,342, filed December 27, 2016. The foregoing application is hereby incorporated by reference in its entirety into this specification and is hereby expressly made a part hereof.

[0002] The present disclosure generally relates to the continuous monitoring of analyte values received from an analyte sensor system. More specifically, the present disclosure relates to systems, methods, devices, and apparatuses for enabling patient - setting of an analyte sensor system and subsequent participation by a healthcare provider in its use.

Background Art

[0003] Diabetes mellitus is a disorder in which the pancreas cannot produce sufficient insulin (type - 1 or insulin - dependent), and / or insulin is ineffective (type - 2 or non - insulin - dependent). In a diabetic state, an affected individual suffers from hyperglycemia, which causes numerous physiological abnormalities (renal failure, skin ulcers, or bleeding into the vitreous of the eye) associated with microvascular deterioration. Hypoglycemic reactions (hypoglycemia) can be induced by inadvertent over - ingestion of insulin, or extreme exercise or inadequate food intake after normal dosing of insulin or glucose - lowering agents.

[0004] Conventionally, diabetic patients carry a self - monitoring blood glucose (SMBG) monitor, which typically requires an uncomfortable finger - prick method. Due to the lack of comfort and convenience, diabetic patients usually only measure their blood glucose levels 2 - 4 times a day. Unfortunately, these time intervals are too far apart and dispersed, so there is a possibility that it may be too late for diabetic patients to be informed of hyperglycemic or hypoglycemic conditions, and as a result, it may sometimes cause dangerous side effects. In fact, not only do diabetic patients risk being unable to obtain SMBG values in a timely manner, but due to the limitations of conventional methods, diabetic patients may also not know whether their blood glucose levels are rising (higher) or falling (lower).

[0005] As a result, various non - invasive, transdermal (e.g., percutaneous), and / or implantable electrochemical sensors have been developed for continuously detecting and / or quantifying blood glucose levels. Continuous glucose monitors are gaining popularity as an easy way to monitor blood glucose levels. Previously, patients sampled 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 taking a small blood sample from the patient and measuring the blood glucose level with a test strip or a blood glucose meter. However, this technique has drawbacks as patients prefer not to have to take blood samples and users do not know how their blood glucose levels are between samples throughout the day.

[0006] One potentially dangerous time frame is at night because a patient's blood glucose level can drop dangerously low during sleep. As a result, continuous glucose monitors are gaining popularity by providing sensors that continuously measure a patient's blood glucose level and wirelessly transmit the measured blood glucose level to a display. This enables the patient or the patient's caregiver to monitor the patient's blood glucose level throughout the day and even set alarms when the blood glucose level reaches a predetermined level or experiences a defined change.

[0007] In the United States, there are approximately 30 million people with diabetes. 86 million people have prediabetes. However, nine out of ten people are unaware that they have prediabetes. Currently, one in three people will develop type 2 (T-2) diabetes in their lifetime. T-2 is preventable, but once developed, patients need to 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 healthcare professionals (HCPs).

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

[0009] This background is provided to introduce a brief explanation of the following summary and detailed description. This background is not intended to help determine the scope of the claimed subject matter, nor is it intended to be construed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.

Summary of the Invention

Problems to be Solved by the Invention

[0010] The system and method according to this principle, according to the implementation, address many of the above problems. More specifically, the system and method provide a way for HCPs to be involved in the initial patient system setup so that the received data can truly bring about a transformation. Patients not only understand what the various numbers mean but also how to use the data. Better-educated patients can significantly improve their health outcomes and greatly reduce medical 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. The dedicated display device is a medical device designed to display blood glucose levels, trend patterns, and other information about the user. However, as the popularity of smartphones and software applications (apps) running on smartphones has grown, there are also users who prefer not to have to carry a dedicated display device. Instead, there are also users who prefer to monitor their blood glucose levels using a dedicated software application running on a mobile computing device such as a smartphone, tablet, or wearable device such as a smartwatch or smart glasses.

[0012] T-2 patients can benefit greatly from CGM technology, but this market is very heterogeneous among both patients and caregivers and thus difficult to address. For example, newly diagnosed individuals are very different from those who have tried many conventional treatment efforts such as drug therapy. New users are very different from older users. Newly diagnosed patients may be highly motivated to control their disease, but patients who have tried and failed to control it may become frustrated. In some cases, patient management is inadequate for several years until drug therapy is initiated, and such patients often suffer from numerous co-morbidities and complications. Patients also have a wide range of levels of compliance with treatment.

[0013] The attitudes of patients and clinicians are quite different, and their goals may vary. Often, there is a significant gap between physicians and patients with uncontrolled type 2 diabetes in the way the definition of control in the context of the impact of uncontrolled type 2 diabetes is perceived, and in the perception of diabetes control, including the obstacles to control. Compared to patients with uncontrolled type 2 diabetes, physicians generally have a more focused and clinical perspective on diabetes management, for example, focusing on factors such as HbA1c values, the frequency and severity of hypoglycemia, and medical complications due to diabetes. Patients with uncontrolled type 2 diabetes often have a broader perspective, taking into account daily factors such as energy levels and how much they need to think about diabetes, in addition to clinical measures.

Means for Solving the Problem

[0014] A first aspect is a continuous glucose monitoring device configured for use by a healthcare professional (HCP), the continuous glucose monitoring device including a housing, a circuit configured to receive signals from a transmitter coupled to an implantable glucose sensor, a calibration module configured to convert the received signals into clinical units, and a user interface configured to display the glucose concentration measured in the clinical units, the user interface further being configured to receive input data regarding the patient level, the input data regarding the patient level causing the device to operate in a mode suitable for the patient level.

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

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

[0017] Implementations of aspects and embodiments can include one or more of the following. The data can be about whether the patient has type I diabetes, type II diabetes, or prediabetes, or can be about the user's technical skill level. The method can further include storing glucose concentration values in clinical units and input data. The method can further include transmitting the stored glucose concentration values from the transmitter to the HCP device when a query signal is received or triggered by the query signal. The query signal can be received by the transmitter from a short-range communication device or a Bluetooth® low energy device coupled to the HCP device. The continuous glucose monitoring device can be configured to download an application configured to control continuous glucose monitoring.

[0018] The mode can be a blind mode in which an application running on a continuous glucose monitoring device is configured to receive and store glucose concentration data but not display it. The application can further be configured to receive input data corresponding to event data, where the event data corresponds to dosing data, meal data, or exercise data. The mode can be a non-blind mode in which the continuous glucose monitoring device is configured to receive, store, and display glucose concentration data. The mode can be configured to start in blind mode and switch to non-blind mode at a predetermined time after the sensor session starts. The mode can be configured to start in blind mode and switch to non-blind mode upon the occurrence of a trigger event. The trigger event can correspond to patient parameters meeting a predetermined threshold criterion. The mode can be configured to start in blind mode and switch to non-blind mode upon receiving a trigger signal from an external device. Patient data can include a transmitter serial number, and the transmitter serial number has a plurality of extensions selectable by an HCP, where the extensions are selected to be appropriate for the patient, and the serial number extension specifies the mode in which the continuous glucose monitoring device should operate. The mode can be a real-time blind mode in which an application running on the continuous glucose monitoring device is configured to receive and store real-time glucose concentration data but not display it and is configured to display non-real-time historical glucose concentration data. The method can further include operating a diagnostic application on an HCP device, where the diagnostic application enables an HCP to view and set CGM parameters without changing the course of treatment. The parameters can include remaining sensor time, sensor status, and current session time. The mode can be blind mode, and the transmitter can be configured to store data measured by an implantable sensor.

[0019] A third aspect is a method of configuring a continuous glucose monitoring device for use by a patient, the configuration being performed by a HCP, the method comprising establishing a communication session related to the HCP account between the HCP client device and the server; prompting the HCP to input patient data on a user interface associated with the HCP client device; also prompting the HCP to input 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 input patient data and sensor identification data; and storing and transmitting the input patient data and identification data to the server for association with a patient account.

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

[0021] A fourth aspect is a method of configuring a continuous glucose monitoring device for use by a patient, the configuration being performed by a HCP, the method comprising establishing a first communication session related to the HCP account between the HCP client device and the server; prompting the HCP to input 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 input patient data and identification data; and storing the input patient data and identification data and transmitting them to the server for association with the patient account.

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

[0023] The method can further include receiving an output from the server in response to transmitting the input patient data and sensor identification data to the server, the received output including code configured to be used by the patient smart device to download an application for use in continuous glucose monitoring. The code can be received by email or text, and the method can further include transmitting configuration information to the continuous glucose monitoring device. The transmission can be performed by short-range wireless communication or Bluetooth® low energy.

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

[0025] The implementation of aspects and embodiments can include one or more of the following. An apparatus configured to receive a first signal can be configured to receive the first signal using a wired or wireless communication protocol. An apparatus configured to receive a first signal can be activated by an inquiry signal from a transmitter. An apparatus configured to receive a first signal can use the inquiry signal to activate the transmitter. After activation, the circuit can extract stored glucose concentration data from the transmitter. The communication protocol can be wireless and can be selected from the group consisting of Bluetooth® low energy communication or near field communication. The apparatus can 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, whereby the operating state of the transmitter can be determined.

[0026] A sixth aspect is a reading device configured for use by an HCP, the reading device including a circuit configured to determine proper functioning of a transmitter associated with a continuous glucose monitor, measure one or more operating parameters of the transmitter, and provide an output based on the measured one or more operating parameters, whereby the operating state of the transmitter is determined.

[0027] A seventh aspect is a method for determining proper activation of a transmitter, the transmitter being associated with a continuous glucose monitor, the method including detecting insertion of a sensor in the transmitter and, upon detection, transitioning the transmitter from a non-active 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 can include one or more of the following. In an active state, the transmitter can transmit a signal using Bluetooth® Low Energy. The method can further include receiving the transmitted signal at an HCP device, and the method can further include receiving the transmitted signal at a patient device. The patient device can be a smartphone or a smartwatch. The method can further include, upon receiving an affirmative response signal from the patient device by the transmitter, transmitting a signal from the transmitter to the HCP device, whereby the HCP device is provided with confirmation that the patient device is operating properly with the patient sensor and the transmitter. The method can further include collecting data from the transmitter over a period of time measured by the sensor. Extracting can include querying the transmitter using an HCP device, and the query can be performed using short-range wireless communication or Bluetooth® Low Energy. The method can further include transmitting a signal from the transmitter, the signal being encoded with data indicating that sensor insertion has occurred.

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

[0030] Implementations of aspects and embodiments can include one or more of the following. Sending a wake-up command can be performed using near field communication or Bluetooth® Low Energy. Sending a wake-up command can be performed by communicating a signal to a wake-up pin on a processor that is at least partially operating the transmitter. Sending a wake-up command can be performed in response to detecting a signal measured by an implantable glucose sensor.

[0031] A ninth aspect is a method of quickly activating a transmitter configured to store for a predetermined period, physically engage with an implantable glucose sensor, and transmit a signal representative of a measured glucose concentration value to a mobile device, the method including, in the transmitter, detecting a signal from a connected sensor and, if the detected signal is determined to have an amplitude exceeding a predetermined threshold, transitioning the transmitter from a non-active state to an active state.

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

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

[0034] Aspect 11 is a method for quickly starting a transmitter configured to physically engage with an implantable glucose sensor and transmit a signal representing a measured glucose concentration value to a mobile device. When starting the transmitter, the transmitter is coupled to the sensor and adhered to the patient by a patch. The transmitter receives a measurement signal from the sensor, and the start causes the transmitter to emit a signal based on the signal representing the measurement signal. Render an indication of the start in the transmitter, the sensor, or the patch, whereby the user can receive a notification of the start without the need to use another device.

[0035] In one implementation, the rendered indication can be in visual or auditory form.

[0036] Aspect 12 is a method for quickly starting a transmitter configured to physically engage with an implantable glucose sensor and transmit a signal representing a measured glucose concentration value to a mobile device. When starting the transmitter, the transmitter is coupled to the sensor and adhered to the patient by a patch. The transmitter receives a measurement signal from the sensor, and the start causes the transmitter to emit a signal based on the signal representing the measurement signal, transmit it from the transmitter to an external device, and the external device renders an indication of the start, whereby the user can receive a notification of the start.

[0037] Aspect 13 is a method for quickly starting a CGM system including a transmitter configured to physically engage with an implantable glucose sensor, the transmitter being configured to transmit a signal representing a measured glucose concentration value to a patient's mobile device. When wirelessly connecting the patient's mobile device to the transmitter, download an application to the patient's mobile device, and further, when wirelessly connecting and downloading the application, establish a communication session related to the user account between the patient's mobile device and the server.

[0038] Implementations of aspects and embodiments can include one or more of the following. The wireless connection can include a connection using short-range wireless communication or Bluetooth® Low Energy. The application can be downloaded from a transmitter or server to the patient's mobile device. The method can further include causing the transmitter to begin transmitting a signal from the sensor, the signal indicating a glucose measurement taken by the sensor.

[0039] A fourteenth aspect is a system for quickly activating a transmitter configured to physically engage with an implantable glucose sensor and transmit a signal representing a measured glucose concentration value to a mobile device, the system including an applicator configured to install the implantable sensor, the applicator further configured to install the transmitter so as to physically engage with the implantable sensor, the transmitter having a switch that activates the transmitter to an active state upon startup, in the active state the transmitter receives a signal from the sensor and transmits a signal representing the measured glucose concentration value to the mobile device, and the switch is configured to be activated when the transmitter physically engages with the implantable sensor.

[0040] A fifteenth aspect is a transmitter further configured to physically engage with an implantable glucose sensor, configured to transmit a signal representing a measured glucose concentration value to a mobile device, and configured to be quickly activated, the transmitter including a housing including means for physically engaging with a glucose sensor configured to be at least partially implanted in a patient's body, an optical sensor disposed within the housing and optically exposed to the outside of the housing through a window, and a cover applied to the window and configured to prevent exposure of the optical sensor to light prior to use of the transmitter, the cover being removable by a user to expose the optical sensor to light prior to use and causing the transmitter to transition to an active state when activated, whereby the transmitter can be activated by removal of the cover.

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

[0042] A 16th aspect is a transmitter configured to physically engage with an indwelling glucose sensor and 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 indwelling within a patient's body, a circuit 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 the aspects and embodiments can include one or more of the following. The memory can be further configured to associate the timestamp information with one or more received data packets related to the signal from the sensor. The circuit can be a short-range wireless communication circuit or a Bluetooth® low energy circuit. The circuit can be a Bluetooth® low energy circuit and can be configured to periodically poll nearby Bluetooth® devices for timestamp information. The circuit can be configured to receive timestamp information from an HCP device. The circuit can be configured to receive timestamp information from the patient's mobile device. The circuit can further include a processor in signal communication with the memory, the processor being configured to compensate for time drift or time lag. The processor can be configured to compensate for time drift or time lag by causing periodic or aperiodic synchronization.

[0044] A 17th aspect is a kit for pairing a mobile device of a patient, which includes a transmitter configured to transmit a signal representing a measured glucose concentration value and a continuous glucose monitoring application, the kit including a transmitter including means for physically engaging with a glucose sensor, and an identification component including a flexible electronic device and configured to be scanned by a mobile device of the patient that receives identification information regarding the transmitter stored in the flexible electronic device, wherein upon receiving the identification information, the mobile device of the patient is configured to pair with the transmitter, and the pairing enables the mobile device of the patient to receive a signal representing the measured glucose concentration value transmitted by the transmitter.

[0045] Implementations of the aspects and embodiments can include one or more of the following. The identification component can include a sticker and can further include calibration information. The pairing can further be between the glucose monitoring application and the transmitter and can be performed based on an identified RSSI signal strength. The identification component can be incorporated as part of a sensor adhesion patch, and the application can be configured to confirm that the sensor is within an appropriate operating range by determining whether a received count is within a predetermined range over a predetermined period.

[0046] An 18th aspect is a method for pairing a mobile device of a patient, which includes a transmitter configured to transmit a signal representing a measured glucose concentration value and a continuous glucose monitoring application, the method including receiving, at a user interface of the mobile device, an input desiring an indication that the mobile device is to be paired with the transmitter, detecting a motion artifact in an accelerometer within the mobile device, upon detection, transmitting a signal to put the transmitter in a pairing mode, and pairing the transmitter with the mobile device.

[0047] Implementations of aspects and embodiments can include one or more of the following. The method can further include presenting on a user interface a desired motion artifact, such as when the motion artifact includes a rocking motion of a predetermined number of taps or a predetermined threshold period.

[0048] A nineteenth aspect is a method of pairing a patient's mobile device including a transmitter configured to send a signal representing a measured glucose concentration value and a continuous glucose monitoring application, the method including receiving, at a user interface of the mobile device, an indication that the mobile device is to be paired with the transmitter, detecting a signal from the transmitter, determining whether an RSSI measurement value of the detected signal exceeds a predetermined threshold, and causing a pairing to occur 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 can include verifying the identification or availability of the user-identifying transmitter based on a selection criterion including at least one continuous detection of information regarding the strength of the signal detected from the selected transmitter over a predetermined period and information regarding the quality of the signal detected from the selected transmitter over a predetermined period.

[0050] A twentieth aspect is a reader device configured for use by an HCP and configured to set a transmitter associated with a continuous glucose monitor, the reader device including a circuit 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 device further configured to receive transmitter parameters changed from the user interface and store the changed transmitter parameters in the transmitter.

[0051] A 21st aspect is a method of activating a transmitter configured to be used in a sensor session, physically engage with an implantable glucose sensor, transmit a signal representing a measured glucose concentration value to a mobile device, and transition from an active state to an inactive state following a sensor session of a predetermined period, the method including transmitting 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 the aspects and embodiments can include one or more of the following. Transmitting the wake-up command can be performed using near-field communication or Bluetooth® Low Energy. The method can further include downloading data stored in the transmitter to the external device. The wake-up command can be transmitted using a near-field communication protocol. The download can be performed using a near-field communication protocol or a Bluetooth® Low Energy protocol. The external device can be an HCP device, and the HCP device can be an HCP reader or controller or an HCP smartphone. The external device can be a patient device such as a patient's smartphone.

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

[0054] A 23rd aspect is a method for reducing noise in signal transmission between a transmitter configured to physically engage with an implantable glucose sensor and transmit a signal representing a glucose concentration value measured using a short - range communication protocol to a mobile device, and the mobile device, the method including: when detecting, in the transmitter, a signal having energy greater than a predetermined threshold level on a short - range communication circuit, setting a first flag and associating the first flag with corresponding data; when detecting short - range wireless communication signaling between the transmitter and an external device, setting a second flag and associating the second flag with corresponding data; transmitting glucose concentration data from the transmitter to the external device; in the external device, storing the transmitted data; and in calculations involving the transmitted data, associating data for which both the first and second flags are set with a lower weight than data for which neither flag is set.

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

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

[0057] In one implementation, the threshold detector can disable an antenna associated with the short-range communication circuit.

[0058] Aspect 26 is a transmitter configured to reduce noise in signal transmission to a mobile device, including a housing including means for physically engaging with a glucose sensor configured to be at least partially implanted in a patient's body, a wireless communication circuit disposed within the housing and configured to transmit signals 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. When the detector detects a wake-up signal, the detector deactivates the wireless communication circuit after completion of the wake-up process. The present invention is directed to a transmitter.

[0059] In one implementation, the wireless communication circuit can be a short-range wireless communication circuit.

[0060] Aspect 27 is a transmitter configured to extend battery life and further configured for signal transmission to a mobile device, including a housing including means for physically engaging with a glucose sensor configured to be at least partially implanted in 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 supply power to 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, 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 and to disable the wake-up pin when the wake-up circuit transitions to the inactive state. The present invention is directed to a transmitter.

[0061] Aspect 28 is a transmitter configured to extend battery life and further configured to transmit signals to a mobile device, the transmitter including a housing including means for physically engaging a glucose sensor configured to be at least partially implanted 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, a wake-up circuit configured to transition the transmitter from the inactive state to the active state after completion of the sensor session such 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 fortified against EMI.

[0062] Implementations of aspects and embodiments can include one or more of the following. Fortification can be by use of strong pull-up / pull-down resistors and / or further by use of capacitors. Fortification can also be by mechanically shorting the wake-up pin to a non-active polarity.

[0063] Aspect 29 is a transmitter configured to extend battery life and further configured for signal transmission to a mobile device, the transmitter including a housing including means for physically engaging with a glucose sensor configured to be at least partially implanted 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, a wake-up circuit configured to transition the transmitter from the inactive state to the active state after completion of the sensor session such 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 and to disable the wake-up circuit when the wake-up circuit transitions to the inactive state.

[0064] Aspect 30 is a transmitter configured to enhance data storage and further configured for signal transmission to a mobile device, the transmitter including a housing including means for physically engaging with a glucose sensor configured to be at least partially implanted 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 representative of glucose values measured by the glucose sensor, and a processor configured to perform data processing on the data stored in the memory, the processor being 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 can include one or more of the following. The processor can be configured to compress data into the minimum number of data points necessary to accurately represent the patient's glucose exposure. The data points can include those corresponding to the maximum point, minimum point, and inflection points, along with their corresponding abscissa time values. The processor can be configured to compress data by excluding data points representing stable values, where the stable values are within a range of stability. The processor can be configured to compress data using irreversible or reversible compression techniques. The irreversible or reversible compression techniques can include one or more selected from the group consisting of Lempel-Ziv compression, Huffman coding, or algorithmic coding. The processor can be configured to compress data by storing only data whose change exceeds a defined amount, and the data between such points is interpolated. The processor can be configured to compress data by removing artifacts.

[0066] A 31st aspect is a method of operating a transmitter configured to transmit signals from an implantable glucose sensor to a mobile device for enhanced data storage, including receiving signals over time from the implantable glucose sensor, storing data representing the received signals in a memory, and performing data processing on the stored data, where the data processing includes periodically or aperiodically compressing the data stored in the memory such that the data occupies no more memory than before compression.

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

[0068] A 32nd aspect is a method of operating a transmitter configured to transmit signals from an implantable glucose sensor to a mobile device to improve data accuracy, the method including receiving signals from the implantable glucose sensor over time, storing data representing the received signals in a memory, and performing data processing on the stored data, where the data processing includes post-processing the data stored in the memory periodically or aperiodically so that the accuracy of the data, or the accuracy of calculations based on the data, is improved.

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

[0070] Aspect 33 is a method of operating a continuous glucose monitor, which includes receiving a signal from an implantable glucose sensor at a transmitter and receiving an external signal from an external sensor at the transmitter, and the sensor signal and the external signal are stored based on the absolute time or relative time of reception.

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

[0072] Aspect 34 is a method of operating a continuous glucose monitor, which includes receiving a signal from a transmitter measured by an implantable glucose sensor at a mobile device, receiving an external signal from an external sensor at the mobile device, and storing the sensor signal and the external signal at the mobile device based on the absolute time or relative time of reception.

[0073] Aspect 35 is a transmitter configured to physically engage with an implantable glucose sensor and transmit a signal representing a measured glucose concentration value to a mobile device, including a housing configured to physically engage with a glucose sensor configured to be at least partially implanted in 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] Aspects and implementations of embodiments can include one or more of the following: The first communication circuit can be a Near Field Communication (NFC) circuit; The second communication circuit can be a Bluetooth® Low Energy circuit, and the mobile device can be an HCP device; The transmitter can further include a feedback indicator that facilitates physical alignment by the user between the antenna of the het NFC circuit and the antenna of the mobile device.

[0075] A 36th aspect is a communication method between a mobile device and a transmitter configured to transmit to the mobile device a signal representing a glucose concentration value measured by physically engaging with a continuous glucose sensor, 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 operation mode; transmitting an advertisement message according to an encrypted wireless protocol and initiating a connection with the mobile device via the encrypted wireless protocol; and transmitting an estimated glucose value to the mobile device via the connection when the connection with the mobile device is established via the encrypted wireless protocol.

[0076] Aspects and implementations can include one or more of the following: Before receiving the data extraction command, receiving, at the transmitter, a query command using a short-range wireless protocol; in response to the query command, transmitting, using the short-range wireless protocol, an encrypted identifier of the transmitter, 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 in response to the query command, transmitting operation state information specifying one or more operation states of the transmitter.

[0077] Aspect 37 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 a continuous glucose monitoring device including a transmitter coupled to an implantable 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 transitioning the continuous glucose monitoring device to an operating mode in which the continuous glucose monitoring device will operate.

[0078] Aspect 38 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, automatically transitioning the transmitter from a non-active state to an active state in which the transmitter can transmit a signal encoded with data corresponding to a reading received from the sensor in response to the detection, broadcasting an advertisement message according to a first wireless protocol, opening the application on the patient's mobile device in response to the broadcast, causing the patient's mobile device to input a security code, pairing the transmitter with the patient's mobile device using the first wireless protocol, pairing the transmitter with the patient's mobile device using the first wireless protocol if the security code is correct, and initiating a sensor session in response to the pairing.

[0079] Aspect 39 is a method for quickly activating a transmitter configured to store for a predetermined period, physically engage with an implantable glucose sensor, and transmit a signal representing a measured glucose concentration value to a mobile device. The method includes, in the transmitter stored in a package, detecting a signal indicating an acceleration event, and, when the detected signal is determined to indicate that the acceleration event originated from an acceleration within a specified range, transitioning the transmitter from an inactive state to an active state.

[0080] Aspect 40 is a communication method between a mobile device and a transmitter configured to physically engage with an implantable glucose sensor and transmit a signal representing a measured glucose concentration value to the mobile device. The method includes, in the transmitter, receiving a data extraction command from the mobile device using a short-range wireless protocol, causing the transmitter to enter a data extraction operation mode in response to the data extraction command, transmitting an advertisement message according to an encrypted wireless protocol and starting a connection with the mobile device via the encrypted wireless protocol, and transmitting operation state information specifying at least one operation state of the transmitter when the connection with the mobile device via the encrypted wireless protocol is established. At least one operation state of the transmitter includes a sensor session completion state indicating that the session is complete and data is downloadable.

[0081] Aspect 41 is a communication method between an HCP reader and a transmitter configured to physically engage with an implantable glucose sensor and transmit a signal representing a measured glucose concentration value to the HCP reader. In the transmitter, receiving a data extraction command including an encrypted version of the transmitter's identifier from the HCP reader using a short-range wireless protocol; in response to the data extraction command, if the transmitter determines that the identifier included in the data extraction command is correct, putting the transmitter into a data extraction operation mode; transmitting an advertisement message according to an encrypted wireless protocol and starting a connection with the HCP reader via the encrypted wireless protocol, wherein the advertisement message includes information for preferentially connecting the HCP reader over other devices; and transmitting sensor data to the HCP reader via the connection when the connection with the HCP reader is established via the encrypted wireless protocol.

[0082] In further aspects and embodiments, the method features in the various aspects are explained from the perspective of the system as in the various aspects configured to implement the method features. Without limitation, any of the features of any of the embodiments of the aspects, including any embodiment of any of the 1st to 34th aspects mentioned above, are applicable to all other aspects and embodiments identified herein, including any embodiment of any of the 1st to 34th aspects mentioned above. Further, without limitation, any of the features of the embodiments of the various aspects, including any embodiment of any of the 1st to 34th aspects mentioned above, can be combined independently in any way, in part or in whole, with other embodiments described herein. For example, one, two, or three or more embodiments can be combined in whole or in part. Further, without limitation, any of the features of the embodiments of the various aspects, including any embodiment of any of the 1st to 34th aspects mentioned above, can be made optional with respect to other aspects or embodiments. Any aspect or embodiment of the method can be implemented by a system or apparatus of another aspect or embodiment, and any aspect or embodiment of the system or apparatus can be configured to implement a method of another aspect or embodiment, including any embodiment of any of the 1st to 34th aspects mentioned above.

[0083] The advantages of the aspects can, in certain embodiments, include one or more of the following. The systems and methods according to the present principle can enhance communication between HCPs and patients and provide valuable educational tools that enable better education of users about their diseases and their treatment. HCPs and patients are provided with more useful information for decision-making, treatment, and behavioral decision-making. HCPs can have more meaningful discussions with patients. It is advantageous for HCPs to be provided with pre-downloadable data prior to meeting with patients, making the patient examination more useful and beneficial. Other advantages will be understood from the following description, including the drawings and the claims.

[0084] This summary is provided to introduce the selection of concepts in a simplified form. The concepts will be further described in the detailed description section. Elements or steps other than those described in this summary are possible, and the elements or steps are not necessarily required. This summary is not intended to identify the key features or essential features of the claimed subject matter, nor is it intended to be used 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 of the disadvantages described in any part of this disclosure.

[0085] Further aspects of the present disclosure will be more readily apparent when considering the detailed description of the various disclosed embodiments described below with reference to the accompanying drawings.

Brief Description of the Drawings

[0086]

Figure 1A

Figure 1B

Figure 2A

Figure 2B

Figure 3A

Figure 3B

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26A

Figure 26B

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36A

Figure 36B

Figure 37

Figure 38

Figure 39

Figure 40

Figure 41

Best Mode for Carrying Out the Invention

[0087] The figures are explained in more detail in the following description and examples, provided only for purposes of illustration, and merely represent typical or exemplary embodiments of the present disclosure. The figures are not intended to be comprehensive or to limit the present disclosure to the exact form disclosed. It should also be understood that the present disclosure may be practiced with modifications or variations, and that the present disclosure may be limited only by the claims and their equivalents.

[0088] Embodiments of the present disclosure relate to systems, methods, and devices for HCP configuration of an analyte monitoring system, as well as auxiliary technologies and functionality. In the 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 ways to not only configure the communication protocol and the analyte monitoring system but also download data therefrom. Further, embodiments of the present disclosure may relate to systems and methods for conserving battery life in such systems since such systems can constitute wearable devices and both circuit real estate and battery capacity are precious.

[0089] Details of some exemplary embodiments of the systems, methods, and devices of the present disclosure are described in this description and in some cases, in other parts of the present disclosure. Other features, objects, and advantages of the present disclosure will become apparent to those skilled in the art upon examination of the present 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, within the scope of the present disclosure, and protected by one or more of the appended claims.

[0090] Summary In some embodiments, the system is provided for continuous measurement of a host analyte. The system can include a continuous analyte sensor configured to continuously measure the concentration of a host analyte, 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, such as, for example, raw sensor data, converted sensor data, and / or any other sensor data. The sensor electronics module can be further configured to generate sensor information customized for each display device so that different display devices can receive different sensor information.

[0091] For ease of explanation and illustration, in some examples, the detailed description describes exemplary systems and methods from the perspective of a continuous glucose monitoring environment, but it should be understood that the scope of the present invention is not limited to that particular environment, and one of ordinary skill in the art will understand that the systems and methods described herein can be embodied in various forms. Accordingly, any structural and / or functional details disclosed herein should not be construed as limiting the systems and methods, but rather as representative embodiments and / or attributes of arrangements provided to teach one or more ways to implement the systems and methods that may be advantageous in other situations.

[0092] For example, but not limited to, the monitoring systems and methods described can 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 body fluids of the host and / or another party or associated therewith.

[0093] As an example, without limitation, embodiments of the monitoring systems and methods described herein may include, but are not limited to, fingertip puncture blood sampling, blood analyte test strips, non-invasive sensors, wearable monitors (e.g., smart bracelets, smart watches, smart rings, smart necklaces or pendants, activity monitors, fitness monitors, health and / or medical monitors, clip-on monitors, and the like), adhesive sensors, smart textiles and / or garment-integrated sensors, sensors, transcutaneous (i.e., percutaneous) sensors, and / or ingestible, inhalable, or implantable sensors, which may include shoe inserts and / or insoles.

[0094] In some embodiments, without limitation, the monitoring systems and methods may include, instead of or in addition to the sensors described herein, inertial measurement units, activity, altitude, position, and / or location sensors, biometric sensors, such as optical heart rate monitors, photoelectric plethysmogram (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 stretch, displacement, pressure, weight, or impact, galvanometric sensors, capacitive sensors, electric field sensors, temperature / thermal sensors, microphones, vibration sensors, ultrasonic sensors, piezoelectric / piezoresistive sensors, and / or other sensors, such as transducers, for measuring information of a host and / or another party or related thereto.

[0095] As used herein, the term "analyte" is a broad term and should be given its ordinary and customary meaning to one of ordinary skill in the art (and should not be limited to a special or customized meaning), and further, without limitation, refers to substances or chemical components in a biological fluid that can be analyzed (e.g., blood, interstitial fluid, cerebrospinal fluid, lymph, urine, sweat, saliva, etc.). Analytes can include naturally occurring substances, artificial substances, metabolites, and / or reaction products. In some implementations, the analyte for measurement by a method or device is glucose. However, without limitation, the following: acarboxyprothrombin; acetoacetic acid; acetone; acetyl CoA; acyl carnitine; adenine phosphoribosyltransferase; adenosine deaminase; albumin; alpha-fetoprotein; amino acid profile (arginine (Krebs cycle), histidine / urocanic acid, homocysteine, phenylalanine / tyrosine, tryptophan); androstenedione; antipyrine; arabinitol enantiomer; arginase; benzoylecgonine (cocaine); biotinidase; biopterin; c-reactive protein; carnitine; carnosinase; CD4; ceruloplasmin; chenodeoxycholic acid; chloroquine; cholesterol; cholinesterase; conjugated 1-beta-hydroxychenodeoxycholic acid; cortisol; creatine kinase; creatine kinase MM isozyme; cyclosporine A; d-penicillamine; deethylchloroquine; dehydroepiandrosterone sulfate; DNA (acetylation agent polymorphism, alcohol dehydrogenase, alpha1-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 malariae, gonadal differentiation, 21-deoxycortisol); desbutylhalofantrine; dihydroptenidine reductase; diphtheria / tetanus antitoxin; erythrocyte arginase; erythrocyte protoporphyrin;Esterase D; fatty acid / acylglycine; triglyceride; glycerol; free beta-human chorionic gonadotropin; free erythrocyte porphyrin; free thyroxine (FT4); free triiodothyronine (FT3); fumarylacetoacetase; galactose / gal-1-phosphate; galactose-1-phosphate uridyltransferase; gentamicin; glucose-6-phosphate dehydrogenase; glutathione; glutathione peroxidase; glycolic acid; glycosylated hemoglobin; halofantrine; hemoglobin variant; hexosaminidase A; human erythrocyte carbonic anhydrase I; 17-alpha-hydroxyprogesterone; hypoxanthine phosphoribosyltransferase; immunoreactive trypsin; ketone bodies; lactate; lead; lipoprotein ((a), B / A-1, beta); lysozyme; mefloquine; netilmicin; phenobarbital; phenytoin; phytanic acid / pristanic acid; progesterone; prolactin; prolidase; purine nucleoside phosphorylase; quinene; reverse triiodothyronine (rT3); selenium; serum pancreatic lipase; sisomicin; somatomedin C; specific antibodies (adenovirus, antinuclear antibody, anti-zeta antibody, arbovirus, OESK virus, Medina 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, Loa loa, parainfluenza virus, Plasmodium falciparum, poliovirus, Pseudomonas aeruginosa, respiratory syncytial virus, Rickettsia (scrub typhus), Schistosoma mansoni, Toxoplasma gondii, Treponema pallidum, Trypanosoma cruzi / Langer, vesicular stomatitis virus, bancroftian filariasis, flavivirus (e.g., tick-borne encephalitis, 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;UDP-galactose-4-epimerase; urea; uroporphyrinogen I synthetase; vitamin A; white blood cells; and other analytes, such as zinc protoporphyrin, are similarly considered. Salts, sugars, proteins, fats, vitamins, and hormones that occur naturally in blood or interstitial fluid may also, in certain implementations, constitute analytes. Analytes may occur naturally in biological fluids, such as metabolites, hormones, antigens, antibodies, etc. Alternatively, analytes may be endogenous or exogenous to the body, such as imaging contrast agents, radioisotopes, chemical agents, fluorocarbon-based synthetic blood, or, without limitation, insulin; glucagon, ethanol; cannabis (marijuana, tetrahydrocannabinol, hashish); inhalants (nitrous oxide, amyl nitrite, butyl nitrite, chlorinated hydrocarbons, hydrocarbons); cocaine (crack cocaine); stimulants (amphetamine, methamphetamine, Ritalin, Cylert, Preludin, Dexedrine, Prestate, Voranil, Sandrex, Plegine); depressants (barbiturates, methaqualone, barium, Librium, Miltown, Serax, Equanil, Tranxene, etc., sedatives); hallucinogens (fenciclonidine, lysergic acid, mescaline, peyote, psilocybin); narcotics (heroin, codeine, morphine, opium, meperidine, Percocet, Percodan, Tussionex, fentanyl, Darvon, Talwin, Romilar); synthetic narcotics (fentanyl, meperidine, amphetamine, methamphetamine, fenciclonidine analogs, such as ecstasy); anabolic steroids; and nicotine, can be introduced into drugs or pharmaceutical compositions. Metabolites of drugs and pharmaceutical compositions are also considered analytes. For example, ascorbic acid, uric acid, dopamine, norepinephrine, 3-methoxytyramine (3MT), 3,4-dihydroxyphenylacetic acid (DOPAC), homovanillic acid (HVA), 5-hydroxytryptamine (5HT), and 5-hydroxyindoleacetic acid (FHIAA), as well as analytes such as neurochemicals and other chemicals produced in the body, such as intermediates in the citric acid cycle, can also be analyzed.;

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

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

[0098] In certain embodiments, a number of delivery actions (each having its own delivery option) can be associated with a single alert, such that displayable sensor information having different content and formats is transmitted to respective display devices, e.g., in response to a trigger of the single alert. For example, a mobile phone can receive a data package that includes minimal displayable sensor information (which can, in particular, be formatted to be displayed on the mobile phone), while a desktop computer can receive a data package that includes 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 an intelligent and dynamic estimation algorithm that estimates current or predicted risks, and alert conditions that combine higher accuracy, timeliness in imminent danger, avoidance of false alarms, and less patient discomfort. Generally, clinical risk alerts include a dynamic and intelligent estimation algorithm based on analyte values, rate of change, acceleration, clinical risk, statistical establishment, known physiological constraints, and / or individual physiological patterns, thereby providing more appropriate, clinically safe, and patient-friendly alerts. U.S. Patent Application Publication No. 2007 / 0208246, which is hereby incorporated by reference in its entirety, describes some systems and methods associated with the clinical risk alerts (or alarms) described herein. In some embodiments, the clinical risk alerts can be triggered over a predetermined period to enable the user to pay attention to their condition. Additionally, the clinical risk alerts can stop when leaving the clinical risk area so as not to discomfort the patient by repeating clinical alarms (e.g., visual, auditory, or vibratory) when the patient's condition is improving. In some embodiments, the dynamic and intelligent assessment determines the likelihood that a patient will avoid clinical risk based on analyte concentration, rate of change, and other aspects of the dynamic and intelligent assessment algorithm. If the likelihood of avoiding clinical risk is minimal or non-existent, a clinical risk alert will be triggered. However, if there is a likelihood of avoiding clinical risk, the system is configured to wait for a predetermined amount of time and re-analyze the likelihood of avoiding clinical risk. In some embodiments, if there is a likelihood of avoiding clinical risk, the system is further configured to provide a goal, treatment recommendation, or other information that can assist the patient in actively avoiding clinical risk.

[0100] In some embodiments, the sensor electronic device module is configured to search for one or more display devices within the communication range of the sensor electronic device 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 positioned on the display device.

[0101] In some embodiments, the sensor electronic device module is configured to provide one or more different alarms indicating that an alarm should be initiated by one or more display devices (e.g., sequentially and / or simultaneously) via the sensor electronic device module and / or via the transmission of a data package. In certain embodiments, the sensor electronic device module merely provides a data field indicating the presence of an alarm condition, and the display device can determine to trigger an alarm when it reads the data field indicating the presence of the alarm condition. In some embodiments, the sensor electronic device module determines which of the one or more alerts to trigger based on the one or more alerts that are triggered. For example, when an alert trigger indicates severe hypoglycemia, the sensor electronic device module can perform a number of actions such as activating an alarm on the sensor electronic device module, transmitting a data package indicating the activation of the alarm on the display to a monitoring device, and transmitting the data package to a care provider as a text message. As an example, a text message including displayable sensor information indicating the state of the host (e.g., "severe hypoglycemia") can be presented on a custom monitoring device, a mobile phone, a pager device, and / or the like.

[0102] In some embodiments, the sensor electronics module is configured to wait for a period of time for the host to respond to an alert triggered (e.g., by snoozing and / or an off function and / or pressing or selecting on the sensor electronics module and / or display device), and then trigger additional alerts (e.g., in an increasing manner) until responding to one or more alerts. In some embodiments, the sensor electronics module is configured to send a control signal (e.g., a stop signal) to a medical device associated with an alarm condition (e.g., hypoglycemia), such as an insulin pump, and 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 such that the wireless communication distance of the sensor electronics module can be increased, for example, to 10, 20, 30, 50, 75, 100, 150, or 200 meters or more, and the repeater is configured to repeat wireless communication from the sensor electronics module to a display device located remotely from the sensor electronics. The repeater may be useful for families with children suffering from diabetes. For example, in a large house where a parent sleeps away from the child, it enables the parent to carry or place the display device in a fixed location.

[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 list of display devices and / or attempt wireless communication with the display device in a predetermined order and / or a programmable order (e.g., ranking and / or stepwise increase), for example, the failure of communication with and / or attempt to alarm the first display device triggers communication with and / or attempt to alarm the second display device, among others. In an exemplary embodiment, the sensor electronics module is configured to sequentially use a list of display devices such as (1) a default display device or a custom analyte monitoring device, (2) a mobile phone via auditory and / or visual means such as text messages to the host and / or care provider, voice messages to the host and / or care provider, and / or 911, (3) a tablet, (4) a smartwatch or bracelet, and / or (5) smart glasses or other wearable display devices to search for the host or care provider and attempt to alarm.

[0105] According to an embodiment, one or more display devices that receive data packages from a sensor electronic device module are “dummy displays”, and the display devices display displayable sensor information received from the sensor electronic device module without performing additional processing (e.g., predictive algorithm processing required for real-time display of sensor information). In some embodiments, the displayable sensor information includes converted sensor data that does not require processing by the display device before displaying the displayable sensor information. Some display devices can include software that includes a display instruction (software programming that includes an instruction configured to display the displayable sensor information and optionally query the sensor electronic device module to obtain the displayable sensor information) configured to enable the displayable sensor information to be displayed therein. In some embodiments, the display device is programmed with the display instruction by the manufacturer and can include security and / or authentication to avoid 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., JavaScript (registered trademark) downloadable via the Internet), and thus any display device that supports the download of the program (e.g., any display device that supports Java (registered trademark) applets) can thereby be configured to display the displayable sensor information (e.g., mobile phones, tablets, PDAs, PCs, and the like).

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

[0107] In certain embodiments, one or more display devices include a built-in authentication mechanism, and authentication is required for communication between the sensor electronics module and the display device. 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, the challenge is a request for a password, a valid response is the correct password, and pairing between the sensor electronics module and the display device can be achieved via a password by a user and / or manufacturer. This can be referred to as two-way authentication in some cases. In some embodiments, biometric authentication can also be employed.

[0108] In some embodiments, one or more display devices are configured to query a sensor electronics module about displayable sensor information, and the display device functions as a master device that requests sensor information on demand from the sensor electronics module (e.g., a slave device), in response to the query, for example. In some embodiments, the sensor electronics module is configured to transmit sensor information to one or more display devices periodically, systematically, regularly, 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 a data package associated with a triggered alert (e.g., triggered by one or more alert conditions). However, any combination of the data transmission statuses described above can be implemented with any combination of paired sensor electronics modules and display devices (s). For example, one or more display devices can be configured to query a database of a sensor electronics module and receive alert information triggered by meeting one or more alert conditions. In addition, 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 those described in the previous example), whereby the system can include display devices that function differently with respect to how they acquire sensor information.

[0109] In some embodiments, the display device is configured to query a data storage memory within the sensor electronics module for certain types of data content, including direct queries to a database within the memory of the sensor electronics module and / or requests for structured or constructible packages of data content therefrom, i.e., the 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 communicating. In some additional or alternative embodiments, the sensor electronics module generates sensor information that is displayable based on its knowledge of which display device will receive a particular transmission. Additionally, some display devices can obtain calibration information through manual entry of calibration information, automatic delivery of calibration information, and / or an integrated reference analyte monitor incorporated into the display device, and wirelessly transmit the calibration information to the sensor electronics module. U.S. Patent Application Publication Nos. 2006 / 0222566, 2007 / 0203966, 2007 / 0208245, and 2005 / 0154271 (all of which are hereby incorporated 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 the embodiments disclosed herein.

[0110] Generally, a plurality 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 a sensor electronics module. The plurality of display devices can be configured to display at least a portion of the displayable sensor information wirelessly communicated from the sensor electronics module. Displayable sensor information can include, for example, sensor data such as analyte concentration values, rate of change information, trend information, alert information, sensor diagnostic information, and / or calibration information, etc., of unprocessed data and / or converted sensor data.

[0111] Analyte sensor Referring to FIG. 1A, in some embodiments, analyte sensor 10 includes a continuous analyte sensor, e.g., a subcutaneous, transdermal (e.g., percutaneous), or intravascular device. In some embodiments, such sensors or devices can analyze multiple intermittent blood samples. The present disclosure includes embodiments of glucose sensors, although such embodiments can be used equally well for other analytes. Glucose sensors can use any glucose measurement method, including enzymatic, chemical, physical, electrochemical, spectrophotometric, polarimetric, calorimetric, electrophoretic, radiometric, immunochemical, and the like.

[0112] Glucose sensors can provide a data stream indicative of the concentration of glucose in a host using any known method, including invasive, minimally invasive, and non-invasive sensing techniques (e.g., fluorescence monitoring). The data stream is typically an unprocessed data signal, which is converted into a calibrated and / or filtered data stream for use in providing useful glucose values to a user such as a patient or caregiver (e.g., a patient, relative, guardian, teacher, physician, 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 representing the concentration of glucose (e.g., in the form of analyte data).

[0114] In certain embodiments, analyte sensor 10 is an implantable glucose sensor as 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 as described with reference to U.S. Patent Application Publication No. 2006 / 0020187-A1. In embodiments, analyte sensor 10 is configured to be implanted within the host's vasculature or extracorporeally as described in U.S. Patent Application Publication No. 2007 / 0027385-A1, co-pending U.S. Patent Application Publication No. 2008 / 0119703-A1, filed Oct. 4, 2006, U.S. Patent Application Publication No. 2008 / 0108942-A1, filed Mar. 26, 2007, and U.S. Patent Application No. 2007 / 0197890-A1, filed Feb. 14, 2007. In embodiments, a continuous glucose sensor includes, for example, a transcutaneous sensor as described in the specification of U.S. Patent No. 6,565,509 to Say et al. In embodiments, analyte sensor 10 is a continuous glucose sensor that includes, for example, a subcutaneous sensor as described with reference to the specification of U.S. Patent No. 6,579,690 to Bonnecaze et al. or the specification of U.S. Patent No. 6,484,046 to Say et al. In embodiments, a continuous glucose sensor includes, for example, a refillable subcutaneous sensor as described with reference to the specification of U.S. Patent No. 6,512,939 to Colvin et al. A continuous glucose sensor can include, for example, an intravascular sensor as described with reference to the specification of U.S. Patent No. 6,477,395 to Schulman et al. A continuous glucose sensor can include, for example, an intravascular sensor as described with reference to the specification of U.S. Patent No. 6,424,847 to Mastrototaro et al.

[0115] Figures 2A and 2B are perspective and side views of a housing 200 that can be used in connection with the implementation of an embodiment of an analyte sensor system 8 according to certain aspects of the present disclosure. The housing 200 includes a placement unit 214 and a sensor electronics module 12 attached to the housing in certain embodiments. The housing 200 is shown in a functional position and includes a placement unit 214 and a sensor electronics module 12 meshingly engaged within the housing. In some embodiments, the placement 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 a number of advantages over other transcutaneous sensors that may be subject to motion-related artifacts associated with the movement of the host while the host is using the device. The placement unit 214 and / or the sensor electronics module 12 can 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 is provided between the placement unit 214 and the sensor electronics module 12, which allows for improved manufacturability, i.e., a potentially relatively inexpensive placement unit 214 can be discarded when improving or servicing the analyte sensor system 8, while a relatively expensive sensor electronics module 12 can be reused with a number of sensor systems. In some embodiments, the sensor electronics module 12 is configured by signal processing (programming) to perform functions such as filtering, calibrating, and / or 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 contact 238 is placed on or within a subassembly, hereinafter referred to as the contact subassembly 236 herein, configured to fit within the base 234 of the placement unit 214 and the hinge 248, and the hinge enables the contact subassembly 236 to pivot between a first position (when inserted) and a second position (when in use) relative to the placement unit 214. The term "hinge" as used herein is a broad term and includes, but is not limited to, any of various pivoting, articulating, and / or hinging mechanisms such as adhesive hinges, sliding joints, and the like, and the term "hinge" does not necessarily mean a pivot point or fixed point about which articulation occurs. In some embodiments, the contact 238 is formed of a conductive elastomeric material such as carbon black elastomer through which the sensor 10 extends.

[0118] Referring further to FIGS. 2A and 2B, in a particular embodiment, the placement unit 214 includes an adhesive pad 208 disposed on the back of the placement unit and including a releasable backing layer. Thus, the placement unit 214 is adhered to the host's skin by removing the backing layer and pressing at least a portion of the base 234 of the placement unit 214 against the host's skin. Additionally or alternatively, the adhesive pad can be placed over a portion or all of the sensor system 8 and / or 10 after sensor insertion to ensure adhesion and optionally to ensure an airtight or watertight seal around the wound exit site (or sensor insertion site) (not shown). Suitable adhesive pads can be selected and designed to stretch, expand, conform, and / or breathe with respect to 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. Patent No. 7,310,544, which is hereby incorporated by reference in its entirety. The configuration and arrangement can provide water-resistant, waterproof, and / or hermetic characteristics associated with the embodiments of the placement unit / sensor electronics module 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 Configuration Referring again to FIG. 1A, a system 100 is shown that can be used in connection with the implementation of aspects of an analyte sensor system. In some instances, system 100 can be used to implement various systems described herein. The system 100 of the embodiment, according to certain aspects of the present disclosure, includes an analyte sensor system 8 and display devices 110, 120, 130, and 140. The analyte sensor system 8, in the illustrated embodiment, includes a sensor electronics module 12 and a continuous analyte sensor 10 associated with the sensor electronics module 12. The sensor electronics module 12 can wirelessly communicate (e.g., directly or indirectly) with one or more of the display devices 110, 120, 130, and 140. In an embodiment, the system 100 also includes a medical device 136 and a server system 134. The sensor electronics module 12 can also wirelessly communicate (e.g., directly or indirectly) with the medical device 136 and the server system 134. In some examples, the display devices 110 - 140 can also wirelessly communicate with the server system 134 and / or the medical device 136.

[0121] In certain embodiments, sensor electronics module 12 includes electronic circuitry associated with the measurement and processing of continuous analyte sensor data, including predictive algorithms associated with the processing and calibration of sensor data. The sensor electronics module 12 can be physically connected to the continuous analyte sensor 10, and can be integrated with (irreversibly attached thereto), or removably attached to, the continuous analyte sensor 10. The sensor electronics module 12 can include hardware, firmware, and / or software that enables the measurement of analyte levels via a glucose sensor. For example, the sensor electronics module 12 can include a potentiostat, a power source 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 fixed to a printed circuit board (PCB) or the like, and can take various 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] The sensor electronics module 12 can 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 more detail herein, as well as in U.S. Patent 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 hereby incorporated by reference in their entirety for all purposes.

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

[0124] Here, it should be noted that in some cases, using wired or wireless RF telemetry to communicate with sensors and user devices can be particularly complex, especially with regard to breakage, infection, and electrical noise. In some cases, the electrical conductivity of the body can be used to enable wireless communication with implanted devices. Such methods include, for example, capacitive body-to-body communication that 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 particular 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, the medical device 136 can be a passive device in an exemplary embodiment of the present disclosure. For example, the medical device 136 can 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 the analyte sensor system 8. One reason is to provide the ability to stop or activate insulin administration to the insulin pump when the glucose value falls below a threshold. One solution that enables a passive device (e.g., medical device 136) to receive analyte data (e.g., glucose values) without being coupled to the analyte sensor system 8 is to include the analyte data within an advertisement message transmitted from the analyte sensor system 8. The data included within the advertisement message can be encoded such that only devices having identification information associated with the 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 by a user, for example, for processing sensor data and / or displaying data from the sensor device 136b and / or receiving input for operations of the sensor device and / or data processing, in a wired or wireless communication with a dedicated monitor or display device 136a.

[0126] Referring further to FIG. 1A, the plurality of display devices can include a custom display device specially designed to display certain types of displayable sensor information (e.g., in some embodiments, numerical values and arrows) associated with the analyte values received from the sensor electronics module 12. The 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 Android, iOS, or other operating systems, and is configured to display a graphical representation of continuous sensor data (e.g., including current and past data). Other display devices can include tablets 130, smartwatches 140, medical devices 136 (e.g., insulin delivery devices, or blood glucose meters), and / or other handheld devices such as desktop or laptop computers.

[0127] Since different display devices provide different user interfaces, the content 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, the plurality of different display devices can communicate directly wirelessly 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 displays and / or functions associated with multiple different types and / or levels of displayable sensor information, which is described in more detail elsewhere in this specification.

[0128] As further illustrated in FIG. 1A, system 100 can also include a wireless access point (WAP) 138, which can be used to couple to one or more of the analyte sensor system 8, the plurality of display devices, the server system 134, and the medical device 136 to each other. For example, WAP 138 can provide Wi-Fi and / or cellular connectivity within system 100. Near field communication (NFC) can also be used between devices of system 100. Server system 134 can be used to collect analyte data from the analyte sensor system 8 and / or the plurality of display devices to, for example, perform analysis of the analyte data, generate general or individual models regarding blood glucose values and profiles, and the like.

[0129] Referring now to FIG. 3A, system 300 is shown. System 300 can be used in connection with the implementation of the disclosed systems, methods, and device embodiments. By way of example, using the various components described below in FIG. 3A, wireless communication of glucose data can be provided, for example, between an analyte sensor system, such as that shown in FIG. 1A, and a plurality of display devices, medical devices, servers, and the like.

[0130] As shown in FIG. 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 communication medium 305.

[0131] As will be described in detail below, the analyte sensor system 308 and the display device 310 can exchange messaging via the communication medium 305, and the communication medium 305 can also be used to deliver analyte data to the display device 310 and / or the server system 334. As alluded to above, examples of the display device 310 can include various electronic computing devices such as 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. Here, it will be noted that the GUI of the display device 310 can perform the corresponding functions when receiving user input and can display menus and information derived from 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, game platform OSs (e.g., Xbox, PlayStation, Wii), etc. 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 protocol, infrared (IR), radio frequency (RF), 2G, 3G, 4G, etc., and / or wired protocols and media.

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

[0133] As described above, the communication medium 305 can be used to connect the analyte sensor system 308, the display device 310, and / or the server system 334 to each other or to a network, or communicatively couple them, 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. Further, 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), and others. Those skilled in the art will recognize other ways to implement the communication medium 305 for the purpose of communication upon a reading of this disclosure.

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

[0135] 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, for example, including an integrated circuit or an assembly thereof, a printed circuit board or an assembly thereof, or in separate enclosures / packages / racks, or a combination thereof. In an embodiment, server 334a is at least partially targeted at communications that occur through communication medium 305. Such communications include delivery and / or messaging (e.g., advertisements, commands, or other messaging), as well as analyte data. For example, server 334a can process messages related to frequency bands, transmission timing, security, alarms, and others, and exchange them between analyte sensor system 308 and display device 310. Server 334a can update information stored in analyte sensor system 308 and / or display device 310, for example, by delivering an application thereto. Server 334a can transmit / receive information to / from analyte sensor system 308 and / or display device 310 in real time or sporadically. Further, server 334a can implement cloud computing capabilities for analyte sensor system 308 and / or display device 310.

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

[0137] As alluded to above, wireless communication protocols can be used to transmit and receive data between the analyte sensor system 308 and the display device 310 via the communication medium 305. Such wireless protocols can be designed for use in wireless networks (e.g., personal area networks (PANs)) that are optimized for periodic, small-scale data transfers to a number of nearby devices (which can be transmitted at low speeds if necessary). For example, one such protocol can be optimized for periodic data transfers, in which case the transceiver can be configured to transmit data over short intervals and then enter a low-power mode over long intervals. The protocol can have low overhead requirements both for normal data transfers and for initializing the communication channel (e.g., by reducing overhead) to reduce power consumption. In some embodiments, a burst broadcasting scheme (e.g., one-way communication) can be used. This can eliminate the overhead required for an acknowledgement signal and enable periodic transmissions that consume little power.

[0138] The protocol can be further configured to establish communication channels with a number of devices and, on the other hand, implement 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 the transmission window and frequency in response to interference and to support communication with a number of devices. Therefore, 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 schemes. Using various network topologies, it can support short-range and / or low-power wireless communications such as peer-to-peer, star, tree, or mesh network topologies like Wi-Fi, Bluetooth®, and Bluetooth® Low Energy (BLE). The wireless protocol can operate in various frequency bands such as the open ISM band at 2.4 GHz. Further, to reduce power consumption, the wireless protocol can adaptively configure the data rate according to the power consumption.

[0139] Referring further to FIG. 3B, system 302 can include a display device 310 communicatively coupled to an analyte sensor system 308 via a communication medium 305. In the illustrated embodiment, display device 310 includes a connectivity interface 315 (which in turn includes a transceiver 320), a storage device 325 (which in turn stores an 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 display device 310, and a real-time clock (RTC) 350. A bus (not shown) can be used to interconnect the various elements of display device 310 and transfer data between these elements. Wireless communication between elements, such as between display device 310 and analyte sensor 308, can also be employed. In certain embodiments, NFC can be employed as such a wireless communication scheme. Further details of the communication techniques between the sensor electronics and the receiver or display device are described below in connection with FIG. 4 and below.

[0140] The display device 310 can be used to alert and provide sensor information or analyte data to the user, and can also include a processor / microprocessor 335 for processing and managing sensor data. The display device 310 can include a display 345, a storage 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, instructions, and / or data to the analyte sensor system 308. The transceiver 320 can further use a communication protocol. The storage device 325 is also used to store an operating system for the display device 310 and / or for a custom (e.g., proprietary) application designed to wirelessly communicate data between the transceiver and the display device 310. The storage device 325 can be a single memory device or multiple memory devices, and can be a volatile or non-volatile memory for storing software programs and application data and / or instructions. The instructions can be executed by the processor 335 to control and manage the transceiver 320.

[0141] In some embodiments, when a standardized communication protocol is used, a commercially available transceiver circuit can be utilized, which incorporates a processing circuit to handle low-level data communication functions such as encoding of data, transmission frequency, handshake protocol, and management of the like. In these embodiments, the processors 335, 380 need not manage these activities; rather, they manage high-level functions such as providing data values desired for transmission, raising or lowering power, setting the speed at which messages are transmitted, and the like. Instructions and data values for performing these high-level functions can be provided to the transceiver circuit via a data bus and transfer protocol established by the manufacturer of the transceivers 320, 360.

[0142] The components of the analyte sensor system 308 may require periodic replacement. For example, the analyte sensor system 308 can 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 storage 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 be powered and activated for a much longer period (e.g., 3 - 6 months or more) than the sensor 375 until 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, especially the battery, significantly improves the convenience and cost of using the analyte sensor system 308 for users as well. In some embodiments, the sensor electronics module can connect to the sensor 375 and establish a sensor session when first used (or in some cases, restarted after replacing the battery). As further described below, when the module is first used or restarted (e.g., after replacing the battery), there may first be a process for establishing communication between the display device 310 and the sensor electronics module. When the display device 310 and the sensor electronics module establish communication, they can communicate periodically and / or continuously throughout the life of multiple sensors 375, for example, until the battery needs to be replaced. Each time the sensor 375 is replaced, a new sensor session can be established. The new sensor session can be initiated through a process completed using the display device 310, and the process can be triggered by a notification of a new sensor via communication between the sensor electronics module and the display device 310 that can persist throughout the 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 analyte values can be collected and transmitted throughout the life of the sensor 375 (e.g., in the range of 1 to 30 days or more). New measurements can often be transmitted sufficiently to appropriately monitor blood glucose levels. Instead of continuously communicating with the transmission and receiving circuitry of each of the analyte sensor system 308 and the display device 310, the analyte sensor system 308 and the display device 310 can establish a communication channel between them regularly and / or periodically. Thus, the analyte sensor system 308 can communicate in some instances via wireless transmission with the display device 310 (e.g., a handheld computing device, a medical device, or a dedicated device) at a predetermined time interval. The duration of the predetermined time interval is 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 the display device 310 with sensor information (e.g., measured glucose values or analyte data) to output to the user (e.g., via the display 345) in substantially real time. In some embodiments, the predetermined time interval is every 5 minutes, although it is recognized that this time interval can vary to any desired time.

[0144] Continuing to refer to FIG. 3B, as shown, the connectivity interface 315 interfaces the display device 310 to the communication medium 305, such that the display device 310 can be communicatively coupled to the analyte sensor system 308 via the communication medium 305. The transceiver 320 of the connectivity interface 315 can include a number of transceiver modules operable with different wireless standards. The transceiver 320 can be used to receive analyte data as well as associated commands and messages from the analyte sensor system 308. Additionally, the connectivity interface 315 can include additional components for controlling wireless and / or wired connections, such as in some instances a baseband and / or Ethernet® modem, an audio / video codec, and the like.

[0145] The memory device 325 can include volatile memory (e.g., RAM) and / or non-volatile memory (e.g., flash storage), can include any of EPROM, EEPROM, cache, or can include some combination / variation of these. In various embodiments, the memory device 325 can store user input data collected by the display device 310 and / or other data (e.g., input from other users collected via the analyte sensor application 330). The memory 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. Additionally, as will be described in more detail below herein, the memory device 325 can store the analyte sensor application 330, which when executed using the processor 335, can receive input (e.g., via conventional hard / soft keys or touch screen, voice detection, or other input mechanisms) and enable the 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 the GUI 340, which can be provided by the display 345 of the display device 310. As an example, the display 345 can be a touch screen display that accepts various hand gestures as inputs. The application 330 can process and / or present data related to an analyte received by the display device 310 according to the various operations described herein, and can present such data via the display 345. Additionally, the application 330 can be used to acquire, access, display, control, and / or interface connect analyte data associated with the analyte sensor system 308, as well as related messaging and processes, as described in further detail herein.

[0147] The application 330 can be downloaded, installed, and initially configured 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 via a communication medium (e.g., 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., stored in the server system 334, locally stored from the storage device 325, or regardless of storage from the analyte sensor system 308). By way of example, the application 330 can present a menu that includes various controls or commands that can be executed in relation to the operation of the analyte sensor system 308 and one or more display devices 310. The application 330 can also be used to interface with or control other display devices 310, for example, to distribute or make available analyte data, including, for example, receiving / sending analyte data directly to / from other display devices 310 and / or sending commands to the analyte sensor system 308 and other display devices 310 to be connected, as described herein. In some implementations, the application 330 can interact with other application(s) on the display device to search for or provide related data such as other health data, for example.

[0148] The analyte sensor application 330 can include various code / function 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 the various functions herein (e.g., in connection with 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, thus operably coupling the code to a processor 335 (which can include circuitry for such execution) and / or executing by the processor to perform specific functions related to interfacing with and performing tasks related to analyte data (e.g., as described herein with respect to various operations and flowcharts). As further described below, the display module can present various screens to the user (e.g., via a display 345), the screens including graphical representations of information provided by the application 330. In further embodiments, the application 330 can be used to display an environment for the user to browse and interact with various display devices that may be connectable to the analyte sensor system 308, as well as the analyte sensor system 308 itself. The sensor application 330 can include a native application modified by a software design kit (e.g., depending on the operating system) to perform the functions / features described herein.

[0149] Referring back to FIG. 3B, the display device 310 also includes a processor 335. The processor 335 can include processor sub-modules, which, by way of example, include an application processor that interfaces with and / or controls other elements of the display device 310 (e.g., connectivity interface 315, application 330, GUI 340, display 345, RTC 350, etc.). The processor 335 can include a controller and / or a microcontroller, which provides various controls related to device management, such as, for example, a list of available or previously paired devices, information related to measurements, information related to the state of the network (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, and other such, and interfaces with buttons and switches. Additionally, the controller can include user input such as a user's fingerprint (e.g., for allowing user access to data or for use in the authorization / encryption of data including analyte data), as well as various controls related to the collection of analyte data.

[0150] The processor 335 can include circuits such as logic circuits for peripheral components and audio components, memory, battery and power circuits, and other circuit drivers. The processor 335 and any of its sub-processors can include logic circuits 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 can be coupled by a bus to the display 345, as well as to the connectivity interface 315 and the storage device 325 (including the application 330). Thus, the processor 335 can receive and process the electrical signals generated by each of these respective elements and thus perform various functions. As an example, the processor 335 can, upon instruction from the application 330, access the stored content from the storage device 325, process the stored content, and display and / or output it by the display 345. Additionally, the processor 335 can process the stored content and transmit it via the connectivity interface 315 and the communication medium 305 to other display devices 310, analyte sensor systems 308, or server systems 334. The display device 310 can include other peripheral components not shown in detail in FIG. 3B.

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

[0152] Note that at present, elements with the same name between the display device 310 and the analyte sensor system 308 can include the same features, structures, and / or capabilities. Thus, with respect to such elements, the description of the display device 310 above can, in some cases, be applied to the analyte sensor system 308.

[0153] Monitoring and collecting a patient's diabetes information by an HCP and simultaneously assisting in the management of the patient's illness can be difficult because there is no product that is user-friendly and cost-effective (for both the HCP and the patient). Even if such a device is provided, it is generally desirable to involve the HCP significantly in the setup, especially for patients who are unfamiliar with such procedures. These goals are complicated by the proliferation of user-mobile devices that provide very high convenience for the user / patient, but it is difficult for the HCP to be proficient in all such products and all such applications installed on such products.

[0154] In one implementation, referring to system 400 of FIG. 4, which is intended to show the arrangement of devices within the HCP office, a low-cost, programmable, and user-friendly product, herein referred to as “specialty product” 402, may be provided. Subsequently, this product is loaned and provided to the patient, who can return it at the end of the sensor session. The specialty product 402 can include functions similar to those of other mobile devices, such as a smartphone, and can communicate with the transmitter 404 via an appropriate communication protocol. Since the specialty product 402 provided to the HCP will be well-known to the HCP, the HCP does not need to learn an entirely new device. The specialty product 402 can also be embodied by an HCP device, such as an HCP computer 406 that operates the HCP application 429, or a mobile device (such as a smartphone) configured to operate the HCP application, in one implementation. In this implementation, the patient is not provided with a device for providing data display during their sessions, or uses their smartphone if appropriate communication is 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 within the HCP 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 certain operations, such as performing transmitter and / or sensor verification, setting up user or patient accounts, downloading data from the transmitter, 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., setting up user / patient accounts, sensor and / or transmitter verification, downloading data from the transmitter, etc.).As further described herein, the HCP device can be equipped with NFC and BLE wireless technologies to perform operations.

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

[0156] When a separate specialty product mobile device is employed, the HCP device 406 can employ one or more devices that enable communication with the specialty product 402, for example, a reader 420 that can be embodied in a dongle 426 in some cases. Since technologies such as NFC require particularly close proximity between the reader and the specialty product, a target 422 may be displayed on the reader 420 to indicate the position of the antenna. Similar targets can be placed on the specialty product 402, or if the HCP uses its smartphone or other mobile device, the HCP can recognize or be able to recognize where the NFC antenna is located. Further, in some implementations, the dongle or reader can include both NFC and BLE wireless.

[0157] Using such a reader 420 instead of an HCP smartphone, for example, provides various advantages. It is generally low-cost, does not require charging since it is wired to the HCP device, and can also have a larger coil for NFC pairing. It is often preferred by the HCP as a device that is not easily lost, has a long lifespan, can be conveniently set to provide confirmation of sensor functionality, and does not require another pairing action since it is wired to the HCP device.

[0158] Using an HCP reader can also provide other advantages. For example, if the user / patient lacks a smartphone or, alternatively, lacks a smartphone that is compatible with the analyte monitoring system, the HCP reader 420 or the HCP user device 402 can be employed to initiate or power on the patient's device and to set the transmitter 404 in order to download data from the user's device at the end of the session.

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

[0160] The HCP application may be used to enter data into fields for setting up a user account, and further, for a diagnostic function including verifying that the sensor is operating, e.g., that the sensor and transmitter are delivering counts to a specialized product (e.g., HCP specialized product 402) or other device, or that the sensor and transmitter are receiving a predetermined number of counts over a predetermined time. Details of such functions are provided below. The HCP application can further verify that the sensor is operating, e.g., within minutes of application to the patient, by visual indicators and / or audible beep sounds on the application. The HCP application may further be employed to extract data from the sensor. For example, the HCP application can pair with the sensor / transmitter in conjunction with an HCP device (e.g., HCP specialized product 402) or HCP reader and extract data within seconds or minutes. A visual indicator and / or audible beep sound may be provided when data transfer is complete. And the HCP application can upload the data to a server and provide an indication that the data upload was successful. As a further function, the HCP application can cause the transmitter to delete patient data when it is securely stored on the HCP device or server. The HCP application can store data for multiple patients at once. In some cases, the HCP application can incorporate a limited patient data display function, with the main purpose being to collect the data, upload it, and delete the data after upload. The HCP application can have various main icons or pages related to account setup, sensor operation verification, data extraction, and a list of patient data statuses.

[0161] The transmitter 404 has been described above, but for the purposes of this discussion, it should be noted that the same generally includes a processor 408 as well as a memory (or other storage device) 410. The transmitter 404 includes circuitry 412 configured to couple to the sensor wire. The circuitry 412 generally includes contacts that electrically couple to 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 a communication circuit 414 through which the transmitter can communicate with other devices, including, for example, the HCP device 406, the specialty product 402, or other user devices such as a personal smartphone. The communication circuit 414 can include provisions such as a circuit or antenna 416 for NFC communication and a circuit or antenna 418 for BLE communication. It will be understood that circuits including antennas can be provided for other communication modes as well, both wired and wireless.

[0162] System 450 of FIG. 5 shows another view of a device, generally within an HCP office, that includes a communication path. This figure also shows other devices that can be employed in the system, including a patient's personal device 434 such as a smartphone. FIG. 5 shows an implantable sensor 436 within the patient and a transmitter 404 that communicates with a flexible electronics 438. The flexible electronics can be provided, for example, as a sticker provided within (or with) the sensor and / or transmitter package and 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 a reader 420 and / or the specialty product 402 or patient device 434 such that the transmitter identification for that session can be associated with the patient's user account. In other implementations, it will be understood that a passive code, such as a barcode, QR code (registered trademark), etc., that can subsequently be read by the reader 420 and / or the specialty product 402 or patient device 434 can be employed.

[0163] The flexible electronic device 438 can be conveniently employed to simplify the transmitter pairing process, such as transmitter pairing with a specialized product or a patient device, for example, via a wireless link such as NFC or BLE which will be described in more detail below.

[0164] When the flexible electronic device is provided as a sticker, the transmitter pairing ID may be pre-programmed in the same state as being placed within or on the transmitter package. Upon reception, the patient can touch or tap their receiver or phone to the package, the transmitter pairing ID is read, and automatically input into the pairing device. Such a thing can 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 the sensor patch. For example, each patch can include an NFC electronic device, information such as lot or expiration date can be pre-entered, and upon insertion into the housing, the transmitter can verify that the sensor is within the "safely usable" window and transmit this information to the cloud, for example, via one of the connected devices such as the reader 420, the specialized product 402, the patient device 434, or even the HCP device 406. Such information enables the technical support function to access the information to rationalize troubleshooting and monitor on-site failures per lot for use in optimizing the process.

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

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

[0167] FIG. 5 also shows an HCP beacon / proximity device 440 arranged to communicate with various devices. The device 440 can include a wireless device arranged at a fixed location, such as an HCP office, and broadcasting fixed data pieces via BLE. When a patient arrives at the HCP office for a review, e.g., a CGM 14-day review, the transmitter 404 or the specialty product 402 or the patient device 434 can detect this beacon signal and trigger an automatic download of the stored memory analyte concentration data for access by the HCP via the HCP application 429. The HCP application 429 can also be included in the HCP specialty device 402. In such a scenario, 40 HCP beacons can be paired with the transmitter during the initial setup phase, if desired. Further, to initiate the download, the beacon device 440 may also need to communicate 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. FIG. 6 is a flowchart 500 showing an overall way in which the implementation of this configuration can be positioned. This figure provides an overview of what will be described in more detail throughout the remainder of this specification and with reference to the elements of FIG. 5.

[0168] In the first step, a sensor / transmitter is provided to the patient / user (step 452). Such are generally provided as a kit, and often the transmitter is reusable, and thus only the sensor is provided. However, as described above, the flexible electronic circuit can be provided by means such as a sticker to provide machine-readable identification information regarding the sensor or the transmitter or both. Such information can also be provided as part of, for example, a barcode, a QR code (registered trademark), etc.

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

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

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

[0172] At the next visit by the HCP, the patient returns (step 460), and the HCP can take an action to "wake up" the transmitter if it has transitioned to an inactive state (step 462). The HCP can then download or extract sensor data from the transmitter (step 464). Optionally, the data can be sent intermittently or continuously to a server, or to a specialized product or user device, depending on the nature of the settings.

[0173] The details of each of these 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 a first step, a communication session is established between the HCP device and the server (step 472). This can be done in a typical manner where the HCP provides a username and password, as well as additional identification information in some implementations. The HCP can then enter patient information on the HCP device (step 474) or via a specialized device. Optionally, especially when a new transmitter is being used, the HCP can enter transmitter data on the HCP device (step 482). This step can be adopted using, for example, the flexible electronic circuits, barcodes, QR codes (registered trademarks), etc. 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 according to the input data (step 478).

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

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

[0179] The mode may further change according to the operation mode. Although details will be described later, here, in many cases, to avoid the user's actions from "contaminating" the initial glucose concentration data, the HCP may desire that the user start in blind mode (step 490) so that the user does not take actions that recursively affect their glucose data. It should be noted that although such actions may ultimately be desired, many HCPs first want to see "where the user is" regarding glucose control, and the blind mode is particularly useful for such attempts. The mode can also be made non-blind in different implementations (step 492) so that the user can view their current data and act based on it. Again, such a thing is generally desired after the user has obtained an idea about their current blood glucose control level. In some cases, the user starts in blind mode, and at the occurrence of a trigger event or expiration of a period, the combined mode can be made useful (step 494), and the system is configured to switch to non-blind mode. For example, the HCP may desire that the user spend 7 days in blind mode and 7 days in non-blind mode. Alternatively, when the user reaches the current level of blood glucose control, the system automatically switches to non-blind mode, for example, and can control their glucose concentration within a predetermined target range. In any case, such trigger- and duration-based switching may be performed automatically, or the system may be configured to provide such a function.

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

[0181] However, in many cases, the patient has to return to the HCP's office for data extraction and analysis (step 502). The data can generally be extracted in a very short period, for example, less than 5 seconds or 10 seconds. The data can generally be extracted using wired or wireless communication according to certain interrogation signals 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 data extraction, or even as part of the sensor session, various diagnostic routines can be executed by the HCP device to confirm the proper operation of the sensor and transmitter. In one implementation, referring back to FIG. 4, such things can be executed by the diagnostic application 428 on the HCP device. Further, the HCP can set up a user account as part of the initial setup or during the data extraction interview.

[0183] As described above, the patient user can obtain the product at the HCP's office, but in many cases, does not know how to obtain an account or set up the product. In one implementation, referring to the flowchart 600 of FIG. 8, the HCP sets up a user account and the product for the user. The patient enters the HCP office, and the HCP provides the transmitter package, for example, as described above. Such a product uses a transmitter, for example, a flexible electronic device, or includes a transmitter ID in the product box or other part, or a specialized product as required. The HCP starts a communication session and interrogates the patient for patient information including, for example, name, date of birth, email address, etc. to enter it into the HCP application (step 505). The HCP can verbally request the patient's consent to enter or use the patient's email address.

[0184] Next, the HCP inputs patient information into an application or a server portal, such as an HCP portal, which can be, for example, a web application that provides access to a server. The server is generally a cloud server and is often also the recipient of patient data when the patient returns after a sensor session. The HCP application can also provide functions including verification of sensor operation, data extraction, and providing timestamp data to the transmitter. Whether it is an HCP application or an HCP portal, the data is sent to the server (step 507). In some cases, the input data can indicate the mode in which the transmitter should be placed, and this mode can be propagated to a specialized product or the patient's smart device.

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

[0186] More specifically, the HCP can manually input transmitter information along with patient information. The input transmitter information can include a transmitter ID. By inputting such information, the user account can be associated with a specific transmitter. If the HCP does not wish to input such information, or does not wish to input it manually, the same can be input in the manner described above by using, for example, a flexible electronic circuit scanned by an HCP receiving device, a QR code (registered trademark), a barcode, etc. 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 any case, the HCP application can search for a transmitter ID, such as a serial number, and cause it to be sent to the server.

[0187] On the server side, the transmitter associates (or creates an account) with the patient account using the transmitter identification information (step 511). When 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 the patient with instructions, such as a document or a displayable file (step 513), which includes the code or token. The HCP can further provide instructions on how to download monitoring or other relevant applications. The code can be scanned (or manually entered), thereby establishing an association between the patient and the downloaded application. That is, after the code is entered into the smart device or specialty product, the code can provide data such that the application is automatically associated with the patient without the patient having to bear the burden of additional data entry. In an alternative implementation, the HCP can cause an invitation to be sent to the email address provided by the patient. It will be understood that such an invitation can also be sent via a text message or the like. The patient can then use the code to download the application (step 515). The application may be automatically associated with the patient account using the code (step 517). Alternatively, the application can be downloaded with the code entered after installation. In any case, the transmitter is linked to the user's account.

[0188] Subsequently, the HCP portal links the patient information with the application downloaded by the patient. The HCP portal can further automatically generate another account for the patient, for example, an account available for future purchases such as sensors and transmitter products. The opening of this other account may include another email or text invitation to the patient.

[0189] The flowchart 650 of FIG. 9 shows the process flow within the HCP office in various use cases using various levels of user-provided technology. As can be seen from the flowchart, having a data extraction step that can be provided by an HCP reader or a similar device provides HCP re-assurance for reimbursement regardless of the outcome of the scenario.

[0190] Instructions for performing a series of steps shown in the subsequent flowchart can be provided to the HCP on an HCP reader or other HCP device. In this way, the HCP can be guided through the setup process step by step. The instructions may be incorporated into the HCP application described above or may be included in a separate dedicated application. Additionally, note that the HCP reader or other HCP device may include additional applications dedicated to tutorials regarding any of the various aspects of system use and installation and, in some cases, auxiliary aspects such as reimbursement assistance.

[0191] In the first step, the HCP provides a sensor and a transmitter to the patient (step 506). If the patient does not have a phone (step 508), a sensor session can be started (step 522), and after completion of the sensor session, the HCP uses a data extractor to extract data from the sensor to perform steps including setting up an account and verifying that the sensor is functioning (step 524).

[0192] If it is determined that the patient has a phone (step 510), that the phone is compatible with other components of the system (step 514), and that 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 the server (step 526), and the data is reviewed by the HCP on the server (step 528).

[0193] If the patient does not have a smartphone (step 508), the sensor session can still be performed by collecting the data with the transmitter and then extracting it. Similarly, even if the phone is not compatible (step 512), even if the data is not immediately sent to the user device, the sensor session can still be performed because the data can still be collected by the transmitter. Even if the patient's phone cannot be paired with the transmitter (step 516), such data can still be extracted after being collected. Finally, even if the pairing was successful but for some reason the data cannot be sent from the patient device (step 520), the data can still be stored for later extraction.

[0194] In any case, after the sensor session ends, the patient can return the transmitter to the HCP office for data extraction (step 524). FIG. 10 is a flowchart 700 showing a more complex method according to this principle. In a first step, a patient who is considering or has been told to consider a CGM can meet with an HCP and perform various measurements such as A1C and laboratory tests (step 532) in order to determine whether the patient is suitable for and can benefit from the CGM (step 534). To determine whether the patient can monitor data from the CGM, the HCP can inquire whether the patient has a compatible smart device, such as a smartwatch, smartphone, tablet, etc. (step 536). Compatibility may be determined manually, for example, by comparing the type of the device, such as the model number, with a list of compatible devices. Alternatively, the HCP can perform a compatibility check by using, for example, a test signal that provides a result displayed 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 a monitoring application at the HCP office (step 538). The HCP can apply the sensor and transmitter to the patient (step 540). Then, the HCP can verify that the sensor and transmitter are operable, for example, by exchanging data with the transmitter via a wireless communication link that can be implemented via NFC or BLE, such as by using an HCP reader and NFC (step 542). Details of such verification are provided elsewhere. Then, the HCP can input patient information and the HCP application or HCP server portal (step 544). As described above, this step can 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 input patient information via the HCP reader device.

[0195] Next, the HCP can print the patient's distribution materials from the server portal and extract the transmitter ID from the kit. The transmitter ID can be embodied by the flexible electronic device, barcode, QR code (registered trademark), etc. described above (step 546). The patient distribution materials and the disposal bag can be provided to the patient, and the HCP can explain the subsequent steps (step 548). The patient can complete the setup wizard at the office or at home (step 552). When at home, a check may be provided as to whether the patient has completed the setup wizard (step 554). If so, the system can determine whether a specific access mode has been 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 can enter the default baseline mode (step 566). In some cases, the baseline mode corresponds to the blind mode. If the patient has completed the setup wizard and the HCP has selected an access mode, the wearing period can be started according to the access mode (step 558). For example, the access mode 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 whether the setup wizard has not ended after a predetermined number of hours. Thereafter, a follow-up email can be sent to the HCP or the patient.

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

[0197] Returning to step 536 described above, if the patient does not have a compatible smart device, the HCP may set the system to the default baseline mode, for example, blind without pairing with a smartphone (step 568). The HCP can enter the patient information into the HCP server clinic portal and print the patient distribution materials again (step 570). The HCP can use a reader, for example, with NFC, to verify that the sensor is functioning properly (step 572). Details of such verification steps 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 can be initiated (step 576). This step can also be the default to the baseline mode following step 566.

[0198] The patient may return with the sensor / transmitter in the 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 can consult the HCP directly or via telemedicine (step 564).

[0199] The flowchart 750 of FIG. 11 summarizes many 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). Next, the HCP can use the application to provide a pairing step with a sensor transmitter, for example, when the pairing is done by the HCP device, a specialized product, or a user smart device (step 592). Next, the HCP application can shift the transmitter to the HCP mode (step 594). In this mode, the HCP can use the HCP application to confirm the proper operation of the sensor and the transmitter (step 596). This mode can be enabled by enabling a communication protocol that allows only one connection or blocking other communication requests from other devices. In any case, in this mode, the HCP application can be given fairly large permissions and privileges in order to enable the configuration of the specialized product or the user smart device and subsequently allow the device to return to a more typical mode, and the details of such a configuration are protected from user changes. After confirmation of proper operation, the transmitter is shifted to the 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 include several other modes, such as blind, non-blind, etc.

[0200] After the wearing period, the patient returns to the HCP office (step 602), and the HCP extracts data from the transmitter using the HCP application (step 604). Optionally, the HCP can upload the data to a server using the HCP application (step 606).

[0201] The above variations will also be understood. For example, when using the NFC of a mobile phone to scan a transmitter, the CGM monitoring application can be downloaded to the phone, the phone and the transmitter can be paired, and the system can be automatically set up on the phone and the transmitter, such as starting the activation of the sensor.

[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 there is often no suitable or strong Wi-Fi or cellular connection, and downloading via a public network may pose privacy issues, eliminating the need to download the specialized settings of the actual application. Thus, pairing may be initiated by an NFC connection, and the application may be transferred via NFC or BLE. If the application stored in the transmitter is not the latest version, it may be updated to the latest version when the user has a strong and secure connection. For example, in such a case, the application can communicate with the 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 an example of steps that can be included in establishing communication between an HCP device, such as an HCP reader (e.g., HCP reader 420 shown in FIG. 4) in an HCP office, and a sensor / transmitter. For example, these steps can 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 the operation of the appropriate sensors, 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, for example. In some examples, the short-range wireless protocol used may not be encrypted at the protocol level (of course, in these examples, encryption may still be used at the application level 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 illustrative purposes, the short-range protocol used is NFC and the encrypted protocol used is BLE. Thus, in this example, both the HCP reader and the transmitter are provided with an NFC transceiver circuit and a BLE transceiver circuit.

[0204] In a first step, a sensor / transmitter is attached to the patient and configured for use (step 840). To confirm that the system is properly configured and operating, the HCP establishes communication between the HCP reader and the transmitter using NFC. The HCP achieves this by bringing the HCP reader close to the transmitter so that the two are within the NFC effective range. When the HCP reader and the transmitter are within range, the HCP reader transmits 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 form, for example, using public / private key encryption techniques (step 844). Further, to extract the transmitter ID from the encrypted form, 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 as soon as it provides the form of the transmitter ID or related information of 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 state, for example.

[0206] Examples of transmitter states that can be communicated to an HCP reader by a transmitter can include the following: (i) a memory state (indicating that the transmitter is still in its package or has not started a session including collecting glucose data or performing sensor insertion verification); (ii) a sensor verification state where 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 and / or the time taken for verification to end, the result of the verification, and when to check the verification result 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 completion state (e.g., indicating that the transmitter has ended the execution of a session; the data is logged and downloadable).

[0207] Additional information that can be sent to an HCP reader in response to a query command can include, for example, how many attempts were made in sensor verification. In one example, this information can be useful in understanding whether one or more incorrect sensor activations have occurred (e.g., if one or more sensor verifications were performed incorrectly without the HCP executing or starting the verification process).

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

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

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

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

[0212] Based on the information received from the transmitter, when the HCP confirms that the system is operating correctly and is in a session, the HCP completes the setup process by performing necessary additional steps such as transitioning to the operation mode of the system (e.g., blind or non-blind). Thereafter, the patient can use the device during the session.

[0213] After the session is completed (e.g., after 14 days), when the patient returns to the HCP office, the HCP sets the transmitter to data extraction mode using the HCP reader. In some examples, after the 14-day session ends, it is contemplated that one or more circuits of the transmitter can transition to a low-power mode automatically or upon receiving an instruction from the user via the user device. Since patient data is to be exchanged here (e.g., after the session is completed), an encrypted protocol that requires authentication such as BLE is used. To establish a BLE connection, first the NFC protocol is used to set the transmitter to data extraction mode. In particular, the BLE connection is established by bringing the HCP reader close to the transmitter again and issuing a command to the NFC to transition to data extraction mode using a hash version or encrypted version of the transmitter ID as a parameter (e.g., the HCP reader obtained during the previous session (step 846)). When the transmitter confirms that the received hash is correct, the transmitter starts the advertising and connection protocol to advertise and connect to the HCP reader (step 848).

[0214] If the transmitter is currently communicating (or has previously communicated) with the user / patient device when the command to transition to data extraction mode is called, the advertising method is started after the user device disconnects. To prevent user devices listed in the whitelist (such as the mobile device of the user who has communicated with the transmitter for 14 days) from connecting to the transmitter instead of the HCP reader, the transmitter can use a new BLE Generic Access Profile (GAP) address and / or a new Generic Unique Identifier (UUID) to ensure that the HCP reader has priority for connection attempts. In some examples, during the extraction mode, the HCP reader can access information already stored in the memory of the HCP reader or another computing entity (e.g., a server) and identify and determine the identifier of the transmitter when receiving an initial communication request from the transmitter.

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

[0216] Referring to FIG. 38, when communication is established between two devices (e.g., a transmitter and an HCP reader), an authentication procedure can be performed as part of the data connection process (step 850). The authentication procedure can use existing standard and / or proprietary authentication techniques, such as those shown in U.S. Patent Application No. 14 / 968,695, which is hereby incorporated by reference in its entirety. Once the authentication procedure, including the exchange and authentication of the secret keys, is complete, the BLE connection is fully established (step 852).

[0217] Once authenticated, the transmitter can provide the data obtained during the session in use to the HCP reader (step 854). In particular, the transmitter can provide the estimated glucose value 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, and data available from other sensors incorporated into the system (e.g., motion data from an accelerometer)). Note that the glucose data can be transmitted within a predetermined time (e.g., within 15 seconds), while the personal data and motion data can be transmitted without a time budget.

[0218] As described above, during the data extraction mode, the transmitter searches for all relevant details of the completed glucose session and communicates exclusively with the HCP reader as a data stream. When the data extraction is complete, the transmitter is placed in a low power or sleep state (i.e., the lowest possible memory mode) that may last for a long time before the transmitter's battery is depleted (step 856). Note that after being placed in the memory mode, if the transmitter is used for further purposes (e.g., failure analysis, additional data extraction, etc.), the transmitter is returned to the manufacturer and the transmitter can be woken up via NFC. In the various scenarios described above, NFC is used as one of the communication protocols between the HCP reader and the transmitter. Since NFC communication is a very short-range protocol that requires the NFC antennas of the HCP reader and the transmitter to be brought into substantial contact with each other, the HCP needs to carefully align the two antennas when establishing communication. This can be difficult and cumbersome in some situations, especially as the size of the sensor system continues to decrease and the antenna size decreases accordingly. Furthermore, from the perspective of the HCP, it is important that the data extraction process can be executed quickly and easily in order to minimize the time and effort required.

[0219] Accordingly, 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 can comprise an auditory transducer that emits a sound that increases in volume, pitch, and / or the frequency at which discrete pulses are emitted 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 the feedback. Similarly, visual feedback may be provided instead of, or in addition to, the auditory or tactile feedback. For example, a light source on the HCP reader or transmitter, such as an LED, can emit light pulses that increase in frequency as the proximity between the two antennas increases (and vice versa).

[0220] In addition to the modes described above, the modes can be configured to be particularly interesting for patient use, and it should be noted that a degree of flexibility and a "choose your own path" function are enabled. In this way, the user can view the use of the sensors and transmitters and the associated patient monitoring applications as a "journey" or "adventure" pursued over time, including the use of a transmitter having a plurality of sensors over a plurality of sensor sessions. As will be described in detail below, the transmitter can incorporate a sleep or inactive state function to conserve battery life for such a plurality of sessions, particularly when data extraction is being performed, such that sufficient power remains in the transmitter to enable a signal to be transmitted from the transmitter to another device, for example using an HCP reader, to store the data.

[0221] In the HCP configuration procedure described above, it is important for the HCP to verify that the system is functioning, for example, that the transmitter is properly receiving the sensor count from the sensor and transmitting the count when paired with a smart device that includes the HCP device. Such verification also affects claims and refunds.

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

[0223] In one implementation, the HCP can verify two types of startup steps for the transmitter. Both types are necessary for proper operation. In this way, not only is the transmitter transitioned to the active state, but the HCP application is made aware of the presence of the active state of the transmitter, thereby notifying the HCP of proper operation.

[0224] Therefore, in flowchart 800, the first type of activation step includes detecting proper sensor insertion, and the second type includes detecting proper start of a sensor session. In the first type, the transmitter is wake-up activated upon sensor insertion and, upon wake-up, is caused to start communication with the HCP device or HCP reader (step 614). For example, the transmitter can start advertising via BLE, and the HCP device can detect and thus determine the activation of the transmitter (step 616). In this case, in some implementations, the transmitter and the HCP device should be previously paired. In other implementations, steps 614 or 616 can be used to start the pairing process. Detection by the HCP device can, as with other methods, be by performing a visual inspection, followed by confirmation by a message back to the HCP device, prompting the HCP to detect the start of reception of the sensor count. Alternatively, the transmitter can be configured to send a separate notification message via NFC or BLE to the HCP device that sensor insertion has occurred. In either case, the HCP device detects the communication and detects that the first step has been executed (step 618).

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

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

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

[0228] The advantage of the method of FIG. 12 and methods similar to those described below is that for the transmitter to be properly verified and transition to an active or operating state during the sensor's wear period, both steps must occur. Thus, incorrect startups are normally avoided. Other ways to avoid incorrect startups, which can potentially affect battery life, are described below.

[0229] In the example described above, the information obtained from the transmitter verifies that the sensor is functioning correctly. In an alternative approach, the applicator used to insert the sensor into the user's body can be equipped with a communication function (e.g., NFC, BLE) that enables the applicator to verify that the sensor is correctly inserted and functioning properly. In one implementation, the transmitter can send a signal (e.g., via NFC or BLE) to the applicator 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 indicating that the sensor is operational to the HCP application and / or an application on the user device. FIG. 40 shows an applicator 902 communicating with a transmitter / sensor 904. The transmitter / sensor 904 then communicates with the user device 906.

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

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

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

[0233] The above implementation is described as part of the bonding process in the flowchart 950 of FIG. 15. It will be understood that other wake-up methods can be combined throughout the process. As can be seen, such a startup process is expected to be completed in a short time, for example, within 5 minutes. Two options here include automatic detection of sensor signals and forced wake-up by 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, for example, for 2 minutes, and starts a sensor session.

[0234] In the first step, the transmitter starts in the low-power mode (step 632). If a sensor signal is detected, a test can be performed to determine whether the current corresponding to that signal exceeds a threshold (step 634). Otherwise, the transmitter can be maintained in the 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, the NFC signal can be used to wake up the sensor even if the sensor count has not been measured. In some cases, both of the above may be used and required for the transmitter to wake up. In other words, the measured current is required to exceed the threshold or be within a target range, and the wake-up signal is required via NFC to wake up the transmitter and maintain the transmitter in this mode during the sensor session.

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

[0236] After wake-up, the transmitter can check the operation of the sensor (step 640). Such a step can include checking whether the detected current is within an appropriate range (step 642). If so, the system state is determined to be operable (step 644). Otherwise, the system state is determined to have failed (step 646). In some cases, it may be required that the current be within a predetermined range for at least a predetermined period to cause the wake-up of the transmitter. Also, if an external display device such as a specialized product or a user smart device is used after wake-up, the step of pairing the transmitter with the display can be executed (step 648). If the system pairs successfully (step 652), the system status is again determined to be operable (step 644). If the system does not pair successfully, the pairing operation can be executed again (step 648).

[0237] In some implementations, appropriate time measurements can be utilized along with the count / current measurements to determine the sensor insertion time. In one example, the transmitter can be in its normal operating mode (e.g., after step 636). In such an implementation, the transmitter can then measure the count / current within or above the sensor detection threshold level and can 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 subsequent measurements, the transmitter can determine and verify that the detected count / current measurement at 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 gives the display device an opportunity to verify that time a is the valid sensor insertion time. The transmitter can then communicate to the display device that time a (rather than time b) is the accurate sensor insertion / sensor session start time. Thus, the signal processing algorithm within the transmitter and / or appropriate entity can then adjust time-dependent variables (e.g., the display start of the delay timing or EGV value based on the verified sensor insertion time (e.g., time a) rather than based on time b). In some implementations, it is contemplated that if the transmitter first receives the sensor session command from the display device and further verifies that time a is the accurate sensor insertion / sensor session start time, time b (i.e., the initial display at the start of the sensor session from the display device) can be overridden by time a.

[0238] In another example, when the transmitter is actually determined to have come out of the low-power state (e.g., from step 632), the transmitter can verify the wake-up time of the transmitter (e.g., time c) as the sensor insertion time. Since the wake-up processing algorithm can introduce a delay time, the wake-up time c can be recorded as the exact wake-up time of the transmitter before the marked wake-up time (e.g., the wake-up time marked in step 636).

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

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

[0241] As one implementation, and as shown by apparatus 1100 of FIGS. 18 and 19, a wake-up trigger system and technique can be implemented by an optical sensor 664 covered with an opaque sticker 662. The optical sensor activates the transmitter by closing a circuit when light strikes the sensor. By maintaining an opaque sticker that covers the sensor until it is peeled off by the user when pairing is ready, light is prevented from striking the sensor when it is inside the package.

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

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

[0244] In yet another implementation, referring to flowchart 1150 of FIG. 20, the transmitter may wake up when the user activates a switch or when the 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 instructing the user to activate it. Alternatively, the switch may be pressed by an applicator while the sensor is being equipped on the user's body. The embedded switch can be part of a flexible wearable, and when the switch is pressed, a physical, e.g., metal-to-metal contact is made and the device can be woken up from low power or inactive or sleep mode. As before, at the end of the intended period, the system stops recording data and prepares to download the data. Further, in some implementations, the system can communicate to an application or another device that it has started up properly.

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

[0246] Other techniques may also be employed to cause the transmitter to wake up. For example, referring to flowchart 1200 of FIG. 21, the mobile device and the transmitter can establish a communication session, e.g., it can perform wireless communication as described above (step 672). An application for patient use, e.g., a CGM application, or another type of analyte monitoring application may be downloaded to the mobile device (step 674). Alternatively, the application can be downloaded from the transmitter to the mobile device (step 676). When the application is on the mobile device, a secure communication session can be formed between the mobile device and the server and associated with the user account (step 678). Also, the transmitter can be woken up using the mobile application (step 680).

[0247] In this regard, it should be noted that starting a sensor session after a certain period of time has elapsed since the moment of insertion may have an adverse effect on the accuracy of measurement data. The systems and methods according to this principle provide various ways to address this. In particular, referring to the flowchart 1250 of FIG. 22, the user (or HCP) can indicate that sensor insertion has occurred on the downloaded application (step 682). The user then pairs the transmitter with the mobile device (step 684), after which the system can automatically start from the time the sensor was inserted (step 686).

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

[0249] In any case, in subsequent sessions, the user can attach the 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 the flowchart 1275 of FIG. 23, the systems and methods according to this principle can address issues related to the lack of glucose values obtained during the warm-up period. For example, using a low-cost or disposable transmitter, the patient can overlap the wearing of two transmitters / sensors (step 694). One or more displays can be paired with both transmitters and can automatically switch to using the new transmitter when the warm-up period is complete (step 696). In a variant, an indicator can be provided to indicate which is the old or expired transmitter / sensor (step 698). In this way, the possibility of accidentally removing the new sensor is reduced.

[0251] The indicator of step 698 may be provided by a visual indicator of an expired or new transmitter, such as an LED light. Physical indicators may also be used, such as using vibration. In another alternative, a display device, such as a specialized product or the user's smartphone, can use a proximity sensor to inform the user when the display device is near a sensor that is expired or not expired. The resolution of the proximity sensor, i.e., the ability to distinguish one sensor from another, can be low if the sensors are widely separated, such as on opposite sides of the body, or if the sensors need to be separated by a user command, etc. In some cases, such a system may require physically touching the display device to distinguish transmitters within inches of each other. Communication modes for such purposes can 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 with an adapter that plugs into the display device and reads the transmitter at the other end can be used. A specially configured device for such purposes can be designed to have a port where the transmitter can be placed or connected, or otherwise have a contact point for transmitter contact. In one example, an ultra-low voltage power socket inspection device can be used, which can include, for example, a small light indicating whether the contacted transmitter is expired and should be removed.

[0252] In one variant, referring to the flowchart of FIG. 39, there is another technique that can be used to wake up the transmitter when the user installs the transmitter for the first time. In this variant, a mechanism is provided to automatically wake up the transmitter when the user attaches the transmitter to the sensor bay / casing. This can be achieved in any of a variety of ways. For example, the installation of the transmitter into the bay / casing may activate a dedicated wake-up circuit. As another example, a simple mechanical mechanism can be employed where the insertion of the transmitter into the bay / casing engages with a part of the bay / casing to activate a mechanical switch on the transmitter, thereby waking up the transmitter.

[0253] Referring now to FIG. 39, after the user removes the transmitter from its package and installs it in the sensor bay / casing, the transmitter automatically wakes up without user intervention (step 870). Typically, the transmitter can wake up within a few seconds. Next, the transmitter starts broadcasting BLE advertisements or beacons as part of the advertisement and connection protocol (step 872). If the user has already installed a dedicated software application on their user device (e.g., smartphone), the application can automatically open and prompt the user to ask if they want to pair the device in response to the advertisement (step 874). Assuming the user desires to pair, the user enters a transmitter ID or other code that can be used for security measures (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, and the user device can read it when the user device contacts the transmitter. If the transmitter ID or other code is correct, the transmitter and the user device are paired via BLE (step 878). And the session can automatically start after a warm-up period, which can be shown on the application with a countdown timer (step 880).

[0254] In the example shown in FIG. 39, when the transmitter is installed in the sensor bay / housing, it automatically drives the pairing and session start processes without requiring additional actions on the user's part, such as starting a session with a start button.

[0255] At the end of the session, the transmitter sends a signal indicating that the session has ended to the application on the user device, and the application notifies the user that the session has been completed (step 882). Then, the transmitter transitions to a low power or sleep state and wakes 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 the next session is started after the first session as described in FIG. 39, the process is similar to that shown in FIG. 39 but with fewer steps because the transmitter and the user device are already paired. In this case, when the user inserts the transmitter into a new sensor bay / housing, the transmitter automatically wakes up from the sleep mode and broadcasts a BLE advertisement that automatically launches a dedicated application running on the user device. Then, the session 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 is about to start. If the transmitter determines during the warm-up period that the sensor is a used or expired sensor, the transmitter notifies the application of this status and then transitions to a low power or sleep mode.

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

[0258] In other variations, a mechanism may be provided that allows the transmitter to remove itself. For example, the transmitter can 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 to loosen the patch and / or retract the sensor.

[0259] In another variant, and referring to flowchart 1300 of FIG. 24, a common transmitter configured to be used with overlapping sensor sessions may be employed (step 702). In one implementation, the cassette is used with a plurality of sensors that can be arranged to signal communicate with the transmitter (step 704), and at least two sensors signal communicate with the transmitter simultaneously, e.g., via NFC or BLE. In such a system using a transmitter with multiple sensors, each sensor can be successively and continuously equipped over time with some overlap between the two sensors. An integrated equipment mechanism can be used with the cassette or the sensor drum. Alternatively, a separate equipment mechanism, e.g., an instrument for inserting a new sensor already within the cassette, can be used. The transmitter may have multiple spots, ports, or slots for the 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 variant of this implementation, a reusable applicator can be used, which operates manually or automatically and can take an assembly consisting of the sensor, the transmitter, and the needle. Such a reusable applicator may be repeatedly used to attach multiple serial sensors.

[0260] The above has described the installation and, to some extent, the pairing of the transmitter with the sensor and the 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 previously, if it is not paired with a phone or similar device, the transmitter generally does not communicate with a source of real-time clock data. Instead, the transmitter only measures or times how long it has been operating since it started. For example, if a user sensor session ends after 14 days of use but the user only returns the transmitter to the HCP 17 days later, this can be a problem. In such a scenario, the transmitter does not have absolute data on how much time has elapsed since it started, especially if it was in a low-power mode for part of that time. Further, the HCP may wish to perform an analysis 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, for example, using the real time of the 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). And the transmitter can 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., 0 seconds coincide at 2:00 PM on July 1), which can be valid for both the blind / 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. Next, the transmitter uses this time information to further timestamp the sensor data collected by the transmitter during the wearing period (e.g., for 14 days).

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

[0263] This implementation is illustrated by flowchart 1400 of FIG. 26A. In this figure, the transmitter may be in use in the current sensor session (step 710). If a timestamp has not yet been acquired, or if recalibration according to a new timestamp is desired, the transmitter can intermittently or periodically scan for adjacent devices, e.g., adjacent Bluetooth® devices (step 712). In this way, the transmitter can request a timestamp from a neighboring Bluetooth® device and then acquire the timestamp (step 714).

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

[0265] In a variant, the user may pair with the transmitter when returning home following an HCP visit, and the transmitter may receive a timestamp as part of this pairing process. In this case, the user's specialty product, or the user's smartphone provides time synchronization, where time synchronization refers to providing a timestamp to the transmitter. In this way, the transmitter can be periodically synchronized to real-world time via the user's smartphone. In a related variant, although the transmitter is installed in the HCP office, if the user does not synchronize the transmitter to their application until 5 hours later, real-time is only obtained at the 5-hour mark. However, if the transmitter is used to receive data during this time, such data can be retrospectively timestamped, and as a result, it can still be used as timestamped data in subsequent analysis.

[0266] As described above, one of the mode selections available to the HCP is to blind (or not blind) the patient to the display of the measured analyte value. In this regard, it should be noted that patients may be adversely affected and, for example, may change their normal daily activities or behavior if they are permitted to monitor glucose data. This can potentially misinterpret or interfere with the HCP's accurate interpretation of the patient's glucose data.

[0267] If it is desired that the patient be completely blind to the data, generally the need to use a specialized product or the user's smartphone is reduced, unless it is used for data backup. When the smart device application is not involved, it is called the "extreme blind" mode.

[0268] In certain embodiments regarding the extreme blind mode, the blind mode can be implemented such that the BLE radio is turned off after a predetermined or specific period, so that the transmitter does not provide the EGV value to the phone / receiver. This embodiment can be particularly useful for patients without a smartphone. The transmitter can turn off the BLE radio when it determines that it is not paired with any phone or device after a predetermined time (and after the HCP has placed 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 at the setup stage. Instead, the HCP simply places the transmitter on the user, and the user leaves the HCP office.

[0269] However, since 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 started. However, the transmitter circuit can still keep time by maintaining a counter that will be started at the initial HCP setup stage. 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 keeping the counter running even after the sensor session has ended, the transmitter can provide information regarding how much time it has been "activated" 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 the data was collected and for what period.

[0270] In certain implementations, the user can place the transmitter anywhere, which can include the HCP's office, at home, in their car, or any other location. In this case, there is no need or it is not possible to confirm (by the HCP) the insertion or activation of the sensor. As described above, a time reference, such as UTC time, is not provided to the transmitter. Since the mode has not been changed by any means, for example, not changed by the HCP using an HCP device, a specialized product, a reader, a dongle, etc., the transmitter starts up in a default mode that can be a blind mode. Since no Bluetooth® pairing has occurred, the transmitter can automatically turn off its Bluetooth® radio after a certain period, for example, 1 to 12 hours later.

[0271] In one implementation, the session simply ends after a predetermined sensor period, for example, 15 days later. The transmitter transitions to a very low-power "clock mode". In this mode, the transmitter can wake up periodically, for example, every 5 minutes, every 30 minutes, etc., to update the record corresponding to the counter. In some cases, the transmitter can transition to or avoid the "deep sleep mode" required for NFC to wake up.

[0272] In yet another variant of this system, the clock mode ends after a predetermined period, for example, 15 days later. This time can also be set to be variable and based on the remaining battery level. In this "clock mode", Bluetooth® advertising is not displayed in the blind mode, thus achieving energy savings.

[0273] In any case, the user returns to the HCP office and the HCP reader communicates with the device. For example, the HCP reader can activate the device via NFC, enable Bluetooth® low energy communication, download data via it, and then end the session.

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

[0275] At the start of a session, various steps may occur. In some cases, the HCP provides a UTC time reference at the start of the session and then "fixes" the session to a specific absolute start time. This fixing 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, for example, when the user installs the transmitter himself at his home or in his car. During the period indicated by Z, BLE advertising may be performed to enable potential communication. For example, in the non-blind mode where data from the transmitter is sent to another device for display, following line C, the power decreases more rapidly. In the blind mode indicated by line D, following the first BLE advertisement, BLE turns off and the power decreases more gradually.

[0277] The next segment shows the post - session activity. Line E indicates the clocked power mode where the transmitter continues to monitor the passage of time. Line F shows the post - session activity when BLE advertising occurred during the session. Since the measurement data was related to the absolute timestamps during this period, even timekeeping is no longer required, so line F can show extremely low power consumption, i.e., the "deep sleep" mode. In Figure 26B, the line basically looks flat. In either of these cases, when visiting the HCP office and subsequently downloading the measurement data, the UTC time reference can be provided to the data. In some cases, it is the time reference received first, and the measured data may be retrospectively associated with various time references based on the provided UTC time reference. In some cases, for example, when BLE advertising and data communication are performed with a smartphone, the UTC time reference received during the post - session HCP visit may provide a supporting time reference, such as a second time reference to verify the accuracy of the initial time reference. However, if the device following line F is used, since the period shown by line F is unknown (time data is not recorded), the time reference provided during the HCP visit will not confirm the initial time.

[0278] In a particular implementation of the system described above, it is advantageous if all energy usage in the form of Bluetooth® advertising and indeed communication methods is turned off in blind mode. The blind mode must 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 activated via NFC commands at the HCP. In non - ambiguous cases, it is generally already on.

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

[0280] As described above, to enable such a mode during configuration, the HCP programs the transmitter, or a specialized product or smartphone application, in various modes according to the user's needs / status and skill level. The HCP also programs the transmitter to be in blind or non-blind mode.

[0281] In one exemplary way to achieve programming, multiple serial number extensions can be provided to the transmitter, and each extension defines the behavior when an application or other connected device pairs with the transmitter. For example, the first extension may correspond to a blind professional mode. When this serial number extension is used, when paired with a device, the device displays only the operational status of the sensor. The second extension may correspond to a semi-blind professional mode. When this serial number extension is used, when paired with a device, the device displays only the operational status of the sensor and the defined alerts. The third extension may correspond to real-time personal and professional modes. When this serial number extension is used, when paired with a device, the device can be configured to display alerts, glucose values, trend graphs, etc.

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

[0283] If the user downloads the application but does not view the analyte data, it is called the "semi-blind mode". In this mode, the user can receive alerts and calibration information and, in some cases, can further input data regarding the drugs taken, the food consumed, and the exercise performed. In this way, alerts can be adopted to mitigate serious adverse events. For example, the transmitter can change color, vibrate, increase temperature, or the connected transmitter can issue an alert on the user's smartphone without providing glucose trends or numbers. Such functions enable the user to take action, for example, to touch with a finger, to help address potential concerns identified by the sensor with the alert.

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

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

[0286] For example, one implementation may enable a physician to initiate a patient on a blind CGM system that will collect glucose data. The physician can set triggers to automatically switch the system to non-blind mode, enabling alerts and patient access to real-time data, based on, for example, time or the occurrence of an event. In one implementation, after 14 days the data will no longer be blinded, so the user can view their data. In another implementation, the data may be unblinded if the user achieves a movement goal or a dietary goal. In yet another implementation, the data may be blinded for 7 days and then unblinded for the subsequent 7 days. Other variations are also contemplated.

[0287] In any case, the physician can then compare the two data sets to provide the patient with practical insights and treatment adjustments.

[0288] In other variations, “real-time blinding” can be utilized to provide further insights. In particular, note that in blind mode, the user cannot view glucose data or receive glucose alerts. This helps prevent the user from acting immediately upon seeing changes in blood glucose levels, which could affect the medical plan that an HCP might prescribe for the patient. On the other hand, allowing the patient to view the data also helps the patient understand the impact of lifestyle events on glucose values. Thus, “real-time blind” provides an intermediate ground and achieves both objectives. In particular, real-time blind configures the system so that the patient cannot view the data immediately. However, the patient will be able to view older data—for example, data from the previous day or data that is several hours old.

[0289] The duration can be made settable, for example, by the HCP, or the 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 a normal trend screen and only incorporates a reflection view, avoiding the confusion that may enter the user by interpreting old data as current data.

[0290] As shown in FIG. 4, a diagnostic application 428 may be employed, which may be particularly advantageously employed 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 enables the HCP to set alerts without changing the treatment regimen. For example, in addition to receiving real-time alerts to mitigate potential harmful events, the user can view the diagnostic application and view the status of the sensor, such as remaining time, error messages, etc. In the use of the diagnostic application, the alerts can be static with respect to the episode data, i.e., not continuous and not showing a glucose profile or history. A low glucose alert simply displays a number and a trend arrow, or just a number, or a threshold. In this way, the user is still required to manage diabetes in the same way as was previously used with just a fingerstick. By hiding the glucose profile information, the user cannot make dramatic treatment changes to their current treatment, so such knowledge does not change the outcome of the diagnostic session.

[0291] One aspect of the above HCP configuration process involves pairing a transmitter with a specialty product or other smart device. For example, referring to the 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 specialty product, a mobile device, an HCP device, etc. (step 718). However, pairing the transmitter using traditional manual processes can sometimes be cumbersome. Such processes involve entering the transmitter ID or identifying the transmitter to the device to be paired. Such cumbersome and time-consuming processes can prevent the HCP from setting up the transmitter for the patient.

[0292] Accordingly, in one implementation, a user-friendly and rapid method can be employed to identify the transmitter using the HCP device.

[0293] For example, referring to the schematic diagram of FIG. 29, in one implementation, the system 1550 can be configured to include one or more processors 726, and 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 the transmitter can be paired and which can communicate signals with a user device, such as an HCP device, a specialty product, a smartphone, etc.

[0294] Referring to flowchart 1600 of FIG. 30, the start of communication can include identifying at least one of the transmitter and the receiver, authenticating at least one of the transmitter and the receiver, or including at least one of device connection and pairing (step 732). For example, without limitation, connection or pairing can include transmitting a communication key such as an identification resolution key (IRK) (step 734), transmitting transmitter identification information, secure and easy pairing, barcode scanning, user input of a code, biometric authentication, etc., and communicatively connecting the receiver and the transmitter including one or more of the above. In some embodiments, communication can include transmitting data via at least one radio frequency (RF) protocol.

[0295] In some implementations, an application key can be used to ensure secure communication between devices. The system can be configured to generate an 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 can further be configured to use the application key to encrypt information, such as data related to analyte levels. The system can further be configured to operate in at least one of a mode in which the transmitter and the receiver are continuously communicatively connected and a mode in which communication is intermittently initiated. The system can further be configured to operate the receiving device as a gateway to communicate with one or more other receiving devices.

[0296] One scenario where it can be particularly important to pair a transmitter and a receiver in a quick and user-friendly way can occur when a user is receiving emergency medical treatment and hospital staff or first responders need access to up-to-date analyte sensor data. In this situation, it can be useful to avoid the normal authentication techniques that might otherwise be used when pairing the transmitter to the receiver. Of course, to avoid potential vulnerabilities, it is necessary to address security and privacy issues. Thus, for example, a receiving device can be provided with an application that enables an emergency responder to access communication keys, etc., from a server that has a portal available only to pre-approved individuals or entities (such as a hospital or other emergency medical facility). Communication keys or other credentials obtained from the server can enable a secure communication to be established between the transmitter and the receiving device. As another example, the transmitter can be configured to expose a dedicated wireless interface that is 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, the continuously connected mode can refer to a connection model in which the connected receiver and transmitter maintain the connection for as long as possible until the receiver and transmitter are in an error or out-of-range state.

[0298] In some embodiments, the system may be configured to operate in a mode in which communication is intermittently initiated. For example, the system can transmit data periodically (e.g., when the transmission period is 1 minute, 5 minutes, or 10 minutes, etc.) and during a transmission window for a period shorter than the entire period, and terminate communication during the remaining period. The system may further be configured to change the periodicity or interval of intermittent communication based on factors such as time, the manner or trend of 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 can advantageously result from the intermittent rather than continuous operation of at least one of the transmitter and the receiving device.

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

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

[0301] As a non-limiting example, Received Signal Strength Indication (RSSI) is a measure of information regarding the strength of a detected signal. RSSI is determined from the power received by an antenna. RSSI is a relative (percentage) measurement that is defined differently by different chip manufacturers, and thus its value for a given power level at an antenna cannot be precisely or uniquely determined. While it is theoretically possible to determine the distance from a transmitter in free space from the RSSI value, due to the effects of objects, walls, reflections, multipath interference, etc., reliable distance estimation is often not practical, especially in indoor environments. However, in an environment associated with a particular receiver / transmitter pair, the trends observed with RSSI are 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 device signals. The receiving device may be configured to monitor the detected transmitter device signals and identify a transmitter based on selection criteria such as detection of an ongoing signal, information or statistical measures regarding signal strength such as RSSI, and signal quality from an identified transmitter over a predetermined period. If the signals from the identified transmitter do not meet the selection criteria during or after a predetermined period, the system may be configured to continue monitoring the detected transmitter device signals to select a transmitter for the start 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 device.

[0303] In some embodiments, at least one system component, e.g., without limitation, a receiving device or a 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 to initiate communication from the displayed list of detected transmitters. The list can be sorted or prioritized by at least one of information related to signal strength, e.g., RSSI, information related to signal quality, signal detection duration, and other prioritization criteria. For example, the list can be filtered by a threshold criterion such that the list includes signals that meet a predetermined threshold requirement for at least one of the aforementioned criteria. In some embodiments, the list can be limited to a predetermined number of detected transmitters, e.g., 10 or fewer transmitters associated with the highest RSSI values, based on at least one prioritization criterion.

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

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

[0306] In some embodiments, the receiving device can be configured to identify or select a transmitter by detecting RSSI or other signal-related information from one or more transmitters. For example, but not limited to, the transmitter module of the sensor electronics device can be identified or selected based on at least one of one or more extreme value (maximum or minimum) thresholds of RSSI, one or more extreme value thresholds of the average other than one RSSI from the same device, the difference in the maximum, minimum, or average RSSI values from each of a plurality of detected devices, the selection of the maximum peak or average RSSI of all devices found within a predetermined time interval, the difference (e.g., delta, variance, or trend), derivative, acceleration, or rate of change of the RSSI values received from each of one or more detected devices, statistical measures such as standard deviation or mean absolute deviation (MAD) in the RSSI values from each of one or more devices, and filters based on the type or class of the device.

[0307] In some embodiments, one or more detected signals can be emitted 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 receiving 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 disposed transdermally, or when both of the foregoing conditions are met. Upon detecting the advertising signal, the receiving device can be configured to prompt the user to couple or pair with the transmitter and move closer to or away from the sensor electronics, or vice versa. The receiver may be configured to identify or select the transmitter based on a value derived from the RSSI associated with the advertising signal, including the RSSI itself.

[0308] In some embodiments, the receiver can further be configured to provide the user with an indication that the transmitter has been identified. The indication can include, for example, feedback from the identified transmitter (e.g., light, beep or other audible signal, or tactile feedback), or a notification to the user via a user interface of a 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, when, for example, the transmitter and the receiver are in proximity, if the detected RSSI or other signal-related parameter or statistical measure exceeds a predetermined maximum threshold, the receiver may be configured to prompt the user to move the receiving device further away from the sensor electronics so that the receiver can identify the sensor electronics based on the change in RSSI or other information regarding signal strength or quality. The receiver may 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, but not limited to, when the RSSI exceeds a predetermined maximum threshold, the receiver first prompts the user to move the receiving device away from the sensor electronics, and then later prompts 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 comprise an accelerometer, a light or infrared detector, a microphone, or other sensors to assist in identifying the transmitter. For example, but not limited to, the transmitting device of the sensor electronics module may be configured to start transmitting an advertisement signal when the user generates a signal to the accelerometer, such as by tapping on the sensor electronics module. Alternatively, when detecting an advertisement signal, the receiving device may be configured to prompt the user to touch or tap on the sensor electronics module. When the user responds to the prompt by touching or tapping on the sensor electronics, the resulting accelerometer or other sensor signal can be transmitted to a receiver configured to receive the accelerometer or other sensor signal. The accelerometer or other sensor signal may be used for the purpose of identifying or selecting the transmitter. In some embodiments, for example, the touch or tap of the transmitter can be used as a verification step to confirm that the transmitter has been identified or selected, or that communication has been initiated.

[0311] Similarly, referring to flowchart 1650 of FIG. 31, an input indicating a desire to pair a mobile device with a transmitter can be received on the UI of the mobile device (step 740). Next, a change in movement or an artifact caused by the user can be detected by an 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 5 seconds, jumping up and down three times, etc. Alternatively, the motion artifact in 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 / handset and automatically pairs or the user confirms the intention to pair.

[0312] In some embodiments, the transmitting device can be configured to detect the presence of a receiving device signal. The transmitting device can monitor the detected receiving device signal and identify a receiver based on selection criteria such as detection of an ongoing signal, information or statistical measures regarding signal strength such as RSSI, and at least one of signal quality from an identified receiver over a predetermined period. If the signal from the identified receiver does not meet the selection criteria during or after a predetermined period, the system can be configured to continue monitoring the detected receiving device signal to 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 receiving device.

[0313] As a non-limiting example, the transmitter can be configured to send information regarding the strength of signals from a receiver, such as RSSI, to the receiving device. In some embodiments, at least one of the receiver and the 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 the methods described herein.

[0314] In some embodiments, the transmitting device can be configured to identify or select a receiver by detecting RSSI or other signal-related information from one or more receivers. For example, but not limited to, the sensor electronics device can be identified or selected based on at least one of one or more extreme (maximum or minimum) threshold values of RSSI, one or more extreme threshold values of the average other than one RSSI from the same device, the difference in the maximum, minimum, or average RSSI values from each of a plurality of detected devices, the selection of the maximum peak or average RSSI of all devices found within a predetermined time interval, for example, the difference, derivative, acceleration, or rate of change of the RSSI values received from each of one or more detected devices, statistical measures such as standard deviation or mean absolute deviation (MAD) in the RSSI values from each of one or more devices, and filters based on the type or class of the device.

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

[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 RSSI or other signal-related information from either or both of the transmitter or the receiver module, according to the methods described herein.

[0317] The above-described embodiments are included only by way of example. Those skilled in the art will readily understand that the implementation of the systems and methods disclosed herein is not limited to the described embodiments. For example, without limitation, 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 smartwatch, 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 sensor, a transcutaneous (i.e., through the skin) sensor, a chewable insert or insole incorporating an ingestible, inhalable or implantable sensor, or other electronic devices, and various systems can comprise 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 above-described system and method, and referring to system 1700 shown in FIG. 32, the HCP uses HCP device 760 running HCP application 748 to access server 752 to which patient data is communicated. Additionally, patient device 754 can also communicate with server 752, and the patient device can be, for example, a dedicated product, the patient's smart device, etc. Patient device 754 may be operating patient / user application 756, in which case the application can be, for example, a CGM monitoring application, etc. Application 756 can further enable communication with a transmitter.

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

[0320] Therefore, to address these issues, controller module 758 can be implemented within server 752. Controller module 758 is used by HCP application 748 to configure patient application 756 (and other necessary functions) of patient device 754. In this way, the HCP settings portion related to application configuration is separated from the retrospective analysis portion of the server function. 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 a Session including Data Extraction As described above, most HCPs do not have much time to configure the transmitter for the patient at the start of the session or to extract data from the transmitter at the end of the session. Therefore, a quick and convenient way to perform such tasks is highly desirable. Referring again to FIG. 4, the reader device 420 in combination with the 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 operates on an HCP device such as an HCP computer. In another implementation, the HCP application operates on a mobile device and can incorporate the functionality of an HCP desktop application. Such features generally include, for example, supplying 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 can include, for example, Android phones, iPhones®, and other mobile devices.

[0323] For example, one category of devices that can be employed is a smartphone, such as a user smart device, or a phone dedicated for this purpose, such as a specialized HCP product. Alternatively, a device having an RF wireless communication function can always be connected to an HCP device such as an HCP computer. For example, a dongle 426 can be provided that is always connected and can include a plurality of antennas, for example, 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 that the transmitter does not need to be very close to a computer or dongle (unlike NFC) to perform various steps, which include the transmitter being configured during an initial stage 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. The advantages of using a dongle include that it can generally include a larger NFC antenna that is easier to use than the small NFC antenna in a mobile device. 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. The factors for determining which wireless protocol is desirable can include, for example, the time taken for data download or upload, the distance between devices, etc.

[0326] In addition to using a 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 the HCP mode. In the HCP mode, the HCP can be enabled to perform functions such as transfer of timestamps, verification of operations, etc. The HCP mode can last for a predetermined amount of time, e.g., 10 minutes, and then can automatically transition to the default "normal" mode, for example, due to regular consumption during a sensor session. The advantage of the HCP mode is security. For example, in the HCP mode, the transmitter can be configured such that no other communication can occur. Thus, information cannot be obtained from the transmitter except via the dongle. BLE communication can also be enabled during this predetermined period of the HCP mode. When returning to the normal mode, normal communication as usual can be performed.

[0327] In one implementation, for data extraction in particular, the wake-up of the transmitter can be done via NFC, but since BLE is generally much faster than NFC, the data transfer can be done via BLE. In some implementations, the dongle can comprise a suitable ASIC or program processor to provide some intelligence in the decisions and determinations it is configured to make. For example, the dongle can determine, taking into account other factors in the receiver and transmitter, which is the best way to transfer data, e.g., whether it is better to transfer data via NFC or BLE. Also, as shown in FIG. 4, the dongle can have a target 422 disposed thereon, whereby the user is made aware of where to place the transmitter for NFC communication.

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

[0329] For example, in one implementation, a wake-up circuit that can immediately wake up the transmitter and speed up the startup process can be employed in the electronic device of the transmitter. More specifically, the wake-up circuit includes a function of waking up the wireless transmitter after one or more measurements have been made over a predetermined period or after the wireless transmitter has been turned off or placed in a low-power state to save battery life. The wake-up circuit wakes up the transmitter and wirelessly transmits one or more measured values to a dedicated display or other smart device, such as a specialized product. When using the wake-up circuit, the sensor electronic device module or transmitter can be configured to remain in a low-power mode or a memory mode until immediately before the completion of the manufacturing process, for example, before shipment by the manufacturer or seller, so that the sensor electronic device module does not consume power during storage at the manufacturer or seller. Similarly, the sensor electronic device module can also transition to a "low-power" or "no-power" mode during a predetermined inactive period, such as during a wireless communication session, for example, during period T inactive During this period, it can transition to a "low-power" or "no-power" mode. It should be noted that in some embodiments, one or more components constituting the sensor electronic device module, such as a transceiver, may wake up or stop, while one or more other components may remain in a low-power / sleep mode. In other embodiments, all components constituting the sensor electronic device module may wake up or transition to a low-power / sleep mode. Such components within the sensor electronic device module or transmitter can include a power-down module that can use hardware, software, or firmware to transition the transmitter from an active state to an inactive state.

[0330] In one embodiment, the wake-up and power-on of the sensor electronic device module (e.g., T inactiveDuring a period or the like, transitioning the sensor electronic device module to the active mode or the operating mode) can occur when a sensor reading value exceeding a predetermined threshold is detected. For example, the predetermined threshold can be specified in terms of count or via other means, for example, by the use of a potentiostat, an A / D converter, etc. In some implementations, the processor of the sensor electronic device module (or other controller chip or device of the sensor electronic device module) can wake up periodically (e.g., every 5 minutes) to monitor the count. If the received count number is below a predetermined count threshold, the processor or controller can return to the low power mode. If the received count number exceeds the predetermined count threshold, the processor or controller wakes up and processes and / or transfers the sensor information to the remote measurement module for distribution to one or more display devices. Also, in some implementations, the processor or other controller of the sensor electronic device module can remain in the operating mode of monitoring the count to determine whether the sensor electronic device module starts receiving / acquiring and / or processing sensor information from the continuous analyte sensor, and such continuous periodic monitoring checks can be performed more than once.

[0331] The system and method according to this principle may incorporate functions to avoid potential problems of the above wake-up circuit, 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 generally be received over the application of current for approximately Y seconds or minutes (e.g., 300 seconds or 5 minutes). In yet other embodiments, the benchmark count threshold can be monitored in the context of a persistent condition, for example, the persistent condition can include a consistent count frequency over a subset of the Y period.

[0332] In the implementation of the above method, an initial determination can be made as to whether the received count meets or exceeds a benchmark count threshold, and then another determination can be made to determine whether the received count meets or exceeds a second benchmark count threshold (U) over a second period (V). For example, the processor, or generally the sensor electronics module, does not wake up unless the second benchmark count threshold U is met or exceeded over the second period V.

[0333] The operation can further include determining that the second benchmark count threshold U is met or exceeded for the second period V over a plurality of intervals (n). This method may be used to check for persistence. That is, for example, as opposed to a false wake-up due to inadvertent contact of the user with the sensor electronics module, it is a verification step to ensure that the sensor electronics module actually means to wake up from a low-power memory mode due to the insertion of a continuous analyte sensor. This implementation can ensure that a count representing actual sensor data is generated, rather than a count from electrostatic discharge (ESI)-based data that tends to have bursts.

[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 mode or a memory mode. For example, the sensor electronics module can transition to a low-power mode or a power-off mode during a certain inactive period T, such as during a wireless communication session. inactive However, in scenarios where the sensor electronics module has to wake up to send and receive sensor information, if the sensor electronics module fails to wake up, that would be a problem.

[0335] Accordingly, some embodiments implement a mechanism for the sensor electronics module to reliably wake up when guaranteed. In particular, some embodiments utilize a watchdog timer. A watchdog timer is a hardware function of an electronic component or circuit with a countdown timer. The watchdog timer can be used to detect and recover from system anomalies or malfunctions. For example, when the countdown timer reaches 0, the chip is reset. Since the watchdog is hardware and not controlled by software, software errors do not interfere with its operation.

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

[0337] In another embodiment, system 1750 of FIG. 33 shows an exemplary wake-up circuit that can be used within the transmitter electronics to immediately activate the transmitter and speed up the startup process. For example, the wake-up circuit can be used to return the transmitter from a memory mode, and data extraction can be initiated by the wake-up circuit. For example, when an operator / HCP removes the transmitter from the sensor and connects the transmitter to a fixture, such as a reader, the transmitter can be configured to start advertising, and the pairing and extraction processes can be initiated. This can include Bluetooth® pairing with hash tags and challenge values for forming a secure link.

[0338] More specifically, FIG. 33 shows a transmitter electronic device 764 that is stationary adjacent to an HCP fixture such as a reader 771 that can be implemented as a dongle attached to an HCP device. The transmitter electronic device 764 includes an ASIC 766 and a memory 768. A transmitter 770 is configured within the transmitter electronic device 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 scope of the transmitter electronic device. Otherwise, such calibration can be performed on a smart device that signal communicates with the transmitter. A sensor coupling circuit 772 enables conductive communication with a wire from an implantable analyte sensor. A wake-up circuit 778 is provided to achieve the function of the wake-up circuit described above. As shown, the wake-up circuit 778 may include a wake-up pin 780 that enables convenient access during debugging, i.e., enables the wake-up to be executed quickly. For example, in a properly configured wake-up circuit, a "high" level potential can be applied to such a wake-up pin 780, and the circuit can be such that it starts a routine that brings about the wake-up of the transmitter. Alternatively, a logically low level potential may be applied. At other times, the pin can be left floating.

[0339] In addition to the flowchart 1800 of FIG. 34, one way to wake up the transmitter after the sensor session is over is to interrogate it with an NFC signal, for example, to initiate an inquiry to the transmitter for on-demand information (step 782). Then, the data can be transferred using NFC or other means, such as 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 wake-up signals. Generally, NFC is suitable for wake-up due to its speed and low power consumption. However, the security of NFC is generally due to proximity.

[0340] However, the problems that occur in the above device include incorrect startups. For example, the energy captured by the NFC antenna may lead to incorrect startups or data degradation. If the wake-up circuit has a wake-up pin, electromagnetic energy can couple to the pin, causing similar harmful startups, data degradation, and battery depletion (for example, it is generally desirable to maintain 10% of the battery charge for data extraction). In a specific example, the energy captured by the NFC antenna can couple to the sensor circuit or the power circuit, such as the power rail connected to the ASIC or the rectifier. The coupled energy can introduce noise into the sensor data and have an adverse effect on the electronics of the transmitter. Therefore, it is important to know when to consider sensor data and when to ignore it during various intentional and unintentional NFC operations.

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

[0342] A test is performed (step 790) regarding whether both FLAG_1 and FLAG_2 are set. 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 a period can be processed to compensate accordingly. For example, the processor can first flag the sensor data measured or sampled during NFC operation, and then the data can be held (step 792) or adjusted (step 794). Other options include applying different weights to the data, 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 unintentional data is being captured via NFC, for example, random noise is being captured from other RFID sources. Various steps can be taken, but in one implementation, such data can be removed, deleted, or ignored from future calculations (step 796).

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

[0345] Referring to flowchart 1900 of FIG. 36A, a hardware approach can also be employed to address this issue. In particular, following the end of the session (step 802), such a hardware approach can include operations taken to interfere with the operation of the wake-up pin or turn off the NFC antenna or circuit (step 810).

[0346] In the former approach, it should be noted that the wake-up pin is generally floating by a pull-up / pull-down resistor, which can be, for example, a resistor extending between the wake-up pin and ground. For example, refer to FIG. 36B where transmitter system 817 includes 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. For example, the voltage V at point 825 is the same as ground. However, with sufficient electromagnetic induction (EMI), an incorrect transition can occur at this pin, resulting in a voltage at point 825 different from ground and potentially causing an incorrect wake-up. Usually, EMI occurs intermittently. However, if multiple incorrect wake-ups occur due to EMI, it can start to have a significant adverse effect on battery life. During a wake-up event, the battery is automatically connected to the processor and consumes additional current compared to the standby current. This leads to a shortening of the service life.

[0347] Accordingly, 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 strengthened or otherwise made more robust against EMI (step 806). For example, a strong pull-up / pull-down resistor and, optionally, a capacitor can also be used. Finally, the wake-up pin can be effectively disabled before transitioning to the standby mode, for example, by providing an instruction to the wake-up pin via an ASIC (step 808).

[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 the energy captured by the NFC antenna, monitor such captured energy, and compare it to a threshold. If the threshold is met or exceeded, the NFC circuit and / or NFC antenna can be switched off.

[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 circuit is only being used to wake up the transmitter from sleep mode, the NFC antenna / circuit can be disabled after the wake-up process is complete. In this way, the NFC antenna no longer picks up random signals.

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

[0351] The wake-up circuit described above is very beneficial by providing a convenient way to activate the transmitter. However, it does not necessarily have no 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 where the transmitter is placed periodically creates a conductive path between the sensor leads, an incorrect current can pass between the sensor leads, causing an incorrect startup and draining the transmitter battery. Therefore, the battery power of the transmitter can be conserved by disabling the wake-up circuit. The method is as follows.

[0352] One way to effectively disable the wake-up circuit is to increase the threshold potential required to be measured for processor verification of sensor operation, for example, by increasing the above-described benchmark count threshold. In this way, spurious wake-ups may be accidentally detected at least until the next threshold measurement, for example, measured at intervals as described above, and thus the system can more quickly transition back to the memory mode.

[0353] Another approach to enhancing consumer health is not only to extend the lifespan of the sensor session by considering battery depletion, but also to make the sensor and transmitter smaller and potentially disposable. For example, some users may purchase such a device over the counter and may wish to use the same device for two weeks to get an idea of their blood glucose fluctuations, even if such a device does not provide real-time data. Such a disposable CGM can only collect data and enable periodic data transfer. To reduce costs and streamline data transfer, a disposable CGM can collect data and periodically downsample the data, retaining only a few points necessary to accurately describe the glucose exposure accordingly. For example, the CGM and transmitter may retain only data regarding the maximum value, minimum value, and certain inflection points.

[0354] More specifically, and referring to flowchart 1950 of FIG. 37, during a sensor session, the transmitter can receive count data from the sensor (step 820). The transmitter can store the count data along with a time stamp (step 822). For example, the time stamp can be an absolute time stamp indicating the date and time, or the time stamp can be relative, indicating, for example, that the transmitter has been in use for 1000 minutes during this sensor session.

[0355] The transmitter can include various ways to compress data (step 824). As described above, the transmitter can compress data (step 826), and such compression can include using timestamp data. Stable, or other linear data, or data that can be functionally represented, can be deleted and replaced with just endpoint data or data regarding the function. For example, stable data can be deleted by only saving and transferring the data points between inflection points. For example, if glucose is stable at 90 mg per dL for 2 hours and then slowly reaches 95 mg per dL, the data in between can be excluded and only the endpoints can be stored and / or transmitted. Alternatively, only data that changes by more than a certain amount, such as 5 or 10 mg / dL, can be recorded and / or transmitted, and the data in between can be interpolated.

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

[0357] As another aspect, a disposable CGM in this way does not necessarily have or include a calibration or conversion algorithm. Such processing can be provided elsewhere, such as on a display device or in the cloud.

[0358] Since the use is retrospective, specific artifacts can be completely removed to avoid the possibility of misunderstanding. These include artifacts such as "dip and recovery" disorders and PSD-type artifacts. Such data segments may be blocked on the display as "glucose data not available". If the duration of the artifact is short enough, the simplified glucose trace need not be affected at all.

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

[0360] The advantages include cost and data transfer time. In particular, costs are reduced by avoiding data transmission and by selecting passive communication technologies. Memory storage time and cost are reduced by intelligently downsampling hundreds of data points per day to a much smaller number, e.g., 10 - 20 points, and by incorporating reversible data compression methods.

[0361] To further improve accuracy, the data may be post - processed within the transmitter, e.g., it may go through steps such as smoothing to improve accuracy (step 830 in FIG. G5). The post - processing can occur, for example, after each CGM session, at intervals such as one - week length, ten - day length, fourteen - day length, etc. In this way, the need for an external software application to perform such post - processing of such raw data can be eliminated. In another implementation, the data can be post - processed at the end of each 24 - hour period. Smoothing, and lessons learned and insights gained, can be applied prophylactically while the user is still wearing the device, maximizing the potential overall accuracy after the entire CGM sensor session. As a result of such retroactive processing, additional data is obtained by retroactive processing, so the range bars of glucose data on the trend graph can become narrower over time.

[0362] Context awareness can also be employed to provide further insights and a degree of "calibration." For example, significant changes are expected during meals. Such context data can be collected by time data, including analysis of historical patterns, such as the time when the user typically eats lunch. For example, context data can also be collected from geographical location data, such as when the user is in the same location as a restaurant that the user is known to frequent. Based on the user's past patterns of activity, context information, and a reference time frame, the sensitivity of important algorithms can be increased or decreased during these meal periods. In this case, timestamp data can also be used.

[0363] As a further way to improve the accuracy and reliability of data, the transmitter can provide one or more insights using available external data (step 832). For example, if the transmitter uses an accelerometer or other activity measurement method, or if the transmitter signal communicates with a display device that includes an accelerometer, accelerometer data can be used to determine various insights. For example, such insights can include reasons for particularly noisy data and cases where such noise is due to user movement or signal interference. For example, long-term activity and / or short-term intense activity as measured by an accelerometer will increase the sensitivity of the algorithms used to predict or measure glucose. Subsequently, if continuous movement activity is measured, the confidence level of the rate of change may increase. In other words, if the transmitter or application knows that the user is exercising, the noisy data is more likely to be maintained because the reliability that it is not caused by noise in the data increases.

[0364] Ambient noise sensors can be used in a similar way. For example, such ambient noise sensors can be used to identify sleep or other times when significant long-term ambient noise reduction is identified. Such can also be correlated with time to more accurately identify sleep intervals.

[0365] Using all such collected data, a statistical analysis is performed at the end of the diagnostic session, which gives the user instructions regarding their performance and also gives a convenient overall "score" for clinician use after the CGM period. Important statistics can include "% time in target range" or "% time in hypoglycemia", an indicator of hypoglycemia risk, etc. This overall "score" can be used to "triage" patients at high risk of triggering workflows for clinicians to first focus on these individuals when reviewing the data. This can function as a prelude to more detailed statistical reports and more formal clinical decision support software.

[0366] For example, in a large diabetes center or a large diagnostic lab, it is possible to process diagnostic CGM data from 100 patients per day and generate 100 individual reports. The results and corresponding patients can be triaged based on the overall "risk score" provided so that clinicians can first contact high-risk patients and address ongoing concerns identified with 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 those described above for smoothing, 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 as well as the adhesive patch, may be returned to the HCP for data extraction and analysis. In some cases, data extraction may already be occurring via the connection between the transmitter and the receiver. Such a device may be calibrated only once, or may be provided with factory calibration. Existing applicator technology can be used to place the sensor on the user, and in some cases the transmitter can be snap-fit onto the sensor housing. Such technology is described, for example, in U.S. Patent Application No. 15 / 298,721, filed Oct. 20, 2016, titled “Transdermal Analyte Sensor, Applicator Therefor, and Related Methods,” owned by the assignee of the present application and incorporated herein by reference in its entirety.

[0368] In another particular exemplary implementation, a small, single-use disposable sensor product can include a “smart” transmitter as described above, which can be used primarily for non-assisted purposes. Data from such a smart transmitter can be shared with a third party, even during a sensor session. Such third parties can include, for example, payers. Such a device may be factory calibrated and in some cases may even be available without a prescription. An equipped system may be provided for the patient to place it on themselves.

[0369] Implementations of the system and method according to this principle can include providing functions such as a target range, for example creating soft alarms or notifications that provide education to the user after the fact of providing event entries, which are not necessarily real-time but enable the input of, for example, targeted medication compliance, providing appropriate APIs for setting event inputs from a meal application or from a direct user interface by the user, providing appropriate APIs for setting event inputs from a health kit, etc.

[0370] Other implementations can include the HCP office communicating with patients using their encrypted email systems. Such information can be provided "all in one place", for example as part of the electronic medical record. Files corresponding to 14-day (or other sensor session period) reports can 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 that shows trends, blood glucose levels, and 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 settings. Events can be indicated using a date / time stamp. Statistics may be provided that allow the user or HCP to compare one day to another. The patient can use such data to learn "cause and effect" based on what is displayed on the home screen, and in this way be able to learn such patterns on their own or be empowered to do so.

[0372] The patient application can provide color-coding indicating whether the blood glucose level is high, low, or at the target value. Smartphone notifications can be similarly configured to indicate to the user whether they are high or low based on the set alerts.

[0373] In some implementations, during a sensor session, if a connected receiver is employed, it can inform the HCP whether the patient is hyperglycemic or experiencing 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 within, above, and below the target range. The application may overlay the results to explain trends. The application can post events including those related to nutrition, stress, activity, illness, infection, sleep patterns, etc. Such an application can be made available at least immediately prior to a patient visit to enable HCP review to better inform the patient's examination, and the application can highlight specific important information to enable the HCP to better formulate a treatment plan for the patient. Highlighting specific important information can include comparing the detected or determined patterns to criteria stored in a database, particularly criteria for detecting particularly dangerous patterns. Often, the HCP application can be configured such that the HCP can break down desired changes into small steps that tend to be most effective for the patient and promote a positive reinforcement loop.

[0375] In one implementation, a patient can learn how their body reacts to various activities by performing daily tasks and learn which variables affect their health from an application, such as application 403. In this way, the patient can gain a deeper understanding of the causal relationships and remove some of the guesswork in treating their illness. For example, exemplary tasks can be eating their favorite meal at their favorite restaurant, or drinking orange juice at breakfast, or taking a 30-minute walk. The patient application can provide an overview of how these activities affected their health, at least from the perspective of blood sugar response. If such sensors are also available, the patient can learn how such activities affected their blood sugar level, cholesterol level, blood pressure, etc. The patient application can also be configured to prompt the patient to take their medication and to remind them which medication to take. Smartphone reminders and notifications can also be set for vitamin intake, blood pressure measurement, etc.

[0376] The application can be configured to allow the user to select goals that are important to them and provide customized education, actions, and milestones tailored to that goal or task. For example, the application can be configured to allow the user to enter the goals they want to achieve in a specific priority order. Tasks can include, for example, "want to wear my favorite high school jeans again", "want to choose a healthy meal near work", etc. Tasks can last, for example, for two weeks. Once achieved, the patient can move on to the next step they have selected in priority. The application can provide a daily progress report that can be shared with others. The application can also display people who are struggling with the same goals as successful people. For example, the app can say, "The goal you selected was also selected by 85% of other people your age. They reported that portion control and exercise were the secrets to their success."

[0377] In an exemplary implementation, a Certified Diabetes Educator (CDE) can assist a new patient using the following steps. The CDE can inquire whether the patient has a smartphone, and if so, the CDE can help the patient download a patient application to the smartphone. The CDE can then insert the sensor into the patient's abdomen and then insert the transmitter into the sensor pod. At this point, the application can be configured. Various user accounts can be set up, such as those that can 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, for example. The patient can then confirm their understanding and consent to the various statements.

[0378] The CDE can then set the patient's glucose threshold and thus set the patient's target range. The CDE can explain that the patient will be notified on the smartphone if the patient's glucose concentration goes above or below the threshold. The CDE can then assist the patient in pairing the sensor and transmitter to the application. Various methods of performing such pairing have been described above. The CDE can then explain to the patient how to mark events such as eating carbohydrates or performing physical activity. And such event input techniques are provided to the patient. The CDE can then provide a brochure 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 is operating, for example, by receiving an appropriate number of counts, but that glucose concentration data may not be available for several hours.

[0379] After the sensor session ends, for example, 14 days later, "Congratulations, your session has ended. For the sensor removal procedure, please swipe." If data was uploaded during the session, the patient can discard the sensor and transmitter in an appropriate manner. Otherwise, the user can keep the same or just the transmitter and provide the same to the doctor for data extraction during the next visit. When checking the data using the HCP application, the doctor can 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 those shown in FIG. 8 for example, the HCP assists the patient in this task. In an alternative implementation, the user account can be set up on behalf of the patient before the patient is provided with a kit that includes the sensor, transmitter, and applicator. In a particular implementation, the kit can also include a mobile device (e.g., an Android mobile phone, iPhone (registered trademark), etc.) on which the application is 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 is set up on a server so that the patient can automatically log in using an application on their mobile device by entering only minimal information.

[0382] In step 886, before providing the kit to the patient, a patient account is set up on the server in place of the patient within the maintained database. Among the items assigned to the patient account, such as the patient name, date of birth (DOB), etc., the patient account is assigned the unique identifier of the mobile device included in the kit that is to 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 that includes a mobile device. In step 890, the user launches an application that establishes communication with the server and automatically transmits the unique identifier of the mobile device. The application also transmits the patient information pre-assigned to the patient record that is used to associate the patient with the mobile device. This information can include, for example, one or more of the following: the patient's email address, DOB, phone number, etc.

[0384] In step 892, the server attempts to match the unique identifier of the mobile device and the patient information with the patient record stored in its database. If the match is successful, in step 894, the server either logs in or transmits to the application the credentials required to access the matching patient record in the database. Then, in step 896, the application accesses the patient record using the credentials.

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

[0386] It should be noted that in some cases, the functions of the server used in the above-described automatic login procedure 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 the device manufacturer, and one or more additional servers may be controlled and operated by the database provider.

[0387] For ease of explanation and illustration, in some examples, the detailed description has described exemplary systems and methods from the perspective of a continuous glucose monitoring environment, but it should be understood that the scope of the present invention is not limited to that particular environment, and those skilled in the art will understand that the systems and methods described herein can be embodied in various forms. Accordingly, any structural and / or functional details disclosed herein should not be construed as limiting the systems and methods, but rather as representative embodiments and / or attributes of an arrangement provided to teach those skilled in the art one or more ways of implementing systems and methods that may be advantageous in other situations.

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

[0389] By way of example, without 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, smartwatches, smart rings, smart necklaces or pendants, exercise monitors, fitness monitors, health and / or medical monitors, clip-on monitors, and the like), adhesive sensors, smart textiles and / or clothing-embedded sensors, sensors, transcutaneous (i.e., percutaneous) sensors, and / or ingestible, inhalable, or implantable sensors, including shoe inserts and / or insoles.

[0390] In some embodiments, without limitation, the monitoring systems and methods may include, instead of or in addition to the sensors described herein, an inertial measurement unit including an accelerometer, gyroscope, magnetometer, and / or barometer for measuring information of the host and / or another party or associated therewith, motion, altitude, position, and / or location sensors, biometric sensors, such as an optical heart rate monitor, a photoelectric plethysmogram (PPG) / pulse oximeter, a fluorescence monitor, and an optical sensor including a camera, wearable electrodes, an electrocardiogram (EKG or ECG) sensor, an electroencephalogram (EEG) sensor, and / or an electromyogram (EMG) sensor, chemical sensors, such as flexible sensors for measuring stretch, displacement, pressure, weight, or shock, galvanometric sensors, capacitive sensors, electric field sensors, temperature / thermal sensors, microphones, vibration sensors, ultrasonic sensors, piezoelectric / piezoresistive sensors, and / or other sensors such as transducers.

[0391] In this specification, the terms "computer program medium" and "computer usable medium" and "computer readable medium" generally refer to, among other things, temporary or non-temporary media such as main memory, storage unit interfaces, removable storage media, and / or channels, as well as their variations. These and various other forms of computer program media 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 are generally 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 group). When executed, such instructions may enable a computing module or its processor or a processor connected thereto to perform the features or functions of the present disclosure as contemplated herein.

[0392] Various embodiments have been described with reference to their specific exemplary features. However, it will be apparent that various modifications and changes can be made without departing from the broader spirit and scope of the various embodiments recited in the appended claims. Therefore, the specification and drawings should be regarded in an illustrative rather than a limiting sense.

[0393] Although various exemplary embodiments and implementations have been described above, the various features, aspects, and functions described in one or more of the individual embodiments are not limited in their applicability to the particular embodiments in which they are described. Instead, such features can be applied, alone or in various combinations, to one or more of the other embodiments of the present application, regardless of whether such embodiments are described and regardless of whether such features are presented as being part of the embodiments described. Accordingly, the breadth and scope of the present application should not be limited by any of the exemplary embodiments described above.

[0394] The terms and phrases used in this application, and variations thereof, should be considered to be without limiting co...

Claims

1. A method of configuring a continuous glucose monitoring device for use by a patient, the configuration involving a healthcare professional (HCP), comprising: establishing, by an HCP client device, a communication session related to the HCP account between the HCP client device and a server; prompting, by the HCP client device, the HCP to input patient data on a user interface associated with the HCP client device; prompting, by the HCP client device, the HCP to input identification data corresponding to a transmitter and / or sensor associated with the continuous glucose monitoring device on the user interface associated with the HCP client device; receiving, by the HCP client device, the input patient data and the identification data; storing, by the HCP client device, the input patient data and the identification data and transmitting them to the server for association with a patient account; receiving, by the HCP client device, an output from the server in response to transmitting the input 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, the code being unique to the patient; A method as described above.

2. The method according to claim 1, wherein the identification data is identification data related to the transmitter.

3. The method according to claim 1 or 2, wherein the code is received by email or text.

4. The method according to any one of claims 1 to 3, further comprising transmitting, by the HCP client device, configuration information to the continuous glucose monitoring device.

5. The method according to claim 4, wherein the transmission is performed by short-range wireless communication or Bluetooth (R) low energy.

6. A method of configuring a continuous glucose monitoring device for use by a patient, the configuration involving a healthcare professional (HCP), comprising: The HCP client device establishes a first communication session related to the HCP account between the HCP client device and the server, The HCP client device prompts the HCP to input patient data on the user interface related to the HCP client device, The HCP client device establishes a second communication session between the HCP client device and the transmitter related to the continuous glucose monitoring device, whereby the transmitter and / or sensor related to the continuous glucose monitoring device can be identified by the HCP client device, The HCP client device receives the input patient data and identification data, The HCP client device stores the input patient data and the identification data and transmits them to the server for association with the patient account, The HCP client device receives an output from the server in response to transmitting the input patient data and the identification data to the server, the received output including code configured to be used by the patient smart device to download an application for use in continuous glucose monitoring, the code being a code unique to the patient, A method comprising. **Claim 7** The method according to claim 6, wherein the second communication session transmits transmitter identification data to the HCP client device. **Claim 8** The method according to claim 6 or 7, wherein the code is received by email or text. **Claim 9** The method according to any one of claims 6 to 8, further comprising the HCP client device transmitting configuration information to the continuous glucose monitoring device. **Claim 10** The method according to claim 9, wherein the transmission is performed by short-range wireless communication or Bluetooth (registered trademark) low energy.

Images