System, device and method for episode detection and evaluation

Abstract

To be useful for assisting patient behavior modification and reducing occurrence of episodes by correlation between possible causes and detected episodes.SOLUTION: Systems, devices and methods are provided that allow detection of episodes in analyte measurement, prompting a patient to self-report possible causes for the episodes. A question related to the episode can be displayed in an area 1294 and each can include a selection list 1298 of possible answers on a response screen 1210 with a corresponding check mark field for selecting an answer thereof. When a plurality of questions related to the episode are presented, a selection list 1298 for each question can be included, with each selection list configured as a drop down menu. Besides the prescribed responses, a free-form text input field 1296 can be provided for custom responses.SELECTED DRAWING: Figure 12A

Description

Cross-reference to related art

[0001] This application claims the benefit of and priority to U.S. Provisional Application No. 62 / 189,137, filed July 6, 2015, and U.S. Provisional Application No. 62 / 191,208, filed July 10, 2015, both of which are incorporated by reference in their entireties for all purposes. [Technical field]

[0002] The subject matter described herein relates to systems, devices, and methods that can determine or predict the occurrence of an episode in analyte data and assess the circumstances and potential causes for the episode. [Background technology]

[0003] Many systems have been developed for automated monitoring of analytes, such as glucose, in bodily fluids, such as blood, interstitial fluid (ISF), dermal fluid of the dermis layer, or other biological fluids.

[0004] These systems can provide analyte level determinations or measurements to healthcare providers (HCPs), diabetic patients, and / or caregivers over time. Knowing the current analyte level and how it is likely to change over time can be useful in determining courses of action to mitigate potentially significant analyte level changes, called excursions. However, understanding what causes, symptoms, and / or treatments influence the occurrence of excursions would be beneficial in reducing their frequency and severity.

[0005] For example, diabetic patients can benefit from reduced analyte level variability by reducing the frequency and / or severity of excursions. Diabetic patients with relatively high analyte variability have difficulty treating high analyte level excursions by administering medicines such as insulin to reduce analyte levels, as doing so may increase the risk of low level excursions due to the large swings in analyte levels that define high variability. Conversely, treating low level excursions by ingestion of food or carbohydrates to increase a diabetic patient's analyte level may increase the risk of high level excursions due to the subsequent elevated analyte levels and high variability. Reducing the frequency and / or severity of excursions may be an important prerequisite for reducing variability.

[0006] Many metrics are available to HCPs and patients to characterize or explain variability in analyte levels (e.g., mean, median, percentile variation, variability metrics, risk metrics, rate of change, etc.). Analyte monitoring devices and systems can generate vast amounts of data that can overwhelm and confuse users with little or no insight into the reasons leading to excursions or high variability. Additionally, recording information that would be useful in understanding causation can be burdensome for patients as they are unclear about what information to record.

[0007] One of the main challenges in investigating the causes of excursions and fluctuations is the lack of correlation between the analyte level monitoring mechanisms responsible for collecting the data on which the analysis is based and the relevant conditions leading to the occurrence of an excursion or the time periods that contribute most to the fluctuations. Investigation of these activities is usually conducted by a question and answer session between the diabetic patient and the HCP, which may take place days or weeks after the fact. Such sessions are uninformative because the diabetic patient often does not remember the activities or conditions that led to the excursion or because the diabetic patient did not recognize the need to track these conditions, for example by investigating recent medication doses, carbohydrate content of recently consumed foods, recent exercise, activity, or sleep duration, etc. Furthermore, when directly questioned by the HCP, the diabetic patient may feel pressured to give answers that make them appear to be living a healthier lifestyle than they actually are. Summary of the Invention [Problem to be solved by the invention]

[0008] For these and other reasons, there is a need for improved monitoring, research, and evaluation of variations and excursions. [Means for solving the problem]

[0009] This specification provides many exemplary embodiments of systems, devices, and methods for investigating why analyte excursions and / or relatively high analyte variability occur. For example, to reduce analyte variability, these embodiments can identify and / or investigate the occurrence of analyte episodes that cause excessive variability. In many embodiments, these episodes can include actual analyte excursions that exceed clinically safe levels, but can also include other variations that are not typically considered excursions.

[0010] For example, certain embodiments may monitor analyte levels in a diabetic patient, determine whether one or more analyte-related episodes have occurred (or predict future occurrences) based on the monitored analyte levels, prompt the diabetic patient for information regarding the episode, and investigate (or enable investigation of) behaviors and other conditions that may be contributing to the episode in an improved manner. Many of these embodiments may utilize an in-vivo sensor control device that receives analyte level measurements from a sensor in the diabetic patient's body, a reader device that receives the measurement data from the sensor control device, and a monitoring application resident on the reader device that analyzes the measurement data.

[0011] Episode investigation software (EIS) that facilitates the collection of information from the diabetic user and enables the implementation or subsequent investigation of root causes and conditions underlying episodes and fluctuations can be provided to the reading device and / or one or more computing devices, e.g., via a web server, e.g., as an app on a smartphone.

[0012] This specification also describes exemplary embodiments for running the software with one or more wrappers on a computing device. The computing device may be a reader device or other device. The wrappers may enable modification of data passing through interfaces between various software modules or functions.

[0013] Other systems, devices, methods, features, and advantages associated with the subject matter described herein will become apparent to one of ordinary skill in the art upon review of the following figures and detailed description. All such additional systems, methods, features, and advantages are intended to be encompassed herein, be within the scope of the subject matter described herein, and be protected by the accompanying claims. No feature of the exemplary embodiments should be construed as limiting the scope of the appended claims unless the claims expressly recite such features. [Brief description of the drawings]

[0014] Details of the subject matter described herein, both in structure and operation, will become apparent from examination of the accompanying drawings, in which like parts are designated with like reference numerals. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the subject matter. Moreover, all figures are intended to convey concepts, and relative sizes, shapes, and other detailed attributes have been shown diagrammatically, rather than faithfully or accurately. [Figure 1A] FIG. 1 is a schematic diagram illustrating an exemplary embodiment of an analyte monitoring system for real-time measurement, data acquisition, and / or processing of an analyte (e.g., glucose) using a monitoring application on a reader. [Figure 1B] FIG. 2 is a schematic block diagram illustrating an exemplary embodiment of a reading device. [Figure 1C] FIG. 2 is a schematic block diagram illustrating an exemplary embodiment of a sensor control device. [Diagram 2] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 3A] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 3B] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 4A]1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 4B] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Diagram 5] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 6A] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 6B] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 7] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 8] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 9A]1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 9B] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 9C] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 10] FIG. 1 is a flow diagram illustrating an exemplary embodiment of automatic configuration of episode investigation software. [Figure 11] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 12A] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 12B] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 12C]1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 13] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 14A] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 14B] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 15] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a reading device or other computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 16] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 17A] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 17B]1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 18A] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 18B] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 19A] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 19B] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 20] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 21] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 22A]1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 22B] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 22C] FIG. 1 is a flow diagram illustrating an exemplary method performed by instructions implementing episode research software functionality. [Figure 22D] FIG. 1 is a flow diagram illustrating an exemplary method performed by instructions implementing episode research software functionality. [Diagram 23] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Figure 24] 1A-1C illustrate exemplary embodiments of graphical user interface screens that may be displayed on the display of a computing device that runs or accesses an exemplary embodiment of the episode research software. [Diagram 25] FIG. 1 is a flow diagram illustrating an exemplary embodiment of a method for treating a patient with the assistance of episode investigation software. [Figure 26] FIG. 2 is a block diagram illustrating an exemplary embodiment of software stored in a non-transitory storage device of a reading device. [Figure 27] FIG. 2 is a flow diagram illustrating an exemplary embodiment of a method for operating software having a wrapper. [Figure 28] FIG. 2 is a flow diagram illustrating an exemplary embodiment of a method for operating software having a wrapper. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Before describing the present subject matter in detail, it is to be understood that the present disclosure is not limited to particular embodiments described herein, which may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims.

[0016] Exemplary Embodiments of an Analyte Monitoring System As mentioned above, many systems have been developed for automated monitoring of analytes, including but not limited to glucose, in bodily fluids, such as blood, interstitial fluid (ISF), dermal fluid in the dermis layer, or other biological fluids. Some of these systems have at least a portion of a sensor placed within a patient's body, for example, in a blood vessel or in the subcutaneous tissue or dermal layer of a patient, to obtain information regarding at least one analyte in the body. Thus, these systems may be referred to as "in vivo" analyte monitoring systems.

[0017] In vivo analyte monitoring systems include "continuous analyte monitoring" systems (or "continuous glucose monitoring" systems) that can transmit data without prompting, for example, by continuously broadcasting data from the sensor controller to the reader according to a broadcast schedule. In vivo analyte monitoring systems also include "flash analyte monitoring" systems (or "flash glucose monitoring" systems, or simply "flash" systems) that use radio frequency identification (RFID), near field communication (NFC), or other protocols that can transmit data from the sensor controller in response to a data scan or request by the reader. In vivo analyte monitoring systems have been developed that can also operate without the need for finger-prick calibration.

[0018] In vivo analyte monitoring systems can be distinguished from "ex vivo" systems that include a measuring device that contacts a biological sample outside the body (or rather "ex vivo"), which can be analyzed to determine the patient's blood glucose level, and typically has a port for receiving an analyte test strip carrying the patient's bodily fluid. While in many embodiments herein, the monitoring occurs in vivo, the embodiments disclosed herein can be used in in vivo analyte monitoring systems that incorporate ex vivo functionality, as well as completely ex vivo or ex vivo analyte monitoring systems.

[0019] The sensor may be part of a sensor control device that resides in the patient's body and enables and controls the sensing of the analyte. The sensor control device or variations thereof may also be referred to as a "sensor control unit," a "sensor electronics" device or unit, an "on-body electronics" device or unit, an "on-body" device or unit, or a "sensor data communications" device or unit, to name a few.

[0020] The in-vivo monitoring system may also include a device that receives the sensed analyte data from the sensor control device and processes and / or displays the sensed data to a user in any number of forms. This device or variations thereof may also be referred to as a "reading device" (or simply "reader"), a "handheld electronic device" (or handheld terminal), a "portable data processing" device or unit, a "data receiver", a "receiver" device or unit (or simply receiver), or a "remote" device or unit, to name a few. Other devices, such as personal computers, may also be used in conjunction with or incorporated into in-vivo and in-vivo monitoring systems.

[0021] The embodiments described herein can be used to monitor and / or process information regarding any number of one or more different analytes. Analytes that can be monitored include, but are not limited to, acetylcholine, amylase, bilirubin, cholesterol, chorionic gonadotropin, glycosylated hemoglobin (HbA1c), creatine kinase (e.g., CK-MB), creatine, creatinine, DNA, fructosamine, glucose, glucose derivatives, glutamine, growth hormone, hormones, ketones, ketone bodies, lactate, peroxide, prostate specific antigen, prothrombin, RNA, thyroid stimulating hormone, and troponin. Concentrations of drugs, such as antibiotics (e.g., gentamicin, vancomycin, etc.), digitoxin, digoxin, drugs of abuse, theophylline, and warfarin, can also be monitored. In embodiments monitoring multiple analytes, the analytes can be measured at the same time or at different times.

[0022] Many of the exemplary embodiments described herein refer to monitoring glucose, but such references are merely a recognition that glucose is a commonly monitored analyte, and such references should not be construed as excluding practice with analytes other than glucose.

[0023] The manufacturer of the in-vivo system may provide the patient with both a sensor control device and a corresponding reader device, and in some cases the two are sold as a set. The sensor control device has a limited life span and must be replaced periodically (e.g., every two weeks), but the reader device can be used for a much longer period of time and can be reused with each new sensor control device.

[0024] One embodiment of an analyte monitoring system 100 is shown in Figure 1A. The system may include one or more measurement devices, such as a sensor control device 110 having an analyte sensor 104, and a reader device 120, such as a portable smart phone, running a software application, such as a glucose monitoring application 140. One or more instances of episode investigation software (EIS) may be stored and executed within the system 100.

[0025] The EIS can be stored and executed on a network server 130 (e.g., in the cloud) that can be accessed by any computing device, such as the reading device 120, the local computing device 150, and / or a computing device located at a remote location, with an Internet connection and an Internet browser. Here, a device is local if it is accessible in the same vicinity as the reading device 120 (e.g., in the same office, home, or building), and a device is remote if it is located in a different vicinity than the reading device (e.g., in the patient's HCP's office). Alternatively, the EIS can be stored and executed locally on the reading device 120, the local computing device 150, and / or the remote computing device 160. Examples of local and remote computing devices include personal computers (PCs), laptop computers, desk computers, personal digital assistants (PDAs), workstations, wearable smart devices (GOOGLE GLASS, APPLE WATCH), and others.

[0026] Each device capable of storing and / or executing the software may include a non-transitory memory for storing the software, and a processing circuit communicatively coupled to the non-transitory memory for executing the software. These devices also have appropriate communication interfaces (e.g., network communication ports, etc.) for communicating with other devices. For example, server 130 may have a processing circuit 131 communicatively coupled to non-transitory memory 132, local computing device 150 may have a processing circuit 124 communicatively coupled to non-transitory memory 125, and remote computing device 160 may have a processing circuit 126 communicatively coupled to non-transitory memory 127. Because the EIS may be stored and executed by a combination of many devices, server 130, local computing device 150, and remote computing device may each be omitted.

[0027] 1A, the components can wirelessly communicate with each other using wireless communication protocols such as, for example, NFC, RFID, Wi-Fi, Bluetooth, Bluetooth low energy, or proprietary protocols. Each of the components can also communicate directly through a wired link (e.g., USB) or indirectly through a distributed wired network (e.g., TCP / IP).

[0028] Data obtained from the sensor control device 110, as well as patient-supplied data (described below), may be stored in locations accessible to the EIS, such as the reader 120, the network server 130, the local computing device 150, and / or the remote computing device 160. The data may be uploaded from the reader 120. The stored data may be processed and / or analyzed to assist the diabetic, the patient, interested parties (e.g., parents, guardians, caregivers), health care professionals (HCPs), or any user in identifying patterns and causes that may have caused an episode, which may then lead to better control of the analyte.

[0029] The EIS can correlate the diabetic patient's activity, lifestyle and / or behavior with glucose levels, thereby reducing the user's burden of categorizing the effects. The EIS can use clinical information algorithms to search glucose data obtained for an individual patient and the patient's recorded behavior (or multiple patients and patient records) to reveal patterns that affect glucose levels. In some embodiments, the EIS can have instructions to: 1) define an episode of interest; 2) select a core episode in a search routine; 3) build episodes proximate to the core; 4) associate one or more episodes with diabetes self-care behavior; and 5) display the results of the search algorithm's findings. In another embodiment, the EIS can have instructions to: 1) define an episode of interest; 2) select a core episode in a search routine; 3) build episode chains, which are sequences of episodes (including the core episode), and logic rules for including or excluding episodes proximate to the core; 4) associate one or more episode chains with diabetes self-care; and 5) display the results of the search algorithm's findings.

[0030] Further examples of episode investigation systems, software, and algorithms that can be used in conjunction with, or instead of, the EIS systems, software, and algorithms described herein are described in U.S. Patent Application Publication Nos. 2014 / 0350369, 2014 / 0088392, and 2014 / 0088393, all of which are incorporated by reference in their entireties for all purposes.

[0031] Returning to FIG. 1A, the sensor controller 110 is configured to receive glucose level measurements from a sensor 104 that can be placed in vivo, such as a subcutaneous sensor, a skin sensor, a vascular sensor, etc. In another embodiment, the sensor can be placed ex vivo but can monitor analyte levels in vivo, such as certain optical sensors. The sensor controller 110 repeatedly senses the glucose level from the sensor 104, either according to a predetermined schedule or on an ad-hoc basis, and reads one or more signals from the sensor 104 indicative of the glucose level. These glucose level measurements can be stored in the sensor controller 110 and transferred to the reader 120 in batches at predetermined times, on demand, or immediately after the glucose level is obtained.

[0032] Non-limiting examples of a reader can include a measurement device for an in vitro monitoring system, a reader for an in vivo monitoring system, a combination of the two such as an in vivo reader working with a test strip port and measurement functionality, and various devices such as smartphones, tablets, dedicated readers, other computing devices, etc. The reader 120 can include one or more software applications that execute various program routines such as communicating with another device running an EIS, displaying data in various ways, receiving input from a user (e.g., HCP, caregiver, and / or diabetic patient) to aid in diabetes management, and detecting episodes. The reader 120 can have buttons such as a keyboard used to input information, for example. Additionally or alternatively, the reader 120 can have virtual buttons such as a touch screen configured to present a virtual keyboard.

[0033] The reading device 120 may also include or be integrated with a medication (e.g., insulin, etc.) delivery device, e.g., such that they share a common housing. The medication delivery hardware may include a reservoir for storing the medication, a pump connectable to a transfer tube, and an infusion cannula for administering the medication from the reservoir, through the tube, and into the body via a cannula inserted into the diabetic patient.

[0034] FIG. 1B is a block diagram of an exemplary embodiment of a reader 120 in the form of a smartphone, where the reader 120 includes an input component 122, a display 121, and processing circuitry (or hardware) 206, which may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be distributed on separate chips or on several different chips (and parts thereof). The processing hardware 206 may include a communications processor 202 with on-board memory 203, and an application processor 204 with on-board memory 205. Additional processors may and may be present. The reader 120 further includes an RF transceiver 208 coupled to an RF antenna 209, a memory 210, a multifunction circuit 212 with one or more associated antennas 214, a power supply 216, and a power management circuit 218. FIG. 1B is a simplified representation of the components within a smartphone, and may of course include other hardware and functions (e.g., code, drivers, glue logic, etc.).

[0035] The communications processor 202 may interface with an RF transceiver 208 and perform analog-to-digital conversion, coding and decoding, digital signal processing, and other functions to facilitate format conversion (e.g., in-phase and quadrature) of voice, video, and data signals suitable for feeding to the RF transceiver 208 so that the transceiver can then transmit the signals wirelessly. The communications processor 202 may also interface with the RF transceiver to perform the inverse functions necessary to receive wireless transmissions and convert the wireless transmissions into digital data, voice, and video.

[0036] The application processor 204 may be configured to run the operating system and any software applications resident on the reader 120, to perform video and graphics processing, and other functions not related to processing communications sent and received via the RF antenna 209. Any number of applications may be running on the reader 120 at any one time, and will typically include one or more applications related to diabetes monitoring methods, as well as general applications unrelated to such methods, such as, for example, email, calendar, weather, etc.

[0037] The memory 210 may be shared by one or more of the various functional units present in the reader 120, or distributed among two or more of them (e.g., as separate memories present in different chips). The memory 210 may also be a separate chip in itself. The memory 210 may be non-transitory and may be volatile memory (e.g., RAM, etc.) and / or non-volatile memory (e.g., ROM, Flash memory, F-RAM, etc.).

[0038] The multi-function circuitry 212 may be implemented as one or more chips and / or components that perform other functions, including communications circuitry for local wireless communications (e.g., Wi-Fi, Bluetooth, Bluetooth low energy) and determining the geographic location of the reader 120 (e.g., Global Positioning (GPS) hardware). One or more separate antennas 214 may be associated with both functional circuits 212, as needed.

[0039] The power source 216 can include one or more batteries, which may be rechargeable or disposable. The power management circuitry 218 can provide battery charging control, power monitoring, power boosting, DC conversion, etc. As mentioned above, the reader 120 can also have one or more data communication ports, such as a USB port (or connector) for data communication with the remote terminal 160, or the sensor control device 110, or an RS-232 port (or any other wired communication port), to name a few. There is also a network synchronized clock 219 that can provide system time and includes, for example, an RC or crystal oscillator and associated clock buffers and distribution circuitry.

[0040] 1C is a schematic block diagram of an exemplary embodiment of a sensor controller 110 having an analyte sensor 104 and sensor electronics 250 (including analyte monitoring circuitry). Here, most of the sensor electronics 250 are integrated into a single semiconductor chip 251, which may be, for example, a custom application specific integrated circuit (ASIC), although any number of chips may be used. Shown within the ASIC 251 are schematic diagrams of several functional units including an analog front end (AFE) 252, a power management circuit 254, a processor 256, and a communications circuit 258 (which may be implemented as a transmitter, receiver, transceiver, passive circuitry, or according to a communications protocol). In this embodiment, both the AFE 252 and the processor 256 are used as analyte monitoring circuitry, although in alternative embodiments, either circuitry may perform the analyte monitoring function. The processor 256 may include one or more processors, microprocessors, controllers, and / or microcontrollers.

[0041] A non-transitory memory 253 is also included in the ASIC 251 and may be shared by the various functional units in the ASIC 251 or distributed among two or more of them. The memory 253 may be volatile and / or non-volatile memory. In this embodiment, the ASIC 251 is coupled to a power source 260, which may be a coin cell battery. The AFE 252 interfaces with the in-vivo analyte sensor 104 to receive measurement data from the sensor and output the data in digital form to a processor 256, which then processes the data to obtain final discrete values ​​and trend values ​​of the analyte, etc. This data may then be provided to a communication circuit 258 and transmitted via an antenna 261 to a reader 120 (not shown) where it may be further processed, for example by a sensor interface application.

[0042] There is also a clock 255, which may be, for example, an RC or crystal oscillator. The clock 255 may be a monotonic clock that advances at a constant rate (dependent on environmental drift) and continues uninterrupted for the entire life of the sensor. In some embodiments, the sensor controller 110 may keep time by interrupting after a predefined number of seconds (e.g., every second or minute, etc.), which increments a software or hardware counter. The counter's value reflects the number of predefined timespans that have elapsed since the sensor was powered up. For example, if an interrupt occurs every minute, the counter's value reflects the number of minutes that have elapsed since the sensor controller 110 was powered up. The functional components of the ASIC 251 may also be distributed across two or more separate semiconductor chips.

[0043] U.S. Patent Application Publication No. 2011 / 0213225 (the '225 Publication) describes variations on the sensor control device 110 and reader device 120, as well as other components of an in-vivo based analyte monitoring system, all of which are suitable for use with embodiments of the systems, devices, and methods described herein, and the '225 Publication is hereby incorporated by reference in its entirety for all purposes.

[0044] Exemplary embodiments of Episode Investigation Software (EIS) EIS can be used to detect past, present, and / or future episodes. As used herein, the term episode does not refer to all changes in analyte level, but rather to changes that are significant contributors to the variability of an analyte of interest, such as high glucose and low glucose peaks. Episodes can also include clinically significant glucose excursions or events, such as sudden increases and decreases in glucose levels. Different criteria can be used to identify a set of analyte level measurements as an episode, such as the magnitude of the analyte measurements, the rate of change between a series of analyte measurements or between other groups of measurements close in time, the number of analyte measurements (or length of time) that violate a threshold magnitude, threshold violation by the area of ​​the integral of the series of analyte measurements, or any combination thereof. Such episode detection criteria are described in U.S. Patent Application Publication No. 2013 / 0085358, the entire contents of which are incorporated herein by reference for all purposes.

[0045] As previously mentioned, EIS can be implemented in a number of different devices, including mobile devices with sensor interfacing capabilities (e.g., reader 120) or mobile devices without sensor interfacing capabilities (e.g., a typical tablet or cell phone).

[0046] Alternatively, the EIS may be executed in part on electronic equipment co-located with the sensor 104 to communicate data confirming the occurrence of each episode to a device with a user interface (UI) such as a mobile device, personal computer (PC), or the like. In such an embodiment, the sensor controller 110 may perform significant algorithmic processing on the collected measurement data to determine whether the measurement data meets predefined conditions for the occurrence of an episode. The sensor controller 110 may then transmit confirmation that an episode has occurred (and any desired information about the episode, such as type, time, location, etc.), as well as the underlying measurement data, if desired.

[0047] The EIS may be stored in non-transitory memory of a device (e.g., 120, 130, 150, 160) executing software (e.g., instructions). The EIS may be executed by processing circuitry of the device. To the extent user input (text entry, mouse click, touch selection, etc.) is provided, this is via a user interface, e.g., a touch screen, or user input 121 of reading device 120, etc., which is received and read (or interpreted) by the processing circuitry, which then takes appropriate action (e.g., displaying a new screen, displaying a check mark, modifying a selection list, etc.).

[0048] The reader 120 of the embodiment of FIG. 1A may be a smartphone running one or more downloadable software applications, commonly referred to as "apps." The EIS may be configured and distributed as such a downloadable app. Alternatively, the EIS may be resident software installed directly on the reader 120 at the time of manufacture (prior to distribution or sale). The EIS may include software instructions for interfacing with the sensor controller 110 and for processing data received from the sensor controller 110 into a user-readable value indicative of the user's glucose level (e.g., applying an algorithm to the raw sensor data or processing the data to determine an actual analyte level that can be displayed and interpreted by the diabetic or other user). Alternatively, the EIS may operate in conjunction with another software application that communicates with the sensor controller 110 to receive and process the raw data, such as a glucose monitoring application. The glucose monitoring application may similarly be configured and distributed as a downloadable app or may be resident software that is factory-installed.

[0049] Exemplary embodiments of a mobile device with episode investigation software (EIS) For ease of explanation, but not by way of limitation, the EIS will be described with respect to reader 120 as a downloadable app that is embedded with glucose monitoring instructions.

[0050] The reader 120 can automatically receive or request glucose level measurements from the sensor controller 110 and can make the measurements available to the EIS or transmit the measurements to a device running the EIS. The reader 120 can process the measurements and send alerts and / or prompts to the patient based on episodes identified by the EIS. The reader 120 can display one or more of analyte rate of change, reports, tables, graphs, and other representations of the processed glucose level measurements and actions (meals, insulin, etc.) generated and entered by the reader 120 software or the EIS for use by the HCP and patient.

[0051] The reader 120 may receive the glucose reading directly or indirectly (in the case of a primary / secondary receiver system) from the sensor controller 110. Additionally or alternatively, in some embodiments, particularly in vitro or non-sensor measurement devices, the glucose reading, e.g., blood glucose value, may be obtained from a bodily fluid sample on a test strip or manually entered by the patient into the reader 120. The glucose reading, whether obtained manually or from the sensor controller 110, may be transferred to the EIS.

[0052] The sensor controller 110 may be used in a continuous mode where glucose level measurements are repeatedly collected and automatically transmitted (i.e., broadcast) by the sensor controller 110 to the reader 120 every few seconds, minutes, e.g., every 1, 5, 10, 15 minutes, etc. Alternatively, the sensor controller 110 may have sufficient storage memory to hold a number of automatically collected glucose level measurements before transferring them to the reader 120, e.g., enough storage memory to hold 8 hours of data. The patient may obtain glucose level measurements using the reader 120, either manually or "on-demand," by a patient-initiated request for data (e.g., an NFC scan) to the sensor controller 110. This may include all glucose measurements in the sensor controller 110 memory, or a subset of measurements not yet transferred to the reader 120, measurements collected in the most recent time period, or a predefined number of most recently collected measurements (e.g., 2, 3, etc.).

[0053] In one embodiment, the EIS can be configured as a "masked" or "unmasked" version. The masked version can be used for a period of time to establish a baseline, e.g., 3 days, 1 week, 2 weeks, etc. The masked version can limit the patient's access to the glucose readings and other information or features of the application. The patient can obtain glucose levels from the sensor control device 110 and record the glucose levels for subsequent evaluation by the HCP, but has limited access to the glucose information. For example, in some embodiments, during the mask period, the patient is not shown the glucose level readings, but can see the nature or type of various episodes (e.g., high glucose episode, low glucose episode, etc.). In another embodiment, during the mask period, neither the glucose readings nor information regarding the nature or type of episode is shown. For example, the patient can receive a notification that "an episode has occurred" without any detailed information about the episode.

[0054] The masked version encourages the patient to follow normal diet, exercise, and medication behaviors without the possible effects of knowing glucose levels or episode type. Receipt of data from the sensor control unit 110 occurs at frequent intervals, such as at least once every 8 hours or other time, to obtain multiple glucose level measurements. The EIS can prompt the patient to scan the sensor control unit 110 if desired, or use a reminder application.

[0055] The unmasked version of the EIS allows the user access to more features, sometimes all features. In certain embodiments, the masked and unmasked versions of the application do not exist simultaneously on the reader 120. In other embodiments, the masked and unmasked versions can exist simultaneously on the reader 120. In yet other embodiments, the two versions can exist within a single application and can be switched from one version to the other using a software switch that the HCP can access.

[0056] As previously mentioned, the EIS can be installed on the reader 120 in any manner. The glucose monitoring application can be installed on smartphones running various operating systems, such as ANDROID, iOS, etc. It can be installed using standard installation methods. For example, for an "ANDROID" based smartphone, it can be installed by emailing an apk file to the reader 120 and executing the file.

[0057] After installing the EIS (if necessary), the patient and the reader 120 can be registered with the server 130 and associated with each other. The patient can be given a temporary username or assigned a permanent username. The username must be unique, and if a temporary username is given, verification is required to ensure uniqueness when the patient requests a permanent username. The username can be an email address or another unique set of alphanumeric symbols. The reader 120 can be identified by any set of unique identifiers associated with the reader 120, such as an IMEI number or a MAC address.

[0058] 2 is a diagram illustrating an exemplary embodiment of a graphical user interface (GUI) display screen 200 that may be displayed upon activation of the EIS on the display 122 of the reader 120, which in this embodiment is a touch screen. Here, the display screen 200 is a home page 200 that may include a number of fields that the user may select. These fields may be selected by the user by touching (or, in another embodiment, clicking with a mouse cursor, etc.). For ease of reference, these fields will be referred to herein as buttons.

[0059] The home page 200 can include one or more of a menu button 248, a check glucose button 264, a logbook button 259, a daily graph button 265, a start sensor button 270, an episode button 275, an add note button 280, and a sensor status area 290. The sensor status area 290 indicates whether the sensor 104 is active, expired, or has an expiration time period. Exemplary functions of each home page button are described below.

[0060] To log into the server 130, the user clicks on the menu button 248 and selects the login field 249, shown in the exemplary embodiment of FIG. 3A, which displays a login screen 262, shown in the exemplary embodiment of FIG. 3B. The user can then enter the user's username and password to log into the server 130. In some embodiments, the user first logs in before the EIS automatically uploads data to the server 130. After logging in, pressing the menu button 248 displays different menu choices, as described below.

[0061] Returning to FIG. 2, after the sensor control device 110 is applied to the patient, the sensor 104 can be activated using the sensor start button 270. When the sensor 104 is replaced, for example after about 14 days, the activation steps are repeated. In one embodiment in which the reader 120 communicates with the sensor control device 120 via an NFC link, the reader 120 can be held within a close communication range of, for example, about 3 inches or less from the sensor control device 110. If necessary, the reader 120 can be moved closer to the sensor control device 110 until the reader 120 generates an audio and / or vibration or other indication of connection to indicate that communication has been established. After the audio or vibration occurs, the reader 120 can be held in place for about 1-2 seconds until another audio and / or vibration occurs, indicating that the sensor 104 (or the sensor control device 110) has been activated. In some embodiments, glucose levels are not measured and communicated to the reader 120 until a predetermined amount of time has elapsed to properly initialize the sensor 104 after activation. In some embodiments, this "warm-up period" is 60 minutes, although the length of time depends on the exact sensor and may be longer, shorter, or not required at all.

[0062] 2, after the sensor 104 is activated, the EIS can be used to check the glucose level. Selecting the check glucose button 264 causes the reader 120 to obtain one or more glucose readings from the sensor control device 110 using one of the communication methods described herein, such as the on-demand method. Additionally, readings can be automatically transmitted from the reader 120 to the server 130.

[0063] After the glucose level measurement has been transferred, the display 121 of the reader 120 may automatically display a results screen 422, as shown in the exemplary embodiment of FIGURE 4A. The results screen 422 may include one or more of a display of the current glucose level measurement 455, a trend arrow 456 indicating the direction and / or rate of change of the glucose level measurement, and a glucose graph 457. A notes button 458 may also be present on the results screen 422. In some embodiments, if the results are more than a predetermined amount of time old, such as three minutes, a warning message may be displayed indicating that the results are not up to date.

[0064] The glucose measurement 455 may be a measurement of the current glucose level up to a predetermined level, for example 350 mg / dl. It is noted that measurements above the predetermined level may be displayed as the predetermined level. The trend arrow 456 may be one of a number of indicators, for example five different relative arrows. In certain embodiments, an arrow pointing up may indicate that the glucose level measurement is rising at a predetermined high rate, for example, greater than 2 mg / dl per minute. An arrow pointing up and to the right may indicate that the glucose level measurement is rising at a predetermined moderate rate, for example, 1-2 mg / dl per minute. If the glucose level measurement is changing upwards or downwards at a predetermined low rate, for example, less than 1 mg / dl per minute, the arrow may point to the right. An arrow pointing down and to the right can indicate that the measured glucose level is declining at a predetermined moderate rate, e.g., 1-2 mg / dl per minute, and a downward arrow can indicate that the measured glucose level is declining at a predetermined rate, e.g., greater than 2 mg / dl per minute.

[0065] The glucose graph 457 may display glucose level measurements for a given time range, e.g., the last 8 hours, which may be increased or decreased by using the zoom buttons 459 on the reader 120 or standard two-finger zoom techniques. The time range may be shifted by dragging the plot left or right with a finger. The graph may display a symbol, e.g., a clock symbol, indicating that the time on the reader has been changed. Changing the time may result in gaps in the graph, duplicate measurements, or hidden data that the HCP, patient, and / or caregiver need to be aware of.

[0066] 4B shows an exemplary embodiment of a glucose graph 457 after pressing zoom button 459. Below the graph 457 is a dosing timeline 450 showing the times and amounts of fast acting insulin (top) and long acting insulin (bottom) administered during the displayed period, with numerical indicia indicating the respective doses, appropriately aligned to indicate the time of administration. Below the timeline 450 is a meal timeline 451 showing the times and amounts of meals or food ingested during the displayed period, with numerical indicia indicating carbohydrate intake, appropriately aligned to indicate the time of intake.

[0067] Notes can be used to track one or more behaviors such as food intake, insulin, medication, exercise, sleep, etc. FIG. 5 illustrates an exemplary embodiment of a note entry page 500. Notes can be entered from data collection on the logbook page, which can be accessed by pressing the note button 458 on the results screen 422, pressing the add note button 280 on the home page 200, and pressing the logbook button 259 on the home page 200. Notes can be added by scanning bar codes or chips, etc., of foods, etc. The note entry page 500 can have one or more checkmark fields to characterize notes as conveying information about food intake (field 581), one or more types of medications, such as fast acting insulin (field 582) and long acting insulin (field 583), exercise (field 584), medication (field 585), etc. The checkmark fields shown have empty boxes that, when touched by the user, change the field value back and forth between a yes value with a checkmark present and a no value (empty box) without a checkmark present. Other fields can also be used, such as checkmark fields or drop-down menus with more than two values.

[0068] More specific information regarding food and insulin amounts can be entered in input boxes 586 located below the corresponding checkmark fields. At least one free-form text box 587 can be present for entering textual notes regarding the user's activity (e.g., exercise time, dosage of specific medications, types of food ingested) or other circumstances the user wishes to record. Text can be entered via a keyboard (or a virtual keyboard on a touch screen) or verbally, e.g., using a voice recognition function. After the notes are entered, they can be saved and one or more identifiers, such as icons representing the added notes, are placed at the appropriate time on the graphs of the various glucose levels. For example, a meal graphic icon representing food ingested or a medication graphic icon representing an insulin infusion can be added to the daily graph 766 (see FIG. 7) or glucose graph 457 along with the intake or dosage amount.

[0069] Returning again to FIG. 2, pressing the logbook button 259 may open a logbook screen 600, an exemplary embodiment of which is shown in FIG. 6A. The logbook screen may include entries 661 for each data collection from the sensor control device 110 and additional notes. The date and time of each entry may be included along with the current glucose level, the directional rate of change arrow 456, and a time change symbol 457 and a note symbol 458. Selecting an entry may open a summary screen 601 with detailed information related to the selected entry, including a graph 455 showing the glucose level history around the time of the selected logbook entry, the directional rate of change arrow 456, notes 662, free form notes 663, and / or a user added image, an exemplary embodiment of which is shown in FIG. 6B.

[0070] Pressing the daily graph button 265 shown in FIG. 2 can open the daily graph page 700 shown in FIG. 7. The daily graph page 700 can include a graph 766 of glucose level measurements for a day 769 shown at the top of the page and / or user entered notes, e.g., graphs 450, 451 of timelines related to food intake and insulin use, identified by symbols. Icons 768 representing, e.g., exercise time, medication doses, etc., can also be shown on the glucose trace itself in the graph 766. The graphs can share the same horizontal time axis, graphically showing how glucose levels are affected by exercise, food, insulin, or medications. The time scale of the graph can be changed by pinching or spreading the graph with two fingers and shifted by dragging the graph left or right. The time increments on the graph can be adjusted, e.g., from 30 minutes to 9 hours, allowing a detailed view over, e.g., several hours, or an overview of, e.g., about a day and a half. Selecting any of the displayed symbols, for example, medication dosage, exercise, food intake, or insulin use, can open a pop-up screen that displays any notes entered for that date and time.

[0071] The daily graph 766 of glucose level measurements is similar to the glucose graph 457 of FIG. 4B. The daily graph 766 may display glucose level measurements up to a predetermined level, for example, 350 mg / dl. Note that measurements above the predetermined level may be displayed as the predetermined level. If data from the sensor control device 110 is not collected frequently enough, for example, at least once every 8 hours, gaps may appear in the graph 766. If the time on the reader 120 is changed, gaps, overlaps, or hidden data may occur along with the display of a clock symbol.

[0072] As mentioned above, adding notes is beneficial in determining patterns of glucose levels. However, it can be problematic for patients to remember to add notes, especially long after the event occurred. Additionally, reviewing the logbook to correlate specific activities in the notes with glucose levels can be very difficult for both patients and HCPs.

[0073] In some embodiments, episodes can be detected by the EIS when the reading device 120 receives a glucose level measurement. By adding notes and other information when a particular episode occurs, the ability to correlate specific actions with corresponding changes in glucose levels can be greatly improved. When an episode is detected, the EIS can prompt the patient to enter information, and the patient's responses to the prompts, as well as any other notes entered by the patient, can be used to evaluate actions that may have caused the change in glucose level.

[0074] Episode detection can be configured via the server 130 or the EIS user interface. The process can be similar for both. On the reader 120, from the EIS home page 200 (see FIG. 2), the menu button 248 can be selected. From the drop-down menu shown in FIG. 8, the settings button 852 can be selected to start a configuration wizard and open the daily events configuration screen 900 of FIG. 9A. Daily events can include breakfast, lunch, dinner, bedtime, and other events, and can be displayed with default times for each of these events in corresponding time buttons 985. Selecting the time buttons 985 allows the user (e.g., HCP, patient, and / or caregiver) to set these times to correspond to times common to diabetics, and the time periods used for certain displays described below.

[0075] After setting the time, selecting the next button 986a can open an episode setting screen 901, an exemplary embodiment of which is shown in FIG. 9B. In screen 901, episode types to be detected can be selected by selecting a checkbox 987 corresponding to the desired episode type. Episodes can include one or more of: bedtime, wakeup, actual or impending low episode (low glucose level, e.g., value below a predetermined value), actual or impending high episode (high glucose level, e.g., value above a predetermined value), actual or impending spike episode (e.g., glucose level rises by more than a predetermined rate, e.g., rises by more than 1 mg / dl or 2 mg / dl per minute), and actual or impending spike episode (e.g., glucose level falls by more than a predetermined rate, e.g., fall of more than 1 mg / dl or 2 mg / dl per minute). Episode triggers, e.g., level and rate of change, can be selected from predefined options or customized. Further episodes can be defined by the user of the EIS.

[0076] After selecting an episode type, selecting the next button 986b displays an event configuration screen 902, an exemplary embodiment of which is shown in FIG. 9C. In screen 902, a user can select the times at which episode detection may occur by selecting fields 988 (e.g., check boxes) corresponding to the times. The times may include one or more of after breakfast, after lunch, after dinner, at night, and times associated with customized events. Selecting the save button 989 can save the configuration and launch episode detection.

[0077] Episode detection is highly configurable and can include many options. Episode detection can be enabled for one or more of a selected time period, a specific day of the week, a specific day, week, or month, or elapsed time. When episode detection is enabled, data from the selected time period is used to detect an episode, but previous data outside the selected time period can be used to determine if and / or when an episode occurred. Episode detection can also include the option to prompt the patient with one or more predefined questions if an episode is detected. The predefined questions can be based on the detected episode type. Additionally, new questions can be added, for example, by the HCP, caregiver, patient, etc.

[0078] In some embodiments, the EIS may have an optional auto-configuration wizard that facilitates configuration of episode detection to best suit the patient's needs. Auto-configuration may be performed from either the reader 120 or the server 130, and episode detection may be enabled immediately after auto-configuration is complete or after review and manual implementation by the HCP, caregiver, and / or patient.

[0079] An exemplary embodiment of the optional auto-configuration 1000 is shown in the flow chart of FIG. 10. The flow chart begins in step 1010 with the patient wearing the sensor control device 110 for a predetermined period of time, e.g., 1-2 weeks, to establish a baseline glucose profile. In the first instance, where the patient wears the control device 110, the resulting profile will typically be the patient's first or "baseline" profile. Of course, the method can use any glucose profile, as the profile can be modified any number of times, such as during follow-up visits with a medical professional. During this time, EIS can be performed using glucose profile data collected in a masked mode where the glucose level measurements are not made known to the patient, or when the reader 120 is unmasked. In some embodiments, the user can enter notes during the auto-configuration period, while in other embodiments, the notes feature is disabled. In step 1020, at the end of the automatic configuration period, the data can be analyzed by the EIS or glucose monitoring application of the reader 120 to determine characteristics of the reference glucose profile in step 1010 using any of the techniques disclosed in U.S. Patent Application Publication Nos. 2014 / 0088393 A1 and 2014 / 0350369 A1, which are incorporated herein by reference.

[0080] In step 1030, key characteristics may be determined and rules for prioritization of these may be applied to determine which characteristics are most important to the patient. For example, the EIS may have an automatic time period enablement feature that determines whether to enable the EIS to detect one or more types of episodes based on, for example, the user's analyte level profile and / or historical times of relatively high occurrence of episodes. In some embodiments, this feature may enable the EIS to operate during a first time period to detect one type of episode (e.g., hypoglycemia) and during a second, different time period to detect a second, different type of episode (e.g., spike hyperglycemia). In other embodiments, this feature may enable the EIS to operate during a particular time period to detect all types of episodes. A combination of the two may also be implemented. If the EIS is enabled during a particular time period (e.g., 8:00 a.m.-12:00 p.m., 6:00 a.m.-8:00 a.m., etc.), the EIS may operate during that time each week to detect the desired episode types, while at all other times the EIS is disabled. This can be further subdivided to enable different time periods based on days of the week (e.g., 8AM-12PM only every Monday, Wednesday, and Friday, or 6AM-8AM only on weekends). In these and all embodiments described herein, the EIS can operate in real time, either continuously or recurringly, to detect episodes, or can operate only at specific times of day to detect episodes, as described herein.

[0081] In one exemplary embodiment, the prioritization rules or conditions for enabling specific time periods for low glucose episode detection are set as follows: Enable EIS during the first time period if: - the likelihood of low glucose during the first time period is "high"; and - if the likelihood of fluctuation below the median in the first time period is "high" or "medium"; Otherwise ("Else If"), enable EIS during the first time period if: - The likelihood of hypoglucose at all other times is not high, and - A moderate likelihood of low glucose during the first time period; and - The likelihood of fluctuation below the median in the first time period is "high" or "medium."

[0082] In another exemplary embodiment, the prioritization rules or conditions for enabling specific time periods for high glucose and spike episode detection are set as follows: Enable EIS during the first time period if: - the likelihood of hypoglucose at all other times is "low" and - the likelihood of the median glucose in the first time slot is "high"; and - if the likelihood of fluctuation below the median in the first time period is "high" or "medium"; Otherwise (e.g., "Else If"), enable EIS during the first time period if: - the likelihood of hypoglucose at all other times is "low" and - the likelihood of median glucose at all other times is "low" and - the median glucose likelihood in the first time slot is "moderate" and - The likelihood of fluctuation below the median in the first time period is "high" or "medium."

[0083] Similarly, other combinations of logic can be implemented in a manner similar to these examples. The severity of the risk or characteristic (e.g., low, medium, or high) can be determined by reference to the diabetic patient's most recent or other selected glucose profile, multiple selected glucose profiles, and / or other historical glucose data. Various techniques for defining a particular risk or characteristic (e.g., likelihood of low glucose, median glucose value, variation below the median) and quantifying the associated severity of the risk or condition (e.g., low, medium, or high), any of which may be used in embodiments described herein, are described in the following references, which are incorporated herein by reference in their entirety for all purposes: U.S. Patent Application Publication No. 2014 / 0187887, U.S. Patent Application Publication No. 2014 / 0188400, and U.S. Patent Application Publication No. 2014 / 0350369.

[0084] The prioritized characteristics can be used to determine appropriate settings for episode detection in step 1040. The configuration settings can be configured in the EIS in step 1050 and episode detection can begin. Automatic configuration 1000 of episode detection can be performed instead of or in addition to manual configuration. The HCP, caregiver, and / or patient can access the full range of configuration settings for further customization after automatic configuration 1000 is completed.

[0085] As discussed above, episode detection can be used with one or more in vivo analyte monitoring systems (both mask and non-mask modes) and in ex vivo systems coupled to in vivo systems, including, for example, an ex vivo system integrated with an in vivo system. In a non-mask analyte monitoring system, episode detection can occur a) each time a glucose level measurement is transferred from the sensor controller 110 to the reader 120, b) periodically, for example, every 5 or 15 minutes, or c) each time the user activates the EIS or the reader UI. Transfers can be patient initiated or automatically prompted by the EIS. Automatic transfer prompts for glucose level measurements can be configured to occur at predetermined times or intervals, for example, every day at bedtime or at least once every 8 hours.

[0086] Glucose level measurements taken since the most recent transfer can be transferred, and an episode detector in the EIS of the reader 120 can automatically process the data to detect an episode. If an episode is detected, the EIS can notify the patient that an episode has been detected and can prompt the patient to respond to questions regarding the episode. The patient's responses can be time-stamped and entered via one or more of a keyboard, a touch screen, a virtual keyboard such as a keyboard displayed on a touch screen, a voice recorder, and other input devices. The glucose level measurements and the patient's responses can be uploaded to the server 130.

[0087] Mask in vivo and ex vivo analyte monitoring systems function similarly to non-mask analyte monitoring systems, but may have some differences. For example, in mask systems, glucose level data may not be displayed to avoid influencing patient behavior. As with non-mask systems, episode detection may occur when glucose level measurements are transmitted to the reader 120, but in mask and ex vivo systems, the patient is not prompted that an episode has occurred, and may be prompted to respond to questions, including, for example, questions about activity and status when the episode occurred. To further reduce the impact on patient behavior, episode detection may be performed using glucose level measurements for a predefined period of time, such as, for example, from 24 hours ago to the current time, or from 24 hours ago to 2 hours before the current time.

[0088] In the ex vivo system, glucose level measurements can be added manually to the EIS or wirelessly transmitted to the EIS if the ex vivo system is equipped with communication support. Episode detection is performed on the data entered into the EIS and, if an episode is detected, the patient is prompted to respond to questions regarding the episode. The patient's responses can be time-stamped and entered via a touch screen and / or voice recorder. The glucose level measurements and patient responses can be uploaded to the server 130. In certain embodiments, including integration, the in vitro measurement system can be coupled to an in vivo system. For example, the ex vivo test strip port and both the circuitry for the in vivo and ex vivo measurements can be housed in the in vivo housing. In these cases, episode detection and patient response entry functionality can be added to the integrated system.

[0089] Episode detection can also be performed in a glucose monitoring application. The episode detector can use a series of glucose level measurements and configuration parameters as input. Using selected configuration parameters, glucose level measurements can be repeatedly examined to look for patterns and define criteria for an episode. Episodes can be detected based on the defined criteria and displayed on a results screen. When the episode detector algorithm is active, glucose data preceding the period of interest can be included as input to ensure accurate episode detection and start times, especially for episodes that may span the start time of the period of interest. Additionally, patient responses to questions regarding detected episodes can be stored in both the reading device 120 and the device running the EIS.

[0090] Both the glucose monitoring application and the EIS can operate on the same set of glucose level measurements. By running independent episode detection algorithms in both systems, the glucose monitoring application can be configured to detect a subset of the episodes detected by the EIS, or the EIS can be configured to detect a subset of the episodes detected by the glucose monitoring application. It is possible to identify the most clinically meaningful subset of episodes to which the patient is eligible to respond without overwhelming the patient to respond to every detectable episode. The EIS can detect all episodes, and as the patient becomes better able to control their glucose levels based on their behavior, new episodes can be added or replaced to those in the subset detected by the glucose monitoring application to further improve the patient's control of their glucose levels.

[0091] Because the glucose monitoring application and the EIS may have different configuration settings, detected episodes are not forwarded from the glucose monitoring application to the EIS. In some embodiments, one or more of the glucose data and the patient's response and a timestamp are forwarded. The EIS can run an episode detection algorithm and match the patient's response to the detected episode based on the timestamp. Additionally, the EIS can run routines to identify and characterize new episodes.

[0092] As previously discussed, if one or more episodes have been detected within the last predetermined time period, e.g., the last 8 hours, the patient may be notified by the EIS and displayed in a results screen 1122, an exemplary embodiment of which is shown in FIG. 11. Results screen 1122 is similar in many respects to results screen 422. In addition to a current glucose reading 455, the screen may include one or more of a trend arrow 456, a glucose graph 457, and a detected episodes button 1190. Selection of the detected episodes button 1190 may open one or a series of episode response screens that display questions related to the detected episodes. For each detected episode, a separate episode response screen may be displayed; for example, if three episodes have been detected, a series of three response screens may be presented, and the user may process each in turn.

[0093] In another embodiment, a "notification" feature, such as is commonly built into smartphone operating systems, can be used to provide the user with a mechanism to notify the user of an episode and activate the episode response screen. Additionally, both the detect episode button and the notification feature can be used simultaneously.

[0094] 12A illustrates an exemplary embodiment of an episode response screen 1210. Here, the screen 1210 includes an area 1291 where the detected episode type is displayed. A graph 1292 of recent glucose data may be displayed, including a highlighted portion 1293 of the episode, where the highlight is a shading of the space under the graph curve, which may be a different color than the curve itself. In some embodiments, the graph 1292 may be similar to the graph 766 described above, and may also include a medication timeline 450 and a meal timeline 451, which may be displayed above or below the graph 1292. An area 1299 of glucose values ​​within the graph are considered to be normal or within an acceptable range, and may be indicated by a drawn line or shading 1299, or the like.

[0095] Questions related to the episode may be displayed in area 1294, and the response screen 1210 may include a selection list 1298 of possible responses (e.g., reasons or reactions), each with a corresponding checkmark field (e.g., checkbox) for selecting that response. If there are multiple questions related to the episode, a selection list 1298 for each question may be included, each configured as a drop-down menu. In addition to the predefined responses, a free-form text entry field 1296 may be provided for custom responses (e.g., responses using terminology selected at the user's sole discretion). If the patient adds a custom response in the text entry field 1296, the custom response may be automatically displayed as a response along with the selected predefined response.

[0096] In another embodiment, the user is not provided with the option or ability to create custom responses by the mobile application (which may be prevented in some embodiments even in web-based software). Additional fields may be provided in which more detailed information about the episode may be added, such as free text notes, if desired. However, in many embodiments, the user is still required to select a pre-defined option or response from each of one or more presented selection lists (e.g., at least one response to each question presented must be selected from a selection list, and in some embodiments the user does not have the option to add new selection list responses or customize the selection lists, except for deleting selection list responses that do not apply to the user as described herein).

[0097] Diabetes (or other medical condition) management techniques can be improved by embodiments that do not offer the user the option or ability to input a custom response, but rather have the user select from a pre-defined selection list of options. These embodiments can increase the likelihood that the user will consider which response is most appropriate, e.g., the most likely cause that led to the occurrence of the episode. This is important because consideration of potential causes of an episode (or other pertinent questions about the episode) is often most accurate if done contemporaneously (or shortly after) with the occurrence of the episode itself. Using pre-defined selection list responses can result in generalized (avoiding over-specificity) and consistent responses, which can aid and simplify classification of responses and analysis of data at a later stage. By avoiding custom responses, the user can avoid responses that may not actually answer the question. For example, in response to a question about what caused the episode, the user might return a custom response that is just a description of what they were doing when the episode occurred, perhaps to save and consider later. The user can still take such measures via a notes entry field, but forcing the user to respond to a selection list of potential causes can also force consideration of the problem in the present moment, which may be best.

[0098] In certain embodiments, the user can choose to add the customized response to the selection list 1298 of predefined responses, in which case the customized response will be displayed the next time the same type of episode occurs. In other embodiments, the customized response is automatically added to the selection list 1298.

[0099] Additionally, responses that are not applicable to a patient may, in this embodiment, be removed from the selection list 1298 by choosing to delete that response by clicking on the associated delete button 1297. A deleted response will not appear in subsequent instances of displaying that selection list.

[0100] If there are more responses than can fit on the episode response screen 1210, the hidden responses may be scrolled down the screen or viewed on additional screens. After all questions for an episode have been answered, the next episode detected during the unanswered period is displayed on the results screen 1100. This process of entering responses for an episode may be repeated for each episode detected that has not previously been responded to during the period. In some embodiments, only the most recent episode may generate a prompt to obtain a response. If a response has already been obtained for the most recent episode, the system may not prompt for a response again.

[0101] By allowing customization of the selection list 1298, the request for and receipt of input from a particular user is customized for that user. The amount of burden or effort that a user subjectively believes is required to record information about an episode is relatively reduced. This in turn reduces the user's subjective resistance to inputting information and increases usage by the user, which in turn improves the evaluation mechanism of the system and provides more robust data and more accurate feedback to the user or HCP that, if acted upon, can reduce glucose variability and improve the user's quality of life.

[0102] Several questions can be associated with a particular episode. Each question can be displayed on a respective episode response screen. FIGS. 12A-12C show non-limiting examples of response screens for a detected episode "spike". FIG. 12A shows a first screen with the question 1294 "What is the suspected cause?" and two pre-defined responses selected. FIG. 12B shows a second screen with the question "Have you had any symptoms of the spike?" and one pre-defined response selected. FIG. 12C shows a third screen with the question "Have you treated the spike?" and one pre-defined response selected.

[0103] Depending on the episode detected, there may be fewer or more screens and questions. The questions and predetermined responses may vary depending on the episode detected, but in many embodiments, a first or second screen displayed queries the user regarding the cause of the episode, another first or second screen displayed queries the user regarding symptoms associated with the episode, and a third screen queries the user regarding what treatment, if any, was administered.

[0104] If all episodes have been responded to and no new episodes are detected, a time of day question can be asked if the time period is associated with bedtime or wake-up time. The time of day question can be asked once per day for a time period.

[0105] Returning to FIG. 2, a list of all detected episodes can be displayed by selecting the Episode button 275. FIG. 13 illustrates an exemplary embodiment of an episode list 1300. One or more of the following may be displayed: episode type 1391, date and time of the episode 1392, a color-coded field 1393 for the episode type, and an icon 1394, 1395 indicating whether a response has been recorded. In FIG. 13, a response indicator 1394, e.g., an eye icon, may indicate that the patient has recorded a response to a question about the episode, and a non-response indicator 1395, e.g., a checklist icon, may indicate that the patient has not recorded a response. By clicking Enter Episode, the patient can view previously selected responses to the episode (FIGS. 12A-C) and enter a response if the patient has not yet responded.

[0106] Several reports can be generated to help patients, caregivers and HCPs understand how the patient's behaviors affect the episode and mitigate the impact of the behaviors. The reports can be generated on the reading device 120 using locally stored data or can be generated on the server 130 and downloaded to the reading device 120 or a printer.

[0107] Returning to FIG. 8, selecting the Response Report button 853 can open an exemplary Response Report screen 1400, an exemplary embodiment of which is shown in FIG. 14A, which displays the types of episodes that have responses recorded 1410. Button 1420 can be used to adjust the date range. Clicking on the drop down button 1430 can expand the Response Report screen, an exemplary embodiment of which is shown in FIG. 14B, which displays one or more questions 1440 associated with the episode type, the responses entered by the patient 1460, and the total number of times the response was selected 1450.

[0108] Clicking on a response of interest 1460, e.g., "Meal bolus too early or late," may display a new screen 1500, an exemplary embodiment of which is shown in FIG. 15, that may include a graph 1510 of glucose levels and an episode indicator 1520, e.g., a colored dot (as shown) or a vertical line (not shown). The graph 1510 may display the most recent day on which the selected response occurred. If the selected response occurred on other days, a directional indicator 1530 is displayed, and the other days may be displayed by clicking on the indicator 1530.

[0109] Web-accessible Episode Investigation Software (EIS) With respect to a computing device, such as local computer 150 or remote computer 160, the EIS is described as a software package served from server 130 and accessible by a web browser on computing device 150 or 160. Mobile devices (e.g., tablets and smartphones) are considered a subset of such computing devices, although they often have web browsers and do not need to access the EIS via a web browser if the EIS is already installed on the mobile device as an app.

[0110] When the analyte level data is transmitted by the sensor controller 110 to the reader 120, the reader 120 can be programmed to upload the data (either as raw data in the same general format as received from the sensor controller 110, or as algorithmically processed data (e.g., using proprietary data processing algorithms that may apply temperature compensation or other calibrations to the data)) to a database or server 130 via wireless and / or wired communication paths.

[0111] After uploading (and the server 130 performing any necessary data processing that was not performed by the reader 120), the data can be stored and associated with the diabetic patient so that the diabetic patient, HCP, and / or caregiver (or others) can access the data using a web browser that presents the EIS. In many embodiments, the EIS can present the data in different report formats designed to convey the underlying information in an improved and nuanced way that allows the user to easily understand the information and use it as a tool to identify the underlying causes of glucose variability.

[0112] An administrator, a technical person responsible for managing the server 130 and / or the accounts associated therewith, can provide a URL for a web browser to use to access the server 130. The administrator can be responsible for locking and unlocking accounts. There can be multiple user account types, including those associated with administrators, those associated with HCPs, and those associated with diabetics or caregivers. Each account type can have a different set of features available to the person assigned to that account type. As already described to some extent herein, an account can be set up by defining a user ID and password. To access the EIS, a user enters their user ID and password to access the account and associated features. A user can have multiple different account types.

[0113] An administrator is typically a person with clinical management responsibilities. An administrator's function is to add HCP accounts. In many embodiments, an administrator does not have access to diabetic patients or patient personal data or reports. An HCP user can add patient accounts to the system. In many embodiments, an HCP user has full access to patient data and reports. An HCP user can provide an initial user ID and password to the patient that the patient uses to access the EIS data and reports via a web browser and to configure the EIS on the reader 120 to automatically upload data to the server 130.

[0114] Once logged in, the HCP user can select a particular patient from a patient list of patients associated with that HCP. After selecting a patient, the HCP can create a review session for that patient, typically by selecting the option to create a new session from the home screen. One occasion where this action might be taken is during a meeting or visit between the HCP (or his / her representative) and the patient.

[0115] An exemplary embodiment of a home screen or page 1600 that may be displayed on the display of a computing device (e.g., 120, 150, 160) is shown in Figure 16. This home screen may be displayed to an HCP user once a particular patient is selected, and may also be displayed to a patient user once logged in. In this embodiment, the EIS is referred to as a SUGAR SLEUTH, although the subject matter described herein is not limited to this brand.

[0116] On the left side of the home screen 1600 is a navigation bar 1610. A session can be created by selecting a create session button 1602. In some embodiments, the create session button may only be displayed when new data not yet seen via the EIS has been uploaded to the server 130 or has been uploaded since the date and time the most recent session was created. When a new session 1612 is created, its date and / or time can be added to the navigation bar 1610 (e.g., 04-Nov-2015) and a report can be generated for this session using all historical data up to that date and / or time.

[0117] A user (patient, caregiver, or HCP) can generate reports based on the data collected and uploaded to the server 130. The navigation bar 1610 can provide links to each report type that can be generated within each session 1612. Each time a new session 1612 is created, a new set of report links can be displayed at the top of the navigation bar 1610 along with the session identifier 1612. In the illustrated embodiment, the reports available for generation include a Glucose Pattern Insight (GPI) report, a Daily report, an Episode Overlay report, an Episode Summary report, and a Response report. These various report types are described in further detail herein.

[0118] Previous sessions 1612 (not shown here) may also be displayed below the current session 1612. Reports generated in these previous sessions 1612 may be viewed and edited, but in many embodiments are based only on glucose data available up to the date and / or time the previous session was created.

[0119] A new report may be generated by selecting the appropriate field 1614, which in this embodiment is a plus sign (+) next to the title of each report. After a new report is generated, a link to it is placed in the navigation bar 1610 in a location associated with (e.g., below) the particular session 1612. To the extent that multiple reports of a particular type have been generated, the list of those reports may be expanded or collapsed by selecting that field 1616.

[0120] Also present on the home screen 1600 is a selectable field 1604 for changing report settings, here labeled Daily Event / Analysis Settings. For HCP users, a selectable field 1606 for returning to the patient list screen may also be provided. The navigation bar 1610, field 1602, and field 1606 are available on all report screens, as described below.

[0121] Each report generated with the EIS can be based on one or more days of glucose data from a diabetic patient. The EIS provides a graphical interactive data selection tool to assist the user in easily (and quickly) identifying the days that contain the most relevant data for analysis. These days can then be individually selected and used to run a report.

[0122] An exemplary embodiment of a data selection tool 1700 is shown in Figures 17A-B. The data selection tool 1700 may be displayed to a user upon selecting a report generation option (such as by selecting field 1614 in Figure 16) or at another point in the report generation process where selection of an appropriate data set is desired.

[0123] In this embodiment, the data selection tool 1700 displays data arranged in a grid, where each subdivision area 1703 (e.g., each unit or box) in the grid 1702, which may be bounded or infinite, corresponds to a day, and a row shows the number of days in a week (e.g., Sunday at the left end and Saturday at the right end). In FIG. 17A, an example of an area 1703 is shown in a dashed box. The number of days per row is not limited to seven days, and any number of days greater than one can be displayed per row. Any number of rows greater than one (e.g., 1, 2, 3, 4, 5, 6 rows, etc.) can be displayed simultaneously. A vertical scroll bar 1704 can assist the user in scrolling through the many rows that can be displayed, the upper limit of which can be determined by the number of weeks for which data is available. For example, ten weeks of data can be displayed, but five rows of data may be displayed on the screen at the same time, but the user can scroll through the ten weeks of data with the vertical scroll bar.

[0124] The top and bottom rows may be the latest or current week and the oldest week, respectively, both measured from the date and / or time of the session 1612, with rows arranged in successively older chronological order placed between them. Alternatively, the weeks may be displayed in the reverse manner, like a normal calendar, with the earliest week in time at the top and each subsequent row below being one week later in time.

[0125] In another embodiment, the grid can be configured to display multiple days vertically in a single column, for example with the most recent day at the top and the oldest day at the bottom, or vice versa, but this arrangement does not allow many days to be displayed simultaneously.

[0126] Within each unit 1703 of the grid is a graphical display 1706 of the glucose (or other analyte) data for a particular day. Labels 1708 indicating the day of the week and / or date may also be displayed within or adjacent to the unit 1703. The graphical display, or graph 1706, may have an appearance similar to the graph 1292 described in connection with Figures 12A-C, or other glucose graphs described herein, including the references incorporated herein. Days for which no data is displayed, such as day 1714, may be blank, grayed out, shaded, or have missing data.

[0127] The graphs 1706 may include traces 1710 of glucose values ​​for the corresponding days, either as a series of measurement data points as shown, or as a dashed or continuous line. If each unit 1703 is immediately adjacent to one another, the traces 1710 may continue from one day to the next within each row, as shown. Each graph 1706 may include indications, or markers 1712, for each episode detected on the corresponding day. The markers 1712 may have any desired shape (e.g., circle, oval, line, curve, square, polygon, triangle, etc.), color, or appearance. For example, the markers 1712 may be vertical lines as shown, or the shaded areas under the traces shown in FIG. 12A.

[0128] Any combination of shapes, colors, and appearances can be used for the markers 1712. For example, a first type of episode (e.g., high glucose) can be indicated by a first marker 1712-1 of a first shape and / or color, and a second, different type of episode (e.g., low glucose) can be indicated by a second marker 1712-2 of the same shape but different color. Alternatively, one color can be used to indicate all types of episodes, where different episode types are indicated by shapes. In yet another example, one shape can be used to indicate all types of episodes, or different shapes can be used to indicate different episode types, but in each case, severity is indicated by different colors (e.g., yellow for mild, orange for moderate, red for severe), or darkness or opacity of one color. Severity can also be indicated by the size of the marker 1712 (e.g., the more severe the episode, the thicker the vertical line or the larger the shape, etc.) or other different shapes or appearances of the marker 1712.

[0129] The user can then select each day in the grid 1702 that has data that the user would like to use to generate a report. As can be seen from FIG. 17A, the tool 1700 provides an efficient overview of the user's large amount of glucose data, potentially spanning a long period of time. This provides an improvement in that the user can more easily and efficiently select data to generate a report. For example, because the daily data is displayed in graphical form, the user can more efficiently identify days that have repeating patterns or trends in the glucose trace 1710 and select them immediately and easily. Clusters of days where a particular type of episode occurs or where episodes occur at a particular time can be easily identified and selected. Similarly, days with the lowest glucose variability and / or episode occurrence can be easily identified and selected to search for trends in the diabetic's behavior on these days.

[0130] Additionally, embodiments of tool 1700 described herein provide improvements in the field of diabetes care, as tool 1700 can identify and select the most appropriate dataset in a manner that reduces user burden as compared to conventional approaches, thereby increasing the likelihood that a user can use EIS to investigate and identify causes of glucose fluctuations and / or episodes, and ameliorate or treat those causes and improve the health and lifestyle of diabetic or other patients.

[0131] Days can be selected directly on the displayed grid by touching each day (on a touch screen display) or by selecting each day or group of days with the mouse cursor. In either case, selecting a particular day selects only that day (and deselects any previously selected day or days).

[0132] For example, multiple days can be selected by holding a first key (e.g., the control key) and selecting each desired day, in which case all selected days remain selected. A group of days can be selected by holding down a second key (the shift key) and clicking the first and last day in the series, in which case each intervening day in the range is automatically selected by the EIS. The EIS can be configured to prevent the selection of days that do not have data. For reports that rely on a single day's worth of data, such as daily reports, or on a limited number of days' data, the EIS can be configured to allow selection of only up to a limited number of days.

[0133] An exemplary embodiment of a selected day group 1720 is shown in FIG. 17B, where each selected day is shown with a partially transparent color or shading applied. Alternative display methods, such as placing a prominent border around the selected days, may also be used. As shown, the user may select a non-contiguous range of days to be used in generating the report. In some embodiments, a default range of days may be selected, such as the last 7 days, the last 10 days, the last 14 days, etc. Once the desired day or days have been selected, the user may generate a report by selecting the generate report button 1722.

[0134] Many exemplary reports have been and will be described herein. These exemplary reports are shown and described in a format that can provide useful results, but are not intended to limit the precise manner in which the information is displayed and the user is able to interact with them. Thus, all features (graphs, icons, notes, tables, lists, traces, indicators, selectable fields or buttons, drop-down lists, responses, information arrangement, information ordering, etc.) can be modified from the manner shown and described herein and still fall within the scope of this disclosure. Furthermore, unless otherwise stated or logically impractical or impossible, any feature can be added to (or omitted from) any of the different report types and still fall within the scope of this disclosure.

[0135] 18A illustrates an exemplary embodiment of a daily report 1800, which, like all other reports described herein, can be displayed on a computing device display using, for example, a web browser. The daily report 1800 can have a graph 1806 that includes a glucose trace 1710 and one or more color-coded markers 1712 of episodes that occurred during the plotted time period, which is generally 24 hours or less. Here, marker 1712-1 is a shaded area below trace 1710 that indicates a rapid glucose rise episode (e.g., a percentage rise above a minimum duration threshold). Marker 1712-2 is a shaded box that indicates a low glucose, or hypoglycemic, episode (e.g., when the user's analyte level falls below a threshold).

[0136] Alongside the glucose trace 1710 are various icons 1804 indicating notes (as described with respect to FIG. 6B) that were entered for that day. As previously mentioned, each note icon 1806 can include one or more of exercise, food and / or fluid consumption, medication administration (e.g., rapid acting (RA) insulin or long acting (LA) insulin), the presence of a free form note, and bedtime, to name a few. Hovering the cursor over a particular note icon (or touching the note icon, in the case of a touch screen) can display an overlay pop-up window that includes additional information about the note (e.g., duration of the event, time the event occurred, calories burned, type of food or drink consumed, carbohydrate or calorie intake, fluid intake, amount and type of medication, actual free form note, etc.).

[0137] Icons 1805 indicating normal times for events to occur may also be displayed, which may be set and adjusted by the user. Here, three meal icons (e.g., in the shape of an apple) indicate breakfast, lunch, and dinner. Also shown is a sleep icon (e.g., in the shape of a person in bed) indicating the normal time the user would go to bed at night.

[0138] For example, the daily report 1800 below the graphical display 1806 may show a table 1807 listing and describing each episode. The table 1807 may include the time the episode occurred, the episode type, any information about the episode entered by the user, such as suspected cause, symptoms, and treatment (see, e.g., description of FIGS. 12A-C). The table or list may also show note information for any notes entered for that day, and other recorded information, such as blood glucose levels. Each entry in the table 1807 may correspond to a marker 1712 in the graph that indicates the episode. In the table 1807, the user may categorize the episodes and responses by day, by episode timestamp, by episode type, or by response.

[0139] Navigation buttons 1802 (here labeled "Back" and "Next") allow the user to scroll forward or back a day in time, with days that have no data (if any) being automatically skipped by the EIS. Selection of one of the buttons 1802 will result in the creation of a daily report 1800 for either the next day or the previous day. As each new daily report is displayed, it can be added to the appropriate position in the navigation bar 1610.

[0140] FIG. 18B shows another embodiment of a daily report 1806 and an episode table 1807. In this embodiment, there is an interactive filter 1810 between the graph 1806 and the table 1807. The filter 1810 allows the user to select the information to display in the table 1807 based on the location of a time information indicia in the graph 1806. Here, the indicia is the episode indicator 1712, and the information displayed in the table 1807 is the date and time of each episode, the type of each episode, and the recorded responses to questions posed about the episode. Other information such as notes, photos, etc. can also be displayed. The filter 1810 has an axis 1820 with two markers 1812 and 1814 that can be slid along the axis by the user in various ways. For example, the markers 1812 and 1814 can be slid directly, for example, by touching or dragging on a touch screen, or by clicking and dragging with a mouse cursor. The position of marker 1812 along axis 1820 sets the earliest time for the filtering function, and the position of marker 1814 along axis 1820 sets the latest time for the filtering function.

[0141] Here, marker 1812 is placed at 2 PM (as shown, a label indicating the placement time of each marker can be optionally displayed) and marker 1814 is placed at 6 PM. This placement serves to filter all episodes, notes, and other information occurring before 2 PM and after 6 PM in the daily graph 1806 from being included in table 1807. Thus, only episodes and notes occurring between 2 PM and 6 PM (inclusive or exclusive), in this embodiment only two episodes, are displayed in table 1807. Thus, filter 1810 can reduce the amount of information displayed in 1807 and allow the user to focus on episodes occurring during a particular time period. This can be important for days when a relatively large number of episodes are detected, such as in FIG. 18B where approximately 14 episodes 1712 are shown in graph 1806.

[0142] Markers 1812 and 1814 may also be moved indirectly by selecting fields 1816 and / or 1818, which slide markers 1812 and 1814 simultaneously to the left (field 1816) or right (field 1818) so that both markers 1812 and 1814 maintain a fixed interval (e.g., 4 hours as shown). Axis 1820 may have a number of equally spaced discrete landing positions 1822, and the placement and movement of markers 1812 and 1814 is limited to these landing positions. For example, clicking and dragging marker 1812 to the left causes marker 1812 to jump from one landing position 1822 to the next. Similarly, selecting field 1816 causes both markers 1812 and 1814 to move one position 1822 to the left, changing their respective times from 2:00 PM and 6:00 PM to 1:00 PM and 5:00 PM.

[0143] In this embodiment, each landing location 1822 is one hour apart, although larger or smaller intervals can be used. In various different embodiments, the intervals between all locations 1822 can be 10 minutes, 15 minutes, 30 minutes, 60 minutes, 90 minutes, and 120 minutes, to name a few. In another embodiment, there are no landing locations 1822, and the markers 1812 and 1814 can take any position on the axis 1820 to model a continuous or analog movement from the user's perspective. An embodiment in which there are landing locations 1822 can be referred to as having a non-analog movement.

[0144] Filter 1810 may be included in any graph or other data representation described herein that has an associated table, such as table 1807 that lists episodes. The use of filter 1810 is not limited to analyte level graphs and episode indicators, but rather may be used to filter based on any type of information present in the report, such as exercise indicators, meal indicators, sleep indicators, drug dosage indicators (e.g., LA insulin and / or RA insulin), text notes or comments, or segments of the data display of graph 1806 that do not have an overlay indicator (e.g., the analyte data itself). Additionally, filter 1810 may be used in any instance, including non-medical applications, where it is desirable to focus the display of information from one data structure or visual representation (e.g., table 1807) onto one or a portion of another data structure or visual representation (e.g., graph 1806).

[0145] In the embodiment of FIG. 18B, the filters 1810 are oriented horizontally (e.g., along the X-axis), however, alternative embodiments may utilize filters 1810 oriented vertically (e.g., along the Y-axis), filters 1810 oriented in a third direction perpendicular to the horizontal and vertical directions (e.g., along the Z-axis), and any combination thereof. Additionally, multiple filters 1810 may be used oriented in the same direction, such as a dual-scale graph with a left Y-scale representing the magnitude of one type of data and a right Y-scale representing the magnitude of a different type of data. Each filter 1810 may be adjusted independently with respect to each other filter 1810, and adjustment of each of the filters 1810 may adjust the information displayed in the dependent visual representation (e.g., table 1807) in real time. Thus, any number of one or more filters 1810 may be provided in a wide variety of different ways.

[0146] 19A-B show an exemplary embodiment of a GPI report 1900, including a first region 1902 showing the user's ambulatory glucose profile (AGP), and a second region 1904 showing the user's assessment of the severity of a particular condition related to diabetes. An example of a GPI report including an AGP (referred to as "Advanced Daily Patterns (ADP)") is described in detail in U.S. Patent Publication No. 2014 / 0188400, the entire contents of which are incorporated herein by reference for all purposes. A brief description of the GPI report 1900 will now be provided in light of this incorporated specification.

[0147] The AGP region 1902 may include a plot of glucose values ​​for a selected day over a typical time scale. A trace of central tendency (e.g., median or mean) 1910 is shown. Surrounding the trace 1910 is a region 1912 corresponding to data values ​​that fall within a percentile range of central tendency (e.g., the 25th percentile of the data point to the 75th percentile of the data point). Adjacent to the region 1912 is a second region 1914 corresponding to data values ​​that fall within a broader percentile range of central tendency (e.g., the 10th percentile of the data point to the 90th percentile of the data point). The regions 1912 and 1914 may be shown in any desired manner, such as with different lines, colors, or shading, to name a few. The regions 1912 and 1914 may be displayed as solid lines or as individual data points, such as in the embodiment shown in FIG. 19B. Also shown in AGP area 1902 is the user's central tendency goal (herein "median goal") and the user's low glucose threshold, which can be set and adjusted by the user (e.g., diabetic or HCP).

[0148] Area 1904 is a table with icons 1916 that identify the level of severity of the corresponding condition during a typical day's time period. Any number of conditions, one or more, may be listed and cross-referenced with any number of icons, one or more, corresponding to one or more time periods. In this example, three conditions are listed vertically (e.g., along the Y-axis): (1) possible low glucose (hypoglycemia), (2) median glucose value compared to median glucose target, and (3) variation below the median (e.g., difference in glucose values ​​between the median and the 10th percentile). A different measure of central tendency, such as the mean, may be used for these conditions instead of the median.

[0149] In this example, the day is subdivided into five time periods that need not be of equal length and that the user can set to correspond to the user's lifestyle (e.g., to coincide with eating and sleeping). These time periods can be aligned (e.g., use the same time axis) with the AGP 1902 for ease of reference. Icons 1916 in the table can graphically represent the level of severity of the condition during that time period, as indicated by the key in area 1908.

[0150] In this example, the diabetic patient experiences high sub-median variability in relation to the diabetic patient's goals set in the EIS between 12 noon and 3 a.m. There is also a high probability of low glucose during this time period.

[0151] Area 1906 may display a notification of one or more high conditions and list potential causes of the high condition. Here, area 1906 displays a notification of a high below median variation and the possible contributing factors.

[0152] FIG. 19B illustrates another embodiment of a GPI report 1900 using the same data as FIG. 19A, but presented in a different way. Here, each data point is shown in AGP region 1902. Data points 1920 that are below a low threshold can be highlighted (e.g., colored red). One or more of regions 1912 and 1914 can be omitted (here region 1914 is shown, but region 1912 is omitted). Additional highlighting or indication can be used to indicate regions 1922 where one of the tracking conditions in region 1904 is determined to be high. Here, points associated with high sub-median variability are indicated by shaded regions 1922 at the corresponding time periods.

[0153] 20 illustrates an embodiment of an episode summary report 2000 that can assist in identifying episode patterns that may be recurring over a particular time period. Here, the episode summary report 2000 includes a modal 24-hour graph 2004 of glucose levels over a given time period, e.g., the entire 24-hour period, for each selected day. Also displayed within the graph 2004 are markers placed at the episode occurrence times and durations for the selected data set.

[0154] The episode summary report 2000 may also include a table 2002 showing each episode type (e.g., low glucose, high glucose, spike) and the number of instances when that episode type occurred during a particular time period (e.g., the same time period shown in the condition assessment area 1904, both of which may be aligned to the time axis of the graph 2004). The total occurrences of episodes during each time period are also shown. This tabular display 2002 allows the user to easily understand patterns of episode types occurring at particular times. A selectable field 2006 (e.g., a checkbox) is present adjacent to each episode total. Selection of this field may cause the graph 2004 to show (check the checkbox) or hide (uncheck the checkbox) each marker of that type during that time period, further assisting the user in identifying patterns or times when particular episode types are most likely to occur.

[0155] In some embodiments of the EIS, an overnight episode summary report (not shown) may also be provided in a manner similar to the episode summary report 2000. The overnight summary report may differ in that it focuses on a particular time period, e.g., a nighttime swath, whereas the episode summary report 2000 may span a longer time period, e.g., 24 hours, in most embodiments. The overnight episode summary report may have a table that may include one or more of the following: the number of occurrences of each episode type or risk factor during the night, a plot of glucose level measurements, and an indication of episodes and risk factors. Non-limiting examples of overnight low glucose risk factors include a) a bolus within 3 hours of going to bed, b) physical activity in the afternoon or evening, c) alcohol consumption, etc. Non-limiting examples of overnight high glucose risk factors include a) a high carbohydrate dinner or snack, b) a high fat dinner or snack, c) eating out at a restaurant, etc.

[0156] FIG. 21 illustrates an exemplary embodiment of an episode overlay report 2100. In response to a question asked when a particular episode is detected (see discussion of FIGS. 12A-C), an episode aligned modal graph or plot 2102 of glucose level measurements for each episode with an identified response for each patient-specified question can be displayed. The time of occurrence of each episode can be aligned to a central axis (e.g., 0:00) and glucose level measurements at predetermined times before and after the episode, e.g., 1-12 hours, can be graphed or plotted. The episode overlay report 2000 helps to show the impact on the user's glucose levels each time a particular suspected cause leading to an episode occurs.

[0157] For example, a user may have entered a suspected cause for each episode detected within a selected date range. A separate graph 2102 can be generated for each suspected cause, including glucose data associated with each episode for which that suspected cause was identified. Although not shown here, graphs 2102 can similarly be generated for each identified symptom, treatment, or other response associated with a question posed about the episode.

[0158] In this embodiment, four graphs are shown: graph 2102-1, which includes glucose data for each episode where the suspected cause is "depression" and is identified by the user; graph 2102-2, which includes glucose data for each episode where the suspected cause is "no treatment" and is identified by the user; graph 2102-3, which includes glucose data for each episode where the suspected cause is "unhealthy hunger" and is identified by the user; and graph 2102-4, which includes glucose data for each episode where the suspected cause is "exercise" and is identified by the user (one set of glucose data is shown since only one such episode is eligible). Graphs 2102 may be arranged in an order such that responses containing the most eligible episodes are listed at the top and responses containing the fewest eligible episodes are listed at the bottom.

[0159] FIG. 22A illustrates an exemplary embodiment of a response report 2200 that can assist a user in quickly identifying days of interest, i.e., days on which episodes occurred most frequently. This report helps replace the habit of daily searching to find problems (e.g., reducing the need for HCP discernment); rather, the report aggregates the episodic responses recorded by the patient and highlights the most frequently occurring responses that indicate self-care behavior problems that need to be addressed to reduce glucose variability. In the illustrated example, "high glucose episodes" are shown to occur most frequently. After selecting a date range, the response report 2200 can be generated to display an expandable summary 2202 of several responses recorded for each type of response associated with each type of episode. Selecting the expand field 2204 expands the list to display the associated episode types.

[0160] FIG. 22B illustrates an exemplary embodiment of a response report 2200 after high glucose episode type expansion. As can be seen, a list of each question (e.g., questions discussed with respect to FIGS. 12A-C) that was asked of the diabetic patient in response to the detection of the episode type is displayed. These lists can also be expanded such that all response types given to a particular question are displayed along with the number of instances in which the particular response was given. Ordering the responses in descending order of number of instances can facilitate quick identification of the most frequently occurring responses or issues, which are typically issues that should be addressed first by HCPs and patients to most significantly reduce glucose variability. Selecting a particular response row 2205 can display one or both of a daily graph 1806 and an episode table 1807. Other types of graphs can also be displayed. The displayed daily graph 1806 can be associated with, for example, the most recent day within a selected date range on which the response type was actually indicated by the user. Selecting the next or back button 1802 can advance to the next date on which this response was actually offered or provided by the user, or can return to the previous date.

[0161] Thus, report 2200 provides a mechanism for the user to quickly identify the most frequent occurrences of responses or problems that need to be addressed, and to drill down (or identify) the specific days on which the responses or problems occurred. The user can then explore more detailed information and glucose traces associated with this issue, presented on a day-by-day and episode-by-episode basis, to understand how they need to be addressed.

[0162] FIG. 22C is a flow diagram illustrating an exemplary method 2250 of a set of instructions in a server-based version of an EIS that can be used to generate report 2200. Note that episode responses and corresponding date and / or time stamps can be automatically uploaded from reader 120 to server 130. In this example, episode detection is performed using the EIS of server 130 instead of the EIS version executed on reader 120, and detected episodes are associated with episode responses by temporal proximity. This can have the advantage of simplifying the design of the EIS stored and executed by reader 120 in that it is not necessary to associate stored responses with episodes and communicate the association to server 130. (In another embodiment, reader 120 can store and communicate the association of episodes and responses to server 130.) 22C, at 2252, the processing circuit 131 of the server (see FIG. 1A) retrieves recorded episode responses within a selected date range from a non-transitory memory 132 communicatively coupled to the processing circuit 131. At 2254, the processing circuit 131 can use the EIS to detect episodes and associate responses to the detected episode, possibly by temporal proximity (e.g., if the first responses recorded after the detected episode are within a minimum threshold time, they are associated with the detected episode). At 2256, the processing circuit 131 can aggregate the episodes by episode type. Then, at 2258, the processing circuit 131 can arrange the responses for each episode type in descending order of frequency or number of occurrences.

[0163] 22D is a flow diagram illustrating an example method 2280 of a set of instructions in a server-based version of the EIS that may be used to generate a daily graph or report 1806 for a selected episode response. At 2282, the processing circuitry 131 may generate an array arranged in ascending date and time order, with each entry in the array corresponding to an instance in the specified date range in which the selected episode response occurred. At 2284, the processing circuitry 131 may display the daily graph 1806 for the most recent date and time in the array (e.g., by providing information used to render the display of the daily graph 1806).

[0164] At 2286, the processing circuit 131 may monitor for an indication that the user has selected either the "back" or "next" button 1802 and then decrement or increment the array pointer accordingly. If the pointer is at the beginning or end of the array, the "back" or "next" buttons may not be selectable on the display; for example, if there are no dates prior to the date of the currently displayed graph 1806 information, the "back" button will not be selectable and if there are no dates after the date of the current graph 1806, the "next" button will be unavailable. At 2288, the processing circuit 131 may display the daily graph 1806 for the date and time indicated by the pointer.

[0165] When interactive filter 1810 is displayed with daily graph 1806, processing circuitry 131 determines and places markers 1812 and 1814 on opposite sides of the episode's occurrence time to highlight the episode. For example, left marker 1812 may be placed at a predetermined time (e.g., one hour) earlier than the episode's occurrence time, and right marker 1814 may be placed at the same or a different predetermined time (e.g., three hours) later, adjusted to the nearest clock time increment, after the start of the episode.

[0166] 23 illustrates an exemplary embodiment of an episode trace report 2300. For each episode, a plot 2310 of glucose level measurements may be displayed with the episode centered at time 0. The glucose level plot may span a given time period, for example, 6 hours before and after the episode. The report 2300 may also display one or more of patient reported episode reasons, symptoms, treatments, and notes 2320 associated with the episode. The report 2300 may provide a detailed analysis of a particular episode.

[0167] 24 illustrates an example embodiment of an overnight risk factor report 2400, which may include one or more plots of modal glucose levels 2450 associated with no risk factors 2410, high glucose risk factors 2420, and low glucose risk factors 2430. Each plot of modal glucose levels 2450 may include a table showing the number of each type of risk factor 2440.

[0168] The reports described herein are merely examples. An embodiment of the EIS may include any combination of some or all of the reports described herein. An embodiment of the EIS may include other reports in addition to or instead of the reports described herein. Furthermore, it is asserted that the various fields, data arrangements, icons, notes, markers, and indicators of each graph, table, and / or report described herein may be freely interchanged in each embodiment of the graph, table, and / or report described herein, unless otherwise stated or logically impractical.

[0169] The local and remote computers 150 and 160 can perform some or all of the functions of the reader 120 and / or the network server 130. For example, the local computer 150 can detect episodes related to glucose level measurements and prompt the patient for a response to the detected episodes. The episode detection algorithms of the local computer 150 can include configuration for searching for all episodes, similar to the server 130, or for searching for a subset of episodes, similar to the glucose monitoring application of the reader 120.

[0170] 25 is a flow diagram illustrating an exemplary embodiment using EIS. At 2502, a diabetic patient monitors their own glucose for several days (e.g., 7 or 14 days) using a sensor control device 110 and a reader device 120, which may operate with a mask glucose monitoring software or mask EIS embodiment. The data collected thereby can be used to establish a baseline glucose behavior profile for the diabetic patient.

[0171] At 2504, the HCP and diabetic patient or other caregiver can analyze the collected data and establish or adjust medication (e.g., insulin) therapy, such as with the aid of the GPI report 1900. At 2506, a user (HCP, caregiver, or diabetic patient) can set appropriate targets and thresholds in the EIS to enable the generation of various reports (e.g., median threshold target in the GPI report) and detection of episodes and excursions (e.g., low glucose threshold, high glucose threshold, rapid rise threshold, etc., to name a few). At 2508, the EIS can be activated and the diabetic patient can monitor his or her glucose using the reader 120 running the EIS (or glucose monitoring software and EIS) for a first period of time (e.g., several days or weeks). The EIS can be set to operate only at certain times, such as times when baseline data indicates a problem.

[0172] At 2510, a session can be opened between the HCP and the diabetic patient or caregiver to analyze the data collected over the first time period. This can include analysis of one or more reports that the EIS can generate. For example, an episode response report 2200 can be generated to identify the most frequent causes of episodes. The daily graphs 1806 included in the episode response report 2200 can then be used to identify the specific underlying behaviors that contribute to the episodes. Different reports can be used based on the specific circumstances.

[0173] At 2512, the HCP can hold a discussion to make practical modifications to behavior to address the causes and, if necessary, an action plan can be developed to assist in modifying behavior. At 2514, for example, the GPI report 1900 can be utilized to identify and implement necessary adjustments to medication therapy. This process can be repeated as necessary until the diabetic patient's level of variability and / or excursions has been reduced to a desired level.

[0174] The episode investigation software has been described herein in the context of an analyte monitoring system, particularly as being applicable to glucose monitoring to assist diabetics in managing their condition, however, the functions, attributes, reports, and other features of the episode investigation software have broader applications as well, including management of other types of medical conditions, and even outside of the medical field.

[0175] For example, the subject matter disclosed herein is not limited to investigating the causes of episodes, and may be used to monitor and characterize other attributes, conditions, or characteristics of a human being that may or may not qualify as an episode, as the term episode is used in its broadest sense herein. The data collected and analyzed may be virtually any type of data, such as activity-related data (e.g., steps taken, calories burned, etc., tracked and reported by a device, such as an activity monitor), dietary information, location information (e.g., GPS-enabled devices), characteristics of the heart and / or vascular system (e.g., heart rate, blood pressure, heart sounds, etc.), characteristics of another organ, such as the eye (e.g., intraocular pressure), skin (e.g., sweating), brain (e.g., neuro-electrical activity), and other forms of biometric data. These collected data may be compared to one or more criteria, conditions, requirements, thresholds, etc., indicative of the occurrence of an episode, event, feature, symptom, precursor, activity, etc., relevant to a particular application.

[0176] Exemplary embodiments of software for building or modifying robust libraries using the decorator pattern and / or dependency injection The following embodiments may be implemented as part of a software application running on a reader 120 in the system 100 described herein. Readers and analyte monitoring systems are also described in U.S. Patent Publication Nos. 2015 / 0205947 and 2015 / 0341438, both of which are incorporated by reference in their entirety for all purposes. The embodiments described in this section, as well as all of the embodiments herein, may be used with any and all analyte monitoring systems described in these incorporated references, including any systems with in vivo, in vitro, or a combination of the two.

[0177] Also, as with the previous embodiments, the embodiments in this section are not limited to reader 120 in system 100, but rather may be used in a wide variety of other electronic computing devices having processing circuitry and non-transitory memory (such as those described herein). Additionally, the following exemplary embodiments are not limited to use in medical analyte monitoring environments. Rather, these embodiments have broad applicability and may be used in any environment, device, and / or system, whether medical, non-medical, or otherwise.

[0178] These and any software embodiments described herein may be implemented via one or more instructions stored in memory that, when executed by a processing circuit, cause the processing circuit to perform or perform the functions and / or actions described herein.

[0179] For ease of explanation, the exemplary embodiment is described herein as a downloadable software application running on a reader 120 in the form of a portable communication device (e.g., a smartphone). Exemplary embodiments of a smartphone reader 120 and analyte monitoring system 100 are described herein.

[0180] In certain exemplary embodiments, the software application is an analyte monitoring application that may have a sensor interface module (or application) for enabling and controlling communication with the sensor control device 110. The sensor interface module may generate, code, and / or encrypt communication requests sent to the sensor control device 110 requesting that analyte information collected from the wearer of the sensor control device 110 be sent to the reader 120. This module may also decrypt, decode, and / or read information received from the sensor control device 110. In some embodiments, the data received from the sensor control device 110 is raw data in digital form, where the analog readings from the sensor 104 have been converted, or partially processed data in digital form, where the raw data has undergone some filtering, temperature calibration, sensor calibration, error checking, or other processing. The sensor interface module is responsible for further processing of the received data, and may apply these and more extensive forms of filtering, calibration, and / or algorithmic processing to convert the received data into a reliable representation of the user's analyte level, which may be output to a user interface in a format for display to the user.

[0181] The analyte monitoring application may also include a user interface module (or application) responsible for interfacing with a user of the reader 120. This user interface module may select and control the information displayed on the display of the reader 120, such as by causing a home screen to be displayed, changing the display from a first screen to a second screen, etc., in response to input received from the user.

[0182] The user interface may display graphs, numbers, trend arrows, and other indicia for display on display 121 conveying current (e.g., within the last hour) and / or historical (e.g., within days, weeks, or months) sample information for the user. The user interface module may also present menus, options, settings, and other user selectable fields to the user for display on reader 120, and may process user selections received via user input element 122.

[0183] Generally, a user enters a command that is received by the User Interface Module, which then forwards the command or call or passes information to the Sensor Interface Module for execution. In some embodiments, the call or information may call specialized functions, either of which may be called from a software library, or passed through an Application Programming Interface (API). These functions and / or APIs may interface with the Operating System (OS), device drivers, hardware, and other aspects of the phone.

[0184] Similarly, when the sensor interface module, in executing its programming, wishes to execute an instruction or perform a function, it forwards the instruction or call, or passes information, to another module or application that assists in executing the desired instruction. This process can continue from the highest relative programming layer involved in executing the instruction (e.g., application layer) to lower programming layers (e.g., application model, user interface (UI) model, cloud integration, kernel, device driver (enabling operation of a particular hardware component or card), hardware board support package (BSP), etc.).

[0185] In these exemplary embodiments, various interfaces between modules, functions, objects, etc. are exposed to the application layer so that the information (e.g., data, values, null fields, instructions, or other) passed by the interfaces between the modules, functions, objects, etc. can be changed or modified. In some embodiments, this modification involves the injection of new information into the software at the interface, while in other embodiments, this modification involves the removal or deletion of information passed by the interface, and in still other embodiments, this modification can include changing, adding, deleting, and any combination thereof, of specific information. Exposing these interfaces allows the application layer (e.g., an analyte monitoring application) to control the information exchanged through or by the interfaces without changing the core instructions of the various modules, functions, or objects that process, determine, or retrieve the data passed.

[0186] The exemplary embodiments described herein can be implemented such that the library receives wrappers for interfaces provided by the downloadable software application. These wrappers can directly forward calls to existing modules or functions that the software designer does not wish to modify. Thus, any interface code that the software designer wishes to control in the source code of the downloadable software application can be placed in a wrapper. If control is not desired or needed at a particular time, the wrapper can be configured to only forward calls to a particular module or function. The library receives the wrappers as constructor parameters passed in by the entire application.

[0187] However, if the information passed by the interface code requires modification, a decorator or decorator pattern can be added to the wrapper to make the modification. This is often useful. For example, if a combination of hardware, device drivers, and / or operating system has an issue that causes an OS function to function incorrectly or in an unintended manner, the software library may receive incorrect input and generate incorrect output. This may be discovered, for example, while testing the entire application on multiple hardware combinations. If a software module or function is outputting incorrect information, such as propagating an OS error to a library, a decorator can be generated for the wrapper for the interface that passes the incorrect result from the software module or function. The decorator can detect the presence of the error and remove it, modify it, replace it with one or more null or ignore values, or otherwise correct it appropriately.

[0188] Thus, in this example, the application can be modified to identify and correct software problems without modifying the existing modules or functions in the library. In some cases, these existing modules or functions may be complex software entities that cannot be easily revised. For example, the existing modules or functions may have been written by another design team or vendor, the existing modules or functions may be subject to a design freeze or other government confidentiality prohibition against modification, or the existing modules or functions may be standard software units that function as designed, but generate outputs (including, for example, null fields) that inhibit the operation of other software modules that call them.

[0189] The following embodiment is an example JAVA source code excerpt that implements a wrapper for a function that returns the current date in year-month-day format. TIFF2025023160000002.tif199152

[0190] During testing, it was discovered that the OS's getCurrentYear() produced incomplete output on some OS versions, returning only two-digit years (e.g., 15 instead of 2015). This incomplete output can be made complete without modifying the library by inserting a decorator that detects and corrects this issue, as shown in the code excerpt below. TIFF2025023160000003.tif156161

[0191] Thus, the YearFixOsFunctionWrapper wrapper for the interface code in the previous example can detect the presence of an incomplete output (the returned year value is less than or equal to 100) and then apply the appropriate correction to make it complete (for example, adding 2000 to the year value).

[0192] 26 is a block diagram that diagrammatically illustrates software running on the reader 120, where a first software module (or function) 2601 indirectly calls a second existing software module 2602 by directly calling a wrapper 2620 of the second software module 2602. In some embodiments, the second software module 2602 can accomplish a task without calling another module or function. In this embodiment, the second software module 2602 indirectly calls a third software module 2603 by directly calling a wrapper 2630 to accomplish its task, and the second software module 2602 indirectly calls a fourth software module 2604 by directly calling a wrapper 2640.

[0193] In this embodiment, information returned from the third software module 2603 to the second software module 2602 (e.g., returned results) is returned through a wrapper 2630 that is configured to determine whether the results satisfy one or more conditions (e.g., designed to identify erroneous, incomplete, or undesirable results), modify (change, remove, add, etc.) the results, and return the modified results to the second software module 2602. If the conditions are not satisfied, the results are not changed.

[0194] It should be noted that satisfaction of a condition is related to whether or not that condition indicates a need for modification. In this embodiment, conditions are specified that the information should be modified, however, embodiments described herein are operable to specify conditions that do not require modification of the information, in which case a change occurs when the information does not satisfy (or is violated by) the condition.

[0195] The wrapper 2640 operates in a similar manner on the information passed from the software module 2604, determining whether the information satisfies one or more conditions, and if so, modifies the results appropriately before passing them on to the second software module 2602. The second software module 2602 then uses the information passed from the wrappers 2630 and 2640, which may or may not be modified depending on whether each satisfies its respective condition, to perform its function and generate information to be passed on to the first software module 2601. The wrapper 2620 evaluates whether the information passed from the second software module 2602 satisfies the modification conditions, and if so, modifies it before passing it on to the first software module 2601.

[0196] Thus, Figure 26 serves to illustrate the broad stages at which wrappers may be utilized in the embodiments described herein. Wrappers may be used to advantage when one software module or function passes information (e.g., data, values, characters, software instructions, etc.) to another module or function.

[0197] FIG. 27 illustrates an exemplary embodiment of a method 2700 for operating a reader 120 in an analyte monitoring system 100 utilizing an existing software wrapper to perform a task. At 2702, a first function calls a wrapper for a second function to perform a task. At 2704, the wrapper calls or incorporates the second function. At 2706, the second function operates to perform the task and generates output information to be returned to the first function. At 2708, the wrapper determines whether the output information generated by the second function satisfies (or violates) one or more conditions that indicate modification of the information is appropriate. At 2710, if the conditions are satisfied, modification is appropriate and the wrapper modifies the output information according to one or more functions or instructions executed by the wrapper. At 2712, the modified output information is returned by the wrapper to the first function.

[0198] Alternatively, if the modification condition is not satisfied, the output information is passed to the first function without modification at 2714. Method 2700 may be performed any number of times based on the number of software modules or functions required to perform a particular task or tasks. Additionally, each wrapper may be used to detect multiple conditions and perform multiple modifications to correct the detected conditions. For example, each wrapper may incorporate any number of IF-THEN or IF-THEN-ELSE statements and multiple stages of conditional programming to allow the wrapper to accomplish the desired information modification function.

[0199] 28 illustrates an exemplary embodiment of a method 28000 for using a reader 120 to perform reading and scanning, or a sensor control device 110 with software functionality utilizing one or more wrappers. In this example, the reader 120 is a smartphone running a downloaded analyte monitoring application, with a user interface module and a sensor interface module. At 2802, the scanning process is initiated, for example, by a user selecting on the touch screen display 121 that they wish to perform a scan. (During testing, this step can be software bypassed.) The user interface module can recognize this input and call the sensor interface module to begin the scan.

[0200] At 2804, the sensor interface module can directly call a wrapper for the sensor RF module, which can be responsible for generating a bit string that is sent to the sensor controller 110. At 2806, the sensor RF module can then call a wrapper for the OS API driver module (or multiple wrappers for multiple modules) that is responsible for interfacing directly (or indirectly) with RF transmission hardware (e.g., NFC, Bluetooth, BTLE, etc.).

[0201] In this manner, both the interface between the Sensor Interface Module and the Sensor RF Module, and the interface between the Sensor RF Module and the OS API Driver Module are exposed to the application layer of the reader 120. Wrappers around these interfaces can be used for a variety of purposes to aid in testing and / or operation of the analyte monitoring application.

[0202] At 2808, the OS API driver module wrapper can call the OS API driver module, which sends a request to the sensor controller 110. The response received from the sensor controller 110 is the result returned from the OS API driver module to the wrapper after demodulation and / or decoding. At 2810, the OS API driver module wrapper can determine whether the returned result satisfies a modification condition, and if so, at 2812, the wrapper can appropriately modify the returned result and pass it to the sensor RF module. Alternatively, if the modification condition is not satisfied, at 2814, the result returned from the OS API driver module is passed to the sensor RF module in an unmodified form.

[0203] At 2816, the sensor RF module reads the passed results and performs one or more of the sensor RF module's operations on the passed results. For all of the embodiments described herein, execution of a module or function may include performing one or more operations on the information provided to the module or function, which may include computing the information, formatting the information, storing the information in a memory or buffer, calling one or more other functions or modules, and / or other software operations known to those skilled in the art, and combinations thereof. Once the sensor RF module has completed its operations, it returns the results to the sensor RF module's wrapper.

[0204] At 2818, the sensor RF module wrapper may determine whether the returned results satisfy the modification condition, and if so, at 2820, the wrapper may appropriately modify the returned results and pass them to the sensor interface module. Alternatively, if the modification condition is not satisfied, at 2822, the sensor RF module may pass the returned results in an unmodified form to the sensor interface module. At 2824, the sensor interface module may algorithmically process the information provided by the sensor RF module wrapper and provide results indicative of the sensor wearer's analyte level to the user interface module in a format that can be displayed on a display or rendered on a display for a user to read and understand. At 2826, the analyte level may be displayed.

[0205] Method 2800 and other such embodiments can be used in an almost limitless number of situations where control of information passed between modules or functions is desired. For example, the embodiments described herein can be used to modify information generated by the OS of a reading device 120 (e.g., a smartphone). If a low-level error checking routine fails, the smartphone's OS API driver can generate incomplete responses. In one exemplary embodiment, a wrapper for the OS API driver can detect these incomplete responses and complete them by adding characters as appropriate.

[0206] Additionally (or alternatively), the OS API driver wrapper can detect an incomplete response and generate an error. Thus, the wrappers utilized in the present embodiments are not limited to modifying the information passed between modules, but can also generate errors, notifications, interrupts, or other flags within the software application, or leave the information passed between modules untouched (if desired).

[0207] In another embodiment, the use of one or more wrappers can facilitate testing or simulation of an analyte monitoring system by inserting a fixed data set using the wrapper. For example, a wrapper for a sensor RF module can be configured to return fixed information instead of calling another function. In some embodiments, this wrapper can be added to the analyte monitoring application at run time, i.e., after the application is compiled and when the analyte monitoring application is ready to run, or during execution. The fixed information can be data that simulates edge case scenarios, such as scenarios that are difficult to trigger using real hardware and real software routines. Initiation of a low level error (e.g., an error emanating from a software driver for a hardware component) can be an example of such an edge case scenario. The fixed data from the wrapper can propagate to other software functions of the analyte monitoring application, thereby simulating the impact of such edge case scenarios on the analyte monitoring application (e.g., sensor interface module, user interface module, etc.) and aiding in debugging and validation of the overall software. For example, a processing circuit (or software developer, etc.) can determine whether an additive error is generated when the fixed data propagates to another software function.

[0208] Computer program instructions for carrying out operations according to the subject matter described herein may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, JavaScript, Smalltalk, C++, C#, Transact-SQL, XML, PHP, and conventional procedural programming languages ​​such as the "C" programming language, or similar programming languages. The program instructions may be executed as a standalone software package, fully or partially on the user's computing device, partially on the user's computing device and partially on a remote computing device, or fully on a remote computing device or server. In the latter case, the remote computing device may be connected to the user's computing device via any network, including a local area network (LAN) or wide area network (WAN), or by connecting to an external computer (e.g., via the Internet using an Internet Service Provider).

[0209] In all of the embodiments described herein, to the extent that a user may provide input (e.g., by selecting a selectable field on a touch screen of a reading device, by inputting via mechanical buttons or switches of the reading device, by selecting a field on a display with a mouse, to name a few), it can be stated and asserted that the associated processing circuitry (e.g., circuitry executing the software described herein) monitors the user input. This monitoring can include, for example, an interrupt or notification from the software associated with the hardware (touch screen, mouse, etc.) that user input is being accepted. The processing circuitry can also have instructions that cause the processing circuitry to receive and / or read the user input and determine what selections have been made by the user. Similarly, for any graphical user interface and / or screen that is displayed, it can be stated and asserted that the processing circuitry causes (or generates) the graphical user interface or screen and all features therein (icons, text, images, etc.). It is reiterated that, as described elsewhere herein, the processing circuitry can be a single processor chip, multiple processor chips, or partial processor chips distributed throughout an electronic device that communicate with each other.

[0210] It should be noted that all features, elements, components, functions, and steps described with respect to any embodiment described herein are intended to be freely combinable and interchangeable with any other embodiment. If a particular feature, element, component, function, or step is described with respect to only one embodiment, that feature, element, component, function, or step can be used with all other embodiments described herein, unless otherwise specified. Thus, this paragraph serves as a premise and written support for introducing claims that combine features, elements, components, functions, and steps from different embodiments, or substitute features, elements, components, functions, and steps from one embodiment with those of another embodiment, even if the following description does not explicitly state that a combination or substitution of features, elements, components, functions, and steps from different embodiments is possible in a specific example. It is expressly acknowledged that explicitly describing all possible combinations and substitutions would be an undue burden, especially considering that any such combinations and substitutions are readily recognized by those skilled in the art.

[0211] To the extent that memory, storage, and / or computer readable medium are included in or operate in conjunction with the embodiments disclosed herein, such memory, storage, and / or computer readable medium are non-transitory, and thus, to the extent that memory, storage, and / or computer readable medium are encompassed by one or more claims, such memory, storage, and / or computer readable medium are only non-transitory.

[0212] In many instances herein, entities are described as being coupled to other entities. The terms "coupled" and "connected" (or any of their forms) are used interchangeably herein and should be understood to refer, in either case, to a direct coupling of two entities (without significant (e.g., parasitic) intervening entities) and an indirect coupling between two entities (with significant intervening entities). Where entities are illustrated as being directly coupled to one another or described as being connected to one another without description of intervening entities, it should be understood that these entities may also be indirectly coupled to one another, unless the context clearly dictates otherwise.

[0213] As used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise.

[0214] Although the embodiments are susceptible to various modifications and alternative forms, specific examples thereof have been shown and described in detail in the specification. However, it is to be understood that these embodiments are not limited to the particular forms disclosed, but on the contrary, these embodiments are intended to encompass all modifications, equivalents, and alternatives falling within the spirit of the disclosure. Furthermore, the claims may include or include limitations to the contrary that define the scope of the invention by any feature, function, step, or element of the embodiments and any feature, function, step, or element not included in the claims.

[0215] Preferred embodiments of the present invention will be described below in detail. [Embodiment 1] 1. A analyte monitoring system for use in detecting and assessing an episode, comprising: 1. A sensor control device comprising: a sensor configured to obtain a measurement of an analyte level in a patient; and wireless communication circuitry configured to communicate the measurement of the analyte level to a reader, The reading device, A display and a wireless communication circuit configured to receive the measurement of the analyte level from the sensor control unit; a processor circuit communicatively coupled to the wireless communication circuit, the display, and a non-transitory memory; Equipped with The non-transitory memory, when executed by the processor circuit, determining whether the measurement of the analyte level indicates that an episode is occurring; and storing a plurality of instructions for, when it is determined that an episode has occurred, displaying a question related to the episode and one or more candidate responses that are selectable answers to the question. A system characterized by: [Embodiment 2] 2. The sample monitoring system of claim 1, wherein the instructions, when executed by the processor circuit, further cause the processor circuit to make modifications to the candidate list received from a user, the modifications being at least one of adding a customized response that is a selectable answer to the question to the candidate list or deleting a response from the candidate list. [Embodiment 3] The analyte monitoring system of claim 2 , wherein the modification comprises deleting a response from the candidate list. [Embodiment 4] The sample monitoring system of claim 1 , wherein the mobile terminal is a smartphone. [Embodiment 5] 2. The analyte monitoring system of claim 1, wherein the episode is a bedtime episode, a morning episode, a low analyte episode, a high analyte episode, a analyte spike episode, or a analyte spike drop episode. [Embodiment 6] The instructions, when executed by the processor circuit, further cause the processor circuit to: The sample monitoring system of claim 1, wherein if it is determined that an episode has occurred, the sample level of the patient is not displayed, but instead a question related to the episode and a list of one or more selectable responses to the question are displayed. [Embodiment 7] The instructions, when executed by the processor circuit, further cause the processor circuit to: (a) processing a plurality of analyte level measurements received from the sensor control device over a multiple day time period; (b) determining whether the plurality of measurements of the analyte level during the plurality of days indicates the occurrence of one or more episodes; (c) when it is determined that one or more episodes have occurred during the multiple-day period, displaying, for each detected episode, a question related to the episode and one or more response candidates that are selectable answers to the question; The sample monitoring system of claim 1 , wherein the instructions cause the processor circuit to perform (a) through (c) without displaying any sample levels to the patient during the multiple day period. [Embodiment 8] The specimen monitoring system of claim 7, wherein the instructions cause the processor circuit to perform (a) to (c) without displaying to the patient the type of episode detected during each of the multiple day periods. [Embodiment 9] The instructions are then transmitted to the processor circuitry, The sample monitoring system of claim 1, characterized in that if it is determined that no episode has occurred, the system waits until a predetermined event time, and then displays a question related to the event time and a list of one or more selectable responses to the question. [Embodiment 10] 3. The analyte monitoring system of claim 2, wherein the modification is the addition of a customized response to the candidate list that is a selectable answer to the question. [Embodiment 11] 1. A method for reducing patient sample variability, comprising: receiving at least one measurement of an analyte level in a patient from the sensor control device in communications circuitry of the mobile device; determining with processing circuitry of the reader whether the measurement of the analyte level indicates that an episode has occurred; if it is determined that an episode has occurred, causing the processing circuitry of the reading device to display a question related to the episode and one or more candidate responses that are selectable answers to the question; A method comprising: [Embodiment 12] 12. The method of claim 11, further comprising the step of: applying, in the processing circuitry of the reading device, modifications received from a user to the candidate list, the modifications being at least one of adding a customized response that is a selectable answer to the question to the candidate list or deleting a response from the candidate list. [Embodiment 13] The method of claim 11, wherein the reading device is a smartphone. [Embodiment 14] 12. The method of claim 11, wherein the episode is a bedtime episode, a morning episode, a low analyte episode, a high analyte episode, a spike analyte episode, or a spike analyte drop episode. [Embodiment 15] 12. The method of claim 11, further comprising, if the processing circuit determines that an episode has occurred, causing the processing circuit to not display the analyte level for the patient, but instead display a question related to the episode and a list of one or more selectable responses to the question. [Embodiment 16] (a) processing, with the processing circuitry, a plurality of analyte level measurements received from the sensor control device over a multiple day time period; (b) determining with the processing circuitry whether the plurality of measurements of the analyte level during the multi-day period indicate the occurrence of one or more episodes; (c) if it is determined that one or more episodes have occurred during the multiple day time period, causing the processing circuitry to display, for each detected episode, a question related to the episode and one or more response candidates that are selectable answers to the question; Further comprising: The method, wherein the processing circuitry does not display any analyte levels to the patient during the multiple day period, and performs (a)-(c). [Embodiment 17] 17. The method of claim 16, wherein the processing circuitry performs (a)-(c) without displaying to the patient the type of each detected episode during the multiple-day period. [Embodiment 18] 12. The method of claim 11, further comprising, if it is determined that an episode has not occurred, waiting until a predetermined event period, causing the processing circuitry to display a question related to the event period and a list of one or more selectable responses to the question. [Embodiment 19] 12. The method of claim 11, wherein the modification is a deletion of a response from the candidate list. [Embodiment 20] 12. The method of claim 11, wherein the modification is the addition of a customized response to the candidate list that is a selectable answer to the question. [Embodiment 21] 1. A method for generating a report containing information regarding an analyte level in a human, comprising: receiving, by a processing circuit, a first selection for generating a report, the first selection being input by a user; causing the processing circuitry to display a grid including a first plurality of units, each of the first plurality of units comprising: a graphical trace of the analyte levels of the human over a period of time; and an episode indication on the graphical trace indicating the occurrence of a specimen episode, the indication being at a position on the graphical trace corresponding to a time at which the specimen episode occurred; receiving, by the processing circuitry, a second selection of one or more of the first plurality of units, the second selection entered by the user; identifying, by the processing circuitry, a plurality of analyte data corresponding to the second selection of one or more of the first plurality of units; generating the report using the plurality of identified analyte data; A method comprising: [Embodiment 22] 22. The method of claim 21, wherein the grid includes seven unit rows representing a week. [Embodiment 23] 23. The method of claim 22, wherein the grid includes a plurality of the rows arranged in a stacked manner, each of the rows in the plurality of the rows corresponding to a different week. [Embodiment 24] 24. The method of claim 23, wherein the period of time is one day. [Embodiment 25] 22. The method of claim 21, wherein each of the first plurality of units further comprises a shaded region corresponding to a region of the human target analyte level. [Embodiment 26] 22. The method of claim 21, wherein the grid includes a second plurality of units, each of the plurality of units representing a day and including an indication that there is no analyte data for that day. [Embodiment 27] 22. The method of claim 21, further comprising: causing each unit of the grid to display a selection indication in the second selection by the processing circuitry. [Embodiment 28] 28. The method of claim 27, wherein the selection indication is a shading for each unit of the grid in the second selection. [Embodiment 29] 22. The method of claim 21, wherein the plurality of identified analyte data is the only analyte data used to generate the report. [Embodiment 30] 1. A computing device comprising: A display and A processing circuit; a non-transitory memory storing a plurality of instructions; Equipped with The instructions, when executed, cause the processing circuitry to: In response to a first selection to generate a report, displaying a grid including a first plurality of units, each of the first plurality of units comprising: A graphical trace of the human sample level over a period of time; and an episode indication on the graphical trace indicating the occurrence of a specimen episode, the indication being at a position on the graphical trace corresponding to a time at which the specimen episode occurred; identifying a plurality of analyte data corresponding to the one or more second selections of the first plurality of units based on receipt of the one or more second selections of the first plurality of units; generating the report using the plurality of identified analyte data. An apparatus comprising: [Embodiment 31] 31. The apparatus of claim 30, wherein the grid includes seven rows of units representing a week. [Embodiment 32] 32. The apparatus of claim 31, wherein the grid includes a plurality of the rows arranged in a stack, each of the rows in the plurality of the rows corresponding to a different week. [Embodiment 33] 33. The apparatus of claim 32, wherein the period of time is one day. [Embodiment 34] 31. The apparatus of claim 30, wherein each of the first plurality of units further comprises a shaded region corresponding to a region of the human target analyte level. [Embodiment 35] 31. The apparatus of claim 30, wherein the grid includes a second plurality of units, each of the plurality of units representing a day and including an indication that there is no analyte data for that day. [Embodiment 36] 31. The apparatus of claim 30, wherein the instructions, when executed, cause the processing circuitry to display a selection indicia in each unit of the grid in the second selection. [Embodiment 37] 37. The apparatus of claim 36, wherein the selection indication is shading for each unit of the grid in the second selection. [Embodiment 38] 31. The apparatus of claim 30, wherein the instructions, when executed, cause the processing circuit to generate the report using the identified plurality of analyte data as the only analyte data used to generate the report. [Embodiment 39] 1. A method for generating an interactive report containing information regarding analyte levels in a human, comprising: The processing circuitry (a) A graph, Display of time along the horizontal axis, Displaying the magnitude of multiple sample data along the vertical axis; a time-course trace of the analyte levels of the human; and a graph including a plurality of episode indicators, each of which, upon occurrence, indicates the occurrence of a specimen episode, the indicators being positioned along the trace according to the time of occurrence; (b) an adjustable list of a plurality of specimen episodes, each of the plurality of specimen episodes having a corresponding episode indicator within the graph; and (c) a user-tunable filter, A horizontal filter axis corresponding to time, a first marker movable along the lateral filter axis; simultaneously displaying a filter of a second marker movable along the horizontal filter axis, the horizontal filter axis being aligned with a time display along the horizontal axis of the graph, the adjustable list of the plurality of specimen episodes including only specimen episodes having an episode indicator that is located in a position between the first marker and the second marker of the graph; monitoring, by the processing circuitry, for an indication that a user has adjusted a position of the first marker or the second marker; A method comprising: [Embodiment 40] a first set of episode indicators is between the first and second markers, and the plurality of specimen episodes in the adjustable list includes each specimen episode corresponding to the first set of episode indicators; and receiving, by the processing circuitry, an indication that a user has adjusted the position of the first marker and / or the second marker such that a second set of episode indicators is now present between the first marker and the second marker, the second set of episode indicators including at least one episode indicator that was not present in the first set; causing the processing circuitry to display the adjustable list of specimen episodes such that the adjustable list of specimen episodes includes each specimen episode that corresponds to the second set of episode indicators; 40. The method of claim 39, further comprising: [Embodiment 41] 1. A computing device comprising: A display and A processing circuit; a non-transitory memory that stores a plurality of instructions; Equipped with The instructions, when executed, cause the processing circuitry to: (a) A graph, Display of time along the horizontal axis, Displaying the magnitude of multiple sample data along the vertical axis; a time-course trace of the analyte levels of the human; and a graph including a plurality of episode indicators, each of which, upon occurrence, indicates the occurrence of a specimen episode, the indicators being positioned along the trace according to the time of occurrence; (b) an adjustable list of a plurality of specimen episodes, each of the plurality of specimen episodes having a corresponding episode indicator within the graph; and (c) a user-tunable filter, A horizontal filter axis corresponding to time, a first marker movable along the lateral filter axis; simultaneously displaying a filter of a second marker movable along the horizontal filter axis, the horizontal filter axis being aligned with a time display along the horizontal axis of the graph, the adjustable list of the plurality of specimen episodes including only specimen episodes having an episode indicator that is located between the first marker and the second marker of the graph; monitoring for an indication that a user has adjusted the position of the first marker or the second marker; An apparatus comprising: [Embodiment 42] 1. A method for generating a graphical user interface display having an interactive report of information regarding diabetes management, comprising: causing the processor circuit to display a list of one or more specimen episode types, each specimen episode type in the list of one or more specimen episode types being associated with a list of one or more response types, each response type in the list of one or more response types being selectable by the user during a data collection period in response to a query posed to the user by the electrical device regarding the occurrence of the associated specimen episode type; receiving, by the processor circuit, a selection of a first response type from the list of one or more response types; causing the processor circuit to display a graph of analyte data associated with instances in which the first response type was entered by the user; A method comprising: [Embodiment 43] 43. The method of claim 42, further comprising causing the processor circuit to display a list of one or more instances of specimen episodes that occurred during the time period. [Embodiment 44] 44. The method of claim 43, wherein the list of one or more specimen episode types, the list of one or more response types, the graph of the specimen data, and the list of one or more instances of the specimen episodes are simultaneously displayed by the processor circuit. [Embodiment 45] 43. The method of claim 42, wherein the list of one or more specimen episode types is arranged in an order corresponding to a number of instances in the collected specimen data that each specimen episode type was detected. [Embodiment 46] 43. The method of claim 42, wherein the list of one or more response types is arranged in an order corresponding to a number of instances of each response type entered by the user. [Embodiment 47] 43. The method of claim 42, wherein each response type in the list of one or more response types identifies a cause of occurrence of an associated specimen episode type. [Embodiment 48] 43. The method of claim 42, further comprising receiving, by the processor circuit, instructions from the user to display a second graph of analyte data associated with a second instance, the graph being a first graph, the instance being a first instance, and the first response type being entered by the user. [Embodiment 49] 1. A system configured to generate a graphical user interface display having an interactive report of information regarding diabetes management, comprising: A processor circuit; a non-transitory memory communicatively coupled to the processor circuit, the non-transitory memory storing a plurality of instructions; Equipped with The instructions, when executed, cause a pre-processor circuit to: displaying a list of one or more specimen episode types, each specimen episode type in the list of one or more specimen episode types associated with a list of one or more response types, each response type in the list of one or more response types selectable by the user during a data collection period in response to a query posed to the user by the electronic device regarding the occurrence of the associated specimen episode type; monitoring a selection of a first response type from the list of one or more response types; After receiving the selection, the first response type causes a graph of analyte data associated with the instance entered by the user to be displayed. An apparatus comprising: [Embodiment 50] 50. The system of claim 49, wherein the instructions, when executed, further cause the processor circuit to display a list of one or more instances of specimen episodes that occurred during the period of time. [Embodiment 51] 51. The system of claim 50, wherein the list of one or more specimen episode types, the list of one or more response types, the graph of the specimen data, and the list of one or more instances of the specimen episodes are simultaneously displayed by the processor circuit. [Embodiment 52] 50. The system of claim 49, wherein the list of one or more specimen episode types is arranged in an order corresponding to a number of instances in the collected specimen data that each specimen episode type was detected. [Embodiment 53] 50. The system of claim 49, wherein the list of one or more response types is arranged in an order corresponding to a number of instances of each response type entered by the user. [Embodiment 54] 50. The system of claim 49, wherein each response type in the list of one or more response types identifies a cause of occurrence of an associated specimen episode type. [Embodiment 55] 50. The system of claim 49, wherein the graph is a first graph and the instance is a first instance, and the instructions, when executed, cause the processor circuit to monitor for a command from the user to display a second graph of analyte data associated with a second instance, the first response type entered by the user, and upon receiving the command, display the second graph. [Embodiment 56] 1. A method of operating a software application, comprising: invoking a wrapper for a second software module on a processing circuit executing one or more instructions of the first software module; invoking the second software module with the processing circuitry executing one or more instructions of the wrapper for the second software module; generating a result at the processing circuit executing one or more instructions of the second software module; returning, at the processing circuitry, the result to the wrapper of the second software module; determining, in the processing circuitry executing the wrapper for the second software module, whether the result needs to be modified by comparing the result with a condition; if it is determined that the result needs to be modified, returning the modified result to the first software module, at the processing circuitry; if it is determined that the result does not need to be modified, returning the result in an unmodified form to the first software module by the processing circuitry; A method comprising: [Embodiment 57] 57. The method of claim 56, further comprising generating, by the processing circuitry, a notification based on the comparison with the condition. [Embodiment 58] 57. The method of claim 56, wherein the software application is an analyte monitoring application. [Embodiment 59] 60. The method of claim 58, wherein the first software module is a sensor interface module configured to algorithmically process analyte data received from a sensor control device including an analyte sensor configured for in vivo use. [Embodiment 60] 57. The method of claim 56, wherein the result is checked for errors by comparison with the condition. [Embodiment 61] 57. The method of claim 56, wherein the comparison with the condition checks whether the result is incomplete. [Embodiment 62] 1. A computing device comprising: A processing circuit; a non-transitory memory storing a plurality of instructions; Equipped with The instructions, when executed, cause the processing circuitry to: generating a call from the first software module to a wrapper for the second software module; generating a call from the wrapper of the second software module to the second software module; causing the second software module to generate a first result; returning the first result to the wrapper of the second software module; determining whether the first result needs to be modified by comparing the first result with a condition using instructions of the wrapper of the second software module; if it is determined that the first result needs to be modified, returning a second result to the first software module, the second result being formed by modifying the first result; if it is determined that the first result does not need to be modified, returning the first result to the first software module; An apparatus comprising: [Embodiment 63] 63. The apparatus of claim 62, wherein the instructions, when executed, further cause the processing circuitry to generate a notification based on a comparison of the first result to the condition. [Embodiment 64] 63. The apparatus of claim 62, wherein an analyte monitoring application is stored in the memory, and the first software module is a software component of the analyte monitoring application. [Embodiment 65] 63. The device of claim 62, wherein the device is configured as a reader and the first software module is a sensor interface module configured to algorithmically process analyte data received from a sensor control device including an analyte sensor configured for in vivo use. [Embodiment 66] 63. The apparatus of claim 62, wherein the result is checked for an error by comparing the first result with the condition. [Embodiment 67] 63. The apparatus of claim 62, wherein the first result is checked to see if it is incomplete by comparing it to the condition. [Embodiment 68] 1. A method for simulating an error in a software application, comprising: invoking a wrapper for a second software module on a processing circuit executing one or more instructions of the first software module; returning, at the processing circuitry, a set of fixed data from the wrapper of the second software module to the first software module, the fixed data simulating a first error; determining whether a second error has occurred; A method comprising: [Embodiment 69] 70. The method of claim 68, wherein the processing circuitry determines whether the second error has occurred. [Embodiment 70] 70. The method of claim 68, wherein the software application is an analyte monitoring application and the first software module is a software component of the analyte monitoring application. [Explanation of symbols]

[0216] 100 Sample Monitoring System 104 Sensors 110 Sensor control device 120 Reading device 122 Input Components 124 Processing Circuit 125 Non-transient memory 126 Processing Circuit 127 Non-transient memory 130 Servers 131 Processing circuit 132 Non-transient memory 150 Local Computing Device 160 Remote Computing Devices

Claims

[Claim 1] 1. A method for generating an interactive report containing information regarding analyte levels in a human, the method comprising: The processing circuitry (a) A graph, Display of time along the horizontal axis, Display of multiple analyte level magnitudes along the vertical axis; a time-course trace of the analyte levels of the human; and a graph including a plurality of episode indicators, each of which, upon occurrence, indicates the occurrence of a specimen episode, the indicators being positioned along the trace according to the time of occurrence; (b) an adjustable list of a plurality of specimen episodes, each of the plurality of specimen episodes having a corresponding episode indicator within the graph; and (c) simultaneously displaying user adjustable filters; monitoring, by said processing circuitry, for an indication that a user has adjusted said adjustable filter; 23. A method comprising:

Images