System, apparatus, and method for detecting and evaluating episodes

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 and priority of U.S. Provisional Application No. 62 / 189,137, filed on July 6, 2015, and U.S. Provisional Application No. 62 / 191,208, filed on July 10, 2015, and for all purposes, the entire contents of each are hereby incorporated by reference herein.

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 sample data and evaluate the circumstances and potential causes related to that episode.

Background Art

[0003] Many systems have been developed for automatically monitoring samples such as glucose in body fluids, such as blood, interstitial fluid (ISF), dermal fluid in the dermis, or other biological fluids.

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

[0005] For example, it is beneficial for diabetic patients because it is possible to reduce the fluctuations at the analyte level by reducing the frequency and / or severity of excursions. It is difficult for diabetic patients with relatively high analyte variability to treat high analyte level excursions by administering medications such as insulin to lower the analyte level. This is because doing so may increase the risk of low level excursions due to large fluctuations in analyte levels that define the high variability. Conversely, treating low level excursions by ingestion of food or carbohydrates to increase the analyte level in diabetic patients may increase the risk of high level excursions due to the subsequent increased analyte level and high variability. Reducing the frequency and / or severity of excursions can be an important prerequisite for reducing variability.

[0006] HCPs and patients can utilize a number of metrics (e.g., mean, median, percentile variation values, variability metrics, risk metrics, rate of change, etc.) that characterize or explain analyte level fluctuations. Analyte monitoring devices and systems can generate an overwhelming amount of data that can overwhelm and confuse users to the point where little or no insight is gained into the reasons for excursions or high variability. Additionally, recording information that is useful for understanding causal relationships can be burdensome for patients because it is unclear which information should be recorded.

[0007] One of the main challenges in excursions and variability root cause investigations is that the specimen-level monitoring mechanism responsible for collecting the data that forms the basis of the analysis is not related to the associated conditions leading to the excursion or the period that most significantly contributes to the variability. The investigation of these activities is typically done through a question-and-answer session between the diabetic patient and the HCP, which may occur days or weeks after the event. In such sessions, it is often the case that the diabetic patient does not remember the activities or conditions that led to the excursion, or that the diabetic patient does not recognize the need to track these conditions by, for example, investigating recent medication dosages, the carbohydrate content of recently consumed foods, recent exercise, activities, or sleep times. As a result, these activities and conditions are unknown and not useful. Additionally, when directly questioned by the HCP, the diabetic patient may feel compelled to give answers that make them seem like they are living a healthier life than they actually are.

Summary of the Invention

Problems to be Solved by the Invention

[0008] For these and other reasons, there is a need for improved monitoring, investigation, and evaluation of variability and excursions.

Means for Solving the Problems

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

[0010] For example, certain embodiments can monitor the analyte levels of a diabetic patient, determine whether one or more analyte-related episodes have occurred (or predict the occurrence of such in the future) based on the levels of the monitored analyte, and prompt a diabetic patient with information regarding an episode and investigate (or enable the investigation of) actions and other conditions that may have caused the episode in an improved manner. Many of these embodiments can utilize an in-vivo sensor control device that receives measurement results of analyte levels from a sensor within a diabetic patient, a reading device that receives measurement data from the sensor control device, and a monitoring application that resides on the reading device and analyzes the measurement data.

[0011] Episode Investigation Software (EIS), which facilitates the collection of information from a user who is a diabetic patient and enables the implementation or subsequent investigation of the root causes and conditions underlying episodes and variations, can be provided, for example, as a smartphone application, to a reading device and / or one or more computing devices, for example, via a web server.

[0012] This specification also describes exemplary embodiments for operating software having one or more wrappers on a computing device. The computing device can be a reading device or other device. The wrapper can enable the modification of data passing through an interface between various software modules or functions.

[0013] Other systems, devices, methods, functions, and effects related to the subject matter described in this specification will become apparent to those skilled in the art upon examination of the following drawings and detailed description. All such additional systems, methods, functions, and effects are intended to be included within this specification, are within the scope of the subject matter described herein, and are intended to be protected by the appended claims. By the functions of the exemplary embodiments, it is not to be construed that the appended claims are limited in the absence of an express recitation of such functions in the claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] By considering the accompanying drawings in which like reference numerals are used for like parts, the details of the subject matter described herein will become apparent both in structure and operation. The components in the figures are not necessarily to scale, with emphasis instead being placed upon illustrating the principles of the subject matter. Further, all of the figures are intended to convey concepts, and relative sizes, shapes, and other detailed attributes are shown in a more schematic rather than literal or exact manner.

Figure 1A

Figure 1B

Figure 1C

Figure 2

Figure 3A

Figure 3B

Figure 4A

Figure 4B

Figure 5

Figure 6A

Figure 6B

Figure 7

Figure 8

Figure 9A

Figure 9B

Figure 9C

Figure 10

Figure 11

Figure 12A

Figure 12B

Figure 12C

Figure 13

Figure 14A

Figure 14B

Figure 15

Figure 16

Figure 17A

Figure 17B

Figure 18A

Figure 18B

Figure 19A

Figure 19B

Figure 20

Figure 21

Figure 22A

Figure 22B

Figure 22C

Figure 22D

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

[0015] Before elaborating on this subject, it should be understood that the present disclosure is not limited to the specific embodiments described herein and can naturally change. Also, since the scope of the present disclosure is limited only by the appended claims, it should be understood that the terms used herein are for the purpose of describing only specific embodiments and are not intended to be limiting.

[0016] Exemplary Embodiments of a Specimen Monitoring System As described above, many systems for automatically monitoring specimens, including but not limited to glucose in body fluids such as blood, interstitial fluid (ISF), dermal fluid in the dermal layer, or other biological fluids, have been developed. In some of these systems, at least a part of the sensor is disposed inside the patient's body, such as in a blood vessel or in the patient's subcutaneous tissue or dermal layer, in order to obtain information about at least one specimen of the body. Therefore, these systems can be referred to as "in-vivo" specimen monitoring systems.

[0017] In-vivo specimen monitoring systems include "continuous specimen monitoring" systems (or "continuous glucose monitoring" systems) that can transmit data without prompting, for example, by continuously reporting data from a sensor control device to a reader device according to a reporting communication schedule. In-vivo specimen monitoring systems also include "flash specimen monitoring" systems (or "flash glucose monitoring" systems, or simply "flash" systems) using radio frequency identification (RFID), near field communication (NFC), or other protocols that can transmit data from a sensor control device in response to a data scan or request by a reader device. In-vivo specimen monitoring systems have also been developed that can operate without the need for calibration by fingerstick blood sampling.

[0018] An in-vivo specimen monitoring system can be distinguished from an "external" system equipped with a measuring device that contacts a biological sample capable of determining a patient's blood glucose level by analysis outside the body (or rather, "ex-vivo") and usually has a port for receiving a specimen test strip carrying the patient's body fluid. In many embodiments of this specification, the monitoring is performed in-vivo, but the embodiments disclosed herein can be used for an in-vivo specimen monitoring system incorporating ex-vivo functions and a complete ex-vivo or in-vitro specimen monitoring system.

[0019] The sensor may be a part of a sensor control device that resides in the patient's body and enables and controls the detection of the specimen. The sensor control device or its variant can also be referred to, for example, as a "sensor control unit", a "sensor electronic" device or unit, an "on-body electronic" device or unit, an "on-body" device or unit, or a "sensor data communication" device or unit.

[0020] The in-vivo monitoring system can also be equipped with a device that receives the detected specimen data from the sensor control device and processes and / or displays the detected data to the user in any number of forms. This device or its variant can also be referred to, for example, as a "reading device" (or simply a "reader"), a "handheld electronic device" (or a handheld terminal), a "portable data processing" device or unit, a "data receiver", a "receiver" device or unit (or simply a receiver), or a "remote" device or unit. Other devices such as personal computers are also used in conjunction with or incorporated into in-vivo and ex-vivo monitoring systems.

[0021] The embodiments described herein can be used for monitoring and / or processing information regarding one or more different specimens of any number. Specimens that can be monitored include, but are not limited to, acetylcholine, amylase, bilirubin, cholesterol, human 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. For example, the concentrations of drugs such as antibiotics (e.g., gentamicin, vancomycin, etc.), digitoxin, digoxin, abused drugs, theophylline, and warfarin can also be monitored. In embodiments where multiple specimens are monitored, the specimens can be measured simultaneously or at different times.

[0022] Many of the exemplary embodiments described herein refer to the monitoring of glucose, but such references are only based on the recognition that glucose is a commonly monitored specimen, and these references should not be construed as excluding the implementation for specimens other than glucose.

[0023] The manufacturer of the in-vivo system can provide both the sensor control device and the corresponding reading device to the patient, and in some cases, these two are sold as a set. The sensor control device has a limited lifespan and can be replaced regularly (e.g., every two weeks), while the reading device can be used for a fairly long period and can be reused for each newly replaced sensor control device.

[0024] One embodiment of the specimen monitoring system 100 is shown in FIG. 1A. The system can include one or more measuring devices such as a sensor control device 110 having a specimen sensor 104, and a reading device 120 such as a mobile smartphone that executes a software application such as a glucose monitoring application 140. One or more instances of episode investigation software (EIS) can be stored and executed inside the system 100.

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

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

[0027] As shown in FIG. 1A, components can wirelessly communicate with each other using a wireless communication protocol such as, for example, NFC, RFID, Wi-Fi, Bluetooth®, "Bluetooth" low energy, or a proprietary protocol. 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 and patient supply data (described below) can be stored in a location accessible to the EIS, such as, for example, the reader device 120, the network server 130, the local computing device 150, and / or the remote computing device 160. The data can be uploaded from the reader device 120. The stored data can be processed and / or analyzed to assist diabetes patients, patients, interested persons (e.g., parents, guardians, caregivers), healthcare professionals (HCPs), or all users in identifying patterns and causes that may have caused an episode, which can in turn be linked to better control of the specimen.

[0029] The EIS can correlate the activities, lifestyles, and / or behaviors of diabetic patients with glucose levels, thereby reducing the burden on the user to classify the effects. The EIS can use clinical information algorithms to search glucose data obtained for individual patients and the recorded behaviors of the patients (or multiple patients and patient records) to identify patterns that affect glucose levels. In some embodiments, the EIS can have instructions to perform: 1) defining episodes of interest, 2) selecting core episodes of a search routine, 3) constructing episodes proximal to the core, 4) associating one or more episodes with diabetic self-care behaviors, and 5) displaying the findings of the search algorithm. In another embodiment, the EIS can have instructions to perform: 1) defining episodes of interest, 2) selecting core episodes of a search routine, 3) constructing an episode chain that is a sequence of episodes (including the core episode) and constructing logical rules for including or excluding episodes proximal to the core, 4) associating one or more episode chains with diabetic self-care, and 5) displaying the findings of the search algorithm.

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

[0031] Returning to FIG. 1A, the sensor control device 110 is configured to receive measurement values of glucose levels from a sensor 104 that can be disposed within a living body, such as a subcutaneous sensor, a skin sensor, a vascular sensor, and the like. In another embodiment, the sensor can be disposed outside the living body, but can monitor analyte levels within the living body, such as certain optical sensors. The sensor control device 110 causes the sensor 104 to repeatedly detect glucose levels according to a predetermined schedule or at any time as needed, and reads one or more signals indicating the glucose levels from the sensor 104. These measurement values of the glucose levels can be stored in the sensor control device 110 and transferred to the reading device 120 in batches at a predetermined time, on demand, or immediately after the glucose levels are obtained.

[0032] Non-limiting examples of the reading device can include two combinations such as a measuring device of an extracorporeal monitoring system, a reading device of an in-vivo monitoring system, a test strip port, and an in-vivo reader operating with a measuring function, and various devices such as smartphones, tablets, dedicated readers, and other computing devices. The reading device 120 can include one or more software applications that execute various program routines, such as communication with another device executing EIS, display of data in various ways, reception of inputs from users (such as HCPs, caregivers, and / or diabetic patients) useful for diabetes management, and detection of episodes. The reading device 120 can have buttons such as a keyboard used for inputting information, for example. Additionally, or alternatively, the reading device 120 can have virtual buttons such as a touch screen configured to present a virtual keyboard.

[0033] In addition, the reading device 120 includes or is integrated with a pharmaceutical (e.g., insulin, etc.) supply device, and for example, these can share a common housing. The pharmaceutical supply hardware can include a storage container for storing pharmaceuticals, a pump connectable to a transfer tube, and an infusion cannula for administering the pharmaceuticals into the body from the storage container through a tube and via a cannula inserted into a diabetic patient.

[0034] Figure 1B is a block diagram of an exemplary embodiment of the reading device 120 in the form of a smartphone. Here, the reading device 120 has an input component 122, a display 121, and a processing circuit (or hardware) 206, and the processing circuit can include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which can be distributed on individual chips or several different chips (and parts thereof). The processing hardware 206 can include a communication processor 202 having an on-board memory 203 and an application processor 204 having an on-board memory 205. Additional processors can exist and there is a possibility that they exist. The reading device 120 further has an RF transceiver 208 coupled to an RF antenna 209, a memory 210, a multifunctional circuit 212 having one or more associated antennas 214, a power supply 216, and a power management circuit 218. Figure 1B shows the components inside the smartphone in a simplified manner, and of course, it can include other hardware and functions (e.g., code, drivers, glue logic, etc.).

[0035] The communication processor 202 can interface with the RF transceiver 208, facilitating analog-to-digital conversion, encoding and decoding, digital signal processing, and format conversion (e.g., in-phase and quadrature phase) of audio, video, and data signals suitable for supply to the RF transceiver 208, and then the transceiver can perform other functions that enable it to wirelessly transmit the signal. Also, the communication processor 202 can perform the reverse functions necessary to receive wireless transmissions and can interface with the RF transceiver to convert the wireless transmissions into digital data, audio, and video.

[0036] The application processor 204 can be configured to execute an operating system and any software applications resident on the reader 120, perform video and graphic processing, and perform other functions not related to the processing of communications transmitted and received via the RF antenna 209. Any number of applications can be executed at all times on the reader 120, typically including one or more applications related to diabetes monitoring methods, as well as general applications not related to such methods, such as, for example, email, calendar, weather, etc.

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

[0038] The multifunctional circuit 212 can be implemented as one or more chips and / or components that perform other functions, including communication circuits such as local wireless communication (e.g., Wi-Fi, "Bluetooth", "Bluetooth" low energy), and determining the geographical location of the reader device 120 (e.g., global positioning (GPS) hardware). One or more additional antennas 214 are associated with both functional circuits 212 as needed.

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

[0040] FIG. 1C is a schematic block diagram showing an exemplary embodiment of a sensor control device 110 having a specimen sensor 104 and sensor electronics 250 (including a specimen monitoring circuit). Although any number of chips can be used, here most of the sensor electronics 250 are incorporated in one semiconductor chip 251, which may be, for example, a custom application-specific integrated circuit (ASIC). Shown within the ASIC 251 is a schematic diagram of several functional units, including an analog front end (AFE) 252, a power management circuit 254, a processor 256, and a communication circuit 258 (which can be implemented according to a transmitter, receiver, transceiver, passive circuit, or communication protocol). In this embodiment, both the AFE 252 and the processor 256 are used as the specimen monitoring circuit, but in another embodiment, either one of the circuits can perform the specimen monitoring function. The processor 256 can include one or more processors, microprocessors, controllers, and / or microcontrollers.

[0041] A non-transitory memory 253 is also included within the ASIC 251 and can be shared by or distributed among two or more of the various functional units within the ASIC 251. The memory 253 can 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 specimen sensor 104, receives measurement data from the sensor, outputs the data in digital form to the processor 256, and then the processor processes the data to obtain final discrete values and trend values of the specimen, etc. Next, this data can be supplied to the communication circuit 258 and transmitted via an antenna 261 to a reader device 120 (not shown), where it can 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 (depending on environmental drift) and continues without interruption over the entire life of the sensor. In some embodiments, the sensor control device 110 can maintain time by causing an interrupt after a predetermined number of seconds (e.g., every second or every minute, etc.), and the interrupt causes a software or hardware counter to be incremented. The value of the counter reflects the number of predetermined time spans that have elapsed since the sensor was activated. For example, if an interrupt occurs every fraction, the value of the counter reflects the fraction of time that has elapsed since the sensor control device 110 was activated. The functional components of the ASIC 251 can also be distributed across two or more separate semiconductor chips.

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

[0044] Exemplary Embodiments of Episode Investigation Software (EIS) Using EIS, past, current, and / or future episodes can be detected. As used herein, the term "episode" does not refer to all changes at the analyte level, but rather to changes that are significant causes of fluctuations in the analyte of interest, such as high and low glucose peaks. An episode can also include clinically significant glucose excursions or events, such as rapid increases and decreases in glucose levels. Different conditions, such as the magnitude of the analyte measurement, the rate of change between a series of analyte measurements or between other measurement groups that are temporally close, the number of analyte measurements (or length of time) that violate a threshold magnitude, a threshold violation based on the area under the integral of a series of analyte measurements, any combination of these, etc., can be used to identify a set of analyte-level measurements as an episode. Such episode detection conditions are described in U.S. Patent Application Publication No. 2013 / 0085358, which is hereby incorporated by reference in its entirety for all purposes.

[0045] As described above, EIS can be executed on a number of different devices, including a mobile device (e.g., reader device 120) having an interface function with a sensor, or a mobile device (e.g., a general tablet or mobile phone) not having an interface function with a sensor.

[0046] Alternatively, EIS can be partially executed on an electronic device located in the same location as sensor 104 to transmit data for confirming the occurrence of each episode to a device having a user interface (UI) function, such as a mobile device or a personal computer (PC). In such an embodiment, sensor control device 110 performs a substantial amount of algorithmic processing on the collected measurement data to determine whether the measurement data meets a predetermined condition regarding the occurrence of an episode. Next, sensor control device 110 can transmit a confirmation that an episode has occurred (and any desired information, such as the type, time, location, etc., regarding that episode), and optionally, the original measurement data as well.

[0047] The EIS can be stored in the non-transitory memory of a device (e.g., 120, 130, 150, 160) that executes software (e.g., multiple instructions). The EIS can be executed by the processing circuit of the device. To the extent that there is user input (such as text input, mouse click, touch selection, etc.), this is done via a user interface, such as a touch screen, or user input 121 of the reading device 120, etc. The user input is received and read (or interpreted) by the processing circuit, and then appropriate measures are taken (such as displaying a new screen, displaying a check mark, modifying a selection list, etc.).

[0048] The reading device 120 of the embodiment of FIG. 1A may be a smartphone that executes one or more downloadable software applications, generally referred to as "apps". The EIS can be configured and distributed as such a downloadable app. Also, the EIS may be resident software directly installed on the reading device 120 at the time of manufacture (before distribution or sale). The EIS can include software instructions for interfacing with the sensor control device 110 and software instructions for processing the data received from the sensor control device 110 into a value that the user can read and that indicates 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 for a diabetic patient or other user). Alternatively, the EIS can operate with another software application that communicates with the sensor control device 110, such as a glucose monitoring application, to receive and process raw data. The glucose monitoring application can likewise be configured and distributed as a downloadable app or be resident software installed at the time of factory shipment.

[0049] Exemplary Embodiments of a Mobile Device with Episode Investigation Software (EIS) Although not limited thereto, for ease of explanation, with respect to the reader device 120, the EIS will be described as a downloadable app incorporating a glucose monitoring command.

[0050] The reader device 120 can automatically receive a measured value of the glucose level from the sensor control device 110 or request it from the sensor control device, so that the EIS can utilize the measured value, or transmit the measured value to a device that executes the EIS. The reader device 120 can process the measured value based on an episode identified by the EIS and transmit warnings and / or prompts to the patient. The reader device 120 can display the rate of change of the sample, reports, tables, graphs, and other representations of the measured value of the processed glucose level, and one or more of the input actions (diet, insulin, etc.) generated by the software of the reader device 120 or the EIS used by the HCP and the patient.

[0051] The reader device 120 can receive the measured value of glucose directly from the sensor control device 110 or indirectly (in the case of a primary / secondary receiver system). Additionally or alternatively, in some embodiments, particularly in vitro or non-sensor measuring devices, the measured value of glucose, for example, the blood glucose value, can be obtained from a body fluid sample of the test strip or by the patient manually inputting it into the reader device 120. Regardless of whether the measured value of glucose is obtained by manual input or from the sensor control device 110, it can be transferred to the EIS.

[0052] The sensor control device 110 can be used in a continuous mode where measured glucose levels are repeatedly collected and automatically transmitted (i.e., communicated in real-time) by the sensor control device 110 to the reading device 120 every few seconds, every few minutes, for example, every 1, 5, 10, 15 minutes, etc. Alternatively, the sensor control device 110 can have sufficient memory, for example, memory sufficient to hold a large number of measured glucose levels automatically collected for up to 8 hours, until it is transferred to the reading device 120. The patient can use the reading device 120 to obtain measured glucose levels manually or "on demand" by a data request (e.g., NFC scan) initiated by the patient to the sensor control device 110. This can include all measured glucose values in the memory of the sensor control device 110, or untransferred measured values to the reading device 120, measured values collected in a recent period, or a subset of a predetermined number of most recently collected measured values (e.g., 2, or 3, etc.).

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

[0054] The masked version encourages the patient to follow normal diet, exercise, and medication behaviors without being affected by what the patient may know about glucose levels or episode types. The reception of data from the sensor control device 110 is performed at frequent intervals, such as at least once every 8 hours or other intervals, to obtain a number of glucose level measurements. The EIS can prompt the patient to scan the sensor control device 110 if necessary, or can use a reminder application.

[0055] With the unmasked version of the EIS, the user can access more functions, sometimes all functions. In certain embodiments, the masked and unmasked versions of the application do not exist on the reader device 120 simultaneously. In another embodiment, the masked and unmasked versions can exist on the reader device 120 simultaneously. In yet another embodiment, the two versions can exist within one application and can be switched from one version to the other using a software switch accessible by the HCP.

[0056] As described above, the EIS can be installed on the reader device 120 in any manner. The glucose monitoring application can be installed on smartphones that run various operating systems such as ANDROID (registered trademark), iOS, etc. It can be installed using standard installation methods. For example, for an "ANDROID"-based smartphone, an apk file can be sent via email to the reader device 120 and installed by executing the file.

[0057] After installing the EIS if necessary, the patient and the reading device 120 can be registered with the server 130 and associated with each other. A temporary username can be given to the patient, or a permanent username can be assigned. 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 set of unique alphanumeric characters. The reading device 120 can be identified by a set of any unique identifiers, such as an IMEI number or a MAC address, associated with the reading device 120.

[0058] FIG. 2 shows an exemplary embodiment of a graphical user interface (GUI) display screen 200 that can be displayed when the EIS is launched on the display 122 of the reading device 120. In this embodiment, the display screen is a touch screen. Here, the display screen 200 is a home page 200 that can include a plurality of fields that can be selected by the user. These fields can be selected when the user touches (or, in another embodiment, clicks with the mouse cursor, etc.). For ease of reference, these fields will be referred to here as buttons.

[0059] The home page 200 can have one or more menu buttons 248, a glucose check button 264, a logbook button 259, a daily graph button 265, a sensor start button 270, an episode button 275, a memo addition button 280, and a sensor status area 290. The sensor status area 290 indicates whether the sensor 104 is operating, malfunctioning, or the period until it malfunctions. The exemplary functions of each home page button will be described below.

[0060] To log in to server 130, click the menu button 248 and select the login field 249 as shown in the exemplary embodiment of FIG. 3A, and the login screen 262 as shown in the exemplary embodiment of FIG. 3B will be displayed. Next, the user can enter the user's username and password to log in to server 130. In some embodiments, the EIS requires the user to log in to server 130 first before automatically uploading data to it. After logging in, when the menu button 248 is pressed, different menu options will be displayed 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. For example, when the sensor 104 is replaced after about 14 days, the activation step is repeated. In one embodiment where the reader device 120 communicates with the sensor control device 120 via an NFC link, the reader device 120 can be held within a proximity communication range of about 3 inches (about 7.6 cm) or less from the sensor control device 110, for example. If necessary, the reader device 120 can be moved closer to the sensor control device 110 until an audio and / or vibration or other connection indication is generated to indicate that communication has been established. After the audio or vibration occurs, the reader device 120 can be held in place for about 1 - 2 seconds until another audio and / or vibration indicating that the sensor 104 (or the sensor control device 110) has been activated occurs. In some embodiments, the measurement of the glucose level and transmission to the reader device 120 are not performed until a predetermined time for properly initializing the sensor 104 after activation has elapsed. In some embodiments, this "warm-up period" is 60 minutes, but the length of time depends on the sensor itself and can be longer, shorter, or not required at all.

[0062] Further, in FIG. 2, after the sensor 104 is activated, the glucose level can be checked using EIS. When the glucose check button 264 is selected, the reader device 120 obtains one or more glucose measurement values from the sensor control device 110 using one of the communication methods described herein, such as an on-demand method. In addition, the measurement values can be automatically transmitted from the reader device 120 to the server 130.

[0063] After the measured value of the glucose level is transferred, the screen 121 of the reader device 120 can automatically display a result screen 422 as shown in the exemplary embodiment of FIG. 4A. The result screen 422 can include one or more of a display of the measured value 455 of the current glucose level, a trend arrow 456 indicating the direction and / or rate of change of the measured value of the glucose level, and a graph 457 of glucose. A memo button 458 can also be present on the result screen 422. In some embodiments, a warning message can be displayed indicating that the result is not up-to-date if the result has elapsed more than a predetermined time, such as 3 minutes.

[0064] The measured value 455 of glucose can be the measured value of the current glucose level up to a predetermined level, for example, 350 mg / dl. It should be noted that the measured value exceeding the predetermined level can be displayed as the predetermined level. The trend arrow 456 can be one of a plurality of indicators, such as five different relative arrows. In a specific embodiment, the upward arrow can indicate that the measured value of the glucose level is rising rapidly at a predetermined high rate, for example, higher than 2 mg / dl per minute. The arrow pointing to the upper right can indicate that the measured value of the glucose level is rising at a predetermined moderate rate, for example, at a rate of 1 - 2 mg / dl per minute. When the measured value of the glucose level is changing upward or downward at a predetermined low rate, for example, less than 1 mg / dl per minute, the arrow can point to the right. The arrow pointing to the lower right can indicate that the measured value of the glucose level is decreasing at a predetermined moderate rate, for example, at a rate of 1 - 2 mg / dl per minute, and the downward arrow can indicate that the measured value of the glucose level is decreasing rapidly at a predetermined rate, for example, exceeding 2 mg / dl per minute.

[0065] The glucose graph 457 can display the measured values of the glucose level within a predetermined time range, for example, the past 8 hours, and the time range can be increased or decreased by using the zoom button 459 of the reading device 120 or the standard two - finger zoom technique. The time range can be shifted by dragging the plot left or right with a finger. A symbol indicating that the time of the reading device has been changed, for example, a clock symbol, can be displayed on the graph. The change in time may result in gaps, overlapping measured values, or hidden data in the graph that need to be recognized by the HCP, patient, and / or caregiver.

[0066] FIG. 4B is a diagram showing an exemplary embodiment of a glucose graph 457 after the zoom button 459 is pressed. Below the graph 457, there is a numerical display indicating each dosage, and a dosing timeline 450 showing the dosing time and amount of rapid-acting insulin (upper) and long-acting insulin (lower) during the display period, which is appropriately aligned to indicate the dosing time. Below the timeline 450, there is a numerical display indicating the carbohydrate intake amount, and a meal timeline 451 showing the meal or food intake time and amount during the display period, which is appropriately aligned to indicate the intake time.

[0067] The memo can be used to track one or more actions such as food intake amount, insulin, dosing, exercise, sleep, etc. FIG. 5 is a diagram showing an exemplary embodiment of a memo input page 500. The memo can be input by pressing the memo button 458 on the result screen 422, pressing the memo addition button 280 on the home page 200, and collecting data on the logbook page accessible by pressing the logbook button 259 on the home page 200. The memo can be added by scanning barcodes or chips of foods, etc. The memo input page 500 can have one or more checkmark fields for characterizing the memo as information transmission regarding one or more types of medicines such as food intake amount (field 581), rapid-acting insulin (field 582), and long-acting insulin (field 583), exercise (field 584), dosing (field 585), etc. The illustrated checkmark field has an empty box where the field value changes back and forth between a yes value with a checkmark and a no value (empty box) without a checkmark when the user touches it. Other fields such as a checkmark field or a drop-down menu having three or more values can also be used.

[0068] More specific information regarding the amounts of food and insulin can be entered into the input box 586 located below the corresponding checkmark field. At least one free-form text box 587 can be provided for entering text memos regarding the user's activities (e.g., exercise time, dosage of a particular medicine, type of food consumed) or other circumstances the user wishes to record. The text can be entered via a keyboard (or a virtual keyboard on a touch screen), or orally, for example, using a speech recognition function. After entering the memos, they can be saved, and one or more identifiers, such as icons indicating the added memos, are placed at appropriate times on the graph of various glucose levels. For example, a meal graphic icon representing the food consumed, or a medicine graphic icon indicating insulin injection, can be added to the daily graph 766 (see FIG. 7) or the glucose graph 457 along with the intake amount or dosage.

[0069] Referring again to FIG. 2, pressing the logbook button 259 can open the logbook screen 600, an exemplary embodiment of which is shown in FIG. 6A. The logbook screen can include each data collection from the sensor control device 110 and an input 661 for additional memos. It can include the date and time of each input, along with the current glucose level, the directional change rate arrow 456, and the time change symbol 457 and memo symbol 458. Selecting an input can open a summary screen 601 with detailed information related to the selected input, including a graph 455 showing the history of glucose levels before and after the time of the selected logbook input, the directional change rate arrow 456, a memo 662, a free-form memo 663, and / or an image or the like added by the user, 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 the measured values of the glucose level on the day 769 shown at the top of the page and / or a memo input by the user, for example, graphs 450, 451 of the timeline related to food intake and insulin use identified by symbols. For example, icons 768 representing exercise time, drug dosage, etc. can also be shown on the glucose trace itself in graph 766. The graphs can share the same horizontal time axis, and can graphically display how the glucose level is affected by exercise, food, insulin, or drugs. The time scale of the graph can be changed by pinching or expanding the graph with two fingers, and can be shifted by dragging the graph left or right. The time increment on the graph can be adjusted, for example, from 30 minutes to 9 hours, allowing for a detailed view over several hours or an overview of about one and a half days, for example. Selecting any displayed symbol, such as drug dosage, exercise, food intake, or insulin use, can open a pop-up screen that displays the memo entered at that date and time.

[0071] The daily graph 766 of the measured values of the glucose level is similar to the glucose graph 457 in FIG. 4B. The daily graph 766 can display the measured values of the glucose level up to a predetermined level, for example, 350 mg / dl. It should be noted that measured values exceeding the predetermined level can be displayed as the predetermined level. If the data collection frequency from the sensor control device 110 is not sufficient, for example, if it is not performed at least once every 8 hours, gaps may appear in graph 766. When the time of the reading device 120 is changed, a clock symbol is displayed, and there is a possibility of gaps, overlaps, or hidden data occurring.

[0072] As described above, adding a note is beneficial in determining the pattern of glucose levels. However, for the patient, remembering to add a note can be a problem, especially after a long time has passed since an event occurred. In addition, it is very difficult for both the patient and the HCP to investigate the logbook to correlate specific activities in the note with the glucose level.

[0073] In some embodiments, when the reader device 120 receives a measured value of the glucose level, an episode can be detected by the EIS. By adding a note and other information when a specific episode occurs, the ability to correlate a specific action with the corresponding change in the glucose level can be significantly improved. When the EIS detects an episode, it can prompt the patient to enter information, and using the patient's response to the prompt and other notes entered by the patient, it is possible to evaluate the actions that may have caused the change in the glucose level.

[0074] The detection of an episode can be configured via the user interface of the server 130 or the EIS. This process may be the same for both. On the reader device 120, the menu button 248 can be selected from the EIS homepage 200 (see FIG. 2). Selecting the settings button 852 from the drop-down menu shown in FIG. 8 can start the settings wizard and open the daily event settings screen 900 of FIG. 9A. The daily events can include breakfast, lunch, dinner, bedtime, and other events, and can be displayed on the corresponding time buttons 985 together with the default times for each of these events. Selecting the time button 985 allows the user (e.g., HCP, patient, and / or caregiver) to set these times according to the times common to diabetic patients and the time zones used for the specific display described below.

[0075] After setting the time, selecting the Next button 986a can open the episode setting screen 901, an exemplary embodiment of which is shown in FIG. 9B. On screen 901, by selecting the checkbox 987 corresponding to the desired episode type, the episode type to be detected can be selected. Episodes can include one or more of bedtime, wake-up time, actual or impending low episodes (low glucose levels, e.g., values below a predetermined value), actual or impending high episodes (high glucose levels, e.g., values exceeding a predetermined value), actual or impending rapid increase episodes (e.g., an increase exceeding a predetermined percentage of the glucose level, e.g., an increase exceeding 1 mg / dl or 2 mg / dl per minute), and actual or impending rapid decrease episodes (e.g., a decrease exceeding a predetermined percentage of the glucose level, e.g., a decrease exceeding 1 mg / dl or 2 mg / dl per minute). The triggers for episodes, e.g., levels and rates of change, can be selected or customized from predetermined options. Further episodes can be defined by the user of the EIS.

[0076] After selecting the episode type, selecting the Next button 986b will display the event setting screen 902, an exemplary embodiment of which is shown in FIG. 9C. On screen 902, the user can select the times at which episode detection can occur by selecting the fields 988 (e.g., checkboxes) corresponding to the times. The times can include one or more of after breakfast, after lunch, after dinner, at night, and times related to customized events. Selecting the Save button 989 can save the configuration and activate episode detection.

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

[0078] In some embodiments, the EIS can have an optional automatic configuration wizard that facilitates the configuration of episode detection that best suits the patient's needs. The automatic configuration can be performed from either the reader device 120 or the server 130, and episode detection can be enabled immediately after the automatic configuration is completed or after review and manual implementation by an HCP, caregiver, and / or patient.

[0079] An exemplary embodiment of the automatic configuration 1000 of the option is shown in the flowchart of FIG. 10. This flowchart starts in step 1010 with the patient wearing the sensor control device 110 for a predetermined period, for example, 1 to 2 weeks, to establish a reference glucose profile. In the first example where the patient wears the control device 110, the resulting profile will typically be the patient's first or "reference" profile. Of course, since the profile can be modified any number of times, for example, during a visit for follow-up observation with a medical professional, this method can use any glucose profile. During this time, the EIS can be executed using the glucose profile data collected in the mask mode where the patient is not informed of the measured glucose levels, or when the reader 120 is not masked. In some embodiments, the user can enter a memo during the automatic configuration period, while in other embodiments, the memo function is disabled. In step 1020, at the end of the automatic configuration period, using either of the techniques disclosed in U.S. Patent Application Publication Nos. 2014 / 0088393A1 and 2014 / 0350369A1, which are incorporated herein by reference, the data can be analyzed by the EIS of the reader 120 or the glucose monitoring application to determine the characteristics of the reference glucose profile in step 1010.

[0080] In step 1030, the main characteristics can be determined, and rules for their prioritization can be applied to determine which characteristics are most important for the patient. For example, the EIS can have an automatic time zone activation function that determines whether to enable the detection of one or more types of episodes by the EIS based on, for example, the user's sample level profile and / or the historical time when the occurrence of episodes is relatively high. In some embodiments, this function can enable the EIS to operate to detect one type of episode (such as hypoglycemia) in the first time zone and to detect a second different type of episode (such as rapid hyperglycemia) in a second different time zone. In another embodiment, this function can enable the EIS to operate to detect all types of episodes in a specific time zone. These two combinations can also be implemented. When the EIS is effective during a specific time zone (for example, from 8:00 am to noon, from 6:00 am to 8:00 am, etc.), the EIS can operate during that time every week to detect the desired episode type, while at all other times, the EIS is disabled. Different time zones can be subdivided to be enabled based on the day of the week (for example, only on Monday, Wednesday, and Friday from 8:00 am to noon every week, or only on the weekend from 6:00 am to 8:00 am). In these and all embodiments described herein, the EIS can operate continuously or repeatedly in real time as described herein to detect episodes or can operate only at specific times to detect episodes.

[0081] In one exemplary embodiment, the prioritization rules or conditions for enabling a specific time zone for low glucose episode detection are set as follows: Enable the EIS in the first time zone when: - The likelihood of low glucose in the first time zone is "high", and - The likelihood of variation below the median in the first time zone is "high" or "medium", Otherwise (an "else if"), enable EIS during the first time period if the following conditions are met: - The likelihood of low glucose in all other time periods is "not high", and - The likelihood of low glucose in the first time period is "moderate", and - The likelihood of variation below the median in the first time period is "high" or "moderate".

[0082] In another exemplary embodiment, the prioritization rules or conditions for enabling specific time periods for high glucose and rapid increase episode detection are set as follows: Enable EIS during the first time period if the following conditions are met: - The likelihood of low glucose in all other time periods is "low", and - The likelihood of median glucose in the first time period is "high", and - The likelihood of variation below the median in the first time period is "high" or "moderate". Otherwise (e.g., an "else if"), enable EIS during the first time period if the following conditions are met: - The likelihood of low glucose in all other time periods is "low", and - The likelihood of median glucose in all other time periods is "low", and - The likelihood of median glucose in the first time period is "moderate", and - The likelihood of variation below the median in the first time period is "high" or "moderate".

[0083] Similarly, other combinations of logic can be implemented in the same manner as these examples. The severity of a risk or characteristic (e.g., low, medium, or high) can be determined by referring to the most recent or other selected glucose profiles of the diabetic patient, multiple selected glucose profiles, and / or other glucose history data. Techniques for defining specific risks or characteristics (e.g., the likelihood of low glucose, central glucose value, variability below the median) and various techniques for quantifying the relative severity of a risk or condition (e.g., low, medium, or high), all of which can be used in the embodiments described herein, are described for all purposes by reference in the following references, the entire contents of which are hereby incorporated by reference: 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] In step 1040, using the prioritized characteristics, appropriate settings for episode detection can be determined. In step 1050, the configured settings can be set in the EIS and episode detection can be initiated. The automatic configuration 1000 for episode detection can be implemented instead of or in addition to the manual configuration. After the automatic configuration 1000 is completed, the HCP, caregiver, and / or patient can access the entire range of configured settings and further customize them.

[0085] As described above, episode detection can be used for one or more in-vivo specimen monitoring systems (both mask and non-mask modes), and in-vitro systems coupled to in-vivo systems, including, for example, in-vitro systems integrated with in-vivo systems. In a non-mask specimen monitoring system, episode detection can be performed a) each time a glucose level measurement value is transferred from the sensor control device 110 to the reader device 120, b) periodically, for example, every 5 minutes or every 15 minutes, or c) each time the user activates the EIS or the UI of the reader device. The transfer can be initiated by the patient or automatically prompted by the EIS. The automatic transfer prompt for glucose level measurement values can be configured to occur at a predetermined time or interval, for example, at bedtime every day or at least once every 8 hours.

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

[0087] The mask in-vivo specimen monitoring system and the ex-vivo system function in the same way as the non-mask specimen monitoring system, but may have some differences. For example, in the mask system, in order not to affect the patient's behavior, the glucose level data may not be displayed. Similar to the non-mask system, when the measured value of the glucose level is transferred to the reading device 120, episode detection may occur. However, in the mask system and the ex-vivo system, the patient is not prompted that an episode has occurred, and for example, the patient can be prompted to respond to questions, including questions about the activities and states when the episode occurred. In order to further reduce the impact on the patient's behavior, episode detection can be performed using the measured values of the glucose level over a predetermined period, such as a period from 24 hours ago to the current time, a period from 24 hours ago to 2 hours before the current time, etc.

[0088] In the ex-vivo system, the measured value of the glucose level can be manually added to the EIS, or if the ex-vivo system is equipped with communication support, it can be wirelessly transmitted to the EIS. Episode detection is performed on the data input to the EIS. If an episode is detected, the patient is prompted to respond to questions about the episode. The patient's response is time-stamped and can be input via a touch screen and / or a voice recorder. The measured value of the glucose level and the patient's response can be uploaded to the server 130. In certain embodiments, integration can be included and the ex-vivo measurement system can be coupled to the in-vivo system. For example, both the ex-vivo test strip port and the circuits for in-vivo and ex-vivo measurements can be housed in the in-vivo housing. In such cases, the episode detection and patient response input functions 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 inputs. Using the selected configuration parameters, the glucose level measurements can be repeatedly examined to search for patterns and define episode criteria. Episodes can be detected based on the defined criteria and displayed on the result screen. When the episode detector algorithm is active, glucose data preceding the period of interest can be included as an input, ensuring accurate episode detection and the start time, particularly the accurate start time of an episode that may span the start time of the period of interest. In addition, the patient's responses to questions regarding the detected episodes can be stored in both the reader 120 and the device executing the EIS.

[0090] Either the glucose monitoring application or the EIS can act on the same series 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. Without overwhelming the patient to respond to all detectable episodes, a clinically most meaningful subset of episodes suitable for the patient to respond to can be identified. The EIS can detect all episodes, and as the patient becomes better able to control their glucose levels based on their actions, new episodes can be added to, or replace, the episodes within the subset detected by the glucose monitoring application to further improve the control of the patient's glucose levels.

[0091] Since the glucose monitoring application and the EIS can have different configuration settings, detected episodes are not transferred from the glucose monitoring application to the EIS. In some embodiments, one or more of glucose data, patient responses, and timestamps are transferred. The EIS can execute an episode detection algorithm and match the patient's response to the detected episode based on the timestamp. In addition, the EIS can execute routines for identifying and characterizing new episodes.

[0092] As described above, if one or more episodes have been detected within a recent predetermined period, e.g., within the most recent 8 hours, the patient can be notified by the EIS and it can be displayed on a result screen 1122, an exemplary embodiment of which is shown in FIG. 11. The result screen 1122 is similar to the result screen 422 in many respects. In addition to the current glucose measurement value 455, the screen can include one or more of a trend arrow 456, a glucose graph 457, and a detected episode button 1190. Selecting the detected episode button 1190 can open one or a series of episode response screens that display questions related to the detected episode. For each detected episode, an individual episode response screen can be displayed. For example, if three episodes have been detected, a series of three response screens can be shown and the user can process each one sequentially.

[0093] In another embodiment, a "notification" function such as is commonly incorporated into a smartphone operating system can be used to notify the user of an episode and provide the user with a mechanism to activate the episode response screen. Further, both the detected episode button and the notification function can be used simultaneously.

[0094] FIG. 12A is a diagram showing an exemplary embodiment of the 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 including a highlighted portion 1293 of the episode can be displayed. Here, the highlight is a shadow in the lower space of the graph curve and can be a different color from the curve itself. In some embodiments, the graph 1292 may be similar to the aforementioned graph 766 and may also include a dosing timeline 450 and a meal timeline 451 that can be displayed above or below the graph 1292. The area 1299 of the glucose value in the graph is considered to be within the normal or acceptable range and can be indicated by a line or shadow 1299 drawn therein, etc.

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

[0096] In another embodiment, the user is not provided with the option or functionality to generate a custom response by the mobile application (which can also be blocked in some embodiments in web-based software). If desired, additional fields can be provided where detailed information about the episode, such as free text notes, can be added. However, in many embodiments, the user still has to select a preset option or response from each of one or more presented selection lists (e.g., at least one response to each presented question, which requires selection from a selection list, and in some embodiments, the user has no option to add a response to a new selection list or customize the selection list, except to delete responses from the selection list that do not apply to the user as described herein).

[0097] Techniques for managing diabetes (or other medical conditions) can be improved by embodiments that do not provide the user with the option or ability to enter custom responses, but rather cause the user to select from options in a pre-set list of selections. Such embodiments can increase the likelihood that the user will consider which response is most appropriate, e.g., which cause is most likely to have led to the occurrence of an episode. This is important because consideration of the potential causes of an episode (or other appropriate questions regarding the episode) is often most accurate when done simultaneously with (or immediately after) the occurrence of the episode itself. Using responses from a pre-set list of selections results in generalized (avoiding over-specificity) and consistent responses, which can then assist and simplify the classification of responses and the analysis of data at a later stage. By avoiding custom responses, responses that the user may not actually be answering the question can be avoided. For example, in response to a question about what caused an episode, the user may perhaps return a custom response that is only an explanation of what they were doing when the episode occurred, for saving and consideration later. The user can still take such means via a memo input field, but it may also be optimal to force the user to respond to the pre-set list of potential causes, thereby forcing consideration of the issue at hand.

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

[0099] In addition, responses that are not applicable to the patient can, in this embodiment, be removed from the selection list 1298 by selecting the deletion of that response by clicking on the associated delete button 1297. The deleted response will not be displayed in subsequent instances that display that selection list.

[0100] If there are many responses that do not fit on the episode response screen 1210, the hidden responses can be viewed by scrolling the screen or on an additional screen. After responding to all questions regarding the episode, the next episode detected during the period when no response was made is displayed on the result screen 1100. This process of entering responses regarding the episode can be repeated for each episode that was detected and not previously responded to during that period. In some embodiments, only the most recent episode can generate a prompt for obtaining a response. If a response has already been obtained for the most recent episode, the system may not need to prompt again to obtain a response.

[0101] By enabling customization of the selection list 1298, the input request and reception processing from a specific user are customized for that user. The subjective burden or amount of effort that the user subjectively considers necessary to record information regarding the episode is relatively reduced. This, in turn, reduces the user's subjective resistance to information input, increases use by the user, and, as a result, improves the system's evaluation mechanism and can provide more robust data and more accurate feedback to the user or HCP. Acting based on that can reduce the user's glucose fluctuations and improve the quality of life.

[0102] Several questions can be associated with a specific episode. Each question can be displayed on its respective episode response screen. FIGS. 12A - 12C are diagrams showing non - limiting examples of response screens regarding the detected episode "sharp rise". FIG. 12A shows a first screen with the question 1294 "What is the suspected cause?" and two selected predetermined responses. FIG. 12B shows a second screen with the question "Were there any symptoms of a rise?" and one selected predetermined response. FIG. 12C shows a third screen with the question "Was treatment for the rise done?" and one selected predetermined response.

[0103] Depending on the detected episode, the number of screens and questions may be few or many. The questions and predetermined responses can vary according to the detected episode, but in many embodiments, the displayed first or second screen queries the user regarding the cause of the episode, another displayed first or second screen queries the user regarding the symptoms associated with the episode, and the third screen, if any, queries the user regarding what treatment, if any, has been administered.

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

[0105] Returning to FIG. 2, by selecting the episode button 275, a list of all detected episodes can be displayed. FIG. 13 is a diagram showing an exemplary embodiment of the episode list 1300. One or more of the episode type 1391, the date and time of the episode 1392, the color code field 1393 for the episode type, and the icons 1394, 1395 indicating whether a response is recorded can be displayed. In FIG. 13, the response indicator 1394, for example, an icon in the shape of an eye, can indicate that the patient has recorded a response to the question regarding the episode, and the non-response indicator 1395, for example, a checklist icon, can indicate that the patient has not recorded a response. By clicking on the episode entry, the patient can view the previously selected response to the episode (FIGS. 12A - C) and can enter a response if the patient has not yet responded.

[0106] The patient, caregiver, and HCP can understand how the patient's behavior affects an episode and generate several reports that can help mitigate the impact of the behavior. The reports can be generated by the reading device 120 using locally stored data or generated by the server 130 and downloaded to the reading device 120 or printer.

[0107] Returning to FIG. 8, selecting the response report button 853 can open an exemplary response report screen 1400, shown in FIG. 14A, that can display the type 1410 of the episode having the recorded response. The button 1420 can be used to adjust the date range. Clicking the drop-down button 1430 can expand the response report screen, shown in FIG. 14B in an exemplary embodiment, and show one or more questions 1440 related to the episode type, the responses 1460 entered by the patient, and the total number of times the response was selected 1450.

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

[0109] Web-accessible episode investigation software (EIS) Regarding a computing device such as the local computer 150 or the remote computer 160, the EIS is described as a software package that is provided by the server 130 and can be accessed by the web browser of the computing device 150 or 160. Mobile devices (e.g., tablets and smartphones) often have a web browser. If the EIS is already installed on the mobile device as an app, there is no need to access the EIS via the web browser, but it is considered a subset of such computing devices.

[0110] When the sensor control device 110 transmits sample-level data to the reading device 120, the reading device 120 can be programmed to upload the data to the database or the server 130 via a wireless and / or wired communication path (either as raw data in the same general form as received from the sensor control device 110 or as data algorithmically processed using, for example, its own data processing algorithms that can apply temperature compensation or other calibrations to the data).

[0111] After uploading (and the server 130 performs all necessary data processing that the reading device 120 did not perform), the data can be saved and associated with the diabetic patient so that the diabetic patient, HCP, and / or caregiver (or others) can access the data using the web browser that presents the EIS. In many embodiments, the EIS is designed to present the data in different report formats that convey the basic 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 basic causes of glucose fluctuations.

[0112] An administrator, who is a technician responsible for managing Server 130 and / or related accounts, can provide the URL used by a web browser to access Server 130. The administrator can be responsible for locking and unlocking accounts. There can be multiple user account types, including those related to administrators, HCPs, and diabetic patients or caregivers, etc. Each account type can have a different set of functions 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 related functions. A user can have multiple different account types.

[0113] The administrator is usually a person with clinical management responsibilities. The function of the administrator is to add HCP accounts. In many embodiments, the administrator cannot access the personal data or reports of diabetic patients or patients. HCP users can add patient accounts to the system. In many embodiments, HCP users can have full access to patient data and reports. HCP users can provide the initial user ID and password used by patients for the patients to access the data and reports of the EIS via a web browser and to configure the EIS on the reader 120 to automatically upload data to Server 130.

[0114] Upon logging in, an HCP user can select a specific patient from the patient list of patients related to that HCP. After selecting a patient, the HCP can usually generate a review session for that patient by selecting the option to generate a new session from the home screen. One opportunity for this measure to be taken is during a meeting or visit between the HCP (or their representative) and the patient.

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

[0116] There is a navigation bar 1610 on the left side of this home screen 1600. By selecting the session creation button 1602, a session can be generated. In some embodiments, this session creation button can be displayed only when new data that has not yet been viewed via the EIS is uploaded to the server 130 or when data is being uploaded after the date and time when 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 for this session can be generated using all of the data from the past up to that date and / or time.

[0117] A user (patient, caregiver, or HCP) can create a report 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 creation include a "Glucose Pattern Insights (GPI)" report, a daily report, an episode overlay report, an episode summary report, and a response report. These various report types are described in more detail herein.

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

[0119] In this embodiment, a new report can be generated by selecting an appropriate field 1614, which is a plus symbol (+) next to the title of each report. After generating a new report, a link to that report is placed at a position (e.g., below) associated with a specific session 1612 within the navigation bar 1610. As long as multiple reports of a specific type are generated, the list of those reports can be expanded or collapsed by selecting that field 1616.

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

[0121] Each report generated using the EIS can be based on glucose data from one or more days from a diabetic patient. The EIS can provide a graphical interactive data selection tool and assist the user in easily (and quickly) identifying the days that contain the most suitable data for analysis. Next, these days can be individually selected and used for report execution.

[0122] An exemplary embodiment of the data selection tool 1700 is shown in FIGS. 17A and 17B. The data selection tool 1700 can be displayed to the user by selecting a report generation option (such as by selecting field 1614 in FIG. 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 sub - division region 1703 (e.g., each unit or box), which may be bounded or unbounded within the grid 1702, corresponds to one day, and the number of days in a week is shown in one row (e.g., with Sunday at the left - most end and Saturday at the right - most end). In FIG. 17A, one example of region 1703 is shown by the dashed enclosure. The number of days per row is not limited to 7 days, and any number of days greater than or equal to 1 day per row can be displayed. Any number of rows (e.g., 1, 2, 3, 4, 5, 6 rows, etc.) can be displayed simultaneously. The vertical scroll bar 1704 can assist the user when scrolling through the many rows that can be displayed, and its upper limit can be determined by the number of weeks for which data is available. For example, if data for 10 weeks is displayable, but 5 rows of data are displayed on the screen at a time, the user can scroll through the data for 10 weeks using the vertical scroll bar.

[0124] The top - most and bottom - most rows can each be the most recent or current week, and the oldest week, respectively, measured from the date and / or time of session 1612, with rows arranged in a temporally consecutive backward - tracing order in between. Alternatively, the weeks can be displayed in the reverse way, like a normal calendar, where the earliest week in time is at the top and each subsequent row below is one week later in time.

[0125] In another embodiment, for example, the grid can be configured such that the most recent date is displayed at the top and the oldest date is displayed at the bottom, or vice versa, or such that multiple dates can be vertically displayed in a single column. However, in this arrangement, many dates cannot be displayed simultaneously.

[0126] Within each unit 1703 of the grid, there is a graphical display 1706 of glucose (or other analyte) data for a particular date. A label 1708 indicating the day of the week and / or the date can also be displayed inside or adjacent to the unit 1703. The graphical display, or graph 1706, can have an appearance similar to the graph 1292 described in connection with FIGS. 12A - C, or other glucose graphs described in this specification, including references incorporated herein by reference. Days without data displayed, such as day 1714, can be left blank, grayed out, shaded, or indicated as missing data.

[0127] The graph 1706 can include a trace 1710 of the glucose value for the corresponding date, as a continuous series of measured data points, or as either a dashed or solid line, as shown in the figure. If each unit 1703 is directly adjacent to the others, the trace 1710 can be continuous from one day to the next within each row, as shown in the figure. Each graph 1706 can include a display or marker 1712 for each episode detected on the corresponding date. The marker 1712 can have any desired shape (e.g., circle, ellipse, line, curve, square, polygon, triangle, etc.), color, or appearance. For example, the marker 1712 can be the vertical line shown in the figure, or the shaded area below the trace shown in FIG. 12A.

[0128] The shape, color, and appearance can be arbitrarily combined and used for the marker 1712. For example, an episode of the first type (e.g., high glucose) can be indicated by a first marker 1712-1 of the first shape and / or color, and an episode of a second different type (e.g., low glucose) can be indicated by a second marker 1712-2 that has the same shape but a different color. Alternatively, one color can be used to indicate all types of episodes, in which case different episode types are indicated by the shape. 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 either case, they are indicated by colors of different severities (e.g., yellow for mild, orange for moderate, red for severe) or by the darkness or opacity of one color. The severity can also be indicated by the size of the marker 1712 (e.g., the vertical line gets thicker or the shape gets larger as the episode becomes more severe) or by other different shapes or appearances of the marker 1712.

[0129] Next, the user can select each day within the grid 1702 that has the data they want to use for report generation. As can be seen from FIG. 17A, the tool 1700 provides an efficient overview of the user's large amount of glucose data that may span a long period. This results in the improvement that the user can select the data more easily and efficiently to generate a report. For example, since the daily data is displayed in a graph format, the user can more efficiently identify and immediately and easily select the days with the pattern or repetition of the glucose trace 1710. The days on which a particular type of episode occurs or the group of days on which an episode occurs at a particular time can be easily identified and selected. Similarly, the days with the lowest glucose fluctuations and / or episode occurrences can be easily identified and selected, and the behavior trends of diabetic patients on these days can be searched.

[0130] In addition, the embodiments of the tool 1700 described in this specification can identify and select the most appropriate dataset by the tool 1700 in a way that reduces the burden on the user compared to conventional methods, thereby increasing the likelihood that the user can use the EIS to investigate and identify the causes of glucose fluctuations and / or episode occurrences, improve or treat these causes, and improve the health and lifestyle of diabetic patients or other patients, thus bringing improvements to the field of diabetes treatment.

[0131] On the displayed grid, the day can be directly selected by touching each day (in the case of a touch screen display) or by using the mouse cursor to select each day or a group of days. In either case, when a specific day is selected, only that selected day is selected (previously selected days or multiple days become unselected).

[0132] For example, while holding the first key (e.g., the control key), multiple days can be selected by selecting each desired day. In this case, all the selected days remain selected. By continuously pressing the second key (shift key) and clicking on the first and last days of a series of days, a group of days can be selected. In this case, each day intervening within that range is automatically selected by the EIS. The EIS can be configured so that days without data cannot be selected. For reports that depend on one-day data such as daily reports or reports that depend on a limited number of days of data, the EIS can be configured so that only a number of days less than or equal to the limited number of days can be selected.

[0133] An exemplary embodiment of group 1720 for a selected day is shown in FIG. 17B. Here, for each selected day, it is shown by applying a partially transparent coloring or shading. Other display methods can also be used, such as placing a prominent boundary around the selected day. As shown in the figure, the user can select non - consecutive ranges of days for use in generating a report. In some embodiments, for example, default day - number ranges such as the latest 7 days, the latest 10 days, the latest 14 days, etc. can be selected. Once one or more desired days are selected, the user can generate a report by selecting the report - creation button 1722.

[0134] Numerous exemplary reports are described herein and will continue to be described. These exemplary reports are presented and described in a form that can yield useful results, but they do not limit the precise ways in which information is presented and enables interaction with the user. Thus, all functions (graphs, icons, memos, tables, lists, traces, indicators, selectable fields or buttons, dropdown lists, responses, information arrays, information ordering, etc.) can be changed from the methods shown and described herein, and they still fall within the scope of this disclosure. Further, unless otherwise stated or logically unreasonable or impossible, any function can be added to (or omitted in) any different report type, and they still fall within the scope of this disclosure.

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

[0136] Along the glucose trace 1710, various icons 1804 are shown that indicate the memos entered on that day (as described with respect to FIG. 6B). As described above, each memo icon 1806 can include, by way of example, 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 memo, bedtime. Placing a cursor on a particular memo icon (or touching the memo icon in the case of a touch screen) can display an overlay popup window that includes additional information about the memo (e.g., the duration of the event, the time of event occurrence, calories consumed, the type of food and drink consumed, the amount of carbohydrates or calories ingested, the amount of fluid ingested, the amount and type of medication administered, the actual free form memo, etc.).

[0137] Icons 1805 indicating the normal times of event occurrence that can be set and adjusted by the user can also be further displayed. 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) that indicates the normal time the user goes to bed at night.

[0138] For example, a table 1807 listing and explaining each episode can be shown in the daily report 1800 below the graphical display 1806. The table 1807 can include the time when the episode occurred, the episode type, all information regarding the episode input by the user, such as suspected causes, symptoms, and treatments (see the descriptions regarding FIGS. 12A - C for example), etc. The table or list can also display the memo information of all memos input on that day, and other recorded information such as blood glucose levels. Each input in the table 1807 can be associated with a marker 1712 indicating the episode in the graph. In the table 1807, the user can classify the episodes and responses by day, by episode timestamp, by episode type, or by response.

[0139] With the navigation buttons 1802 (here labeled "Back" and "Next"), the user can scroll to move forward or backward one day in time, and days without data (if any) can be automatically skipped by the EIS. Selecting one of the buttons 1802 will result in the creation of a daily report 1800 for either the next day or the previous day. Each time a new daily report is displayed, it can be added to the appropriate position on the navigation bar 1610.

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

[0141] Here, marker 1812 is placed at 2:00 PM (as shown here, labels indicating the placement time of each marker can be optionally displayed). Marker 1814 is placed at 6:00 PM. This placement serves to filter all episodes, memos, and other information that occurred before 2:00 PM and after 6:00 PM in the daily graph 1806 and not include them in table 1807. Therefore, only the episodes and memos that occurred between 2:00 PM and 6:00 PM (including or not including these two end times) are considered. In this embodiment, only two episodes are displayed in table 1807. Thus, the filter 1810 can reduce the amount of information displayed in 1807, and the user can focus on the episodes that occurred in a specific time period. This can be important for days when a relatively large number of episodes are detected, such as in the case of FIG. 18B where approximately 14 episodes 1712 are shown in graph 1806.

[0142] Markers 1812 and 1814 can also be indirectly moved by selecting fields 1816 and / or 1818. These fields slide markers 1812 and 1814 simultaneously to the left (field 1816) or right (field 1818) so that both markers 1812 and 1814 maintain a certain interval (e.g., 4 hours as shown in the figure). Axis 1820 can have a number of discrete landing positions 1822 spaced at equal intervals, and the placement and movement of markers 1812 and 1814 are limited to these landing positions. For example, when marker 1812 is clicked and dragged to the left, marker 1812 jumps from one landing position 1822 to the next. Similarly, when field 1816 is selected, both markers 1812 and 1814 move one position 1822 to the left, and their respective times are changed from 2:00 PM and 6:00 PM to 1:00 PM and 5:00 PM.

[0143] In this embodiment, each landing position 1822 is one hour apart, although larger or smaller intervals can be used. In various different embodiments, the intervals between all positions 1822 can be, for example, 10 minutes, 15 minutes, 30 minutes, 60 minutes, 90 minutes, and 120 minutes. In another embodiment, there are no landing positions 1822, and in order to model continuous or analog movement from the user's perspective, markers 1812 and 1814 can take any position on axis 1820. Embodiments where landing positions 1822 exist can be said to have non-analog movement.

[0144] Filter 1810 can be included in any graph described herein, such as graph 1806, or other data representation that has a related table such as table 1807 listing episodes. The use of filter 1810 is not limited to specimen-level graphs and episode indicators, but rather can be used for filtering based on any type of information present in a report, such as segments of the data display of graph 1806 that do not have movement indicators, meal indicators, sleep indicators, pharmaceutical dosage indicators (e.g., LA insulin and / or RA insulin), text memos or comments, or overlay indicators (e.g., the specimen data itself). Further, filter 1810 can be used in any instance where it is desirable to concentrate the display of information from one data structure or visual representation (e.g., table 1807) into one part or portion of another data structure or visual representation (e.g., graph 1806), including non-medical applications.

[0145] In the embodiment of FIG. 18B, the filter 1810 is oriented in the horizontal direction (e.g., the X-axis direction), but in another embodiment, a filter 1810 oriented in the vertical direction (e.g., the Y-axis direction), a filter 1810 oriented in a third direction (e.g., the Z direction) perpendicular to the horizontal and vertical directions, and any combination thereof can be utilized. Further, multiple filters 1810, such as a dual-scale graph having a left Y-scale representing the size of one type of data and a right Y-scale representing the size of a different type of data, can be oriented and used in the same direction. Each filter 1810 can be adjusted individually with respect to the other filters 1810, and by adjusting each of the filters 1810, the information displayed in the dependent visual representation (e.g., Table 1807) can be adjusted in real time. Accordingly, any number of one or more filters 1810 can be provided in a wide variety of different ways.

[0146] FIGS. 19A and 19B are diagrams showing exemplary embodiments of a GPI report 1900. Here, the GPI report 1900 includes a first region 1902 showing a user's ambulatory glucose profile (AGP) and a second region 1904 showing an assessment of the severity of a particular condition related to the user's diabetes. An example of a GPI report (referred to as "Advanced Daily Patterns (ADP)") including an AGP 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. Here, with reference to this incorporated specification, the GPI report 1900 will be briefly described.

[0147] The AGP area 1902 can include a plot of the glucose values for the selected day over a normal time scale. A central tendency (e.g., median or mean value) 1910 is shown by the trace. Surrounding this trace 1910 is an area 1912 corresponding to data values within a percentile range of a central tendency (e.g., 25th percentile of data points to 75th percentile of data points). Adjacent to area 1912 is a second area 1914 corresponding to data values within a wider percentile range of the central tendency (e.g., 10th percentile of data points to 90th percentile of data points). Areas 1912 and 1914 can be shown in any desired way, such as with different lines, colors, or shading, for example. These areas 1912 and 1914 can display each data point, as with a solid line or as in the embodiment shown in FIG. 19B. Further shown in the AGP area 1902 are a user's central tendency target (here, a "median target") and a user's low glucose threshold that can be set and adjusted by a user (e.g., a diabetic patient or an HCP).

[0148] Area 1904 is a table having icons 1916 that identify the level of severity of the corresponding state in a normal daily time segment. One or more arbitrary number of states can be listed and cross-referenced with one or more arbitrary number of icons corresponding to one or more time periods. In this example, three states are listed vertically (e.g., along the Y-axis): (1) the likelihood of low glucose (hypoglycemia), (2) the central glucose value compared to the central glucose target value, and (3) the variation below the median (e.g., the difference in glucose values between the median and the 10th percentile). For these states, different central tendencies such as the mean value can be used instead of the median value.

[0149] In this example, it is not necessary for them to be of equal length, and one day is divided into five time zones that can be set by the user to accommodate the user's lifestyle (e.g., in accordance with meals and bedtime). These time zones can be aligned with the AGP 1902 (e.g., using the same time axis) for ease of reference. The icon 1916 in the table can graphically represent the level of severity of the condition in that time zone, indicated by the key of the region 1908.

[0150] In this example, a diabetic patient experiences fluctuations below the high median in the time zone from noon to 3 am, in light of the target values set for the diabetic patient in the EIS. Also, in this time zone, the possibility of low glucose is high.

[0151] The region 1906 can display a notification informing of one or more high states and list the potential causes of that high state. Here, the region 1906 is displaying a notification regarding fluctuations below the high median and the factors considered to be the causes.

[0152] FIG. 19B is a diagram showing another embodiment of the GPI report 1900, which uses the same data as FIG. 19A but represents the report in a different way. Here, in the AGP region 1902, each data point is shown. Data points 1920 below the low threshold can be highlighted (e.g., colored red). One or more of the regions 1912 and 1914 can be omitted (here the region 1914 is shown while the region 1912 is omitted). Additional highlighting or indication can be used to show the region 1922 in which one of the tracking states in the region 1904 is determined to be high. Here, the points related to fluctuations below the high median are shown by the shaded region 1922 in the corresponding time zone.

[0153] FIG. 20 is a diagram showing an embodiment of the episode summary report 2000, and is a diagram showing a report that can assist in identifying episode patterns that may be repeated in a specific time period. Here, the episode summary report 2000 includes a modal 24-hour graph 2004 of glucose levels for each selected day at a predetermined time, for example, over the entire 24 hours. Also displayed within graph 2004 are markers placed at the episode occurrence times and durations of the selected data set.

[0154] The episode summary report 2000 can also include a table 2002 showing the number of instances of each episode type (e.g., low glucose, high glucose, rapid increase), and when that episode type occurred in a specific time period (e.g., the same time period as shown in the state evaluation region 1904, and all can be aligned with the time axis of graph 2004). The total number of episodes occurring in each time period is also shown. With this tabular display 2002, the user can easily understand the pattern of episode types occurring at a specific time. Selectable fields 2006 (e.g., check boxes) exist adjacent to the total number of each episode. Selecting this field can further assist the user in identifying whether each marker of that type in that time period is displayed (check the check box) or not displayed (do not check the check box) in graph 2004, when identifying the pattern or time when a specific episode type is most likely to occur.

[0155] In some embodiments of the EIS, a nightly episode summary report (not shown) can also be provided in a manner similar to the episode summary report 2000. The nightly summary report is focused on a specific time period, e.g., the night time period, whereas the episode summary report 2000 can cover a longer time period, e.g., 24 hours, in most embodiments. The nightly episode summary report can have a table that includes the number of occurrences of each episode type or risk factor during the night, a plot of glucose level measurements, and one or more of the indicators of the episode and risk factor. Non-limiting examples of nightly low glucose risk factors include a) a bolus within 3 hours after bedtime, b) physical activity in the afternoon or at night, c) alcohol intake, etc. Non-limiting examples of nightly 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 is a diagram showing an exemplary embodiment of the episode overlay report 2100. In response to questions made when a particular episode is detected (see description regarding FIGS. 12A - C), for each question identified by the patient, an episode alignment modal graph or plot 2102 of the measured glucose levels of each episode having the identified response can be displayed. The occurrence time of each episode can be aligned with the central axis (e.g., 0 o'clock), and the measured glucose levels at a predetermined time before and after the episode, e.g., 1 - 12 hours, can be graphed or plotted. The episode overlay report 2000 is useful in showing the impact on the user's glucose level each time a particular suspected cause leading to an episode occurs.

[0157] For example, for each episode detected within the selected date range, the user may have entered a suspected cause. For each suspected cause, an individual graph 2102 can be generated, and the graph includes glucose data related to each episode for which the suspected cause was identified. Although not shown here, graphs 2102 can similarly be generated for each identified symptom, treatment, or other response related to questions asked about the episode.

[0158] In this embodiment, four graphs are shown: graph 2102-1, which includes glucose data for each episode identified by the user with the suspected cause "depressive state"; graph 2102-2, which includes glucose data for each episode identified by the user with the suspected cause "not treated"; graph 2102-3, which includes glucose data for each episode identified by the user with the suspected cause "abnormal fasting"; and graph 2102-4, which includes glucose data for each episode identified by the user with the suspected cause "exercise" (since only one such episode is eligible, one set of glucose data is shown). The graphs 2102 can be arranged in an order such that the response with the most eligible episodes is listed at the top and the response with the fewest eligible episodes is listed at the bottom.

[0159] Figure 22A is a diagram showing an exemplary embodiment of a response report 2200 that can assist a user in quickly identifying a day of interest, i.e., the day on which an episode occurred most frequently. This report serves to replace the habit of searching daily to find problems (e.g., reducing the need for HCP discrimination), rather this report aggregates the episode responses recorded by the patient and highlights the responses that indicate issues with self-care actions that need to be addressed to reduce glucose fluctuations, with the most frequently occurring responses emphasized. In the illustrated example, it is shown that "high glucose episodes" occur most frequently. After selecting a date range and generating the response report 2200, a collapsible summary 2202 of several responses recorded for each type of response related to each type of episode can be displayed. Selecting the expand field 2204 expands the list and displays the types of related episodes.

[0160] Figure 22B is a diagram showing an exemplary embodiment of the response report 2200 after expansion of the high glucose episode type. As can be seen from the figure, in response to the detection of an episode type, a list of each question asked of the diabetic patient (e.g., the questions described with respect to FIGS. 12A - C) is displayed. These lists can also be expanded such that all response types given for a particular question are displayed along with the number of instances in which a particular response was indicated. By ordering the responses in descending order of the number of instances, quick identification of the most frequently occurring responses or problems can be facilitated, which are usually the problems that the HCP and patient should address first to most significantly reduce glucose fluctuations. Selecting a particular response row 2205 can display one or both of the daily graph 1806 and the episode table 1807. Another type of graph can also be displayed. The displayed daily graph 1806 can be associated, for example, with the most recent day within the selected date range on which the response type was actually indicated by the user. Selecting the next or previous button 1802 allows the user to advance to the next date or return to the previous date on which this response was actually presented or provided by the user.

[0161] Accordingly, report 2200 provides a mechanism for quickly identifying the most frequent responses or problem occurrences that a user needs to address and drilling down (or identifying) the specific days on which the response or problem occurred. The user can then investigate the more detailed information and glucose traces associated with this problem, presented on a daily basis and for each episode, to understand how to address it.

[0162] FIG. 22C is a flow diagram showing an exemplary method 2250 of a series of instructions in a server-based version of the 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 embodiment, instead of the EIS version executed on reader 120, the EIS of server 130 is used to detect episodes, and the detected episodes are associated with episode responses by temporal proximity. There is an advantage in simplifying the design of the EIS stored and executed by reader 120 in that there is no need to associate the stored responses with the episodes and no need to communicate the association to server 130. (In another embodiment, reader 120 can store and communicate to server 130 the association between episodes and responses.) Referring now to FIG. 22C, at 2252, the server's processing circuit 131 (see FIG. 1A) retrieves the recorded episode responses within the selected date range from the 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, if possible, associate the responses with the detected episodes by temporal proximity (e.g., if the first response recorded after the detected episode is within a minimum threshold time, those responses are associated with the detected episode). At 2256, the processing circuit 131 can aggregate the episodes by episode type. Next, at 2258, the processing circuit 131 can array the responses in descending order of occurrence frequency or number of occurrences for each episode type.

[0163] FIG. 22D is a flow diagram showing an exemplary method 2280 of a series of instructions in a server-based version of the EIS that can be used to generate a daily graph or report 1806 for the selected episode responses. At 2282, the processing circuit 131 can generate an array with the date and time arranged in ascending order, where each entry in the array corresponds to an instance in which the selected episode response occurred within the specified date range. At 2284, the processing circuit 131 can cause the daily graph 1806 of the most recent date and time in the array to be displayed (e.g., by supplying information used to render the display of the daily graph 1806).

[0164] In 2286, the processing circuit 131 monitors an instruction indicating that the user has selected either the "Back" or "Next" button 1802, and accordingly, can then decrement or increment the array pointer. When the pointer is at the beginning or end of the array, the "Back" button or "Next" button may not be selectable on the display. For example, if there is no date earlier than the date of the information of the currently displayed graph 1806, the "Back" button cannot be selected, and if there is no date after the date of the current graph 1806, the "Next" button cannot be used. In 2288, the processing circuit 131 can display the daily graph 1806 of the date and time indicated by the pointer.

[0165] When the interactive filter 1810 is displayed together with the daily graph 1806, the processing circuit 131 determines and arranges the markers 1812 and 1814 disposed on the opposite side of the occurrence time of the episode to highlight the episode. For example, the left marker 1812 can be arranged at a time predetermined (e.g., 1 hour) earlier than the occurrence time of the episode, and the right marker 1814 can be arranged at the same or different predetermined time (e.g., 3 hours) after being adjusted to the nearest clock time increment after the start of the episode.

[0166] FIG. 23 is a diagram showing an exemplary embodiment of the episode trace report 2300. For each episode, the plot 2310 of the measured values of the glucose level can be displayed with the episode placed at the center 0 hour. The plot of the glucose level can span a predetermined time, e.g., 6 hours before and after the episode. Also, the report 2300 can display one or more of the reason, symptom, treatment, and memo 2320 of the episode reported by the patient related to the episode. The report 2300 enables a detailed analysis of a specific episode.

[0167] FIG. 24 is a diagram showing an exemplary embodiment of a nocturnal risk factor report 2400 that can include one or more plots of a modal glucose level 2450 associated with a no risk factor 2410, a high glucose risk factor 2420, and a low glucose risk factor 2430. Each plot of the modal glucose level 2450 can include a table showing the number of each type of risk factor 2440.

[0168] The reports described herein are merely examples. Embodiments of the EIS can include any combination of some or all of the reports described herein. Embodiments of the EIS can include, in addition to or instead of the reports described herein, another report. Further, it is strongly asserted that the various fields, data arrays, icons, memos, markers, and indicators of each graph, table, and / or report described herein can be freely replaced in each embodiment of the graphs, tables, and / or reports described herein, unless otherwise stated or logically impossible.

[0169] Local and remote computers 150 and 160 can perform some or all of the functions of the reader device 120 and / or the network server 130. For example, the local computer 150 can detect episodes regarding measured glucose levels and prompt the patient with responses to the detected episodes. The episode detection algorithm of the local computer 150 can include a configuration for searching for all episodes, similar to the server 130, or a configuration for searching for a subset of episodes, similar to the glucose monitoring application of the reader device 120.

[0170] FIG. 25 is a flow diagram showing an exemplary embodiment using EIS. At 2502, a diabetic patient monitors their glucose over several days (e.g., 7 or 14 days) using a sensor control device 110 and a reading device 120 that can operate with mask glucose monitoring software or an embodiment of mask EIS. Using the data collected thereby, a reference glucose behavior profile for the diabetic patient can be established.

[0171] At 2504, an HCP and the diabetic patient or other caregiver can analyze the collected data and utilize a GPI report 1900 etc. to establish or adjust a dosing (e.g., insulin) therapy. At 2506, a user (HCP, caregiver, or diabetic patient) can set appropriate target values and thresholds in the EIS to enable the generation of various reports (e.g., median threshold targets in the GPI report) and perform the detection of episodes and excursions (e.g., for example, low glucose threshold, high glucose threshold, rapid rise threshold, etc.). At 2508, the EIS can be activated and the diabetic patient can monitor their glucose over a first period (e.g., several days or weeks) using a reading device 120 that executes the EIS (or glucose monitoring software and the EIS). The EIS can be set to operate only at specific times, such as times indicating a problem with the reference data.

[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 period. This can include the analysis of one or more reports that the EIS can generate. For example, an episode response report 2200 can be generated to identify the cause of the most frequent episodes. Next, using the daily graph 1806 included in the episode response report 2200, the underlying specific actions that cause the episodes can be identified. Depending on the specific situation, other reports can be used.

[0173] At 2512, the HCP can engage in discussions to make realistic modifications to the actions in order to address the cause, and if necessary, create an action plan to assist in modifying the actions. At 2514, for example, the GPI report 1900 can be utilized to identify and implement the necessary adjustments to the medication treatment. This process can be repeated as necessary until the variability level and / or excursions of the diabetic patient decrease to the desired level.

[0174] As described herein, the episode investigation software has been described as being particularly applicable in the context of a specimen monitoring system, especially for glucose monitoring to assist a diabetic patient in managing their condition. However, the functions, attributes, reports, and other features of the episode investigation software can also be similarly used for broader applications, including the management of other types of medical conditions and even uses outside of the medical field.

[0175] For example, the subject matter disclosed herein is not limited to investigating the cause of an episode. Herein, the term "episode" is used in the broadest sense, so it can be used to monitor and characterize other attributes, states, or characteristics of a human, whether or not they are recognized as an episode. The data collected and analyzed can be activity-related data (e.g., actions taken, calories burned, etc., tracked and reported by a device such as an activity monitoring device), dietary information, location information (e.g., a GPS-enabled device), cardiac characteristics, and / or the vascular system (e.g., heart rate, blood pressure, heart sounds, etc.), characteristics of other organs such as the eyes (e.g., intraocular pressure), skin (e.g., sweating), brain (e.g., neural electrical activity), etc., and can be substantially any type of data, such as other forms of biological data. These collected data can be compared to one or more criteria, conditions, requirements, thresholds, etc. that indicate the occurrence of an episode, event, feature, symptom, precursor, activity, etc. related to a specific use.

[0176] Exemplary embodiments of software for constructing or modifying a robust library using the decorator pattern and / or dependency injection The following embodiments can be implemented as part of a software application that operates on a reader device 120 within the system 100 described herein. The reader device and the specimen monitoring system are also described in U.S. Patent Publication Nos. 2015 / 0205947 and 2015 / 0341438, and for all purposes, the entire contents of each are hereby incorporated by reference herein. The embodiments described in this section, like all embodiments herein, can be used in any specimen monitoring system described in these incorporated references, including any system having in vivo functions, ex vivo functions, and any combination of the two.

[0177] Also, similar to the foregoing embodiments, the embodiments of this section are not limited to the reader device 120 within the system 100, but can be used in a wide range of other electronic computing devices having a processing circuit (such as the processing circuit and memory described herein) and a non-transitory memory. Further, the following exemplary embodiments are not limited to use in a medical specimen monitoring environment. Rather, these embodiments have broad applicability and can be used in any environment, device, and / or system, whether medical-related, non-medical-related, or otherwise.

[0178] These and all software embodiments described herein can be implemented via one or more instructions stored in a memory. When executed by a processing circuit, these instructions enable the processing circuit to perform or cause to be performed the functions and / or actions described herein.

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

[0180] In certain exemplary embodiments, the software application can be a specimen monitoring application that enables communication with the sensor control device 110 and has a sensor interface module (or application) for performing communication control. The sensor interface module can generate, encode, and / or encrypt a communication request to send to the sensor control device 110 a request to transmit to the reader device 120 specimen information collected from the wearer of the sensor control device 110. This module can also perform decoding, decryption, and / or reading of the 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 that has converted the analog measurements from the sensor 104, or partially processed digital-form data that has been subjected to certain filtering, temperature calibration, sensor calibration, error checking, or other processing on the raw data. This sensor interface module is responsible for further processing the received data and can output it to the user interface in a format for displaying the received data to the user, and can perform filtering, calibration, and / or algorithm processing in these and more extended forms to convert the user's specimen level into a reliable representation.

[0181] The specimen monitoring application can also include a user interface module (or application) that is responsible for the interface with the user of the reader device 120. This user interface module can perform selection and control of the information displayed on the display of the reader device 120, for example, display a home screen, and change the display from a first screen to a second screen, for example, in response to an input received from the user.

[0182] This user interface can display graphs, numerical values, trend arrows, and other indicia on display 121 that convey specimen information regarding the user, including current information (e.g., within the most recent hour) and / or historical information (e.g., within several days, weeks, or months). The user interface module can also display menus, options, settings, and other fields selectable by the user on the reader 120 and can process the user's selections received via the user input element 122.

[0183] Generally, when a user inputs a command received by the user interface module, the module transfers an instruction or call, or passes information, to the sensor interface module for the instruction to be executed. In some embodiments, the call or information can either call a specialized function callable from a software library or be passed via an application programming interface (API). These functions and / or APIs can interface with the operating system (OS), device drivers, hardware, and other aspects of the telephone.

[0184] Similarly, when the sensor interface module attempts to execute an instruction or perform a function in the execution of programming, it transfers an instruction or call, or passes information, to another module or application that assists in the execution of the desired instruction. This process can continue from the highest relative programming layer involved in the execution of the instruction (e.g., the application layer) to relatively lower programming layers (e.g., application model, user interface (UI) model, cloud integration, kernel, device driver enabling the operation of a specific 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 information (e.g., data, values, null fields, instructions, or others) passed by the interfaces between modules, functions, objects, etc. can be changed or modified. In some embodiments, this modification involves injecting new information into the software at the interface, while in other embodiments, this modification involves removing or deleting the information passed by the interface. In still other embodiments, this modification can include changing, adding, deleting specific information, and any combination thereof. By exposing these interfaces, the application layer (e.g., the specimen monitoring application) can control the information exchanged through or by the interface without changing the core instructions of various modules, functions, or objects that process, make decisions about, or search for the data passed.

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

[0187] However, if the information passed by the interface code requires modification, a decorator or the decorator pattern can be added to the wrapper to make the modification. This is often beneficial. For example, when a combination of hardware, device driver, and / or operating system has a problem that the functions of the OS do not work correctly or work in an unintended way, the software library may receive incorrect input and generate incorrect output. This can be discovered, for example, while testing the entire application in a combination of multiple hardware. For example, when a software module or function outputs incorrect information, such as the propagation of an OS error to the library, a decorator for the wrapper can be generated for the interface that passes incorrect results from the software module or function. The decorator can detect the presence of the error and correct it as appropriate, such as deleting it, changing it, replacing it with one or more null values or ignore values, or in any other way.

[0188] Therefore, in this example, without changing the existing modules or functions within the library, the application can be modified to identify and correct software problems. In some cases, these existing modules or functions may be complex software entities that are not easily revised. For example, the existing modules or functions may be written by another design team or vendor, the existing modules or functions may be subject to a freeze on design or other administrative confidentiality restrictions on modification, or the existing modules or functions may be standard software units that function as designed but generate an output (e.g., including a null field) that prohibits the operation of other software modules that call it.

[0189] The following embodiments are excerpts of exemplary JAVA (registered trademark) source code that implements a wrapper for the function of returning the current date in the year-month-day format. TIFF0007713581000001.tif199152

[0190] During testing, it is assumed that the OS's getCurrentYear() produced incomplete output in some OS versions that returned only the last two digits of the year (e.g., 15 instead of 2015). This incomplete output can be corrected without modifying the library by detecting this problem and inserting a decorator as shown in the following code excerpt. TIFF0007713581000002.tif156161

[0191] Therefore, the YearFixOsFunctionWrapper wrapper for the interface code in the above example can detect the presence of incomplete output (where the returned year value is 100 or less) and then make it complete by applying an appropriate correction (e.g., adding 2000 to the year value).

[0192] FIG. 26 is a block diagram schematically showing software operating on the reading device 120. Here, 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 perform 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 perform 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, the information (e.g., the returned result) returned from the third software module 2603 to the second software module 2602 is returned via the wrapper 2630, which determines whether the result satisfies one or more conditions (e.g., is designed to identify incorrect, incomplete, or undesirable results), modifies (changes, deletes, adds, etc.) the result, and is configured to return the modified result to the second software module 2602. If the condition is not satisfied, the result is not changed.

[0194] Note that the satisfaction of the condition is related to whether the condition indicates a need for modification. In this embodiment, the condition is identified as one where the information should be modified, but the embodiments described herein can operate to identify conditions where the information does not require modification, in which case a change occurs when the information does not satisfy (or violates) the condition.

[0195] The wrapper 2640 acts in a similar manner on the information passed from the software module 2604, determines whether the information satisfies one or more conditions, and if satisfied, appropriately modifies the result and then passes it 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 the information to be passed to the first software module 2601. The wrapper 2620 evaluates whether the information passed from the second software module 2602 satisfies the modification condition, and if satisfied, modifies it and then passes it to the first software module 2601.

[0196] Therefore, FIG. 26 is useful for showing a wide range of stages where wrappers can be utilized in the embodiments described herein. A wrapper can be effectively used when one software module or function passes information (e.g., data, values, characters, software instructions, etc.) to another module or function.

[0197] FIG. 27 is a diagram showing an exemplary embodiment of a method 2700 for operating a reader 120 in the specimen monitoring system 100, and shows a method 2700 for performing tasks using an existing software wrapper. At 2702, a first function calls a wrapper of 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 generate 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 indicating that information modification is appropriate. At 2710, if the condition is satisfied, the modification is valid, 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, at 2714, the output information is passed to the first function without modification. The method 2700 can be executed any number of times based on the number of software modules or functions required to execute a specific task or multiple tasks. Further, each wrapper can be used to detect multiple conditions and perform multiple corrections for correcting the detected conditions. For example, each wrapper can incorporate any number of IF-THEN statements, or IF-THEN-ELSE statements, and multi-stage conditional programming for the wrapper to complete the desired information modification function.

[0199] FIG. 28 is a diagram illustrating an exemplary embodiment of a method 28000 for using a sensor control device 110 that performs reading and scanning, or has software functionality using one or more wrappers, a reading device 120. In this embodiment, the reading device 120 is a smartphone that executes a downloaded specimen monitoring application having a user interface module and a sensor interface module. At 2802, a scanning process is initiated. This is initiated, for example, by a user making a selection on the touch screen display 121 to perform a scan. (During testing, this step can be bypassed by software.) The user interface module can recognize this input and call the sensor interface module to start the scan.

[0200] At 2804, the sensor interface module can directly call a wrapper for the sensor RF module. The sensor RF module can serve to generate a bit string to be transmitted to the sensor control device 110. At 2806, the sensor RF module can then call a wrapper (or multiple wrappers of multiple modules) for the OS API driver module that serves to directly (or indirectly) interface with RF transmission hardware (such as NFC, Bluetooth®, BTLE, etc.).

[0201] Thus, 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 reading device 120. Wrappers for these interfaces can be used for various purposes to assist in testing and / or operating the specimen monitoring application.

[0202] At 2808, the wrapper of the OS API driver module can call the OS API driver module, whereby the request is sent to the sensor control device 110. The response received from the sensor control device 110 is the result returned from the OS API driver module to its wrapper after demodulation and / or decoding. At 2810, the wrapper of the OS API driver module can determine whether the returned result satisfies the correction condition. If it is satisfied, at 2812, the wrapper can appropriately correct the returned result and pass it to the sensor RF module. Alternatively, if the correction condition is not satisfied, at 2814, the result returned from the OS API driver module is passed to the sensor RF module in an uncorrected form.

[0203] At 2816, the sensor RF module reads the passed result and performs one or more operations of the sensor RF module on the passed result. For all embodiments described herein, the execution of a module or function can include performing one or more operations on the information given to that module or function, and such operations can include the calculation of information, the formatting of information, the storage of information in memory or a buffer, the calling of one or more other functions or modules, and / or other software operations well known to those skilled in the art, and combinations thereof. When the operation of the sensor RF module is completed, it returns the result to the wrapper of the sensor RF module.

[0204] In 2818, the wrapper of the sensor RF module can determine whether the returned result satisfies the correction condition. If it is satisfied, in 2820, the wrapper can appropriately correct the returned result and pass it to the sensor interface module. Alternatively, if the correction condition is not satisfied, in 2822, the result returned from the sensor RF module is passed to the sensor interface module in an uncorrected form. In 2824, the sensor interface module algorithmically processes the information provided by the wrapper of the sensor RF module and can provide the result indicating the analyte level of the sensor wearer to the user interface module in a format that can be displayed on the display or in a format that can be rendered on the display so that the user can read and understand it. In 2826, the analyte level can be displayed.

[0205] Method 2800 and other such embodiments can be used in a virtually unlimited number of situations where control of the information passed between modules or functions is desired. For example, the embodiments described herein can be used to correct information generated by the OS of the reading device 120 (e.g., a smartphone). When a failure occurs in a low-level error checking routine, the smartphone's OS API driver may generate an incomplete response. In one exemplary embodiment, a wrapper for the OS API driver can detect such incomplete responses and add appropriate characters to make them complete.

[0206] In addition (or alternatively), the wrapper for the OS API driver can detect an incomplete response and generate an error. Thus, the wrappers utilized in this embodiment are not limited to correcting information passed between modules and can also generate errors, notifications, or interrupts, or set other flags within a software application, and the information exchanged between modules can be left as is (if necessary).

[0207] In another embodiment, by using wrappers to insert fixed data sets, the use of one or more wrappers can facilitate the testing or simulation of the specimen monitoring system. For example, a wrapper for a sensor RF module can be configured to return fixed information instead of calling another function. In some embodiments, the wrapper can be added at runtime, i.e., after the specimen monitoring application has been compiled and is ready to be executed, or during execution. The fixed information can be data that simulates edge case scenarios, such as scenarios that are difficult to initiate using actual hardware and actual software routines. The initiation of low-level errors (e.g., errors issued from software drivers of hardware components) can be an example of such an edge case scenario. The fixed data from the wrapper propagates to another software function of the specimen monitoring application, thereby simulating the impact that such an edge case scenario has on the specimen monitoring application (e.g., sensor interface module, user interface module, etc.) and assisting in the debugging and verification of the entire software. For example, the processing circuit (or software developer, etc.) can determine whether an addition error is generated when the fixed data propagates to another software function.

[0208] The computer program instructions for causing an operation to be performed in accordance with the subject matter described herein can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java (registered trademark), JavaScript (registered trademark), 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 can be executed entirely or partially on the user's computing device as a stand-alone software package, partially on the user's computing device and on a remote computing device respectively, or entirely on the remote computing device or server. In the latter case, the remote computing device can be connected to the user's computing device via any network, including a local area network (LAN) or a wide area network (WAN), or by connecting to an external computer (e.g., via the Internet using an Internet service provider).

[0209] In all embodiments described herein, within the description range that can be input by a user (for example, by selecting a selectable field on the touch screen of a reading device, inputting through a mechanical button or switch of the reading device, or selecting a field on the display with a mouse), it can be described and claimed that the relevant processing circuit (for example, a circuit that executes the software described herein) monitors the user input. This monitoring can include, for example, interrupts or notifications from software related to hardware (such as a touch screen, mouse, etc.) indicating that a user input has been received. Also, the processing circuit can have instructions for determining what selection has been made by the user when the processing circuit receives and / or reads the user input. Similarly, for all graphical user interfaces and / or screens to be displayed, it can be described and claimed that the processing circuit displays (or generates) the graphical user interface or screen and all mechanisms (icons, text, images, etc.) therein. As also described in another part of this specification, it is repeatedly stated that this processing circuit can be a single processor chip, multiple processor chips, or partial processor chips distributed across the entire electronic device communicating with each other.

[0210] Regarding any of the embodiments described herein, it should be noted that all mechanisms, elements, components, functions, and steps are intended to be freely combinable with and replaceable by those of any other embodiment. If a particular mechanism, element, component, function, or step is described for only one embodiment, then, unless otherwise specified, that mechanism, element, component, function, or step can be used in all other embodiments described herein. Thus, this paragraph serves as a premise for introducing claims that combine or replace mechanisms, elements, components, functions, and steps from different embodiments, and as written support, in a particular example, even if it is not explicitly stated in the following description that combinations or replacements of mechanisms, elements, components, functions, and steps from different embodiments are possible. It is explicitly recognized that it would be an excessive burden to explicitly describe all possible combinations and replacements, considering that it is readily recognized by those skilled in the art that all such combinations and replacements are possible.

[0211] Within the scope of the memories, storage devices, and / or computer-readable media that the embodiments disclosed herein have or operate jointly, these memories, storage devices, and / or computer-readable media are non-transitory. Thus, within the scope in which the memories, storage devices, and / or computer-readable media are included in one or more claims, these memories, storage devices, and / or computer-readable media are only non-transitory.

[0212] In this specification, often an entity is described as being coupled to another entity. The terms "coupled" and "connected" (or any of their forms) are used interchangeably herein and are to be understood as a general term for both the direct coupling of two entities (without non - negligible (e.g., parasitic) intervening entities) and the indirect coupling between two entities (with non - negligible intervening entities). If entities are shown as being directly coupled to each other, or are described as being connected to each other without description of intervening entities, it is to be understood that these entities can also be indirectly coupled to each other, unless the context clearly dictates otherwise.

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

[0214] Embodiments are capable of various modifications and alternative forms, and specific examples thereof have been illustrated and described in detail in the specification. However, these embodiments are not limited to the specific forms disclosed, but rather, these embodiments are to be understood as including all improvements, equivalents, and alternatives encompassed by the spirit of this disclosure. Further, it is possible to claim or add to the claims an opposite limitation that defines the scope of the invention by any mechanism, function, step, or element of the embodiments and by a mechanism, function, step, or element not included in the claims.

[0215] Hereinafter, preferred embodiments of the present invention will be described item by item. [Embodiment 1] A specimen monitoring system for use in detecting and evaluating episodes, comprising a sensor configured to obtain a measurement value of a patient's specimen level, and a wireless communication circuit configured to transmit the measurement value of the specimen level to a reading device, a sensor control device, wherein the reading device, A display, a wireless communication circuit configured to receive the measurement value of the analyte level from the sensor control device, a processor circuit communicably coupled to the wireless communication circuit, the display, and a non-transitory memory, comprising: when the non-transitory memory is executed by the processor circuit, the processor circuit determines whether the measurement value of the analyte level indicates that an episode is occurring, and when it is determined that an episode has occurred, stores a plurality of instructions that cause the processor circuit to display a question related to the episode and a list of candidates for one or more responses that are selectable answers to the question. A system characterized by the above. [Embodiment 2] When the plurality of instructions are executed by the processor circuit, the processor circuit further causes the candidate list to be further modified based on a modification received from the user, the modification being at least one of adding a customized response that is a selectable answer to the question to the candidate list of responses or deleting a response from the candidate list. The analyte monitoring system according to claim 1. [Embodiment 3] The analyte monitoring system according to claim 2, wherein the modification is deleting a response from the candidate list. [Embodiment 4] The analyte monitoring system according to claim 1, wherein the portable terminal is a smartphone. [Embodiment 5] The analyte monitoring system according to claim 1, wherein the episode is a bedtime episode, a wake-up episode, a low analyte episode, a high analyte episode, an analyte rapid increase episode, or an analyte rapid decrease episode. [Embodiment 6] When the plurality of instructions are executed by the processor circuit, the processor circuit further When it is determined that an episode has occurred, without displaying the analyte level of the patient, display a list of questions related to the episode and one or more response candidates that are selectable answers to the questions. The analyte monitoring system according to claim 1, characterized in that. [Embodiment 7] When the plurality of instructions are executed by the processor circuit, the processor circuit is further caused to (a) Process a plurality of measurement values of the analyte level received from the sensor control device over a period of several days, (b) Determine whether the plurality of measurement values of the analyte level indicate the occurrence of one or more episodes during the period of several days, (c) When it is determined that one or more episodes have occurred during the period of several days, for each detected episode, display a list of questions related to the episode and one or more response candidates that are selectable answers to the questions, The plurality of instructions cause the processor circuit to execute (a) to (c) without displaying any analyte level to the patient during the period of several days. The analyte monitoring system according to claim 1, characterized in that. [Embodiment 8] The plurality of instructions cause the processor circuit to execute (a) to (c) without displaying the type of each detected episode to the patient during the period of several days. The analyte monitoring system according to claim 7, characterized in that. [Embodiment 9] The plurality of instructions cause the processor circuit to When it is determined that no episode has occurred, after waiting until a predetermined event time, display a list of questions related to the event time and one or more response candidates that are selectable answers to the questions. The analyte monitoring system according to claim 1, characterized in that. [Embodiment 10] The modification is characterized by adding a customized response that is a selectable answer to the question to the candidate list. The analyte monitoring system according to claim 2, characterized in that. [Embodiment 11] A method for reducing fluctuations in a patient's sample, comprising: Receiving, by a communication circuit of a mobile terminal, at least one measurement value of a patient's sample level from a sensor control device; Determining, by a processing circuit of the reading device, whether the measurement value of the sample level indicates that an episode has occurred; When it is determined that an episode has occurred, causing the processing circuit of the reading device to display a question related to the episode and a list of candidates for one or more responses that are selectable answers to the question; A method characterized by comprising the above. [Embodiment 12] The method according to claim 11, further comprising, by the processing circuit of the reading device, performing a modification received from a user on the candidate list, wherein the modification is at least one of adding a customized response, which is a selectable answer to the question, to the candidate list or deleting a response from the candidate list. [Embodiment 13] The method according to claim 11, wherein the reading device is a smartphone. [Embodiment 14] The method according to claim 11, wherein the episode is a bedtime episode, a wake-up episode, a low sample episode, a high sample episode, a rapid sample increase episode, or a rapid sample decrease episode. [Embodiment 15] The method according to claim 11, further comprising, when it is determined that an episode has occurred, causing the processing circuit to display a question related to the episode and a list of candidates for one or more responses that are selectable answers to the question without displaying the patient's sample level. [Embodiment 16] (a) Processing, by the processing circuit, a plurality of measurement values of the sample level received from the sensor control device over a period of several days; (b) In the processing circuit, determining whether the plurality of measurement values of the analyte level indicate the occurrence of one or more episodes during the period of the plurality of days; (c) If it is determined that one or more episodes have occurred during the period of the plurality of days, in the processing circuit, for each detected episode, displaying a list of candidates for one or more responses that are questions related to the episode and selectable answers to the questions; further comprising; A method characterized in that the processing circuit does not display any analyte levels to the patient during the period of the plurality of days and executes (a) to (c). [Embodiment 17] The method according to claim 16, characterized in that the processing circuit executes (a) to (c) without displaying to the patient the type of each detected episode during the period of the plurality of days. [Embodiment 18] If it is determined that no episode has occurred, after waiting until a predetermined event period, the method according to claim 11, further comprising the step of, in the processing circuit, displaying a list of candidates for one or more responses that are questions related to the event period and selectable answers to the questions. [Embodiment 19] The method according to claim 11, characterized in that the modification is the deletion of a response from the candidate list. [Embodiment 20] The method according to claim 11, characterized in that the modification is the addition of a customized response, which is a selectable answer to the question, to the candidate list. [Embodiment 21] A method for generating a report including information on a human analyte level, comprising: Receiving, by a processing circuit, a first selection for generating a report, the first selection being input by a user; Displaying, by the processing circuit, a grid including a first plurality of units, each of the first plurality of units being A graphical trace of the human analyte level over a period of time, and An episode display on the graphical trace indicating the occurrence of an analyte episode, the display being present at a position on the graphical trace corresponding to the time at which the analyte episode occurred, the step of having; Receiving, by the processing circuit, a second selection of one or more of the first plurality of units, the second selection being input by the user; Identifying, by the processing circuit, 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 characterized by comprising the steps of. [Embodiment 22] The method according to claim 21, characterized in that the grid includes a horizontal row of seven units representing one week. [Embodiment 23] The method according to claim 22, characterized in that the grid includes a plurality of the horizontally arranged rows, and each of the rows in the plurality of rows corresponds to a different week. [Embodiment 24] The method according to claim 23, characterized in that the period of time is one day. [Embodiment 25] The method according to claim 21, characterized in that each of the first plurality of units further includes a shaded area corresponding to the region of the human target analyte level. [Embodiment 26] The method according to claim 21, characterized in that the grid includes a second plurality of units, each of the plurality of units represents one day, and includes a display indicating that there is no analyte data for that day. [Embodiment 27] The method according to claim 21, characterized in that the processing circuit causes a selection display to be displayed for each unit of the grid in the second selection. [Embodiment 28] The method according to claim 27, characterized in that the selected display is shading for each unit of the grid in the second selection. [Embodiment 29] The method according to claim 21, characterized in that the plurality of identified sample data are the only sample data used for generating the report. [Embodiment 30] A computer device, a display, a processing circuit, a non-transitory memory storing a plurality of instructions, comprising: when the plurality of instructions are executed, cause the processing circuit to display a grid including a first plurality of units according to a first selection for generating a report, each of the first plurality of units including a graphical trace of a human sample level over a period of time, and an episode display on the graphical trace indicating the occurrence of a sample episode, the display existing at a position on the graphical trace corresponding to the time when the sample episode occurred, identify a plurality of sample data corresponding to one or more second selections of the first plurality of units based on reception of one or more second selections of the first plurality of units, generate the report using the plurality of identified sample data. An apparatus characterized by the above. [Embodiment 31] The apparatus according to claim 30, characterized in that the grid includes a horizontal row of seven units representing one week. [Embodiment 32] The apparatus according to claim 31, characterized in that the grid includes a plurality of the horizontally arranged rows arranged in a stacked manner, and each of the rows in the plurality of rows corresponds to a different week. [Embodiment 33] The apparatus according to claim 32, characterized in that the period is one day. [Embodiment 34] The apparatus according to claim 30, wherein each of the first plurality of units further includes a shaded area corresponding to the area of the human target analyte level. [Embodiment 35] The apparatus according to claim 30, wherein the grid includes a second plurality of units, each of the plurality of units representing a day and including a display indicating that there is no analyte data for that day. [Embodiment 36] The apparatus according to claim 30, wherein when the plurality of instructions are executed, the processing circuit causes a selected display to be displayed on each unit of the grid in the second selection. [Embodiment 37] The apparatus according to claim 36, wherein the selected display is a shading for each unit of the grid in the second selection. [Embodiment 38] The apparatus according to claim 30, wherein when the plurality of instructions are executed, the processing circuit causes the report to be generated using the plurality of identified analyte data as the only analyte data for generating the report. [Embodiment 39] A method of generating an interactive report including information regarding a human analyte level, comprising: by a processing circuit, (a) a graph, a display of time along a horizontal axis, a display of the magnitude of a plurality of analyte data along a vertical axis, the trace of the human analyte level over time, and a plurality of episode indicators, each indicating the occurrence of an analyte episode at the time of occurrence and being arranged along the trace according to the occurrence time, (b) an adjustable list of a plurality of analyte episodes, each of the plurality of analyte episodes having a corresponding episode indicator within the graph, and (c) a filter adjustable by a user, A horizontal filter axis corresponding to time, A first marker movable along the horizontal filter axis, A second marker movable along the horizontal filter axis, wherein the horizontal filter axis is aligned with the time display along the horizontal axis of the graph, and the adjustable list of the plurality of specimen episodes is located between the first marker and the second marker of the graph. The step of simultaneously displaying only the filter of the specimen episode having an episode indicator, The step of monitoring, by the processing circuit, an instruction indicating that the user has adjusted the position of the first marker or the second marker, A method characterized by comprising the above. [Embodiment 40] A first set of episode indicators exists between the first and second markers, and the plurality of specimen episodes in the adjustable list include each specimen episode corresponding to the first set of episode indicators. Further The step of receiving, by the processing circuit, an instruction indicating that the user has adjusted the position of the first marker and / or the second marker so that a second set of episode indicators exists between the first marker and the second marker, wherein the second set of episode indicators includes at least one episode indicator that did not exist in the first set, The step of displaying, by the processing circuit, the adjustable list of the plurality of specimen episodes so that the plurality of specimen episodes include each specimen episode corresponding to the second set of episode indicators, The method according to claim 39, further comprising the above. [Embodiment 41] A computer device, A display, A processing circuit, A non - transient memory storing a plurality of instructions, Comprising the above, When the plurality of instructions are executed, the processing circuit is caused to (a) a graph comprising a display of time along the horizontal axis, a display of the magnitudes of a plurality of sample data along the vertical axis, the time-course trace of the human sample level, and a plurality of episode indicators, each indicating the occurrence of a sample episode at the time of occurrence and arranged along the trace according to the occurrence time, the graph including the indicators; (b) an adjustable list of a plurality of sample episodes, each of the plurality of sample episodes having a corresponding episode indicator within the graph, the list; and (c) a user-adjustable filter, a horizontal filter axis corresponding to time, a first marker movable along the horizontal filter axis, a second marker movable along the horizontal filter axis, the horizontal filter axis being aligned with the time display along the horizontal axis of the graph, the adjustable list of the plurality of sample episodes being located between the first marker and the second marker of the graph and including only the sample episodes having episode indicators, the filter being simultaneously displayed, monitoring an instruction indicating that the user has adjusted the position of the first marker or the second marker, characterized by the device. [Embodiment 42] A method of generating a graphical user interface display having an interactive report of information related to diabetes management, A step of causing a processor circuit to display a list of one or more specimen episode types, wherein each specimen episode type in the list of the one or more specimen episode types is associated with a list of one or more response types, and for the occurrence of the associated specimen episode type, in response to a question asked by an electrical device to the user, during a data collection period, each response type in the list of the one or more response types is selectable by the user, and A step of receiving, by the processor circuit, a selection of a first response type from the list of the one or more response types, and A step of causing the processor circuit to display a graph of specimen data related to an instance, where the first response type is input by the user, and A method characterized by comprising the above. [Embodiment 43] The method according to claim 42, further comprising a step of causing the processor circuit to display a list of one or more instances of specimen episodes that occurred during the period. [Embodiment 44] The method according to claim 43, wherein the list of the one or more specimen episode types, the list of the one or more response types, the graph of the specimen data, and the list of the one or more instances of specimen episodes are simultaneously displayed by the processor circuit. [Embodiment 45] The method according to claim 42, wherein the list of the one or more specimen episode types is arranged in an order corresponding to the number of instances in which each specimen episode type was detected in the collected specimen data. [Embodiment 46] The method according to claim 42, wherein the list of the one or more response types is arranged in an order corresponding to the number of instances in which each response type was input by the user. [Embodiment 47] The method according to claim 42, characterized in that each response type in the list of the one or more response types identifies the cause of the associated specimen episode type. [Embodiment 48] The method according to claim 42, characterized in that the graph is a first graph, the instance is a first instance, and the processor circuit further comprises the step of receiving, from the user, an instruction to display a second graph of specimen data related to a second instance, the second graph being input by the user and related to the first response type. [Embodiment 49] A system configured to generate a graphical user interface display having an interactive report of information related to diabetes management, a processor circuit; a non-transitory memory communicatively coupled to the processor circuit, the memory storing a plurality of instructions; comprising when the plurality of instructions are executed, causing the pre-processor circuit to display a list of one or more specimen episode types, each specimen episode type in the list of the one or more specimen episode types being associated with a list of one or more response types, and each response type in the list of the one or more response types being selectable by the user in response to a question asked by an electrical device about the occurrence of the associated specimen episode type during a data collection period; monitor a selection of a first response type from the list of the one or more response types; after receiving the selection, cause the first response type to display a graph of specimen data related to an instance input by the user; characterized by the device. [Embodiment 50] The system according to claim 49, characterized in that when the plurality of instructions are executed, the processor circuit is further caused to display a list of one or more instances of specimen episodes that occurred during the period. [Embodiment 51] The system according to claim 50, wherein the list of the one or more analyte episode types, the list of the one or more response types, the graph of the analyte data, and the list of one or more instances of the analyte episode are simultaneously displayed by the processor circuit. [Embodiment 52] The system according to claim 49, wherein the list of the one or more analyte episode types is arranged in an order corresponding to the number of instances in which each analyte episode type is detected in the collected analyte data. [Embodiment 53] The system according to claim 49, wherein the list of the one or more response types is arranged in an order corresponding to the number of instances in which each response type is input by the user. [Embodiment 54] The system according to claim 49, wherein each response type in the list of the one or more response types identifies the cause of the associated analyte episode type. [Embodiment 55] The graph is a first graph, the instance is a first instance, and when the plurality of instructions are executed, the processor circuit monitors an instruction from the user to display a second graph of analyte data related to a second instance, where the first response type is input by the user, and after receiving the instruction, causes the second graph to be displayed. The system according to claim 49. [Embodiment 56] A method of operating a software application, comprising: calling a wrapper of a second software module in a processing circuit executing one or more instructions of a first software module; calling the second software module in the processing circuit executing one or more instructions of the wrapper of the second software module; Executing, by the processing circuit, one or more instructions of the second software module to generate a result; Returning, by the processing circuit, the result to the wrapper of the second software module; Determining, by the processing circuit while executing the wrapper of the second software module, whether the result needs to be corrected by comparing the result with a condition; If it is determined that the result needs to be corrected, returning, by the processing circuit, the corrected result to the first software module; If it is determined that the result does not need to be corrected, returning, by the processing circuit, the result to the first software module in an uncorrected form; A method characterized by comprising the above. [Embodiment 57] The method according to claim 56, further comprising generating, by the processing circuit, a notification based on the comparison with the condition. [Embodiment 58] The method according to claim 56, wherein the software application is a specimen monitoring application. [Embodiment 59] The method according to claim 58, wherein the first software module is a sensor interface module configured to algorithmically process specimen data received from a sensor control device including a specimen sensor configured for in vivo use. [Embodiment 60] The method according to claim 56, wherein it is checked whether there is an error in the result by comparison with the condition. [Embodiment 61] The method according to claim 56, wherein it is checked whether the result is incomplete by comparison with the condition. [Embodiment 62] A computer device, A processing circuit, A non-transitory memory storing a plurality of instructions, comprising: when the plurality of instructions are executed, causing the processing circuit to generate a call to a wrapper of a second software module from a first software module, generate a call to the second software module from the wrapper of the second software module, generate a first result in the second software module, cause the first result to be returned to the wrapper of the second software module, determine whether it is necessary to modify the first result 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, cause a second result, which is the first result modified to form the second result, to be returned to the first software module, if it is determined that the first result does not need to be modified, cause the first result to be returned to the first software module, An apparatus characterized by the above. [Embodiment 63] The apparatus according to claim 62, wherein when the plurality of instructions are executed, the processing circuit is caused to further generate a notification based on a result of comparing the first result with the condition. [Embodiment 64] The apparatus according to claim 62, wherein a specimen monitoring application is stored in the memory, and the first software module is a software component of the specimen monitoring application. [Embodiment 65] The apparatus according to claim 62, wherein the apparatus is configured as a reading device, and the first software module is a sensor interface module configured to algorithmically process specimen data received from a sensor control device including a specimen sensor configured to be used in a living body. [Embodiment 66] The apparatus according to claim 62, wherein by comparing the first result with the condition, it is checked whether there is an error in the result. [Embodiment 67] The apparatus according to claim 62, wherein by comparing the first result with the condition, it is checked whether the result is incomplete. [Embodiment 68] A method for simulating an error in a software application, comprising: calling a wrapper of a second software module in a processing circuit that is executing one or more instructions of a first software module; returning, from the wrapper of the second software module to the first software module in the processing circuit, a set of fixed data that simulates a first error; determining whether a second error has occurred; and a method characterized by comprising the above. [Embodiment 69] The method according to claim 68, wherein the processing circuit determines whether the second error has occurred. [Embodiment 70] The method according to claim 68, wherein the software application is a specimen monitoring application, and the first software module is a software component of the specimen monitoring application.

Description of Reference Numerals

[0216] 100 Specimen monitoring system 104 Sensor 110 Sensor control device 120 Reading device 122 Input component 124 Processing circuit 125 Non-transitory memory 126 Processing circuit 127 Non-volatile memory 130 Server 131 Processing circuit 132 Non-volatile memory 150 Local computing device 160 Remote computing device

Claims

**Claim 1** A method for operating a software application, comprising: executing, by a processing circuit executing one or more instructions of a first software module, a step of calling a wrapper of a second software module; executing, by the processing circuit executing one or more instructions of the wrapper of the second software module, a step of calling the second software module; executing, by the processing circuit executing one or more instructions of the second software module, a step of generating a result; returning, by the processing circuit, the result to the wrapper of the second software module; determining, by the processing circuit executing the wrapper of the second software module, whether the result needs to be corrected by comparing the result with a condition; if it is determined that the result is incomplete and needs to be corrected, returning, by the processing circuit, a corrected result that satisfies the condition to the first software module, the corrected result including correcting the result so that the corrected result can be used by the first software module; if it is determined that the result does not need to be corrected, returning, by the processing circuit, the result to the first software module in an uncorrected form; A method characterized by comprising the above steps. **Claim 2** The method according to claim 1, further comprising generating, by the processing circuit, a notification based on the comparison with the condition. **Claim 3** The method according to claim 1, wherein the software application is a specimen monitoring application. **Claim 4** The method according to claim 3, wherein the first software module is a sensor interface module configured to algorithmically process specimen data received from a sensor control device including a specimen sensor configured for in-vivo use. **Claim 5** The method according to claim 1, wherein it is checked whether there is an error in the result by comparison with the condition. **Claim 6** The method according to claim 1, wherein it is checked whether the result is incomplete by comparison with the condition. **Claim 7** The method according to claim 1, wherein the processing circuit of the wrapper of the second software module modifies the result by adding the result.

8. The method according to claim 1, wherein the processing circuit of the wrapper of the second software module modifies the result by changing the result.

9. A computer device comprising: a processing circuit; a non-transitory memory storing a plurality of instructions; and when the plurality of instructions are executed, cause the processing circuit to: generate a call to a wrapper of a second software module from a first software module; generate a call to the second software module from the wrapper of the second software module; generate a first result in the second software module; cause the first result to be returned to the wrapper of the second software module; using the instructions of the wrapper of the second software module, determine whether the first result is incomplete and needs to be corrected by comparing the first result with a condition; if it is determined that the first result needs to be corrected, return to the first software module a second result that satisfies the condition and that is a correction of the first result formed by correcting the first result and that can be used by the first software module; if it is determined that the first result does not need to be corrected, cause the first result to be returned to the first software module. An apparatus characterized by the above.

10. The apparatus according to claim 9, wherein when the plurality of instructions are executed, the processing circuit is further caused to generate a further notification based on the result of comparing the first result with the condition.

11. The apparatus according to claim 9, wherein a specimen monitoring application is stored in the memory and the first software module is a software component of the specimen monitoring application.

12. The device is configured as a reading device, and the first software module is a sensor interface module configured to algorithmically process sample data received from a sensor control device, the sample data including a sample sensor configured for in-vivo use. The device according to claim 9, characterized in that.

13. The device according to claim 9, characterized in that by comparing the first result with the condition, it is checked whether there is an error in the result.

14. The device according to claim 9, characterized in that by comparing the first result with the condition, it is checked whether the result is incomplete.

15. The device according to claim 9, characterized in that the correction of the first result includes adding the first result.

16. The device according to claim 9, characterized in that the correction of the first result includes changing the first result.

Images