Systems and methods for processing analyte data and generating reports - Patents.com

Abstract

To provide methods, systems, and computer program products for processing analyte data and generating reports on the basis of processed analyte data.SOLUTION: In some implementations, a method, a system, and a computer program product may include: updating a data structure representing a measured value related to a recipient and / or a recipient analyte value; and generating a view comprising an abstraction extracted from the data structure, or an abstraction over a given time period, and comprising a graphical representation comprising a plurality of different graphically distinct elements representative of whether the abstraction is above, or within a predetermined glucose concentration level for the recipient, a call out comprising a value help for the graphical representation, and a textual legend comprising a description of the graphical representation and the abstraction.SELECTED DRAWING: None

Description

[Technical Field]

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 61 / 655,991, filed June 5, 2012, and U.S. Patent Application No. 13 / 788,375, filed March 7, 2013, the entire contents of which are expressly incorporated herein by reference and expressly made a part of this application.

[0002] The present disclosure relates generally to data processing of glucose data and recipient related data. [Background technology]

[0003] Diabetes is a disease in which the pancreas fails to produce enough insulin, as in type 1 diabetes, and / or insulin is ineffective, as in type 2 diabetes. In the diabetic state, patients experience hyperglycemia, which can lead to a number of physiological disorders, such as kidney damage associated with capillary deterioration, skin ulcers, or bleeding in the vitreous of the eye. Inadvertent overdose of insulin, or strenuous exercise or inadequate food intake after taking normal amounts of insulin or glucose-lowering drugs, can trigger a hypoglycemic response, such as hypoglycemia.

[0004] People with diabetes sometimes carry self-monitoring blood glucose (SMBG) monitors, which typically require an uncomfortable finger-prick method. Due to the lack of comfort and convenience, diabetics typically measure their glucose levels only two to four times a day. However, due to the time intervals, diabetes testing is often done too late, sometimes resulting in the dangerous side effects of high blood sugar or hyperglycemic symptoms. In fact, not only are diabetics likely not to obtain SMBG readings at the appropriate time, but diabetics are also unaware of whether their blood glucose levels are high or low based on traditional methods.

[0005] Accordingly, a variety of noninvasive, transcutaneous (e.g., transdermal) and / or implantable electrochemical sensors have been developed for the continuous detection and / or quantification of blood glucose levels. These devices typically transmit raw or nearly unprocessed data for subsequent analysis at a remote device, and the device may have a display that allows it to display information to a user administering the sensor. Summary of the Invention [Problem to be solved by the invention]

[0006] Methods and apparatus, including computer program products, for analyte data processing are provided. [Means for solving the problem]

[0007] In a first implementation, a method, system, or computer-readable medium is provided for generating a user interface associated with sensor data representing a recipient's glucose concentration level when executed by at least one processor. The method, system, or computer-readable medium may include the at least one processor generating a display having an abstraction extracted from the sensor data over a predetermined time period. The display may further include a graphical representation including a plurality of different graphically distinct elements representing whether the abstraction over the predetermined time period is at, above, or within a predetermined glucose concentration range for the recipient, a callout including numerical help for the graphical representation, and a text legend including a description of the graphical representation and the abstraction. The method, system, or computer-readable medium may further include providing the display as a module.

[0008] In a second implementation, a method, system, or computer-readable medium is provided that, when executed by at least one processor, generates a display having abstractions extracted from sensor data over a predetermined time period and provides the display as a module. The display may further include a graphical representation including a plurality of distinct graphical elements depicting glucose variability including the rate of change of the sensor data over the predetermined time period, callouts including numerical help for the graphical representation, and a text legend including an explanation of the graphical representation and the abstractions.

[0009] In a third implementation, a method, system, or computer-readable medium is provided for generating at least one of a plurality of reporting modules configured, when executed by at least one processor, to provide at least a display having abstractions extracted from sensor data over a predetermined period of time, and for providing the display as at least one of the plurality of reporting modules. The sensor data may represent a glucose concentration level of a recipient. The display may have a graphical representation including a plurality of different graphically distinct elements representing the glucose concentration level of the recipient, callouts including numerical help for the graphical representation, and a text legend including a description of the graphical representation and the abstractions.

[0010] The first, second, or third implementations described above may further have additional features described herein, including one or more of the following: The time frame may include at least one of 8 hours, 1 day, 2 days, 7 days, or 30 days. The graphical elements may be used in at least one different shade or position to represent whether the abstraction over the predetermined time period is at, above, or within a predetermined glucose concentration for the recipient. The callout may include a numeric help associated with one of the different graphical elements to provide a numerical value for one of the different graphical elements. The display may be configured to be displayed as a page within a user interface. The modules may have metadata. The metadata may include information that enables selection of a module from among multiple modules. The display may be similarly displayed. The graphical elements may be a representation of whether the abstraction over the predetermined time period is at, above, or within a predetermined glucose concentration for the recipient. The graphical elements may be a representation of glucose variability over the predetermined time period. At least one of the plurality of reporting modules may include an insight module including at least one of the plurality of insights detected based on patterns and selected for display based on ranking by at least one of user preferences, number of devices providing data, one or more types of devices providing data, and correlation with the recipient. At least one of the plurality of reporting modules may include a comparison with module representing a statistical comparison between the recipient and a group selected based on the integrated data representing one or more of a type of diabetes associated with the group, an age associated with the group, a gender associated with the group, an age at diagnosis associated with the group, a location associated with the group, and a treatment facility associated with the group.At least one of the plurality of reporting modules may include at least one of a patient information module, a highlights module, a high and low glucose periods module, a device used module, a comparison module, a daily summary module, a weekly summary module, an overtime summary module, a continuous glucose level module, a report legend module, and a test frequency module.

[0011] In a fourth implementation, a dynamic report generation method, system, or computer-readable medium is provided. The method, system, or computer-readable medium, when executed by at least one processor, may select at least one module from a plurality of modules, wherein the selection is performed based on metadata including one or more of the following rules, and generate a report including the selected at least one module, the report being configured to display information representative of a measured glucose concentration level in a recipient: whether the at least one module can be used with a certain type of device; whether the at least one module can be used with a glycemic status of the recipient; whether the at least one module can be used with an expected amount of data generated by a certain type of device.

[0012] In a fifth implementation, a dynamic report generation method, system, or computer-readable medium is provided that, when executed by at least one processor, may receive a report generation request, select at least one module from among a plurality of modules in response to the request, the selection being based on metadata including information representative of at least one recipient and a type of device being used to measure the glucose concentration level, generate a report including the selected at least one module configured for display in a single display representative of the glucose concentration level measured in the recipient, and provide the generated report to a user interface for display.

[0013] In a sixth implementation, a method, system, or computer-readable medium for dynamic report generation is provided. The method, system, or computer-readable medium, when executed by at least one processor, provides for receiving a report generation request; selecting at least one module from among a plurality of modules stored in a repository, the selection being performed based on metadata including information representative of at least one of at least one recipient, a type of device being used to measure the glucose concentration, and at least one rule; generating a report including the selected at least one module configured to display information representative of the glucose concentration level measured in the recipient; and providing the generated report to a user interface for display.

[0014] The fourth, fifth, or sixth implementations described above may further include additional features described herein, including one or more of those described below. The information describing the recipient may further include at least one of user preferences for at least one module and recipient identification information. The metadata may further include one or more rules. The user preferences may include preferences provided by the recipient, a healthcare professional, and a processor programmatically based on the metadata. The device type may include at least one of a continuous blood glucose monitor or a self-monitoring blood glucose monitor. The one or more rules may include one or more of rules regarding whether the at least one module can be used with a device of that type, whether the at least one module can be used with the recipient's glycemic status, and whether the at least one module can be used with an expected amount of data provided by a device of that type. Creating may further include accessing from a repository, and the metadata may include a template defining the placement of the selected at least one module. The display may graphically highlight at least one of the following conditions: a glucose concentration level measured in the recipient is above, below, or within a predetermined target range of glucose concentration levels for the recipient; if the metadata indicates that at least one module is configured for use with a continuous blood glucose monitor, the selection may include selecting at least one module from a plurality of modules stored in a repository connected to the at least one processor; if the metadata indicates that at least one module is not configured for use with a continuous blood glucose monitor and that other modules are configured for use with a continuous blood glucose monitor, the selection may further include selecting another module from the plurality of modules; if the metadata indicates that at least one module is configured for use with a display of a particular size for display of a report, the selection may further include selecting at least one module from the plurality of modules.If the metadata indicates that the at least one module is configured for use with an expected amount of data generated by a continuous blood glucose monitor, the selection may further include selecting at least one module from the plurality of modules. If the metadata indicates that the at least one module is configured for use with a glycemic condition of the recipient that is hyperglycemic, the selection may further include selecting at least one module from the plurality of modules, the selected at least one module providing an indication indicative of the hyperglycemic condition. If the metadata indicates a user preference for the selected at least one module, the selection may further include selecting at least one module from the plurality of modules. The selection may be made dynamically when a request is received based on an evaluation of metadata stored in a repository coupled to the at least one processor.

[0015] In a seventh implementation, a method, system, or computer-readable medium for processing sensor data representing a glucose concentration level in a recipient is provided. When executed by at least one processor, the method, system, or computer-readable medium may generate a data structure including a plurality of bins assigned to a plurality of predetermined glucose concentration levels, generate a value representing a measured glucose concentration level obtained from the received sensor data, add the value to at least one of the plurality of bins, where the addition of the values ​​increments an occurrence value for at least one of the plurality of bins, analyze the data structure including the at least one of the plurality of bins and the occurrence value to determine at least one described measurement, and generate a report including the at least one described measurement.

[0016] In an eighth implementation, a method, system, or computer-readable medium for processing sensor data representing a glucose concentration level in a recipient is provided. When executed by at least one processor, the method, system, or computer-readable medium may receive sensor data representing a glucose concentration level in the recipient; generate a plurality of data structures for a plurality of consecutive time periods; select at least one of the plurality of data structures based on a time at which the received sensor data was measured; add a value to the selected at least one of the plurality of data structures, where the addition of the value increments an occurrence value for the selected at least one of the plurality of data structures; and analyze the selected at least one of the plurality of data structures and the occurrence value to determine at least one described measurement.

[0017] The seventh and eighth implementations described above may further include additional features described herein, including one or more of the following: The data structure may include a histogram; a plurality of bins may be assigned to a predetermined glucose concentration level from a range of possible glucose concentration levels expected from the recipient; the value may include a count; at least one of the plurality of bins may be selected based on a comparison of the value to a predetermined glucose concentration level assigned to at least one of the plurality of bins, and selecting at least one of the plurality of bins may enable adding a value to the selected at least one of the plurality of bins; a plurality of data structures may be generated for a plurality of consecutive time periods; at least one of the plurality of data structures may be selected based on a time at which the sensor data was measured; at least one of a union or intersection of the plurality of data structures may be calculated to determine at least one described measurement; at least one of the plurality of data structures may be selected based on an identity of the recipient providing the sensor data; a plurality of data structures may be generated for a plurality of different recipients; and values ​​may be added to other data structures representing a plurality of cohort recipients.

[0018] It should be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive. Additional functionality and / or variations may be provided in addition to those described herein. For example, implementations described herein may be directed to various combinations and subcombinations of the disclosed features and / or certain additional combinations and subcombinations of features disclosed in the following detailed description. [Brief explanation of the drawings]

[0019] [Figure 1] 1 shows a diagram depicting a continuous analyte sensor system including a sensor electronics module according to some example implementations. [Figure 2] FIG. 1 shows a block diagram representing a sensor electronics module, according to some example implementations. [Figure 3A] FIG. 1 shows a block diagram representing a sensor electronics module in communication with multiple sensors, including a glucose sensor, according to some example implementations. [Figure 3B] 1 illustrates a perspective view of a sensor system including a mounting unit and a sensor electronics module attached thereto, according to some example implementations. [Figure 3C] FIG. 3C shows a side view of the sensor system of FIG. 3B. [Figure 4A] 1 illustrates a block diagram of an analytical processing system according to some example implementations. [Figure 4B] 1 illustrates another block diagram of an analytical processing system according to some example implementations. [Figure 5] 1 illustrates a block diagram of a calculation engine configured to generate a count representative of an analyte level in a recipient, according to some example implementations. [Figure 6A-1] 10 illustrates an example report template generated by some example implementations. [Figure 6A-2] 10 illustrates an example process for dynamic selection of a reporting module, according to some example implementations. [Figure 6A-3]10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-4] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-5] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-6] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-7] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-8] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-9] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-10] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-11] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-12] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-13] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-14] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-15] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-16] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-17] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-18] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-19] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-20] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-21] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-22] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-23] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-24] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-25] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-26] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-27] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 6A-28] 10 illustrates an example of a reporting module, according to some example implementations. [Figure 7] 10 illustrates further examples of a reporting module, according to some example implementations. [Figure 8] 10 illustrates further examples of a reporting module, according to some example implementations. [Figure 9] 10 illustrates further examples of a reporting module, according to some example implementations. [Figure 10] 10 illustrates further examples of a reporting module, according to some example implementations. [Figure 11] 1 illustrates an example of a process for processing analyte data, according to some example implementations. DETAILED DESCRIPTION OF THE INVENTION

[0020] In the figures, the same reference numbers are used to refer to the same or similar elements.

[0021] 1 illustrates an example system 100 according to some example implementations. System 100 includes a continuous analyte sensor system 8, which includes a sensor electronics module 12 and a continuous analyte sensor 10. System 100 may also include other devices and / or sensors, such as a drug delivery pump 2 and a blood glucose meter 4. Continuous analyte sensor 10 may be physically connected to sensor electronics module 12, may be integral with (e.g., permanently attached to) continuous analyte sensor 10, or may be separably attachable to continuous analyte sensor 10. Sensor electronics module 12, drug delivery pump 2, and / or blood glucose meter 4 may be connected to one or more devices, such as displays 14, 16, 18, and / or 20.

[0022] In some example implementations, system 100 includes a cloud-based analyte processor 490 configured to analyze analyte data (and / or other patient-related data) provided via network 406 (e.g., wired, wireless, or a combination thereof) from sensor system 8 and other devices associated with the recipient (also referred to as the patient), such as display devices 14-20, and may generate reports providing high-level information, such as statistics, regarding the measured analytes over a particular time frame.

[0023] In some exemplary implementations, the cloud-based analyte processor 490 may provide a reporting module. For example, the analyte processor 490 or a report generator therein may generate a display including extracted results extracted from the sensor data over a predetermined time period. The display may further include a graphical representation including multiple distinct graphical elements representing whether the extracted results over the time period meet, exceed, or fall within the recipient's predetermined glucose concentration level, callouts including numerical help for the graphical representation, and a text legend with a description of the graphical representation and the extracted results. The analyte processor 490 and / or report generator may further provide the display as a module.

[0024] In some example implementations, system 100 may dynamically generate reports. For example, analyte processor 490 may receive a request to generate a report. In response to the request, analyte processor 490 may then select at least one module from among a plurality of modules. This selection may be performed based on metadata. The metadata may include information describing the recipient, the type of device being used to measure the glucose concentration level, rules, etc. The selection may be considered dynamic, in the sense that the module selection changes based on the metadata for each request. A report may then be generated that includes at least one selected module, which is then provided to a user interface for display.

[0025] In some embodiments, some of the displays are small (e.g., key fob) displays 14 ( FIG. 1 ) configured to display at least some sensor information, such as analyte concentration values ​​and trend arrows. Key fob devices are typically small hardware devices sized to fit on a keychain and with built-in authentication mechanisms. However, any small display device 14, including a wristband, tag, belt, necklace, pendant, piece of jewelry, adhesive patch, pager, identification (ID) card, etc., can be configured with the functionality described herein in connection with key fob device 14, and all of these are encompassed herein by the terms “small display device” and / or “key fob device.”

[0026] Generally, the key fob device 14 has electronics configured to receive and display displayable sensor information. In some embodiments, the electronics include RAM and program storage memory configured to display at least the sensor data received from the sensor electronics module. In some embodiments, the key fob device 14 has an alarm configured to notify the recipient of a triggered alert (e.g., audibly, visually, and / or vibrating). In some embodiments, the key fob device 14 has a user interface 600, such as an LCD 602 ​​and one or more buttons 604, that allow the user to view data, such as numbers and / or arrows, to toggle through one or more screens, select or define one or more user parameters, and respond to alerts, etc. (e.g., silence, snooze, turn off).

[0027] In some embodiments, the key fob display device has memory (e.g., in a gig stick or thumb drive) to store sensors, medications (e.g., insulin), and other medical information, allowing for data transfer from the sensor electronics module to other devices (e.g., PCs) and / or allowing for memory stick-type functionality as a data back-up location for the sensor electronics module memory (e.g., data storage memory). In some embodiments, the key fob display device is configured to be automatically readable by a network system upon entry into a hospital or other medical complex.

[0028] In some embodiments, the key fob display device has a physical connector, such as a USB port 606, to allow connection to a port on a computer (e.g., USB), allowing the key fob to function as a data download device (e.g., from the sensor electronics module to a PC), a telemetry connector (e.g., a Bluetooth adapter / connector for a PC), and / or to allow configurable settings on the key fob device (e.g., via software on a PC allowing configurable parameters such as numbers, arrows, movement, alarms, fonts, etc.). In some embodiments, the display device, such as a personal computer, personal digital assistant, or the like, can program (and / or change) user parameters associated with the miniature (key fob) display device. In some embodiments, user parameters include contact information, alarm / alert settings (e.g., thresholds, sounds, volume, etc.), calibration information, font size, display preferences, default settings (e.g., screen), etc. Alternatively, the miniature (key fob) display device can be configured for direct programming of user parameters. In some embodiments, the small (key fob) display device includes a telemetry module such as a Bluetooth and USB connector, such that the small (key fob) display device also functions as a telemetry adapter (e.g., a Bluetooth adapter) to enable direct wireless communication between, for example, the sensor electronics module and a PC, where the PC does not have a suitable telemetry adapter internally.

[0029] In some embodiments, one of the multiple displays is a handheld display device 16 ( FIG. 1 ) configured to display sensor information, including analyte concentrations and graphical representations of analyte concentrations over time. Typically, a handheld display device includes a display 608 large enough to display a graphical representation 612 of sensor data over a predetermined period of time, such as 1, 3, 5, 6, 9, 12, 18, or 24 hours of sensor data. In some embodiments, the handheld device 16 is configured to display trend graphs or other graphical representations, numerical values, arrows, and / or alert the recipient. U.S. Patent Application Publication No. 2005 / 0203360, which is incorporated herein by reference in its entirety, describes and illustrates several examples of displaying data on a handheld display device. While FIG. 1 illustrates some embodiments of a handheld display device 16, the handheld device may be a single-application device or a multi-application device, such as a mobile phone, palmtop computer, PDA, portable media player (e.g., iPod®, MP3 player), blood glucose meter, insulin pump, etc.

[0030] In some embodiments, the mobile phone (or PDA) 18 is configured to display and / or relay the sensor information (as described above), such as by voice or text message to the recipient and / or the recipient's caregiver. In some embodiments, the mobile phone 18 further comprises an alarm configured to notify the recipient of the triggered alert, such as in response to receiving a data package indicating an alert instruction. Depending on the embodiment, the data package may include displayable sensor information, such as an on-screen message, a text message, and / or a pre-created graphical representation of the sensor data and / or the converted sensor data, as well as an indication of the alert, such as an audible or vibrating alert that the mobile phone will activate.

[0031] In some embodiments, one of the displays is a medication delivery device, such as an insulin pump and / or insulin pen, configured to display the sensor information. In some embodiments, the sensor electronics module is configured to wirelessly communicate sensor diagnostic information to the medication delivery device to enable the medication delivery device to consider (and add to its calculations / algorithms) the quality, reliability, and / or accuracy of the sensor information for closed-loop and / or semi-closed-loop systems, as further described in detail in U.S. Patent Application Publication No. 2005 / 0192557, which is incorporated herein by reference in its entirety. In some other embodiments, the sensor electronics module is configured to wirelessly communicate with medication delivery devices that do not have a display, to enable closed-loop and / or semi-closed-loop systems, such as those described above.

[0032] In some embodiments, one of the display devices is a drug delivery device that is an associated analyte monitor, such as a blood glucose meter, configured to measure an associated analyte value related to an analyte concentration in a biological sample from the recipient.

[0033] In some embodiments, one of the display devices is a personal computer (PC) 20 (FIG. 1) configured to display sensor information. The PC 20 preferably has software installed that displays and / or performs data analysis (retrospective processing) of historical sensor information. In some embodiments, a hardware device can be provided (not shown) (e.g., a dongle / adapter) configured to plug into a port on the PC and enable wireless communication between the sensor electronics module and the PC. In some embodiments, the PC 20 is configured to set and / or change configurable parameters of the sensor electronics module 12 and / or the miniature (key fob device) 14, as described in further detail elsewhere herein.

[0034] In some embodiments, one of the displays is an on-skin display that is separable, separably attached, and / or dockable from the sensor housing (mounting unit, sensor pod, etc.). In some embodiments, removal of the on-skin display powers down the sensor. In other embodiments, the sensor housing includes sufficient sensor electronics to maintain sensor operation even when the on-skin display is detached from the sensor housing.

[0035] In some embodiments, one of the display devices is an auxiliary device such as a heart rate monitor, a pedometer, a temperature sensor, or a vehicle drive (e.g., configured to enable or disable the vehicle from starting and / or driving in response to at least some sensor information wirelessly communicated from the sensor electronics module (e.g., a glucose value above a predetermined threshold). In some other embodiments, one of the display devices is designed for another functional device (e.g., a caller ID device), where the system is configured to communicate with and / or transfer displayable sensor information to a custom protocol of the other device such that the displayable sensor information can be displayed on the other functional device (e.g., the display of the caller ID device).

[0036] Before providing further details regarding the cloud-based analytical processing system disclosed herein, the following provides a detailed description of sensors and systems that may provide data to the cloud-based processing system disclosed herein.

[0037] In some example implementations, sensor electronics module 12 may include electronic circuitry associated with measuring and processing data generated by continuous analyte sensor 10. This generated continuous analyte sensor data may also include algorithms that can be used to process and calibrate the continuous analyte sensor data, although these algorithms may be provided in other ways as well. Sensor electronics module 12 may include hardware, firmware, software, or a combination thereof that provides measurements of analyte levels from a continuous analyte sensor, such as a continuous glucose sensor. Example implementations of sensor electronics module 12 are further described below with respect to FIG. 2.

[0038] As mentioned, sensor electronics module 12 may be connected (e.g., wirelessly, etc.) to one or more devices, such as displays 14, 16, 18, and / or 20. Displays 14, 16, 18, and / or 20 may be configured for display of information (and / or alerts), such as sensor information transmitted by sensor electronics module 12 for display on displays 14, 16, 18, and / or 20.

[0039] The display device may include a relatively small key fob-like display 14, a relatively large handheld display 16, a mobile phone (e.g., a smartphone, a tablet, etc.), a computer 20, and / or any other user device configured to display at least information (e.g., medication delivery information, individual self-monitoring glucose measurements, a heart rate monitor, a calorie intake monitor, etc.).

[0040] In some example implementations, the relatively small key fob-like display device 14 may include a watch, belt, necklace, pendant, piece of jewelry, adhesive patch, pager, key fob, plastic card (e.g., credit card), identification (ID) card, etc. The display device 14 may have a relatively small display (e.g., smaller than a larger display device) and may be configured to display certain types of displayable sensor information, such as numbers and arrows.

[0041] In some example implementations, the relatively large handheld display device 16 may include a handheld receiving device, a palmtop computer, etc. The large display device may have a relatively large display (e.g., larger than a smaller display device) and may be configured to display information such as a graphical representation of continuous sensor data, including current and historical sensor data output by the sensor system 8.

[0042] In some exemplary implementations, the continuous analyte sensor 10 comprises a sensor that detects and / or measures an analyte, and the continuous analyte sensor 10 may be configured to continuously detect and / or measure an analyte as a non-invasive, subcutaneous, transcutaneous, and / or intravascular device. In some exemplary implementations, the continuous analyte sensor 10 may analyze multiple intermittent blood samples, although other analytes may be used as well.

[0043] In some example implementations, the continuous analyte sensor 10 may comprise a glucose sensor configured to measure glucose in blood using one or more measurement techniques, such as enzymology, chemistry, physics, electrochemistry, spectrophotometry, polarimetry, calorimetry, iontophoresis, radiometry, immunochemistry, etc. In implementations in which the continuous analyte sensor 10 comprises a glucose sensor, the glucose sensor may comprise any device capable of measuring the concentration of glucose and may use a variety of techniques to measure glucose, including invasive, minimally invasive, and non-invasive detection techniques (e.g., fluorescence monitoring), and provide data, such as a data stream, indicative of the concentration of glucose in a recipient. The data stream may be a raw data signal that is converted into a calibrated and / or filtered data stream used to provide a glucose value to a recipient, such as a user, patient, or caregiver (e.g., a parent, relative, supervisor, teacher, doctor, nurse, or any other individual interested in the recipient's health). The continuous analyte sensor 10 may also be implanted as at least one of the following types of sensors: an implantable glucose sensor, a transcutaneous glucose sensor, a type implanted or extracorporeal in a host's blood vessel, a subcutaneous sensor, a refillable subcutaneous sensor, and an intravascular sensor.

[0044] While the description herein describes some implementations including a continuous analyte sensor 10 comprising a glucose sensor, the continuous analyte sensor 10 may similarly comprise other types of analyte sensors. Also, while some implementations describe the glucose sensor as an implantable glucose sensor, other types of devices capable of detecting the concentration of glucose and providing an output signal representative of the glucose concentration may similarly be used. Furthermore, while the description herein describes glucose as the analyte being measured, processed, etc., other analytes may similarly be used, including, for example, ketone bodies (e.g., acetone, acetoacetate, and β-hydroxybutyrate, lactate, etc.), glucagon, acetyl-CoA, triglycerides, fatty acids, intermediates in the citric acid cycle, choline, insulin, cortisol, testosterone, etc.

[0045] 2 illustrates an example of sensor electronics module 12 according to some example implementations. Sensor electronics module 12 may have sensor electronics configured to process sensor information, such as sensor data, and generate transformed sensor data and displayable sensor information. For example, the sensor electronics module may transform sensor data into one or more of the following: filtered sensor data (e.g., one or more filtered analyte concentration values), raw sensor data, calibrated sensor data (e.g., one or more calibrated analyte concentration values), rate of change information, trend information, acceleration rate information, sensor diagnostic information, location information (which may be provided by a location module 269 that provides location information, such as global positioning system information), alarm / warning information, calibration information, sensor data smoothing and / or filtering algorithms, etc.

[0046] In some example implementations, sensor electronics module 12 may be configured to calibrate the sensor data, and data storage memory 220 may store the calibrated sensor data points as transformed sensor data. Also, in some example implementations, sensor electronics module 12 may be configured to wirelessly receive calibration information from a display device, such as devices 14, 16, 18, and / or 20, to enable calibration of the sensor data from sensor 12 and data lines 212. Furthermore, sensor electronics module 12 may be configured to perform additional algorithmic processing on the sensor data (e.g., calibrated and / or filtered data and / or other sensor information), and data storage memory 220 may be configured to store the transformed sensor data and / or sensor diagnostic information associated with the algorithm.

[0047] In some example implementations, sensor electronics module 12 may include an application specific integrated circuit (ASIC) 205 connected to user interface 122. ASIC 205 may further include a potentiostat 210, a telemetry module 232 that transmits data from sensor electronics module 12 to one or more devices, such as devices 14, 16, 18, and / or 20, and / or other components for signal processing and data storage (e.g., processor module 214 and data store 220). While FIG. 2 shows ASIC 205, other types of circuitry may be used as well, including a field programmable gate array (FPGA), one or more microprocessors configured to provide some (if not all) of the processing performed by sensor electronics module 12, analog circuitry, digital circuitry, or a combination thereof.

[0048] 2, potentiostat 210 is connected to continuous analyte sensor 10, such as a glucose sensor, to receive sensor data from the analyte via data line 212. Potentiostat 210 may provide a voltage to continuous analyte sensor 10 via data line 212 to bias the sensor, which measures a value (e.g., current) indicative of the analyte concentration in a recipient (also referred to as the analog portion of the sensor). Depending on the number of working electrodes in continuous analyte sensor 10, potentiostat 210 may have one or more channels (and corresponding one or more data lines 212).

[0049] In some exemplary implementations, potentiostat 210 may include a resistor that converts current values ​​from sensor 10 to voltage values, while in some exemplary implementations a current-to-frequency converter may also be configured to continuously sum measured current values ​​from sensor 10, for example, using a charge-metering device. In some exemplary implementations, an analog-to-digital converter may digitize the analog signal from sensor 10 into so-called "counts" for processing by processor module 214. The resulting counts may be directly related to the current measured by potentiostat 210, and may be directly related to an analyte level, such as a glucose level, in the recipient.

[0050] The telemetry module 232 may be operatively connected to the processor module 214 and may provide hardware, firmware, and / or software that enables wireless communication between the sensor electronics module 12 and one or more other devices, such as a display device, a processor, a network access device, etc. Various wireless technologies that may be implemented within the telemetry module 232 include Bluetooth, Bluetooth Low Energy, ANT, ZigBee, IEEE 802.11, IEEE 802.16, cellular wireless telephone access technology, radio frequency (RF), infrared (IR), paging network communications, magnetic induction, satellite data communications, spread spectrum communications, frequency hopping communications, near field communications, etc. In some example implementations, the telemetry module 232 may comprise a Bluetooth chip, although the combination of the telemetry module 232 and the processor module 214 may also implement Bluetooth technology.

[0051] The processor module 214 may control the processing performed by the sensor electronics module 12. For example, the processor module 214 may be configured to process data (e.g., counts) from the sensors, filter the data, calibrate the data, perform fail-safe checks, etc.

[0052] In some exemplary implementations, the processor module 214 may include a digital filter, such as an infinite impulse response (IIR) filter or a finite impulse response (FIR) filter. This digital filter may smooth the raw data stream received from the sensor 10, the data line 212, and the potentiostat 210 (e.g., after analog-to-digital conversion of the sensor data). Typically, the digital filter is programmed to filter data sampled at predetermined time intervals (also referred to as a sample rate). In some exemplary implementations, such as when the potentiostat 210 is configured to measure an analyte (e.g., glucose) at discrete time intervals, these time intervals determine the sampling rate of the digital filter. In some exemplary implementations, the potentiostat 210 is configured to measure the analyte continuously, for example, using a current-to-frequency converter. In these current-to-frequency converter implementations, the processor module 214 may be programmed to request digital values ​​from the integrator of the current-to-frequency converter at predetermined time intervals (acquisition time). These digital values ​​acquired by the processor module 214 from the integrator may be averaged within the acquisition time for the duration of the current measurement. As such, the acquisition time may be determined by the sampling rate of the digital filter.

[0053] The processor module 214 may further include a data generator configured to generate data packages for transmission to devices such as the displays 14, 16, 18, and / or 20. Additionally, the processor module 215 may generate data packets for transmission to these external sources via the telemetry module 232. As mentioned, in some example implementations, the data packages may be customizable for each display device and / or may include any possible data, such as timestamps, displayable sensor information, converted sensor data, sensor and / or sensor electronics module identifier codes, raw data, filtered data, calibrated data, rate of change information, trend information, error detection or correction, etc.

[0054] The processor module 214 may also have program memory 216 and other memory 218. The processor module 214 may be connected to a communications interface, such as a communications port 238, and a power source, such as a battery 234. The battery 234 may also be connected to a charger and / or regulator 236 that provides power to the sensor electronics module 12 and / or charges the battery 234.

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

[0056] Memory 218 may be used to store information. For example, the processor module 214, including memory 218, may be used as a system cache memory, providing temporary storage for the most recent sensor data received from data lines 212 and potentiostat 210. In some example implementations, the memory may comprise memory storage components such as read-only memory (ROM), random access memory (RAM), dynamic RAM, static RAM, non-static RAM, easily erasable programmable read-only memory (EEPROM), rewritable ROM, flash memory, etc.

[0057] A data storage memory 220 may be coupled to the processor module 214 and may be configured to store various sensor information. In some example implementations, the data storage memory 220 stores one or more days of continuous analyte sensor data. For example, the data storage memory may store 1, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 20, and / or 30 (or more) days of continuous analyte sensor data received from the sensor 10 via the data line 212. The stored sensor information may include one or more of a timestamp, raw sensor data (one or more raw analyte concentration values), calibration data, filtered data, converted sensor data, and / or any other displayable sensor information.

[0058] The user interface 222 may include various interfaces, such as one or more buttons 224, a liquid crystal display (LCD) 226, a vibrator 228, an audio transducer (e.g., a speaker) 230, a backlight, etc. Components comprising the user interface 222 may provide controls to interact with a user (e.g., a recipient). The one or more buttons 224 may enable toggles, menu selections, option selections, status selections, yes / no responses to on-screen questions, an "off" function (e.g., for an alarm), a "snooze" function (e.g., for an alarm), a reset, etc. The LCD 226 may output visual data to the user, for example. The audio transducer 230 (e.g., a speaker) may provide audio signals in response to triggering of specific alerts, such as current and / or predicted hyperglycemic and hypoglycemic symptoms. In some example implementations, the audio signals may be differentiated by tone, volume, duty cycle, pattern, duration, etc. In some example implementations, the auditory signal may be configured to be muted (e.g., snooze or turned off) by pressing one or more buttons 224 on the sensor electronics module and / or by signaling the sensor electronics module using a button or selection on a display device (e.g., key fob, cell phone, etc.).

[0059] While visual and vibration alerts are described with respect to Figure 2, other alert mechanisms may be used as well. For example, in some exemplary implementations, a tactile alert is provided that includes a poking mechanism configured to "poke" the patient in response to one or more alert conditions.

[0060] A battery 234 may be operably connected to the processor module 214 (and possibly other components of the sensor electronics module 12) to provide the necessary power for the sensor electronics module 12. In some exemplary implementations, the battery is a lithium manganese dioxide battery, although any suitable size and power storage battery (e.g., AAA, nickel-cadmium, zinc-carbon, alkaline, lithium, nickel-metal hydride, lithium-ion, zinc-air, zinc-mercury oxide, silver-zinc, or hermetically sealed) can be used. In some exemplary implementations, the battery is rechargeable. In some exemplary implementations, multiple batteries can be used to power the system. In still other implementations, power can be delivered to a recipient transcutaneously, for example, by inductive coupling.

[0061] The charger and / or regulator 236 may be configured to receive energy from an internal and / or external charger. In some example implementations, the battery regulator (or balancer) 236 regulates the recharging process by stopping excessive charging current, allowing sufficient charging of all cells or batteries within the sensor electronics module without overcharging other cells or batteries. In some example implementations, the battery 234 is configured to be charged via an inductive and / or wireless charging pad, although any other charging and / or power delivery mechanism may be used as well.

[0062] One or more communication ports 238, also referred to as external connector(s), may be provided to enable communication with other devices, such as a PC communication (com) port, to enable communication with systems separate from or integrated with the sensor electronics module. The communication port may, for example, comprise a serial communication port (e.g., a universal serial bus or "USB") to enable communication with other computer systems (e.g., PCs, personal digital assistants or "PDAs," servers, etc.). In some example implementations, the sensor electronics module 12 is capable of transmitting historical data to a PC or other computing device (e.g., an analyte processor as disclosed herein) for retrospective analysis by the patient and / or physician.

[0063] In some continuous analyte sensor systems, the on-skin portion of the sensor electronics may be simplified to minimize the complexity and / or size of the on-skin electronics, for example, to provide only raw, calibrated, and / or filtered data to a display device configured to perform other algorithms required for calibration and display of the sensor data. However, the sensor electronics module 12 may also be implemented to perform predictive algorithms used to generate transformed sensor data and / or displayable sensor information, including algorithms that, for example, evaluate the clinical acceptability of the reference and / or sensor data, evaluate the calibration data for best calibration based on inclusion criteria, evaluate the quality of the calibration, compare estimated analyte values ​​with measured analyte values ​​at corresponding times, analyze fluctuations in estimated analyte values, assess the stability of the sensor and / or sensor data, detect signal artifacts (noise), replace signal artifacts, determine the rate of change and / or trend in the sensor data, perform dynamic and intelligent analyte value estimation, perform diagnostics on the sensor and / or sensor data, set the operating mode, evaluate the data for aberrant conduction, etc.

[0064] Although separate data storage and program memory are shown in Figure 2, various configurations may be used as well. For example, one or more memories may be used to provide storage space to support the data processing and storage requirements of sensor electronics module 12.

[0065] 3A is an example diagram showing a sensor electronics module 312 in communication with multiple sensors, including a glucose sensor 320, an altimeter 322, an accelerometer 324, a temperature sensor 328, and a location module 369 (e.g., a global positioning system processor or other location source), according to some example implementations. While FIG. 3A shows the sensor electronics module 312 in communication with specific sensors, other sensors and devices may similarly be used, including, for example, a heart rate monitor, a blood pressure monitor, a pulse oximeter, calorie intake, a drug delivery device, etc. One or more of these sensors may also provide data to the analysis processing system 400 and / or the analyte processor 490, as described further below. In some implementations, a user may manually provide some of the data to the analysis processing system 400 and / or the analyte processor 490. For example, a user may provide calorie expenditure information to the analysis processing system 400 and / or the analyte processor 490 via a user interface.

[0066] 3A , each of the sensors 320-328 wirelessly communicates sensor data to the sensor electronics module 312. In some exemplary implementations, the sensor electronics module 312 includes one or more of the sensors 320-328. In some exemplary implementations, the sensors are combined in any other configuration, such as a combined glucose / temperature sensor that transmits sensor data to the sensor electronics module 312 using a common communications circuit. In some implementations, fewer or additional sensors may be in communication with the sensor electronics module 312. In some exemplary implementations, one or more of the sensors 320-328 are directly connected to the sensor electronics module 312, such as via one or more electrical communications lines.

[0067] The sensor electronics module 312 may generate and transmit data packages to a device, such as the display device 350, which may be any electronic device configured to receive, store, retransmit, and / or display displayable sensor data. The sensor electronics module 312 may analyze sensor data from multiple sensors and determine which displayable sensor data to transmit based on one or more of a number of characteristics of the recipient, the display device 350, the user of the display device 350, and / or characteristics of the sensor data. Thus, the customized displayable sensor information transmitted to the display device 350 may be displayed on the display device with minimal processing by the display device 350.

[0068] 3B and 3C are perspective and side views of a sensor system shown in a functional position, including a mounting unit 314 and a sensor electronics module 12 attached thereto in an implementation, with the mounting unit and the sensor electronics module matingly engaged therein. In some exemplary implementations, the mounting unit 314, also referred to as a housing or sensor pod, includes a base 334 adapted to be secured to a recipient's skin. The base can be formed from a variety of rigid or flexible materials and may have a low-profile profile that minimizes protrusion of the device from the recipient during use. The base 334 may be formed at least in part from a flexible material, which may provide numerous advantages over other transcutaneous sensors in some implementations, but may be susceptible to motion associated with the recipient's movement while the device is in use. The mounting unit 314 and / or sensor electronics module 12 may be positioned above the sensor insertion site to protect the site and / or provide a minimal footprint (utilization of the recipient's skin surface area).

[0069] In some example implementations, a detachable connection between the mounting unit 314 and the sensor electronics module 12 is provided, which may allow for improved manufacturability: when the sensor system is replaced after a useful life, the relatively inexpensive mounting unit 314 can be discarded, while the relatively expensive sensor electronics module 12 can be reused for multiple sensor systems. In some example implementations, the sensor electronics module 12 is configured with signal processing, such as filtering, calibration and / or other algorithms useful for calibration and / or display of sensor information.

[0070] In some example implementations, the connector 338 is mounted on or in the base 334 of the mounting unit 314 and the connection assembly 336, which is configured to fit within a hinge 348 that allows the subassembly (hereinafter referred to as the connection assembly 336) to pivot relative to the mounting unit 314 between a first position (for insertion) and a second position (for use). The hinge may provide a pivoting, articulating, and / or hinging mechanism, such as a glued hinge, a sliding joint, or the like, and in some implementations may perform the hinge action without a fulcrum or fixed point around which articulation occurs. In some example implementations, the connector 338 is formed from a conductive elastic material, such as a carbon black elastomer, through which the sensor 10 extends, although the connector may be formed in other manners as well.

[0071] In some exemplary implementations, the mounting unit 314 is provided with an adhesive pad 308 having a releasable backing layer disposed on the underside of the mounting unit. Thus, removing the backing layer and pressing the base 334 of the mounting unit onto the recipient's skin adheres the mounting unit 314 to the recipient's skin. Additionally or alternatively, adhesive pads can be attached to some or all of the sensor system after sensor insertion is complete to ensure adhesion and, optionally, an airtight or watertight seal around the surgical wound exit site (or sensor insertion site). Appropriate adhesive pads can be selected and designed to stretch, stretch, conform, and / or ventilate an area (e.g., the recipient's skin). Configurations and arrangements providing water-resistant, waterproof, and / or airtight sealing properties may be provided in some mounting unit / sensor electronics module implementations described herein.

[0072] 4A illustrates an example of an analyte data processing system 400 according to some exemplary implementations. The description of FIG. 4A also refers to FIG. 1 and FIG. 4B.

[0073] Analyte data processing system 400 may have one or more user interfaces 410A-410C, such as a browser, an application, and / or any other type of user interface configured to allow access and / or interaction with analyte processor 490, for example, via network 406 and load balancer 412. Analyte processor 490 may further be connected to a repository, such as repository 475.

[0074] The analyte data processing system 400 may also receive data from source systems such as health management systems, patient management systems, prescription management systems, electronic medical record systems, personal health record systems, etc. This source system information may provide metadata for dynamic reporting.

[0075] Analyte data processing system 400 may be implemented in a variety of configurations, including standalone, distributed, and / or cloud-based configurations. However, the following description relates to implementing system 400 in a cloud-based configuration, such as a software-as-a-service (SaaS) configuration in which analyte processor 490 is provided on computing hardware, a server, and data repository maintained remotely from the location of the entity (e.g., remotely from recipients, health care providers, end users, etc.), and accessed over network 406 by authorized users via user interfaces, such as user interfaces 410A, B, and / or C, and / or data retriever 465.

[0076] FIG. 4B illustrates a system 499 similar to system 400, but implemented as a SaaS-based system including multiple servers 404, each of which may be virtualized to provide one or more analyte processors 490. Each virtualized analyte processor 490 may serve a different audience, such as an end user, a clinic, or a recipient wearing a sensor. To more efficiently utilize the Software as a Service (SaaS) provider's computing resources and provide significant performance redundancy and / or reliability, in some implementations consistent with FIG. 4B, it may be beneficial to have multiple servers to serve multiple audiences (e.g., recipients, users, clinics, etc., in user interfaces 410A-C and / or data retrieval portion 465) on a single system 400 and / or 499, maintaining all of the audience's data in a secure manner in repository 475 while also providing customized solutions tailored to each audience.

[0077] Referring again to FIG. 4A , in some exemplary implementations, the analyte data processing system 400 may provide a cloud-based diabetes data management structure that receives data about a patient from various devices, such as medical devices, blood glucose meters, continuous glucose monitors, sensor systems 8, displays 14-20, source systems, and / or other devices (e.g., devices providing food consumption, such as carbohydrates consumed by a recipient or patient, medication delivery data, time, temperature sensors, movement / activity sensors, etc.). In some exemplary implementations, the cloud-based diabetes data management programmatically receives data with little or no intervention on the part of the user. Data received from devices, source systems, etc. may be in various formats and may be structured or unstructured. For example, in some exemplary implementations, the system 400 receives minimally processed or analyzed raw sensor data, and then the received data is formatted, processed (e.g., analyzed), and / or stored to enable report generation. For example, the data retrieval component 465 may execute on one or more devices, such as the computer 20, connected to the sensor system 8. In this example, the data retriever 465 formats the sensor data into one or more common formats compatible with the analyte processor 490 and provides the formatted data to the analyte processor 490 so that the analyte processor 490 can analyze the formatted data. Although FIG. 4A shows one data retriever 465, in some example implementations, multiple data retrievers 465 may be used to format data from multiple devices and / or systems, some of which have different data formats, into one common format compatible with the analyte processor 490.

[0078] In some implementations, the data retrieval unit 465 may be accessed through a kiosk having a processor configured with a user interface, such as a dedicated computer, or may be accessed via a secure web-based interface residing on a non-dedicated computer.

[0079] In some implementations, a processor (e.g., a computer, smartphone, or any other device) first accesses system 400 and downloads software for the data retrieval unit into the processor's memory, thereby programmatically installing the data retrieval unit on the processor. The downloaded software is then programmatically installed on the processor, and the data retrieval unit may then generate displays (or pages) and display them on a user interface to allow a user to retrieve data (e.g., download data to system 400, analyte processor 490, etc.). In some implementations, the user interface may allow a user to select an icon, such as an acquisition icon, to programmatically initiate data transfer to analyte processor 490. For example, a user selects the acquisition icon on a user interface on a processor, such as computer 20, which initiates data transfer from sensor system 8 connected to data retrieval unit 465 and analyte processor 490. In some implementations, the acquisition icon may be implemented as a software widget. The software widget may also be placed on a web page so that, when selected, it initiates the acquisition process for a registered user.

[0080] The software associated with the data retrieval unit may also have a self-updating mechanism so that when acquisition is selected in the user interface, the data retrieval unit programmatically checks for updates (e.g., software, drivers, data, etc.) on the analyte processor 490 (or other designated computer) and installs the updates. Updates may be performed programmatically with little or no user intervention. Data download from the device or system to the data retrieval unit may be performed via a wired connection, such as a device-specific download cable, or wirelessly when the device and processor are equipped for wireless data transfer.

[0081] The analyte processor 490 may check the data downloaded by the data retrieval unit 465 for transmission errors, data format, device error codes, data validity, duplicate data points, and / or other aspects of the data. If out-of-range data points or device errors are found, the analyte processor may flag those data points, subsequently correcting the identified data points via a program or system administrator, and storing the corrected data points. The analyte processor may also be configured by a user, such as a clinician or physician, to perform additional data processing steps, such as time correction, date correction, and analyzing data by specific cohorts, groups, and relationships (e.g., demographics such as age, city, state, gender, ethnicity, type 1 diabetes, type 2 diabetes, age at diabetes diagnosis, lab results, current prescription medications, patient self-reported symptoms, patient diagnosed symptoms, patient questionnaire responses, and any other metadata describing the recipient / patient). Once the analyte processor has performed the initial data processing (eg, checking, cleaning, and analysis), the processed data and / or raw data provided by the data retrieval component may be stored in repository 475 .

[0082] Processing in the analyte processor 490 may include associating metadata with data received from the device and / or sensor. Examples of metadata include patient information, the key used to encrypt the data, the patient's accelerometer, location data (e.g., the patient's location or the patient's clinic location), time, date, the type of device used to generate the associated sensor data, etc. Patient information may include the patient's age, weight, sex, home address, and / or any past health information, such as whether the patient has been diagnosed with type 1 or type 2 diabetes, high blood pressure, or any other condition. Processing may also include analysis, such as determining one or more descriptive measurements and / or generating a report based on the received information and descriptive measurements. These descriptive measurements may include statistics (e.g., median, interquartile range, mean, sum, n, standard deviation, and coefficient of variation). Example reports are shown in Figures 6A-1, 6A-3 through 6A-28, and 7-10.

[0083] In the example of FIG. 4A , user interfaces 410A-C may be used by one or more entities, such as an end user, a recipient, a medical professional, a clinic, a patient, a testing group, a health system, a medical device manufacturer, etc. These entities may remotely access analyte processing system 400 via user interfaces 410A-C to request actions, such as retrieving analyte data, providing analyte data, requesting analysis of the analyte data, requesting generation of a report including a module having a display displaying descriptive measurements of the analyte data, and displaying the analyte data and report. For example, user interface 410A may send a request (e.g., a message) to initiate an action in remote (e.g., separate from the user interface and connected via a network) analyte processor 490. An action may request a report on sensor data provided by data retrieval unit 465 (e.g., a single processor, such as computer 20, may provide data retrieval unit 465 and user interface 410A). Other example actions include providing sensor data, such as glucose data, carbohydrate data, insulin pump data, etc., to analyte processor 490, initiating processing of the sensor data, initiating analysis of the sensor data, and storing the data in repository 475. In some example implementations, the computational resources provided by analyte processor 490 may comprise one or more physical servers that are virtualized to provide the analyte processing services disclosed herein.

[0084] The data retriever 465 may acquire (e.g., receive, retrieve, etc.) data from one or more sources and provide any acquired data in a format compatible for use in the analyte processor 490. In some implementations, the data retriever 465 may execute within one or more source systems and / or devices that provide data to the analyte processor 490. For example, the data retriever 465 may execute within one or more devices, such as the sensor system 8, the sensor 10, the display devices 14, 16, 18, and / or 20, the drug pump 2, the blood glucose meter 4, the computers / processors connected to those devices, and any other devices capable of providing data to the system 400. In these implementations, the data retriever 465 receives data from the recipient devices and formats the sensor data in a format compatible with the analyte processor 490. The data retriever 465 may also execute on source systems, such as disease management systems, weight management systems, prescription management systems, electronic medical record systems, personal health record systems, etc. In these implementations, the data retriever 465 retrieves data from the source system and formats the data in a format compatible with the analyte processor 490 .

[0085] As mentioned, in some exemplary implementations, the data retrieval unit 465 may be downloaded and / or automatically provided to a device, computer, system, etc. For example, when a user on a computer first accesses the system 400, the system 400 may automatically install and configure the data retrieval unit 465 on the user's computer. Once installed, the data retrieval unit 465 may begin acquiring and formatting data for the system 400, if needed, to enable processing of the acquired data by the analyte processor 490. Further by way of example, the data retrieval unit 465 may be downloaded onto a device, such as the computer 20. In this example, when the computer 20 receives sensor data from the sensor electronics module 12, the data retrieval unit 465 may provide the sensor data and / or metadata in a format compatible with the analyte processor 490.

[0086] In some example implementations, the analyte processor 490 may process received data by performing one or more of the following: Associating data received from devices, sensors, source systems, and / or data retrievers with metadata; Determining one or more stated measurements, such as statistics (e.g., median, in and out interquartile range, mean, sum, n, and standard deviation); Creating reports, including modules with displays displaying stated measurements of analyte data; Verifying and validating the completeness of data received from sensors, source systems, and / or data retrievers; Processing received data based on metadata (e.g., to select a particular patient, device, condition, type of diabetes, etc.); Mapping data received from devices, sensors, source systems, and / or data retrievers so that the data can be compared and combined for processing, including analysis.

[0087] The results of any processing performed by analyte processor 490 may also be used to generate one or more reports including selected modules with displays showing the described measurements displayed as graphs, bar charts, static charts, diagrams, etc. Additionally, reports and other output generated by system 400 may be provided via one or more delivery mechanisms, such as report delivery module 420K (e.g., email, secure email, print, text, presentation for display in a user interface such as in user interfaces 410A-C provided on a tablet or other processor), machine-to-machine communication (e.g., via third-party interface 420J), and any other communication mechanism.

[0088] In some example implementations, reports may be dynamically customized for use by entities such as recipients, end users, clinicians, medical professionals, device manufacturers, etc. Additionally, reports may be customized based on the type and / or amount of sensors and systems providing data to system 400 and the type of metadata available to system 400. This customization may be performed by the user, by system 400 programmatically, or a combination of both.

[0089] In some example implementations, one or more user interfaces 410A-C may execute on a processor, such as computer 20 or other processor, to provide kiosk services to healthcare professionals, clinics, etc. For example, a user, such as a recipient (also referred to as a patient), may enter a healthcare facility and access a kiosk to connect to system 400 and provide sensor data and / or metadata to system 400. In this example, the user may provide sensor data and / or metadata to system 400 and then view one or more reports on one or more user interfaces 410A-C that include information representing the sensor data and / or metadata provided to system 400, including statistical measurements of the data. While the previous example uses a kiosk, the kiosk may likewise be used by healthcare professionals or administrative staff.

[0090] While the previous examples describe computer 20 having a user interface and data retrieval unit to provide a kiosk, the user interface may be located in other devices, such as smartphones, tablet computers, displays, and other similar processors. Computer 20 may also be located in locations other than a kiosk. For example, computer 20 may be located in a recipient's home, and computer 20 may have a data retrieval unit 465 that retrieves data from sensors associated with the recipient, such that data retrieval unit 465 can format and provide the sensor data to analyte processor 490. The user interface and data retrieval unit may also be configured in a healthcare professional's or clinician's workstation.

[0091] In some example implementations, the analyte processor 490 may have an authentication / authorization unit 420A that grants access privileges to the analyte processor 490, a data parser 420B that parses requests sent to the analyte processor 490, a calculation engine 420H that receives data from the sensors and processes the received data into histograms, logic 420C, data filters 420D, data formatters 420E, report generators 420G, and counts for use in pattern detection 420I, a report delivery module 420K that delivers formatted reports to a destination, and a third-party access application programming interface that allows other systems and devices to access and interact with the analyte processor 490.

[0092] Analyte processor 490 may receive requests to perform actions (e.g., provide data, store data, analyze / process data, request reports, etc.) from a user interface, such as user interfaces 410A-C. Before analyte processor 490 services a request, analyte processor 490 may process the request to determine whether the request is authorized and authenticated. For example, authenticator and authorizer 420A may determine whether the sender of the request is authorized by requesting the user to provide security credentials (e.g., a user identifier, a password, a stored security token, and / or a verification identifier provided by text message, phone call, or email) in a user interface displayed on the computer. If authorized, to perform actions such as storing (or uploading) data in repository 475, performing data analysis / processing, or requesting report generation, authenticator and authorizer 420A may authenticate the sender of the request to check whether security credentials associated with the sender of the request indicate that the sender (e.g., a user at user interface 410A) is truly authorized to access a particular resource in system 400.

[0093] To further illustrate, a data retriever 465 associated with sensor system 8 and computer 20 may be authorized and authenticated by authenticator and authorizer 420A to access analyte processor 490 to write data to a buffer or other storage mechanism, such as repository 475. On the other hand, an entity, such as a user at user interface 410A, may be authorized and authenticated by authenticator and authorizer 420A to access analyte processor 490, but only be permitted to access specific information. In this second example, a user at user interface 410A may be authorized and authenticated to access repository 475 to view specific information corresponding to the user's own glucose data and to access reports generated for the glucose data, but the user is not authorized and authenticated to access other users' data and / or reports. Another example may be when users associated with a clinic, hospital, and / or testing group require access to all data related to their patients. In this example, the user is permitted access to their own patients, but not other patients. Yet another example may be when a user associated with a clinic, hospital, and / or testing group requests access to all data for associated patients using a particular device, such as a particular type of analyte sensor. In this example, the user is granted access to data specific to that type of analyte sensor, but not to data specific to other sensors (and PII may be deleted or made anonymous).

[0094] Once authorized and / or authenticated, the data parser 420B may then parse the request received by the analyte processor 490 and separate any data, such as sensor data, metadata, etc., from the request. In some implementations, the data parser 420B may perform checks for data formatting, device-related error codes, data validity, duplicate data points, and / or other aspects of the data. The data parser 420B may also associate added metadata with the separated data. The metadata may include any of the metadata described herein, including the owner of the data, a key that tracks the data, an encryption key specific to each user, time and date information, one or more locations where the data is located (or stored), etc. As described further below, in some example implementations, the data parser 420B may provide the data to a calculation engine 420H for formatting the data into counts and histograms.

[0095] In some example implementations, the request (or the parsed data therein) may be processed by a calculation engine 420H, which preprocesses data received from devices, sensors, etc. to form "counts." The counts represent measured values ​​such as analyte values ​​measured by the sensors, glucose values ​​measured by the sensors, continuous glucose values ​​measured by the sensors, and / or other diabetes-related information such as carbohydrates consumed, body temperature, physical activity level, and frequency of occurrence of the measured values.

[0096] 5 illustrates an example implementation of calculation engine 420H. When calculation engine 420H receives request 502, calculation engine 420H may preprocess 504 the request to extract data, such as sensor data, and form a count accordingly. The count may represent, for example, a numerical value representing sensor data provided by data retrieval unit 465, computer 20, sensor system 8, and / or any other data source, and its frequency of occurrence. For example, the count may represent glucose values ​​measured by a continuous glucose sensor, such as continuous analyte sensor 10, and its frequency of occurrence over a particular time period.

[0097] The computation engine 420H may also preprocess (504) the request 502 to provide other metadata and / or determine other metadata, such as determining personally identifiable information (PII) 506 associated with the request 502, time, etc., although in some implementations the computation engine may receive the request without PII information. PII may include the serial number of the sensor system 8 and any other information that may identify a recipient associated with the sensor system 8. In some example implementations, the PII may be stored in encrypted form in the repository 475 to enhance the privacy of the PII. Furthermore, the PII may be encrypted with a different encryption technique and / or key than other information stored in the repository 475. For example, the analyte processor 490 may store data from multiple users, such as recipients, patients, etc., in the repository 475. To maintain privacy, each user's data may be encrypted with a separate key. Additionally, the PII information may be encrypted with additional keys to further enhance user privacy.

[0098] The calculation engine 420H may then perform additional processing using the numerical value 508. The additional processing may include storing the count in a repository 475, which may include one or more databases that store the count. The count may also be stored along with metadata such as time / date information, the original request 502, etc. Additionally, as noted, the count may be encrypted before storage in the repository 475, and in some example implementations, the count and / or metadata may be encrypted with a different encryption technique and / or key than the PII.

[0099] Although some examples described herein describe databases, a database may also be implemented as any type of data store, such as a relational database, a non-relational database, a file system, etc.

[0100] The calculation engine 420H may also use the counts to update one or more histograms 510. For example, rather than continuing to track and process a recipient's glucose level over a particular period of time using raw sensor data values, the calculation engine 420H may convert the data values ​​to counts. The counts may be added to a histogram 590A for a given recipient. In the example of FIG. 5, the histogram 590A has an X-axis of glucose concentration values ​​and a Y-axis of the number of occurrences of each glucose concentration value. In this example, if the count 508 for the recipient is 60, the calculation engine 420H updates 512 the bin associated with the value 60. The histogram 590A may be associated with a given patient / recipient to represent the recipient's glucose level. Because possible glucose concentration levels typically fall within a particular range, in some example implementations, the bin values ​​may be predetermined.

[0101] In some example implementations, histogram 590A may be associated with a predetermined time of day (also called an epoch). For example, histogram 590A may represent a time such as 1 PM to 1:30 PM, and in this example, calculation engine 420H may generate other histograms for other times.

[0102] In some exemplary implementations, the calculation engine 420H may generate multiple histograms for a given recipient for a given time period. For example, it may generate 48 histograms corresponding to 30-minute epochs over a 24-hour period, such that each time a count is received, the count is added to one of the 48 histograms based on the time associated with the count and the corresponding histogram. In this example, a count representation of a blood glucose measurement made at 12:30 AM would update a histogram designated to cover measurements made during that epoch, while another count at 1:30 AM would update a different histogram assigned to represent the 1:30 AM epoch. These 48 histograms may also be stored in a database within a data structure for easy access. For example, each of the 48 histograms may be stored as a row in the database. As further described below, the calculation engine may also use set theory to make decisions based on one or more histograms, statistics, etc.

[0103] Although the previous examples use 30 minute intervals as epochs, other time intervals such as 15 minutes may be used as well.

[0104] In some example implementations, calculation engine 420H may update other histograms representing aggregate values. For example, numerical values ​​508 may be used to update histogram 510, representing the so-called "cohort" of recipients used to generate histogram 590A. The term "cohort" refers to recipients that can be grouped together, and this grouping may be based on one or more factors, such as demographics, health status, age, geographic location (e.g., country, state, or zip code), etc. In the example of FIG. 5, histogram 590B is updated (514) with the same counts as histogram 590A, but histogram 590B represents a cohort associated with, for example, all other patients at the clinic where the recipient is treated. In that way, histogram 590B may provide insight into the recipient and their cohort at the clinic.

[0105] The calculation engine 420H may also update other histograms used to pre-calculate statistics related to recipients or cohorts. For example, the calculation engine may update a histogram (associated with a particular patient) and update other histograms (which may pertain to other patients, such as cohorts selected based on metadata such as zip code, age, and gender). The calculation engine 420H may also form other histograms based on statistics such as unions, intersections, and set differences. For example, the calculation engine 420H may use set theory to determine the union of histograms. The union represents the set of all objects in a first histogram A, a second histogram B, or a combination of both (denoted as A∩B). The calculation engine 420H may determine the intersection (e.g., the set of all objects that are only in the first histogram A and the second histogram B, denoted as AUB) and the set difference (e.g., the set of all elements of the first histogram A that are not in the second histogram B, denoted as A\B).

[0106] In some implementations, the calculation engine uses histogram and set theory operations to determine aggregate statistics and form so-called aggregate histograms. For example, a report may be generated that includes aggregate histograms for all patients in a geographic region, such as the United States. In this example, the calculation engine may identify a set of existing histograms that provides the minimum number of histograms that cover the geographic region of interest. In particular, histograms for all patients (or clients) in the United States may be merged using set theory to form a virtual histogram for the United States for a given time frame, such as the past 30 days. Also, in some implementations, this operation may be performed very quickly when compared to performing such operations on raw sensor data. In some implementations, the repository may store multiple histograms (e.g., histograms may be organized by patient, clinic, zip code, etc.) that can be easily processed using set theory to form or determine statistics for aggregate histograms. Also, in some implementations, aggregate histograms may be configured for storage in a repository, in which case the aggregate histograms would be updated with counts rather than using set theory to generate them. While the previous example describes aggregate histograms generated based on geographic location, aggregate histograms may similarly be generated for other metadata described herein (e.g., demographics, age, zip code, type of diabetes, age at diagnosis, etc.).

[0107] As noted, in some implementations, the computation engine 420H may need to update multiple histograms. When this is the case, the computation engine 420H may update the histograms in a distributed manner based on eventual consistency.

[0108] Although the description of calculation engine 420H refers to a histogram, a histogram, as used herein, refers to a data structure having one or more values ​​(e.g., values) associated with one or more time intervals. For example, a histogram may represent one or more values, such as frequencies of occurrence associated with bins corresponding to one or more time intervals. This data structure may also be stored in a database so that it is easily accessed for reads, such as within a row of the database (or within a column, e.g., if a column database is used).

[0109] In some example implementations, repository 475 stores histograms containing the counts in a database. For example, repository 475 may store data for patients spanning a 1-day, 2-day, 7-day, 30-day, or longer time frame. In this example, days may be subdivided into epochs, each of which has a corresponding histogram stored in repository 475. Each histogram may also be stored as a row (or column) in a database in repository 475 to facilitate rapid data access.

[0110] 4A , logic 420C may also process requests in analyte processor 490 and perform actions (e.g., store, retrieve, process, analyze, report data, etc.). For example, logic 420C may control the actions of analyte processor 490 when processing a request to store data in repository 475. In this example, under the control of logic 420C, the request may be parsed in data parser 420B, converted to counts in calculation engine 420H, added to histograms 590A-590B, and then forwarded to repository 475 for storage. Again, this process may occur sequentially and / or asynchronously (e.g., a data parser may extract and provide data for asynchronous counter updates associated with histograms, and subsequent data storage in the repository may occur asynchronously or substantially simultaneously).

[0111] Logic 420C may also determine one or more descriptive measurements, such as statistics (e.g., median, in and out interquartile range, mean, sum, standard deviation, etc.), based on the counts, histograms, and / or received sensor data. Logic 420C may provide these descriptive measurements to report generator 420G to enable report generation (e.g., for display in user interfaces 410A-C). For example, the mean may be determined by summing the products of the counts and bin values ​​and then dividing that sum by the sum of the counts. Referring again to histogram 590A of FIG. 5, the mean is 46 (20×1 + 30×2 + 60×4) ÷ (1 + 2 + 6).

[0112] Pattern detector 420I may perform pattern detection on data such as sensor data representing blood glucose data, analytes, and other data (e.g., insulin pump data, carbohydrate consumption data, etc.) similarly processed by analyte processor 490 and stored in repository 475. Pattern detector 420I may also detect patterns retrospectively over a predetermined period of time defined by system 400 and / or a user.

[0113] In some example implementations, the pattern detector 420I may receive input data from the repository 475, which may include sensor data representing glucose concentration data, analytes, and other data as well (e.g., insulin pump data, carbohydrate consumption data, histograms and / or counts, data from continuous glucose monitors (CGM data), time of day, carbohydrate amounts, other food information, exercise, wake / sleep timer intervals, medications taken, etc.). The input data may also include historical data obtained over a time frame such as 8 hours, 1 day, 2 days, 7 days, 30 days, and / or any other time. For example, the input data may include counts representing monitored analyte detection levels (e.g., glucose concentration levels) received and stored in the system 400 over a period spanning a 4-week time frame.

[0114] The pattern detector 420I may analyze the input data for patterns. For example, patterns may be recognized based on one or more predefined rules (also called criteria or triggers). Furthermore, one or more of the predefined rules may be changeable and adjustable based on user input. For example, some types of patterns and the rules that define the patterns may be selected, turned on and off, and / or changed by a user, the user's physician, or the user's supervisor, although the system 400 may programmatically select, adjust, and / or change rules as well.

[0115] Some examples of the types of relationships in the input data that may be considered patterns are one or more of the following: glucose levels above a target glucose range (which may be defined by a user, a healthcare professional, the system 400, or a combination thereof); glucose levels below a target glucose range; a sudden change in glucose level from low to high (or vice versa); the time of day when a low, high, in-range, or sudden glucose level event occurs; and / or the day of the week when a low, high, in-range, or sudden glucose level event occurs.

[0116] Another example of a type of relationship within the input data that may be considered a pattern is hypoglycemic events by time of day. As one example, a pattern may be identified in situations where a user experiences low glucose concentrations around the same time of day. Another type of pattern that may be identified is a “rebound high” situation. For example, a rebound high situation may be defined as a situation where a user overcorrects a hypoglycemic event by excessively increasing glucose intake, thereby turning it into a hyperglycemic event. These events may be detected based on one or more predefined rules. Patterns that may be detected include hyperglycemic patterns, hypoglycemic patterns, patterns related to the time of day or week, and weighted scoring for different patterns based on frequency, continuity, and severity. Patterns may also be based on the user's usual sensitivity, hypoglycemic-to-hyperglycemic transition patterns, the duration of severe events, and a combination of glucose variability and time information. A detected pattern may also be a pattern of high variability in glucose data. Additionally, a pattern may be based on a combination of previous pattern data and a currently detected situation, whereby the combined information generates a predictive alert.

[0117] The pattern detector 420I may detect patterns and generate an output, which may be provided to the report generator 420G for reporting. The report may also include a retrospective analysis of the input data and any patterns determined by the pattern detector 420I. While the previous examples describe techniques for detecting patterns in data, other techniques may be used as well.

[0118] The data filter 420D may be used to check whether output generated by the analyte processor 490, such as a response to a particular type of data, report, etc., violates data rules. For example, the data filter 420D may have data rules that check whether the response contains data such as PII to a destination that is not authorized or permitted to receive the response (e.g., based on authorization and authentication, corresponding to the role of the user making the request).

[0119] Data formatter 420E may format the data to be delivered based on the type of destination. For example, data formatter 420E may format a report based on whether it is being sent to a printer, a user interface, secure email, another processor, etc.

[0120] The report generator 420G may generate one or more reports. The reports may provide descriptive information, such as statistical information describing the sensor data received at the analyte processor 490. The reports may also provide retrospective analysis of the sensor data stored in the repository 475. For example, the reports may provide statistical information based on the sensor data (and / or corresponding histograms including counts) over a time frame such as 8 hours, 1 day, 2 days, 7 days, 30 days, and / or any other time period. The reports may also allow a user, such as a patient, recipient, or clinician, to view the reports to identify trends and other health-related issues.

[0121] In some example implementations, report generator 420G generates reports based on data received and / or stored in system 400 (e.g., using sensor data, metadata, counts, histograms, etc.). Examples of reports and / or modules that may be used within reports are shown in FIGS. 6A-1, 6A-3 through 6A-28, and 7-11.

[0122] The report generator 420G may also configure the report based on metadata describing the types of sensors providing sensor data to the system 400, the number of sensors providing sensor data to the system 400, user preferences such as recipient and / or clinician selection, the size of the display of the user interface, and / or the length of the report.

[0123] In some example implementations, the report presents retrospective data (also referred to as historical data) received and stored by system 400 over a particular time frame, such as from the last upload of data to system 400, to 8 hours, 1 day, 2 days, 7 days, 30 days since the last visit to a doctor / clinic, and any other time frame. For example, a user and / or clinician may access user interface 410A and select a time frame for data to retrieve from repository 475 for analysis (e.g., retrieve the recipient's measured glucose data, carbohydrate consumption data, and insulin pump data for the past 30 days, and / or histograms containing counts representing such measured data). While the previous example describes a user selection of a time frame, the time frame may likewise be programmatically selected by system 400. In any case, report generator 420G may compile the report using one or more modules, described further below.

[0124] Figure 6A-1 shows an example of a report 700, which may be generated by report generator 420G. The description of Figure 6A-1 also refers to Figure 4A.

[0125] Report 700 may include one or more modules 710A-D. Modules 710A-D may be self-contained, meaning that they can be used independently of one another. For example, report 700 may include one or more modules 710A-D, and modules 710A-D may be located in various positions within the report. Additionally, modules 710A-D within report 700 may be dynamic, meaning that the specific types of modules selected for a report may change based on metadata. The metadata may include one or more factors such as the type of data available during the reported time frame (e.g., sensor data and metadata), the amount of data available during the time frame, the device used (e.g., insulin pump, glucagon pump, single-point blood glucose meter, continuous blood glucose meter, etc.), user preferences (e.g., preferences of the patient, doctor, clinician, etc.), the size of the user interface available to display the report 700, patient demographics, pre-selected / configured preferences provided by the user and / or the system 400, other modules used within the report (e.g., certain modules may not be permitted for use with other modules, while other modules may be required for use with certain modules), the amount of information displayed (e.g., continuous glucose monitors that generate relatively more data than self-monitoring blood glucose devices may require certain modules), and / or any other factors.

[0126] In some example implementations, the request may be received, for example, by the report generator 420G. Once the request is received, the report generator 420G may generate the report 700 based on the metadata, as described above. For example, the metadata may be accessed by the report generator 420G to obtain information related to one or more factors. For example, the metadata may include patient information, including report preferences, the type and number of devices used, and the display size used to display the report, as described above, and other data related to the user, the device, etc. The metadata may also include rules, such as whether a module is usable with a particular device (e.g., a particular report may only be appropriate for continuous blood glucose rather than individual measurements), whether a module is usable for a particular patient condition (e.g., a caregiver may establish rules requiring particular reports based on a patient's demographics, history, general condition, and / or symptoms or conditions at any time), whether a module may be used on a particular display size, whether a module may be used given a certain volume of data or device type, and / or any other rules defining which modules are usable within a given report.

[0127] In some implementations, the report generator 420G may access metadata that includes a template. For example, a template may define the placement of one or more modules within a report.

[0128] The framework defining the arrangement of each module 710A-D may be a template (also called a model). Templates may also be defined for specific devices or displays, such that when a request is generated and / or metadata is obtained, the report generator 420G can dynamically select one or more modules within a predefined template based on the metadata. For example, one display device may be sized to display four modules, as shown in FIG. 6A-1, while another display device may be sized to display two modules. While FIG. 6A-1 shows an example implementation including four modules, other numbers (and arrangements of those modules) may be used as well.

[0129] In some example implementations, the metadata may have multiple predefined templates configured for a particular patient, a particular caregiver, a particular healthcare professional, a patient group (e.g., a cohort), a business person, etc. In this manner, modules may be dynamically selected based on an evaluation of the metadata. Also, in some implementations, the use of templates may allow dynamic generation of modules to be performed more quickly when compared to not using templates. In any case, when report generator 420G selects which of modules 710A-D to include in report 700, report generator 420G may then obtain the underlying data (e.g., sensor data, demographics, etc.) used in the selected modules.

[0130] Figure 6A-2 illustrates an example of a dynamic report generation process according to some example implementations. The description of Figure 6A-2 also refers to Figure 4A.

[0131] At 715, a request to generate a report may be received. For example, report generator 420G may receive a request from processor 20, device 18, 16, or 14, and / or any other user interface to create report R00 including one or more modules 710A-D. The request may include information such as patient identification, requesting device identification, the type of report requested, etc. The request may specify a time frame for the report and / or any other information needed to authenticate the requesting device or user.

[0132] At 720, one or more modules, such as the report modules disclosed herein, may be selected based on metadata including rules, templates, etc. This metadata may describe one or more of the following: the type of data possible; the amount of data; the type of device used; user preferences; the size of the user interface on which the report can be displayed; patient demographics; patient information including report preferences, the type and number of devices used, and the size of the display used to display the report, and other data related to the user, device, etc. Rules such as whether a module is usable with a particular device (e.g., a particular report may only be appropriate for continuous blood glucose rather than individual measurements), whether a module is usable for a particular patient condition (e.g., a caregiver may establish rules requiring particular reports based on a patient's demographics, history, or condition), whether a module may be used on a particular display size, whether a module may be used given a certain volume of data or device type, and / or one or more templates. For example, module selection may be based on metadata including user preferences for particular modules, the type of device being used, the display area of ​​the device, rules defining which modules are available given the device type, the patient's condition / symptoms, and the display area of ​​the device. Additionally, metadata may be stored in a repository such as repository 475, while some metadata may be provided as part of the request received at or 710.

[0133] At 725, a report may be generated based on the modules selected at 720. For example, if the metadata indicates that a user prefers two particular modules (e.g., a first module related to a continuous glucose monitor and a second module related to a self-monitoring glucose monitor) and the metadata indicates that the device currently being used is a continuous glucose monitor, the report generator 420G may dynamically select the first module. However, if a second request is received but the metadata indicates that a self-monitoring glucose monitor is being used, the report generator 420G may dynamically select the second module. The module(s) may also be arranged in the report based on predefined templates as described herein.

[0134] In some implementations, the analyte processor 490 may have one or more default settings for the report 700 containing modules therein. The default settings may also be dynamic, meaning that the default settings change based on the patient. For example, if a recipient has type 1 diabetes, a default target glucose range may be defined as 70-180 mg / dL, and for type 2 diabetes, a default target range may be defined as 90-130 mg / dL, although these default settings may be changed by a user, such as a clinician, doctor, or patient. The analyte processor 490 may also base reports and / or particular modules on a default time frame of data, such as the most recent 30 days of data, although other default time frames may be used as well. Furthermore, if there are gaps in the data provided to the analyte processor that prevent 30 consecutive days of analysis, the report may start with the most recent data and roll back without exceeding the 30-day limit.

[0135] 6A-3 shows an example of a patient information module 605A. The patient information module 605A may provide information identifying the patient, such as the patient's name 605B, appointment date 605C, email address 605D, symptoms 605E, and any other information that may be used to identify the user, such as the patient, recipient, medical record number, etc. In some example implementations, the patient information module 605A may be configured to allow for quick identification of the patient at the top of the report 600. Although the patient information module 605A shows personally identifiable information (PII), such as the name 605B and email address 605C, the patient information module 605A may be configured to be anonymous to avoid disclosing the PII information.

[0136] FIG. 6A-4 shows an example of a highlight module 607A. The highlight module 607A may have one or more sub-modules 607B-E that provide abstractions of data received and processed in the analyte processor 490. In some example implementations, the highlight module 607A provides abstractions by extracting details of data obtained over a time frame, such as 8 hours, 1 day, 2 days, 7 days, 30 days, and / or any other period, into a graphical representation along with some textual information. In the example of FIG. 6A, the time frame of the data is indicated by 607F (for one month in this example, but other time frames may be used as well). The glucose module 607B may extract 30 days of data provided by a continuous blood glucose sensor (which may represent a large amount of data that could overwhelm a patient or clinician). This data may be extracted into graph components, such as a graphical bar 609A and textual information, such as callouts 609D-F, representing the percentage of time the patient spent below, above, and within the target range over the past 30 days.

[0137] In some example implementations, the extract may convey complex statistical information in the format of a graphical bar. Furthermore, the graphical bar may use different shading to represent different values, states, or symptoms and may have callouts containing text information providing summary information, numerical help, etc. Different shading may be used to convey different states of the recipient or patient as determined based on the received data (e.g., counts, etc.). For example, the glucose module 607B may use the lightest shading 609A on the graphical bar 609B to convey a target glucose range, while other shading may be used to represent other portions of the recipient's glucose range. While some examples described herein are described using shading, other distinct graph components, such as color, icons, or other components, may be used as well.

[0138] In some implementations, each sub-module of the highlight module 607A uses horizontal bars with different shading to represent ideal and sub-ideal values. For example, the lighter the shading, the more ideal the value. Furthermore, the sub-modules may vary depending on whether self-monitored glucose concentration data values ​​or continuous glucose monitoring data values ​​are being shown. For example, titles and descriptive text may indicate whether the module is continuous data or not; in some cases, the sub-module may not be relevant for only non-continuous glucose data values ​​(e.g., obtained from a finger prick meter) or only continuous glucose monitoring data values. The glucose module 607B may include a text legend 609C for the target range for the glucose readings, a graphic bar 609B including one or more different shadings (at least one shading 609A that can indicate a target range) across the range of glucose readings, and callouts 609D-F.

[0139] In the example shown for glucose module 607B, the shading corresponding to 180 to 315 indicates a range multiplied by a factor (e.g., 1.75) of the maximum target glucose range, and the symbols 25% and 75% indicate the inner and outer quartiles shaded separately, although other shading schemes, ranges, and factors may be used.

[0140] The glucose module 607B can present statistical information established for a recipient, such as the patient identified in 605B, over a time frame defined by the report generator 420G, for example, by a user (e.g., a patient, a clinician, and / or programmatically selected by the system 400). In the example of FIG. 6A, the statistical time frame is the previous 30 days, although other time frames, such as 8 hours, days, weeks, months, years, etc., may be used. Additionally, the statistical information may be determined from data received by the analyte processor 490 regarding one or more devices, source systems, etc. For example, the data may represent sensor data (e.g., continuous blood glucose data, insulin pump data, self-monitored blood glucose data, carbohydrate consumption data, etc.) and / or metadata provided to the analyte processor 490, and in some example implementations may be formatted according to counts, although other data formats may be used.

[0141] In some example implementations, the statistical information presented in the glucose module 607A may be determined using 30 days' worth of data stored in the repository 475 in one or more histograms including counts, although other data formats, such as any other data formats discussed herein, may be used. While the previous example is described with respect to 30 days' worth of stored data, other time frames may be used, and the time frame may be user-selected. Additionally, the graphic bar 609B may include a callout 609D containing text information indicating that over approximately the last 30 days 607F, 25% of the glucose measurements received by the analyte processor 490 from one or more devices were within the target range, with the callout 609D including text information indicating that the inner quartile was 123. The callout 609E indicates that over approximately the past 30 days, the median was 163, and the callout 609E indicates that the outer quartile was 205.

[0142] 6A-5 show examples of glucose modules, specifically glucose distribution modules 750 and 760. Each of glucose distribution modules 750 and 760 provides a graphical abstraction of the sensor data provided to analyte processor 490, displaying glucose values ​​in the illustrated example. Glucose values ​​within the target range are shown as a distinct graphical representation, such as the lightest shading, and values ​​outside the glucose range are shown as a distinct graphical representation, such as the second darkest shading. Textual information may be presented adjacent to the abstracted graph. This textual information may include statistical information determined from the sensor data. For example, module 750 displays a mean value of 171 for a given time frame, plus or minus 64 standard deviations, a median value (e.g., 123) with quartile values ​​(e.g., 163 and 206), an indication of the variability of the glucose values, such as the coefficient of variation (CV), which in this example is 37%, a glucose range with percentages and graphical indicators, a minimum glucose value (e.g., 39), and a maximum glucose value (e.g., 401). In the example of FIG. 6A-5, the arrows associated with the glucose range indicate above the glucose range, within the glucose range, or below the glucose range. Specifically, the recipient / patient has a particular range of glucose values, and some measured glucose values ​​are below that range (e.g., 4%, indicated by a downward arrow), some are within the range (e.g., 58%, indicated by a horizontal arrow), and some are above the range (e.g., 39%, indicated by a vertical upward arrow). Module 760 shows textual information, but may be presented in a different format. In any case, modules 750 and 760 provide a single display that condenses a month's worth of data into an abstracted graph highlighting the frequency of occurrence of in-range and out-of-range measurements.

[0143] 6A-4, the stability module 607C may include a text legend 609G that stability measures glucose variability and its rate of change, and that higher stability values ​​may be considered more favorable for the patient. The stability module 607C may also include a graphic element, such as a graphic bar 609H, presenting a range of glucose variability values ​​using different shadings and a callout 609I containing text information about whether glucose variability over a particular time frame (in this example, about 30 days 607F) is very low, low, moderate, or high.

[0144] In some example implementations, the stability module 607C can present a metric that combines glucose variability (which may be determined as a coefficient of variation) with the number of instances and time in a state of rapid glucose change (acceleration). For example, the analyte processor 490 can receive sensor data from the data retrieval 465, which retrieves data from a sensor, such as the sensor system 8. In this example, glucose variability and acceleration can be assigned a score having a range, such as from 0 to 50, with lower scores being considered preferable to higher scores. The variability score can be determined by normalizing the coefficient of variation over a particular time frame (e.g., 30 days) to a score range of 0 to 50, with a coefficient of variation of 0.7 or greater receiving a maximum score of 50. The acceleration score can be determined by sampling the rate of change over a sampling window, measured as mg / dL / min (milligrams per deciliter per minute), which is stored in the repository 475 as a histogram and count over the window (e.g., over a 15-minute window / interval), by evaluating the rate of change over the sampling window, measured as mg / dL / min (milligrams per deciliter per minute) estimated based on the rate of change over the current and previous sampling windows. The combined variability and acceleration score is a weighted mg / dL / min that may be calculated over some, if not all, of the sampling window for the time frame of the report or module 607C and then normalized to a scale of, for example, 0 to 50. In this example, a weighted equivalent of 6 mg / dL / min or greater may receive a score of 50. The variability and acceleration scores may then be combined (e.g., added) to determine the location of the callout 609I on the graphic bar 609H.

[0145] In some example implementations, the stability module 607C may only be included in the report 600 if sensor data from a continuous glucose monitor is available for processing.

[0146] Further, although in the previous example the stability module 607C provides a metric that combines the coefficient of variation and acceleration, the stability module 607C may be configured to provide a metric that represents one of the coefficient of variation or acceleration.

[0147] Although the previous examples set forth specific numerical values, units of measurement, etc., these values ​​and units of measurement are exemplary only and other values ​​may be used.

[0148] The time between module 607D may include a text legend 609J indicating that the target range for glucose measurements is between two values ​​(e.g., 70 mg / dL and 180 mg / dL) and that a higher percentage of time within the target range is generally more favorable for the patient. The time between module 607D may further include a graphic element, such as a graphic bar 609O, that visually presents the percentage range using different shadings, and a callout 609L that contains text information representing the percentage of time that the glucose readings are within the target range. In some implementations, the time between module 607D is generated when continuous glucose sensor data is available from a continuous glucose monitor. However, if only non-continuous glucose data is available (e.g., only data available from a self-monitoring blood glucose monitor), the time between module 607D can instead be configured to represent the time between tests performed using a self-monitoring blood glucose monitor or the percentage of self-monitoring blood glucose tests between ranges.

[0149] The time below module 607E may include a text legend 609K about how a percentage of time below a certain value, such as 70 mg / dL, is generally more favorable for the patient. The time below module 607E may further include a graphic element, such as a graphic bar 609N, that presents a percentage range using one or more different shadings, and a callout 609M that includes text information representing the percentage of time the glucose reading was below a certain value, in this example 70 mg / dL. In some example implementations, the time below module 607E is generated with respect to continuous glucose monitor data. However, if only self-monitoring blood glucose monitor data is processed, the time below module 607E may instead be configured to display the time between tests performed on the self-monitoring blood glucose monitor. Although module 607E is shown as a time (or test) below which presents a percentage, module 607E may also be configured as a time (or test) above which which presents the percentage of time (or test) that the glucose value is above a certain value.

[0150] FIG. 6A-6 shows an example of a percentage above test module 674PS, which is similar to the time below module 607E, but shows the percentage of time above the target range.

[0151] 6A-7 illustrate an example of an insight module 615 configured to abstract one or more patterns detected based on a patient's data processed by the analyte processor 490. In some exemplary implementations, the insight includes a graphical element 617A, such as an icon, and textual information 617B. For example, an insight 617C may display one or more patterns detected by the analyte processor 490 (and, in some exemplary implementations, the pattern detector 420I) over a specific time frame, such as an 8-hour, 1-day, 2-day, 7-day, or 30-day period. Additionally, patterns may be "hard-coded" and triggered when an event is detected in the data. For example, patterns may detect high glucose concentration levels above a target glucose range and then associate them with days of the week and times of day to determine whether a patient experiences high blood glucose during a particular day or time of day. In this example, the detected pattern may correspond to detecting that a patient has high glucose concentration levels every night after 8:00 PM or every Sunday evening for the past 30 days. Additionally, the pattern detector 420I, in some example implementations, can detect patterns based on histograms and counts over a period of the past 30 days. Other patterns can be detected based on data from sensors and / or metadata and similarly presented by the insight module 615. For example, the metadata can indicate that a patient has type 2 diabetes and uses a particular device, such as a self-monitoring blood glucose monitor or insulin pump. In this example, the metadata can be used to determine which patterns to use for detection and which (and how many) insights to present in the insight module 615.

[0152] In some example implementations, the insights presented in the insight module 615 can be weighted to emphasize certain insights or events and then ranked so that some, but not all, of the insights can be presented, which can be detected by the analyte processor 490 and / or the pattern detector 420I. For example, the insight module 615 can be configured to include more (or fewer) insights based on user preferences, the quantity of devices providing data to the analyte processor 490, and / or the type of devices providing data to the analyte processor 490. The insights can be further processed to determine strong correlations for a given patient, such that the insights presented in the report 600 have a high degree of confidence that the insights represent the patient's current situation. Furthermore, similar patterns can be merged, and weighting can be used to emphasize positive insights over negative insights (and vice versa).

[0153] In some exemplary implementations, insights presented by the insight module 615 can be associated with one or more patterns detected by the pattern detector 420I. Example patterns include patterns for glucose values ​​within a target glucose range, patterns for glucose values ​​above a target glucose range, patterns for glucose values ​​below a target glucose range, patterns for detecting rapid changes from high to low glucose values ​​(or vice versa), patterns for high coefficients of variation, etc. In some exemplary implementations, each pattern in the pattern detector 420I has a single characteristic, so separate patterns can be used to specifically look for under-range patterns, other patterns looking for low coefficients of variation, etc. In some exemplary implementations, each pattern in the pattern detector 420I is statistically based, and standard descriptive statistics can be used. In some exemplary implementations, each pattern in the pattern detector 420I can be assigned a score or weight to indicate its relative importance to other patterns. In some exemplary implementations, each pattern in the pattern detector 420I can be assigned an application time window during which pattern detection is performed.

[0154] To further illustrate examples of patterns, basic patterns can be constructed to allow for searching for specific patterns in the data, such as values ​​within a range, a high coefficient of variation, etc. Each pattern has one characteristic, such as within a range, with a separate pattern specifically looking for values ​​below a range, another looking for a low coefficient of variation, etc. Each pattern is statistically based and can use standard descriptive statistics applied to pattern matching. Each pattern can be assigned a score for various rules encoded in each pattern, such as whether it is positive or negative, how important the insight is, etc. Each pattern can also be assigned a possible set of date ranges for which the pattern is applicable. For example, counting the number of times a high glucose value is followed by a low below range is a pattern that applies to just about any range. However, noting high levels of variation can be applied to monthly, weekly, daily, intraday, hourly, hourly, and combinations thereof. Every pattern can be assigned a minimum acceptable score before it can be considered for display. Each pattern (and any associated rules) can be processed against a set of data for a particular time frame, and if the pattern is applied and meets certain minimum requirements, the patterns are then ranked according to importance. Thus, the ranked patterns each correspond to an insight, resulting in a ranking of the insights. For example, the insight module may present only a subset, such as the top five insights, although other quantities of insights may be configured to present.

[0155] The insight module 615 can present statistical patterns over the time frame of the report. Furthermore, the particular insight representing the statistical pattern can be presented that has the highest correlation for that patient. For example, before a particular insight is presented, the analyte processor 490 can perform post-processing, such as merging similar statistical patterns together, weighting positive insights somewhat more than negative insights (or vice versa), etc. The selected insight can be considered deterministic in the sense that the insight will be generated identically each time the time range, patient information, and health data are exactly the same.

[0156] 6A-8 show examples of a high and low period module 620A. The high and low period module 620A highlights patterns of high and low periods for data measured over a predetermined period, such as 1 day, 2 days, 7 days, 30 days, and other time frames. In this example, the high and low period module 620A indicates that a patient providing sensor data to the analyte processing engine 490 had a pattern of high glucose instances (e.g., above a defined target range) detected at 622B-I over the last 30 days 622A. These high points (e.g., high points such as 622E) may indicate a pattern of high glucose during the evening hours. The high and low period module 620A further indicates that no low points occurred. If an analyte processor pattern of low glucose had been detected, the low glucose pattern may be displayed similarly to the high glucose pattern, albeit in the reversed direction. In some example implementations, the analyte processor 490, including the pattern detector 420I, can detect the high and low events indicated by the high and low module 620A. Additionally, detection may be based on patterns (e.g., patterns may define features to identify or detect in data received and / or stored in system 400 and / or repository 475). Additionally, areas under graphed portions may be shaded to convey whether a high or low period exceeded a threshold. For example, the area under high portion 622I may be shaded to indicate that the high portion is of particular interest (e.g., exceeding a magnitude threshold, which may be an upper target range threshold, for a period exceeding the threshold). Additionally, multiple thresholds (and shading) may be used to convey other areas of interest on the graph, such as patterns of relatively higher portions (or longer periods of high) or lower portions (or longer periods of low) detected using different thresholds and presented using different shading.

[0157] 6A-9 shows an example of a device usage module 630. The device usage module 630 may include a text legend 632A for each device providing data for analysis and reporting with the analyte processor 490, a graphic element such as a graphic bar 632B with different shading to indicate the range of time the device is actually used, and a callout 632C providing text information regarding the percentage of time the device was used over a particular time frame, such as 1 day, 2 days, 7 days, 30 days, etc. While the example in FIG. 6A-9 shows only one device, if a given patient provides data to the analyte processor 490 using additional devices, those additional devices would also be depicted with a text legend, graphic bar, and callout indicating the percentage of time the device was used over the time frame.

[0158] In some exemplary implementations, the device usage module 630 may include whether the device's clock is inaccurate and whether any corrections have been made by the analyte processor 490. For example, the data retriever 465 may determine that the device clock was off (or in error) by a certain amount and report that certain amount to the analyte processor 490. In this case, the device usage module 630 may indicate this amount of error. In some exemplary implementations, the analyte processor 490 shifts data from the device to correct for the error and make it consistent with other data. In this case, the device usage module 630 may indicate the amount of the time shift.

[0159] Figures 6A-10 show additional examples of devices in use, including a Device in Use module 733A for a continuous glucose monitor, a Device in Use module 733B for a self-monitoring blood glucose monitor, and a Device in Use module 733C for implementations including multiple devices, such as a continuous glucose monitor and a self-monitoring blood glucose monitor. Figure 6A-10 further illustrates the dynamic nature of the reports, with module generation 733C dynamically configured based on the device the patient is using. Figure 6A-10 also shows a time-shift feature, indicating device clock differences (or errors).

[0160] 6A-11 illustrate a comparison module 640. The comparison module 640 can represent a statistical comparison of a patient, such as the patient identified in 605B, to a group, such as a cohort. The comparison module 640 can include a text legend 642A about what the other group is (e.g., other patients at the clinic), a graphic element, such as a graphic bar 642B containing one or more different shadings to present a range of values, and callouts 642C-D. In the example of the comparison module 640, the callout 642B textually displays the percentage of time the device was used over a particular period, such as 1 day, 2 days, 7 days, and 30 days 605E. In the example of FIG. 6A-11, the graphic bar 642B and callouts 642C-642D compare the patient 605B to other clinical patients 642A, and the comparison is based on data obtained from the patient and other clinical patients over a given time frame, such as 1 day, 2 days, 7 days, and 30 days 605F. The comparison is based on data collected over a 30-day time frame, regarding the time the patient is below the target glucose range (2%, as indicated by callout 642D) and the time other patients in the clinic are below the target glucose range (7%, as indicated by callout 642C), although other statistical comparisons, time frames, and groups may be used. In some exemplary implementations, the statistical comparisons shown for the comparison module may be determined based on histograms and counts as disclosed herein. Additionally, the analyte processor 490 may programmatically select the group 642A to be used as a cohort, although the user may select the group. The group 642A may be selected based on metadata representing one or more of the following: type of diabetes, age, sex, age at diagnosis, location, treatment device, type of sensor device used, and other factors or demographics such as any type of metadata discussed herein. In some exemplary implementations, the analyte processor 490 may programmatically select the group most similar to patient 605B, although other selection schemes may be implemented.

[0161] FIG. 6A-12 shows another example of a comparison module 674XY. The comparison module is generated by the report generator and compares the recipient to another user or a group (e.g., a cohort) of users. In the example of FIG. 6A-12, the patient is compared to all patients in the clinic with respect to a particular range, such as the percentage of glucose concentration levels below and above the target glucose concentration range. In this example, the patient has a 16% time range below and a 29% time range above, while the group has a 27% time range below and a 56% time range above. While the previous comparison compared the patient to a cohort associated with the same clinic as the patient, other groups or comparisons may also be made. For example, the analyte processor 490 may include metadata that allows comparisons based on one or more of the following: diabetes type, age, gender, age at diagnosis, etc.

[0162] In some implementations, the analyte processor 490 can programmatically select groups to compare the patient to in the comparison module, and this selection can be made to identify groups that are most similar to the patient. Furthermore, in some implementations, this selection can be weighted in favor of groups in which the patient is somewhat better than other patients in the group. This selection can also be determined programmatically. For example, the analyte processor 490 can determine all possible cohorts to which the user belongs and select groups with even the slightest positive association. The analyte processor 490 can determine the patient's differences with all cohorts (e.g., by comparing their statistics) and select the cohort with the smallest difference (which may be the most similar to the patient). Furthermore, positive differences can be selected in preference to negative differences. For example, for patients with glucose concentrations that are out of range 16% of the time, a clinic with patients who are out of range 18% of the time may be selected in preference to another cohort or statistic with a negative difference (e.g., when compared to another group with a negative difference, such as a group of cohorts that are out of range 15% of the time). Furthermore, in the absence of a positive difference, the analyte processor 490 may look for a slightly negative difference so that a slightly negative correlation can trump a significantly positive one. Returning to the previous example of out-of-range glucose concentrations, if there is no 18% group, the analyte processor 490 may select the group that is slightly negative at 16%.

[0163] 6A-13, the daily summary module 650 can provide a modal daily display of glucose data collected over a given time frame, such as the previous month 652A, for one or more devices providing data to a given patent, such as patient 605B. In some implementations, the data presented to the patient can be selected for the purpose of encouraging the patient (e.g., by indicating that the patient is doing well). The daily summary module 650 displays the patient's daily fluctuations over a given time frame.

[0164] In the example daily summary module 650, the x-axis 652B represents a first time interval, such as 24 hours, and the y-axis 652C represents measurements, such as glucose values. The analyte processor 490 can determine statistics, such as the percentage of time within a target glucose range (coded as in range), the median glucose value, the middle 50% range of glucose value measurements, and the variability of glucose measurements, based on 30 days' worth of sensor data, although other time frames may be used. The example daily summary module 650 shows the median range and interquartile range, but other determined statistics may be presented. Additionally, the determined statistics can be categorized based on time of day, such as a particular hour or period (e.g., epoch, or more generally, ranges such as morning, afternoon, etc.). Once categorized, the determined statistics can be presented in a module, such as the daily summary module 650.

[0165] In some example implementations, the daily summary module 650 may plot a median glucose value with a separate element 652D, such as a thick line or object, over a first time frame, such as a 24-hour period, the middle 50th percentile of glucose values ​​is plotted with another separate element 652E, such as a lighter shade, and the target glucose range is indicated by two separate elements 652G, 652H, shown as lines at, for example, 70 mg / DL and 180 mg / DL.

[0166] When the daily summary module 650 presents self-monitored blood glucose data, each individual test (or sub-density aspect of the data) may be displayed as an element, such as a dot. Figure 6A-14 shows an example of a daily summary module 769A configured to present self-monitored blood glucose data.

[0167] 6A-13, if the daily summary module 650 includes continuous blood glucose monitor data, each individual measurement may not be plotted, but instead the median ±25% may be plotted with slight shading to indicate the interquartile range. In some exemplary implementations, the median and interquartile range values ​​are calculated every 30 minutes. In some exemplary implementations, when plotting only self-monitored blood glucose data, the shading is lighter and a light dashed line is used. When continuous blood glucose monitor data is included, the shading is darker and a solid line is used to distinguish between types of data sets. In some exemplary implementations, the analyte processor 490 calculates the median and interquartile range values ​​to enable representation in the daily summary module 650 using a c-spline smoothing algorithm, such as Fritsche-Carlson monotonic cubic Hermite interpolation, although other techniques may be used.

[0168] In some example implementations, the daily aggregation module 650 may include a text aggregation 652F. For example, the text listing 652F may include standard descriptive statistics (e.g., median, middle 50% (IQR), variability (CV), and percentage within range) categorized by time ranges within the day, such as night, morning, noon, afternoon, and evening. Each statistic may be calculated using every value in the reporting range and has been grouped into those time groups without sampling or weighted merging.

[0169] 6A-15 shows another example of a daily summary module 690A. In this example, the daily summary module 690 shows a daily display of data from multiple sources, which in this example correspond to glucose data 690B, carbohydrate consumption data 690C, and insulin pump data 690D. The daily summary module 690A plots the glucose data 690B in a manner similar to 650. However, the carbohydrates 690B are presented using multiple shades representing ranges of different carbohydrate consumption values ​​(e.g., a given shade represents the consumption of a given carbohydrate), and the insulin pump data 690D is presented as a bar graph.

[0170] FIG. 6A-16 shows another example of a module displaying daily recipient / patient analyte levels, such as glucose, and other values. The daily detail module provides summaries including glucose level 7100 and carbohydrate level 7200, with measurement intensity presented using various graphic indicators, such as darker shading, to indicate different values ​​of glucose or carbohydrate. The module in FIG. 6A-16 also shows insulin dosages 7300, including the quantity and time taken, with callouts such as "1," "2," etc., with corresponding text descriptions for the dosage events. For example, callout "1" 7400 corresponds to text description 7420. The module may include a summary 7500 containing statistical data such as average glucose, total carbohydrates, total insulin, basal insulin, and bolus insulin. The Daily Detail module provides a single display (which can exist as a single page in the user interface) that condenses a day's worth of data into an abstracted graph correlating measurements between medication doses, carbohydrates, and measured glucose, allowing the recipient / patient to immediately perform visual correlations between carbohydrate, glucose, and medication dose events.

[0171] FIG. 6A-17 shows another example of a daily summary module. In this example, the daily summary module represents a day's worth of data from multiple sources, which in this example correspond to glucose data, carbohydrate consumption data, and insulin pump data. The daily summary module of FIG. 6A-17 presents discrete data, such as SMBG data, as shown by data points 769A, 769B, etc. Additionally, insulin dosages show actual dosage effects / profiles 769C. The daily summary module provides a single display (which may be presented as a single page in a user interface) that condenses an extended time frame, such as 29 days and / or some other period, into a graphical representation correlating measurements between dosage / pump data, carbohydrates, and measured glucose, allowing the recipient / patient to immediately perform visual correlations between carbohydrate, glucose, and dosage events.

[0172] 6A-18 illustrates an example of a weekly aggregation module 660. The module 660 may be implemented in a manner similar to the daily aggregation module 650, except that the current data spans a seven-day period rather than a 24-hour period, as indicated by the x-axis 662A. In some example implementations, the breakdown of the data presented in the weekly aggregation module 660 may be calculated for periods greater than two hours, although other breakdowns may be used.

[0173] FIG. 6A-19 shows another example of a weekly summary module 692A. The weekly summary module 692A can be implemented in a manner similar to the daily summary module 650, except that the current data spans a seven-day period rather than a 24-hour period. In this example, the weekly summary module 692A displays data by day from multiple sources, which in this example represent glucose data, carbohydrate consumption data, and insulin pump data. FIG. 6A-20 shows an example of a weekly summary module 769B configured to display self-monitored blood glucose data.

[0174] 6A-21 shows an example of a time-course aggregation module 694A. The time-course aggregation 694A is similar to the daily and weekly aggregation modules disclosed herein, but the time-course aggregation 694A plots glucose values ​​over time using median values ​​for 12- to 18-hour intervals, depending on whether continuous glucose monitoring data is included.

[0175] 6A-22 shows an example of a continuous glucose level module 670A. The module 670A presents in graphical form the time a patient has been within, above, or below a target glucose range based on retrospective data obtained over a time frame such as 8 hours, 1 day, 2 days, 7 days, 30 days, etc. The continuous glucose level module 670A may include a legend 670B, an indication of the time period 670C during which information is plotted, and one or more graphical elements 670D-670J, such as bars, icons, etc., for one or more intervals within the time frame 670C.

[0176] In some example implementations, the y-axis represents the days of the week during time frame 670C, and the x-axis represents the times (or epochs) during the time frame. For example, graphical element 670D shows an over-range glucose condition on Friday, April 6th at approximately 12:00 AM, followed by another graphical element 670E representing an in-range glucose value. Graphic element 670K shows a glucose value below the target range on Wednesday at approximately 4:00 AM.

[0177] In some example implementations, the graphic elements for above the target range, below the target range, and being in the target range are separate. For example, above the target range 670D is shown as a bar above the target range 670E, which is shown as a line. Below the target range 670K is shown below the target range line 670L. Additionally, the graphic elements may include numerical help and other information. For example, selecting a graphic element presented on a computer may provide additional information about the glucose values, such as providing the actual values ​​for glucose values ​​above the range indicated by 670G (e.g., "352") and 670K (e.g., "57"), i.e., glucose values ​​below the range.

[0178] In some exemplary implementations, the recipient may select a target range for glucose values, although other entities, such as a clinician, healthcare provider, and the system 400, may select the target range. Moreover, in-target and below-target ranges may be detected by a pattern detector 420I based on one or more patterns in some exemplary implementations. For example, the pattern detector 420I processes the sensor data (or histograms and counts) stored in the repository 475 to identify glucose values ​​above the target range, including patterns correlating dates and times of above-range glucose values, which may be presented in the glucose value module 676A. The pattern detector 420I may process the sensor data (or histograms and counts) stored in the repository 475 to include patterns that identify below-target range glucose values. In some exemplary implementations, the pattern detector may perform weighting and / or thresholding of glucose values. For example, the pattern detector 420I may weight glucose values ​​using a function (e.g., equating, normalizing, or mapping to some other function). The weights can ensure accurate detection of high and / or low glucose events for reporting via a reporting module, such as daily summary module 650. Additionally, pattern detection unit 420I can use one or more thresholds to ensure that high and / or low glucose events are indeed events that should be reported as high and / or low glucose events.

[0179] In some example implementations, the pattern detector 420I can detect rapid changes in glucose and correlate the date and time of the rapid change for presentation in the glucose value module 676A. Furthermore, the rapid shifts can be presented in reports such as the continuous glucose level module 670A.

[0180] In some example implementations, the continuous glucose level module 670A may encode or highlight so-called "outliers," which represent high glucose peak values ​​within an epoch or low glucose peak values ​​within an epoch. Referring to the continuous glucose level module 670A, the outlier is encoded as having a value of 352 mg / dL at 620G. The continuous glucose level module 670A may further encode or highlight rapid changes in glucose values ​​from high to low (or vice versa).

[0181] In some example implementations, the pattern detector 420I may attempt to limit the quantitative data presented in the continuous glucose level module 670A. For example, if the continuous glucose level module 670A were to present hundreds of outliers and rapid shifts in glucose values, a user may be prevented from understanding the data presented in the continuous glucose level module 670A. Thus, the pattern detector 420I may process the glucose values ​​corresponding to outliers and rapid shifts until only a subset of the outliers and rapid shifts is detected. For example, the pattern detector 420I may process the glucose values ​​corresponding to outliers and rapid shifts until only approximately 30 outliers and rapid shifts are detected, which may be presented in the continuous glucose level module 670A, etc. (see, e.g., “352” in 620G, “57” in 620K).

[0182] To process the sensor data (or representative counts, etc.) to detect only a subset of outliers and rapid shifts, the pattern detector 420I, in some exemplary implementations, can process all of the data for a report or module time frame, e.g., 30 days, to identify outliers above the target glucose range, outliers below the target glucose range, and rapid shifts. The pattern detector 420I can then filter some of such values ​​based on a threshold and window. For example, a threshold can be applied to identify the top 8% of outliers above the target glucose range and the bottom 8% of outliers below the target glucose range. The pattern detector 420I can further apply a window to shifts through a portion of the data to detect rapid shifts. For example, all of the data can be processed in a 4-hour window to identify rapid glucose shifts from low to high (and high to low). After applying the threshold and window, the pattern detector 420I can determine how many high outliers, low outliers, and rapid shifts remain. If the remaining amount of high outliers, low outliers, and rapid shifts is below a presentation threshold (e.g., 30 outliers and rapid shift events presented for a 30-day display of continuous glucose levels), the pattern detector 420I can present the remaining high outliers, low outliers, and rapid shifts to the report generator 420G for presentation in the continuous glucose level module 670A. If the remaining high outliers, low outliers, and rapid shifts are above the presentation threshold, the pattern detector 420I can change the threshold and window size to reduce the number of high outliers, low outliers, and rapid shifts. For example, the threshold can be reduced from 8% to 7%, and 4 hours can be shortened to 3.6 hours. This process can be repeated until the number of outliers and / or rapid shifts is below the presentation threshold.

[0183] FIG. 6A-23 shows another example of a continuous glucose level module 670Z. In the example of FIG. 6A-23, glucose values ​​above the target range are shown with shading 670Y that can be distinguished from the shading 670W used for glucose values ​​below the target range and the shading 670X used for glucose values ​​in the target range. However, the continuous glucose level module 670Z can also use positional differentiation among the graphic elements, as in the continuous glucose level module 670A. For example, values ​​above the target range are shown as elements 670Y above the target range bar 670X, while values ​​below the target range are shown below the target range bar 670V. While FIG. 6A-23 uses both shading differentiation and positional differentiation to distinguish high, optimal, and low glucose values, each can be used without the other.

[0184] FIG. 6A-24 shows another example of a continuous glucose level module 770. Module 770 is similar in some respects to other continuous glucose level modules disclosed herein, but continuous glucose level module 770 uses shading and size to convey intensity. Specifically, at 774, the glucose level is significantly outside the target glucose range, as illustrated by the darker shading and vertical size of the block at 772. In contrast, at 776, the deviation from the target glucose range is somewhat smaller than at 778, where the darker intensity shading drops to a lower intensity level and also decreases in vertical dimension. Module 770 can use a thin bar 780 to indicate predetermined periods during which the recipient patient is within range and periods during which no shading (or color) is shown and no data may be present, as at 782. Module 770 shows the first four days of the period, but module 770 may indicate other time frames. In this way, module 770 abstracts the time spent above or below range into an easy-to-read graph that uses a visual indicator, such as intensity, to show how far the patient / recipient is outside the range.

[0185] 6A-25 shows another example of a continuous glucose level module 676A. The continuous glucose level module 676A is similar in some respects to the continuous glucose level module 670A, etc., however, the continuous glucose level module 676A includes distinct graphical elements only with respect to shading (e.g., color, intensity, contrast, etc.) so that glucose values ​​above the target range are shown in shading 676B that is distinct from glucose values ​​below the target range 676C and from shading 676D that represents glucose values ​​in the target range.

[0186] FIG. 6A-26 shows an example of a glucose meter level module 674A. While the glucose meter level module 674A is similar in some respects to the continuous glucose level module 670A, etc., the glucose meter level module 674A displays discrete values ​​associated with glucose measurements (e.g., made by a self-monitoring blood glucose meter) and may further include graphical elements, such as generally circular icons 674B and 674C indicating a particular percentage of the highest glucose reading above the target range and generally polygonal icons 674D and 674E indicating a particular percentage of glucose readings below the target range. Daily averages and variability may be listed to the right, with variability displayed for a given day only if two or more glucose readings are provided for that day. In some implementations, if a patient uses a self-monitoring blood glucose device and a continuous glucose monitor and provides their data to the analyte processor 490, the report generator generates two types of reports, such as the continuous glucose level module 670Z and the discrete glucose meter reading module 674A. Furthermore, processing by the analyte processor 490 is transparent in the sense that the analyte processor 490 can process both types of data and generate reports regardless of the source or type of data.

[0187] FIG. 6A-27 shows another example of a glucose meter level module 674AA. The glucose meter level module 674AA is similar in many ways to the glucose meter level module 674A, but includes arrows to indicate above or below a range. For example, 674AB shows an up arrow and 674AC shows a down arrow. Other indicators may be used to indicate high or low values ​​of glucose data during the day. Additionally, markers may be used to segment the time shown into periods such as morning, afternoon, evening, and night to assist the user in interpreting the presented data.

[0188] 6A-28 illustrates a report legend 687A, which may be included as a module in the report 700. In some implementations, the report legend module 687A may be included as the final module or portion of the report and may contain descriptions and explanations for the various portions of the report.

[0189] FIG. 7 shows an example of test frequencies for a self-monitored blood glucose test frequency module 700. The self-monitored blood glucose test frequency module 700 includes epochs, such as weekdays 702 and weekends 704, and corresponding time intervals 706 during those periods. Circles represent measurements taken by the recipient. For example, circle 708A represents the recipient measuring blood glucose at 1:00 AM one or more times during weekdays 702, and circle 708B represents the recipient measuring blood glucose at 1:00 AM one or more times during weekends 704. The larger the circle, the more measurements have occurred in the corresponding time period and interval. For example, circle 710B is larger than circle 708B, and thus circle 710B represents the recipient taking more blood glucose measurements at 8:00 AM compared to 1:00 AM. The report generator 420G can generate the self-monitored blood glucose test frequency module 700 based on the counts and corresponding histograms generated by the calculation engine 420H.

[0190] 8 shows an example of a patient question module 899. The patient question module 899 can be configured to allow a user, such as a clinician, physician, or the like, to ask a patient a question via a report that includes the patient question module 899 presented in a user interface. Once the question is asked, the patient's answers can be captured and included in the report. The patient question module 899 can include a standard set of default questions (e.g., obtained from the American Diabetes Association Criteria for Care Manual), which are selected by the user or programmatically by the analyte processor 490.

[0191] FIG. 9 shows another example of an insight module that includes a patient question within the same module (eg, "Many glucose checks are within range").

[0192] 10 shows an example of a module that provides "Days of Interest." The Days of Interest module aggregates information for a given time frame. For example, over a 30-day period, the Days of Interest module can indicate the days of the week when the patient's glucose values ​​were most in range (e.g., every Saturday), the days of the week when the patient's glucose values ​​were most variable (e.g., every Tuesday), and the days of the week when the patient's glucose values ​​were higher (e.g., every Sunday) or lower (e.g., every Thursday) than the target range. This allows the patient / recipient to determine if there are any lifestyle issues on the identified days that may be contributing to variability, high values, etc.

[0193] 11 shows an example of a process 1100 for processing analyte data, according to some example implementations. The description of the process 1100 may further be related to FIGS. 1, 4A, 4B, and 5.

[0194] At 1110, according to some example implementations, sensor data representing analytes measured in the recipient may be received. For example, the analyte processor 490 may receive sensor data, such as values ​​representing blood glucose levels, from one or more devices, such as the display devices 14, 16, 18, and 20, the sensor system 8, the data retrieval unit 465, and the user interfaces 410A through 410C. The analyte processor 490 may further receive (and / or determine) metadata associated with the analyte data, such as patient information and the time associated with the measurement of the analyte data. The analyte processor 490 may process the received sensor data and / or metadata using one or more aspects of the analyte processor 490 (e.g., the authentication and authorization 420, the data parser 430B, the calculation engine 420H, the pattern detection unit 420I, the report generator 420G, etc., as disclosed herein) and store the received sensor data and / or metadata in the repository 475. While the description of step 1100 is with respect to sensor data, the analyte processor 490 may process other types of data as well.

[0195] At 1120, according to some exemplary implementations, the sensor data and / or metadata received by the analyte processor 490 may be stored in the repository 475 based on histograms and counts associated with the received sensor data and / or metadata. For example, the sensor data and / or metadata received at 1110 may be processed by the calculation engine 420H to form counts, as described above with respect to FIG. 5. Further, the counts are then added to corresponding histograms (which may be stored in the repository 475) based on metadata such as the time of day and patient identification associated with the measurement. In some exemplary implementations, the counts may be added to other histograms associated with cohorts. The repository 475 may store received sensor data, metadata, histograms, and / or counts for one or more patients (also referred to as recipients) for a time frame of 8 hours, 1 day, 2 days, 7 days, 30 days, or more, allowing the system 400 to analyze the stored data and generate reports as disclosed herein.

[0196] At 1130, according to some exemplary implementations, the analyte processor 490 may receive a request to perform an action. For example, the analyte processor 490 may receive the request from a system, a processor, and / or a user interface (e.g., user interface 410A). The action may correspond to a request to generate a report for a particular patient, although other actions may be requested. The request may also indicate a time frame for the report, which may be programmatically determined by the system 400. The request may indicate other aspects of the request, such as the types of modules to be included in the report. In some exemplary implementations, the request may undergo additional processing, such as authorization, authentication, and analysis, by the analyte processor 490.

[0197] Additionally, the request may correspond to other actions in the analyte processor 490. Example actions include storing sensor data, metadata, and any other type of data in the repository 475, retrieving sensor data, metadata, and any other type of data in the repository 475, configuring reports and / or modules, customizing aspects of the system 400 (e.g., adding devices, customizing reports, target glucose ranges, time frames for reports, etc.).

[0198] In 1140, the analyte processor 490 and / or logic 420 can evaluate the time frame of the report, the patient's identification, and other metadata associated with the patient (e.g., number of devices, type of device, etc.) and analyze the portion of the sensor data associated with the time frame. Further explaining, logic 420 can determine that the time frame of the report is the past 30 days, the patient's identification 605A, and that the patient is associated with one type of continuous blood glucose monitoring device. In this example, logic 420C can determine descriptive measures (e.g., one or more statistics) for the patient for the past 30 days based on the data stored in repository 475 and / or can ask pattern generator 420I to detect patterns related to the patient's data stored in repository 475 during this 30 day period. In some example implementations, the time frame of the report and the corresponding data to be evaluated for the report are selected by a user (e.g., patient, clinician, etc.) or programmatically selected by system 400.

[0199] At 1150, logic 420 can initiate report generation in report generator 420G based on the analysis performed at 1140. For example, logic 420 can evaluate the report's time frame, the patient's identification, and other metadata associated with the patient (e.g., number of devices, type of device, etc.) to determine the types of modules to include in the report and the configuration of those modules. Further illustrating, logic 420 can determine that the report's time frame is the past 30 days, the patient's identification 605A, and that the patient is associated with one type of continuous blood glucose monitoring device. In this example, logic 420C can determine modules customized to present analysis, such as statistics and patterns, related to the continuous blood glucose monitoring data, such as highlights module 607A, continuous glucose level module 670A, etc. In some example implementations, the modules can be dynamically selected as described above with respect to FIG. 6A-2. The modules can be configured to form a report including the patient's data over the past 30 days, such as report 700 of FIG. 6A-1, although other types of reports and / or modules can be used. Although the previous examples have been of reports produced as graphical reports, reports may also be text-based or generated as machine-to-machine data exchange.

[0200] At 1160, the generated report may be provided to a user interface, such as user interfaces 410A-410C, another machine, or the like.

[0201] 4A and 4B, in some exemplary implementations, the system 400 can store health data separately from personal information, which is encrypted. For example, the system 400 can include a security layer below the logical layer such that encryption occurs once the data is stored in the repository 475. In some exemplary implementations, encryption is based on multiple factors, such as the recipient, the storage location (e.g., matrix information), etc. For example, encryption algorithms, such as advanced encryption algorithms, can be implemented. In some implementations, encryption keys can be stored separately in separate parts of the system 400 (e.g., in the analyte processor 490, a database server, etc.), along with individual user credentials for authentication.

[0202] In some example implementations, repository 475 is distributed. For example, repository 475 may include multiple persistent storage devices, which are distributed. Furthermore, the persistent storage devices may include one or more of a relational database, a non-relational document storage device, a non-relational key-value data storage device, a hierarchical file system-like storage device (also referred to as a data storage device), etc. Furthermore, repository 475 may be replicated, and the storage devices may be geographically distributed.

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

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

[0205] To enable interaction with a user, the subject matter described herein can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user, and a keyboard and pointing device (e.g., a mouse or trackball) that can be used to enable the user to provide input to the computer. Other types of devices can also be used to enable interaction with the user. For example, feedback provided to the user can be some form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user can be received in some form, such as acoustic, spoken, or tactile input.

[0206] The subject matter described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or that includes middleware components (e.g., an application server), or that includes front-end components (e.g., a client computer having a graphical user interface or web browser through which a user may interact with an implementation of the subject matter described herein), or that includes some combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communications network). Examples of communications networks include a local area network ("LAN"), a wide area network ("WAN"), and the Internet.

[0207] While several variations have been detailed above, other modifications are contemplated. For example, while the description of a particular implementation of the present subject matter discusses analytical applications, the present subject matter is applicable to other types of software and data service access. Moreover, while the description above refers to particular products, other products may be used. Furthermore, the logic flow illustrated in the accompanying figures and described herein does not require the particular order described or sequential order to achieve desired results. Other implementations may be within the scope of the following claims.

[0208] While several variations have been detailed above, other modifications are contemplated. For example, while the description of a particular implementation of the present subject matter discusses analytical applications, the present subject matter is applicable to other types of software and data service access. Moreover, while the description above refers to particular products, other products may be used. Furthermore, the logic flow illustrated in the accompanying figures and described herein does not require the particular order described or sequential order to achieve desired results. Other implementations may be within the scope of the following claims.

[0209] Methods and apparatus suitable for use in connection with embodiments of preferred implementations are disclosed in U.S. Patent Nos. 4,757,022, 4,994,167, 6,001,067, 6,558,321, 6,702,857, 6,741,877, 6,862,465, 6,931,327, 7,074,307, 7,081,195, 7,108,778, 7,110,803, 7,134,999, 7,136,689, and 7,192,450. No. 7,226,978, U.S. Patent No. 7,276,029, U.S. Patent No. 7,310,544, U.S. Patent No. 7,364,592, U.S. Patent No. 7,366,556, U.S. Patent No. 7,379,765, U.S. Patent No. 7,424,318, U.S. Patent No. 7,460,898, U.S. Patent No. 7,467,003, U.S. Patent No. 7,471,972, U.S. Patent No. 7,494,465, U.S. Patent No. 7,497,827, U.S. Patent No. 7,519,408, U.S. Patent No. 7,583,990, U.S. Patent No. 7,591,80 1, U.S. Patent No. 7,599,726, U.S. Patent No. 7,613,491, U.S. Patent No. 7,615,007, U.S. Patent No. 7,632,228, U.S. Patent No. 7,637,868, U.S. Patent No. 7,640,048, U.S. Patent No. 7,651,596, U.S. Patent No. 7,654,956, U.S. Patent No. 7,657,297, U.S. Patent No. 7,711,402, U.S. Patent No. 7,713,574, U.S. Patent No. 7,715,893, U.S. Patent No. 7,761,130, U.S. Patent No. 7,771,352, U.S. Patent No. 7,774,1 45, U.S. Patent No. 7,775,975, U.S. Patent No. 7,778,680, U.S. Patent No. 7,783,333, U.S. Patent No. 7,792,562, U.S. Patent No. 7,797,028, U.S. Patent No. 7,826,981, U.S. Patent No. 7,828,728, U.S. Patent No. 7,831,287, U.S. Patent No. 7,835,777, U.S. Patent No. 7,857,760, U.S. Patent No. 7,860,545, U.S. Patent No. 7,875,293, U.S. Patent No. 7,881,763, U.S. Patent No. 7,885,697, U.S. Patent No. 7,896,809, U.S. Patent No. 7,899,511, U.S. Patent No. 7,901,354, U.S. Patent No. 7,905,833, U.S. Patent No. 7,914,450, U.S. Patent No. 7,917,186, U.S. Patent No. 7,920,906, U.S. Patent No. 7,925,321, U.S. Patent No. 7,927,274, U.S. Patent No. 7,933,639, U.S. Patent No. 7,935,057, U.S. Patent No. 7,946,984, U.S. Patent No. 7,949,381, U.S. Patent No. 7,955,261, U.S. Patent No. 7,959,569, U.S. Patent No. 7,970,448, U.S. Patent No. Nos. 7,974,672, 7,976,492, 7,979,104, 7,986,986, 7,998,071, 8,000,901, 8,005,524, 8,005,525, 8,010,174, 8,027,708, 8,050,731, 8,052,601, 8,053,018, 8,060,173, 8,060,174, 8,064, 977, U.S. Patent No. 8,073,519, U.S. Patent No. 8,073,520, U.S. Patent No. 8,118,877, U.S. Patent No. 8,128,562, U.S. Patent No. 8,133,178, U.S. Patent No. 8,150,488, U.S. Patent No. 8,155,723, U.S. Patent No. 8,160,669, U.S. Patent No. 8,160,671, U.S. Patent No. 8,167,801, U.S. Patent No. 8,170,803, U.S. Patent No. 8,195,265, U.S. Patent No. 8,206,297, U.S. Patent No. 8,216,139, U.S. Patent No. 8,229,534, U.S. Patent No. Nos. 8,229,535, 8,229,536, 8,231,531, 8,233,958, 8,233,959, 8,249,684, 8,251,906, 8,255,030, 8,255,032, 8,255,033, 8,257,259, 8,260,393, 8,265,725, 8,275,437, 8,275,438, 8,277,713, U.S. Patent No. 8,280,475, U.S. Patent No. 8,282,549, U.S. Patent No. 8,282,550, U.S. Patent No. 8,285,354, U.S. Patent No. 8,287,453, U.S. Patent No. 8,290,559, U.S. Patent No. 8,290,560, U.S. Patent No. 8,290,561, U.S. Patent No. 8,290,562, U.S. Patent No. 8,292,810, U.S. Patent No. 8, 298,142, U.S. Patent No. 8,311,749, U.S. Patent No. 8,313,434, U.S. Patent No. 8,321,149, U.S. Patent No. 8,332,008, U.S. Patent No. 8,346,338, U.S. Patent No. 8,364,229, U.S. Patent No. 8,369,919, U.S. Patent No. 8,374,667, U.S. Patent No. 8,386,004, and U.S. Patent No. 8,394,021.

[0210] Methods and apparatus suitable for use in connection with aspects of preferred implementations are disclosed in U.S. Patent Application Publication Nos. 2003-0032874-A1, 2005-0033132-A1, 2005-0051427-A1, 2005-0090607-A1, 2005-0176136-A1, 2005-0245799-A1, 2006-0015020-A1, 2006-0016700-A1, and 2006-0020188-A1. U.S. Patent Application Publication No. 2006-0020190-A1, U.S. Patent Application Publication No. 2006-0020191-A1, U.S. Patent Application Publication No. 2006-0020192-A1, U.S. Patent Application Publication No. 2006-0036140-A1, U.S. Patent Application Publication No. 2006-0036143-A1, U.S. Patent Application Publication No. 2006-0040402-A1, U.S. Patent Application Publication No. 2006-0068208-A1, U.S. Patent Application Publication No. 2006-0142651-A1, U.S. Patent Application Publication No. 2006-0155180-A1, U.S. Patent Application Publication No. 2006-0198864-A1, U.S. Patent Application Publication No. 2006-0200020-A1, U.S. Patent Application Publication No. 2006-0200022-A1, U.S. Patent Application Publication No. 2006-0200970-A1, U.S. Patent Application Publication No. 2006-0204536-A1, U.S. Patent Application Publication No. 2006-0224108-A1, U.S. Patent Application Publication No. 2006-0235285-A1, U.S. Patent Application Publication No. 2006-0249381-A1, U.S. Patent Application Publication No. 2006-0252027-A1, U.S. Patent Application Publication No. 2006-0253012-A1, U.S. Patent Application Publication No. 2006-0257995-A1, U.S. Patent Application Publication No. 2006-0258761-A1, U.S. Patent Application Publication No. 2006-0263763-A1, U.S. Patent Application Publication No. 2006-0270922-A1, U.S. Patent Application Publication No. 2006-0270923-A1, U.S. Patent Application Publication No. 2007-0027370-A1, U.S. Patent Application Publication No. 2007-0032706-A1, U.S. Patent Application Publication No. 2007-0032718-A1,U.S. Patent Application Publication No. 2007-0045902-A1, U.S. Patent Application Publication No. 2007-0059196-A1, U.S. Patent Application Publication No. 2007-0066873-A1, U.S. Patent Application Publication No. 2007-0173709-A1, U.S. Patent Application Publication No. 2007-0173710-A1, U.S. Patent Application Publication No. 2007-0208245-A1, U.S. Patent Application Publication No. 2007-0208246-A1, U.S. Patent Application Publication No. 2007-0232879-A1, U.S. Patent Application Publication No. 2008-0045824-A1, U.S. Patent Application Publication No. 2008 -0083617-A1, U.S. Patent Application Publication No. 2008-0086044-A1, U.S. Patent Application Publication No. 2008-0108942-A1, U.S. Patent Application Publication No. 2008-0119703-A1, U.S. Patent Application Publication No. 2008-0119704-A1, U.S. Patent Application Publication No. 2008-0119706-A1, U.S. Patent Application Publication No. 2008-0183061-A1, U.S. Patent Application Publication No. 2008-0183399-A1, U.S. Patent Application Publication No. 2008-0188731-A1, U.S. Patent Application Publication No. 2008-0189051-A1, U.S. Patent Application Publication No. 2008-0194938-A1, U.S. Patent Application Publication No. 2008-0197024-A1, U.S. Patent Application Publication No. 2008-0200788-A1, U.S. Patent Application Publication No. 2008-0200789-A1, U.S. Patent Application Publication No. 2008-0200791-A1, U.S. Patent Application Publication No. 2008-0214915-A1, U.S. Patent Application Publication No. 2008-0228054-A1, U.S. Patent Application Publication No. 2008-0242961-A1, U.S. Patent Application Publication No. 2008-0262469-A1, U.S. Patent Application Publication No. 2008 -0275313-A1, U.S. Patent Application Publication No. 2008-0287765-A1, U.S. Patent Application Publication No. 2008-0306368-A1, U.S. Patent Application Publication No. 2008-0306434-A1, U.S. Patent Application Publication No. 2008-0306435-A1, U.S. Patent Application Publication No. 2008-0306444-A1, U.S. Patent Application Publication No. 2009-0018424-A1, U.S. Patent Application Publication No. 2009-0030294-A1, U.S. Patent Application Publication No. 2009-0036758-A1, U.S. Patent Application Publication No. 2009-0036763-A1,U.S. Patent Application Publication No. 2009-0043181-A1, U.S. Patent Application Publication No. 2009-0043182-A1, U.S. Patent Application Publication No. 2009-0043525-A1, U.S. Patent Application Publication No. 2009-0045055-A1, U.S. Patent Application Publication No. 2009-0062633-A1, U.S. Patent Application Publication No. 2009-0062635-A1, U.S. Patent Application Publication No. 2009-0076360-A1, U.S. Patent Application Publication No. 2009-0099436-A1, U.S. Patent Application Publication No. 2009-0124877-A1, U.S. Patent Application Publication No. 2009 -0124879-A1, U.S. Patent Application Publication No. 2009-0124964-A1, U.S. Patent Application Publication No. 2009-0131769-A1, U.S. Patent Application Publication No. 2009-0131777-A1, U.S. Patent Application Publication No. 2009-0137886-A1, U.S. Patent Application Publication No. 2009-0137887-A1, U.S. Patent Application Publication No. 2009-0143659-A1, U.S. Patent Application Publication No. 2009-0143660-A1, U.S. Patent Application Publication No. 2009-0156919-A1, U.S. Patent Application Publication No. 2009-0163790-A1, U.S. Patent Application Publication No. 2009-0178459-A1, U.S. Patent Application Publication No. 2009-0192366-A1, U.S. Patent Application Publication No. 2009-0192380-A1, U.S. Patent Application Publication No. 2009-0192722-A1, U.S. Patent Application Publication No. 2009-0192724-A1, U.S. Patent Application Publication No. 2009-0192751-A1, U.S. Patent Application Publication No. 2009-0203981-A1, U.S. Patent Application Publication No. 2009-0216103-A1, U.S. Patent Application Publication No. 2009-0240120-A1, U.S. Patent Application Publication No. 2009 -0240193-A1, U.S. Patent Application Publication No. 2009-0242399-A1, U.S. Patent Application Publication No. 2009-0242425-A1, U.S. Patent Application Publication No. 2009-0247855-A1, U.S. Patent Application Publication No. 2009-0247856-A1, U.S. Patent Application Publication No. 2009-0287074-A1, U.S. Patent Application Publication No. 2009-0299155-A1, U.S. Patent Application Publication No. 2009-0299156-A1, U.S. Patent Application Publication No. 2009-0299162-A1, U.S. Patent Application Publication No. 2010-0010331-A1,U.S. Patent Application Publication No. 2010-0010332-A1, U.S. Patent Application Publication No. 2010-0016687-A1, U.S. Patent Application Publication No. 2010-0016698-A1, U.S. Patent Application Publication No. 2010-0030484-A1, U.S. Patent Application Publication No. 2010-0036215-A1, U.S. Patent Application Publication No. 2010-0036225-A1, U.S. Patent Application Publication No. 2010-0041971-A1, U.S. Patent Application Publication No. 2010-0045465-A1, U.S. Patent Application Publication No. 2010-0049024-A1, U.S. Patent Application Publication No. 2010 -0076283-A1, U.S. Patent Application Publication No. 2010-0081908-A1, U.S. Patent Application Publication No. 2010-0081910-A1, U.S. Patent Application Publication No. 2010-0087724-A1, U.S. Patent Application Publication No. 2010-0096259-A1, U.S. Patent Application Publication No. 2010-0121169-A1, U.S. Patent Application Publication No. 2010-0161269-A1, U.S. Patent Application Publication No. 2010-0168540-A1, U.S. Patent Application Publication No. 2010-0168541-A1, U.S. Patent Application Publication No. 2010-0168542-A1, U.S. Patent Application Publication No. 2010-0168543-A1, U.S. Patent Application Publication No. 2010-0168544-A1, U.S. Patent Application Publication No. 2010-0168545-A1, U.S. Patent Application Publication No. 2010-0168546-A1, U.S. Patent Application Publication No. 2010-0168657-A1, U.S. Patent Application Publication No. 2010-0174157-A1, U.S. Patent Application Publication No. 2010-0174158-A1, U.S. Patent Application Publication No. 2010-0174163-A1, U.S. Patent Application Publication No. 2010-0174164-A1, U.S. Patent Application Publication No. 2010 -0174165-A1, U.S. Patent Application Publication No. 2010-0174166-A1, U.S. Patent Application Publication No. 2010-0174167-A1, U.S. Patent Application Publication No. 2010-0179401-A1, U.S. Patent Application Publication No. 2010-0179402-A1, U.S. Patent Application Publication No. 2010-0179404-A1, U.S. Patent Application Publication No. 2010-0179408-A1, U.S. Patent Application Publication No. 2010-0179409-A1, U.S. Patent Application Publication No. 2010-0185065-A1, U.S. Patent Application Publication No. 2010-0185069-A1,U.S. Patent Application Publication No. 2010-0185070-A1, U.S. Patent Application Publication No. 2010-0185071-A1, U.S. Patent Application Publication No. 2010-0185075-A1, U.S. Patent Application Publication No. 2010-0191082-A1, U.S. Patent Application Publication No. 2010-0198035-A1, U.S. Patent Application Publication No. 2010-0198036-A1, U.S. Patent Application Publication No. 2010-0212583-A1, U.S. Patent Application Publication No. 2010-0217557-A1, U.S. Patent Application Publication No. 2010-0223013 ...4-A1, U.S. Patent Application Publication No. 2010-0212585-A1, U.S. Patent Application Publication No. 2010-0212586-A1, U.S. Patent Application Publication No. 2010-0212587-A1, U.S. Patent Application Publication No. 2010-0212588-A1, U.S. Patent Application Publication No. 2010-0212589-A1, U.S. Patent Application Publication No. 2010-0212589-A1, U.S. Patent Application Publication No. 2010-02 0-0223022-A1, U.S. Patent Application Publication No. 2010-0223023-A1, U.S. Patent Application Publication No. 2010-0228109-A1, U.S. Patent Application Publication No. 2010-0228497-A1, U.S. Patent Application Publication No. 2010-0240975-A1, U.S. Patent Application Publication No. 2010-0240976C1, U.S. Patent Application Publication No. 2010-0261987-A1, U.S. Patent Application Publication No. 2010-0274107-A1, U.S. Patent Application Publication No. 2010-0280341-A1, U.S. Patent Application Publication No. 2010-0286496-A1, U.S. Patent Application Publication No. 2010-0298684-A1, U.S. Patent Application Publication No. 2010-0324403-A1, U.S. Patent Application Publication No. 2010-0331656-A1, U.S. Patent Application Publication No. 2010-0331657-A1, U.S. Patent Application Publication No. 2011-0004085-A1, U.S. Patent Application Publication No. 2011-0009727-A1, U.S. Patent Application Publication No. 2011-0024043-A1, U.S. Patent Application Publication No. 2011-0024307-A1, U.S. Patent Application Publication No. 2011-0027127-A1, U.S. Patent Application Publication No. 2011 -0027453-A1, U.S. Patent Application Publication No. 2011-0027458-A1, U.S. Patent Application Publication No. 2011-0028815-A1, U.S. Patent Application Publication No. 2011-0028816-A1, U.S. Patent Application Publication No. 2011-0046467-A1, U.S. Patent Application Publication No. 2011-0077490-A1, U.S. Patent Application Publication No. 2011-0118579-A1, U.S. Patent Application Publication No. 2011-0124992-A1, U.S. Patent Application Publication No. 2011-0125410-A1, U.S. Patent Application Publication No. 2011-0130970-A1,U.S. Patent Application Publication No. 2011-0130971-A1, U.S. Patent Application Publication No. 2011-0130998-A1, U.S. Patent Application Publication No. 2011-0144465-A1, U.S. Patent Application Publication No. 2011-0178378-A1, U.S. Patent Application Publication No. 2011-0190614-A1, U.S. Patent Application Publication No. 2011-0201910-A1, U.S. Patent Application Publication No. 2011-0201911-A1, U.S. Patent Application Publication No. 2011-0218414-A1, U.S. Patent Application Publication No. 2011-0231140-A1, U.S. Patent Application Publication No. 2011-0231141-A1, U.S. Patent Application Publication No. 2011-0231142-A1, U.S. Patent Application Publication No. 2011-0253533-A1, U.S. Patent Application Publication No. 2011-0263958-A1, U.S. Patent Application Publication No. 2011-0270062-A1, U.S. Patent Application Publication No. 2011-0270158-A1, U.S. Patent Application Publication No. 2011-0275919-A1, U.S. Patent Application Publication No. 2011-02906 45-A1, U.S. Patent Application Publication No. 2011-0313543-A1, U.S. Patent Application Publication No. 2011-0320130-A1, U.S. Patent Application Publication No. 2012-0035445-A1, U.S. Patent Application Publication No. 2012-0040101-A1, U.S. Patent Application Publication No. 2012-0046534-A1, U.S. Patent Application Publication No. 2012-0078071-A1, U.S. Patent Application Publication No. 2012-0108934-A1, U.S. Patent Application Publication No. 2012-0130214-A1, U.S. Patent Application Publication No. 2012-0172691-A1, U.S. Patent Publication No. 2012-0179014-A1, U.S. Patent Application Publication No. 2012-0186581-A1, U.S. Patent Application Publication No. 2012-0190953-A1, U.S. Patent Application Publication No. 2012-0191063-A1, U.S. Patent Application Publication No. 2012-0203467-A1, U.S. Patent Application Publication No. 2012-0209098-A1, U.S. Patent Application Publication No. 2012-0215086-A1, U.S. Patent Application Publication No. 2012-0215087-A1, U.S. Patent Application Publication No. 2012-0215201-A1, U.S. Patent Application Publication No. 2012-0 215461-A1, U.S. Patent Application Publication No. 2012-0215462-A1, U.S. Patent Application Publication No. 2012-0215496-A1, U.S. Patent Application Publication No. 2012-0220979-A1, U.S. Patent Application Publication No. 2012-0226121-A1, U.S. Patent Application Publication No. 2012-0228134-A1, U.S. Patent Application Publication No. 2012-0238852-A1, U.S. Patent Application Publication No. 2012-0245448-A1, U.S. Patent Application Publication No. 2012-0245855-A1, U.S. Patent Application Publication No. 2012-0255875-A1,U.S. Patent Application Publication No. 2012-0258748-A1, U.S. Patent Application Publication No. 2012-0259191-A1, U.S. Patent Application Publication No. 2012-0260323-A1, U.S. Patent Application Publication No. 2012-0262298-A1, U.S. Patent Application Publication No. 2012-0265035-A1, U.S. Patent Application Publication No. 2012-0265036-A1, U.S. Patent Application Publication No. 2012-0265037-A1, U.S. Patent Application Publication No. 2012-0277562-A1, U.S. Patent Application Publication No. 2012-0277566-A1, U.S. Patent Application Publication No. 2012-0283541-A1, U.S. Patent Application Publication No. 2012-0283543-A1, U.S. US Patent Application Publication No. 2012-0296311-A1, US Patent Application Publication No. 2012-0302854-A1, US Patent Application Publication No. 2012-0302855-A1, US Patent Application Publication No. 2012-0323100-A1, US Patent Application Publication No. 2013-0012798-A1, US Patent Application Publication No. 2013-0030273-A1, US Patent Application Publication No. 2013-0035575-A1, US Patent Application Publication No. 2013-0035865-A1, US Patent Application Publication No. 2013-0035871-A1, US Patent Application Publication No. 2005-0056552-A1, and US Patent Application Publication No. 2005-0182451-A1. ,

[0211] Methods and devices suitable for use in connection with preferred implementations are disclosed in U.S. patent application Ser. No. 09 / 447,227, filed Nov. 22, 1999, entitled "Device and Method for Determining Analyte Levels," U.S. patent application Ser. No. 12 / 828,967, filed July 1, 2010, entitled "Housing for Intravascular Sensor," U.S. patent application Ser. No. 13 / 461,625, filed May 1, 2012, entitled "Dual Electrode System for Continuous Analyte Sensor," U.S. patent application Ser. No. 13 / 594,602, filed Aug. 24, 2012, entitled "Polymer Membrane for Continuous Analyte Sensor," U.S. patent application Ser. No. 13 / 594,734, filed Aug. 24, 2012, entitled "Polymer Membrane for Continuous Analyte Sensor," and U.S. patent application Ser. No. 13 / 594,734, filed Aug. 24, 2012, entitled "Polymer Membrane for Continuous Analyte Sensor." "Polymer Membranes for Continuous Analyte Sensors," U.S. Patent Application No. 13 / 607,162, filed September 7, 2012, entitled "Systems and Methods for Processing Analyte Sensor Data for Sensor Calibration," U.S. Patent Application No. 13 / 624,727, filed September 21, 2012, entitled "Systems and Methods for Processing and Transmitting Sensor Data," U.S. Patent Application No. 13 / 624,808, filed September 21, 2012, entitled "Systems and Methods for Processing and Transmitting Sensor Data," U.S. Patent Application No. 13 / 624,812, filed September 21, 2012, entitled "Systems and Methods for Processing and Transmitting Sensor Data," No. 13 / 732,848, filed January 2, 2013, entitled "Analyte Sensor Having a Signal-to-Noise Ratio Substantially Unaffected by Non-Constant Value Noise," U.S. Patent Application No. 13 / 733,742, filed January 3, 2013, entitled "End of Life Detection for Analyte Sensors," U.S. Patent Application No. 13 / 733,810, filed January 3, 2013, entitled "Outlier Detection for Analyte Sensors," U.S. Patent Application No. 13 / 742,178, filed January 15, 2013, entitled "System and Method for Processing and Transmitting Sensor Data," No. 13 / 742,694, filed January 16, 2013, entitled "System and Method for Providing Highly Sensitive and Specific Alarms," ​​U.S. Patent Application No. 13 / 742,841, filed January 16, 2013, entitled "System and Method for Dynamically and Intelligently Monitoring a Recipient's Glycemic Status After an Alert is Activated," U.S. Patent Application No. 13 / 747,746, filed January 23, 2013, entitled "Apparatus, System, and Method for Compensating for Temperature Effects on Implantable Sensors," U.S. Patent Application No. 13 / 779, filed February 27, 2013,No. 607, entitled "Zwitterionic Surface Modifications for Continuous Sensors," U.S. Patent Application No. 13 / 780,808, filed February 28, 2013, entitled "Apparatus, System, and Method for Compensating for Temperature Effects on Implantable Sensors," and U.S. Patent Application No. 13 / 784,523, filed March 4, 2013, entitled "Analyte Sensors with Increased Reference Capacity."

[0212] The foregoing description presents the best modes contemplated for carrying out the invention and the manner and method of making and using it in such full, clear, concise, and exact terms as to enable any person skilled in the art to which the invention pertains to make and use the invention. However, the invention is susceptible to modifications and alternative constructions which are fully equivalent to those described above. Accordingly, the invention is not limited to the particular implementations disclosed. Rather, the invention is intended to embrace all modifications and alternative constructions which fall within the spirit and scope of the invention as generally set forth in the following claims, which particularly point out and distinctly claim the subject matter of the invention. While the disclosure has been illustrated and described in detail in the drawings and foregoing description, these illustrations and descriptions are to be considered illustrative or exemplary and not restrictive.

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

[0214] Unless otherwise defined, all terms (including technical and scientific terms) are to be given their accustomed and customary meanings commonly used by those skilled in the art and are not to be limited to any particular or specialized meaning unless expressly defined herein. It should be noted that when special terminology is used when describing a particular feature or aspect of the disclosed subject matter, this should not be construed to imply that the terminology has been redefined herein to be limited to include any particular feature or aspect of the relevant disclosed subject matter. Terms and phrases used herein, and variations thereof, should be construed as open-ended, as opposed to restrictive, unless expressly stated otherwise in the appended claims. As an example, the term "comprising" should be construed to mean "including, but not limited to" or "including, but not limited to." The term "comprising," as used herein, is synonymous with "including," "containing," or "characterized by," and is inclusive or open-ended, and does not exclude additional, unrecited elements or method steps. The term "having" should be construed as "having at least." The term "including" should be construed as "including, but not limited to." The term "example" is used to provide a representative example of the item under discussion, not an exhaustive or limiting enumeration thereof. Adjectives such as "well-known," "conventional," "standard," and similar terms should not be construed to limit the item being described to items available in a given period or at a given time, but instead should be construed to include well-known, conventional, or standard technology that is available now or that may become known some time in the future. The use of terms such as "preferably," "suitable," "desired," or "preferable," and similar terms, should not be understood to imply that a particular feature is critical, essential, or even crucial to the structure or function of the invention. Instead, they are merely intended to highlight alternative or additional features that may or may not be utilized in a particular implementation of the invention.Similarly, a group of items joined by the conjunction "and" should not be construed as requiring that each and every such item be present in the group, but rather should be construed as "and / or" unless otherwise stated. Similarly, a group of items joined by the conjunction "or" should not be construed as requiring mutual exclusivity among the group, but rather should be construed as "and / or" unless otherwise stated.

[0215] Where a range of values ​​is provided, it is understood that each of the upper and lower limits, and intervening values ​​between the upper and lower limits of the range, are included in the range of implementation.

[0216] With respect to the use of substantially any plural and / or singular term herein, those skilled in the art may interpret the plural to the singular or the singular to the plural as appropriate to the context and / or application. Various singular / plural permutations may be expressly set forth herein for clarity. The indefinite article "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain criteria are recited in mutually different dependent claims does not indicate that a combination of such criteria cannot be advantageously used. Any reference signs in the claims should not be construed as limiting the scope.

[0217] As one skilled in the art would understand, when a specific number is intended in an introduced claim recitation, that intention will be expressly recited in that claim; otherwise, no such intention exists. For example, as an aid to understanding, the following appended claims may include the use of the introductory phrases "at least one" and "one or more" to introduce claim recitations. However, the use of such phrases, such as introducing a claim recitation with the indefinite article "a" or "an," should not be construed as meaning that any particular claim containing that introduced claim recitation is limited to implementations that include only one such recitation, even if the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an" (e.g., "a" and / or "an" should generally be construed to mean "at least one" or "one or more"). The same is true for the use of definite articles used to introduce claim recitations. Furthermore, even when specific numbers in the recitations of introduced claims are explicitly recited, the recitation should generally be interpreted as meaning at least the recited numbers, as would be understood by one skilled in the art (e.g., the phrase "two recitations," without any other modifier, generally means at least two recitations or more than two recitations). Furthermore, when a conventional expression similar to "at least one of A, B, and C, etc." is used, such a structure is generally intended in the sense that a person skilled in the art would understand the expression (e.g., "a system having at least one of A, B, and C" includes, but is not limited to, a system having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together).When conventional language similar to "at least one of A, B, or C, etc." is used, such a structure is generally intended in the sense that one of ordinary skill in the art would understand the language (e.g., "a system having at least one of A, B, or C" includes, but is not limited to, systems having A only, B only, C only, A and B together, A and C together, B and C together, and / or A, B, and C together). As will be further understood by those of ordinary skill in the art, substantially any disjunctive word and / or phrase presenting two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both terms. For example, the phrase "A or B" is understood to include the possibilities of "A" or "B," or "A and B."

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

[0219] Moreover, while the foregoing has been described in some detail for purposes of illustration and example, for purposes of clarity and understanding, certain changes and modifications may be practiced, as will be apparent to those skilled in the art. Therefore, the description and examples should not be construed as limiting the scope of the invention to the particular implementations and examples described herein, but rather as including all modifications and alternatives that fall within the fair scope and spirit of the invention. [Explanation of symbols]

[0220] 2. Drug delivery pumps 4 Blood glucose meter 8 Sensor System 10 Continuous Analyte Sensors 12 Sensor Electronics Module 14 Key fob devices 16 Handheld Devices 18 Cell phone (or PDA) 20. Personal Computers 205 Application Specific Integrated Circuits (ASIC) 210 Potentiostat 212 data line 214 Processor Module 216 program memory 218 memory 220 data storage memory 222 User Interface 224 One or more buttons 226 Liquid Crystal Display (LCD) 228 Vibrator 230 Voice Converter 232 Telemetry Module 234 Batteries 236 Charger and / or Regulator 238 communication port 269 ​​Position Module 308 adhesive pad 312 Sensor Electronics Module 314 Installation Unit 320 Glucose Sensor 322 Altimeter 324 Accelerometer 328 Temperature Sensor 334 Base 336 Connection Assembly 338 Connector 348 Hinge 350 display device 369 Location Module 400 Analysis Processing System 404 Server 406 Network 410A User Interface 410B User Interface 410C User Interface 412 Load Balancer 420A Authorizer 420B Data Parser 420C Logic 420D Data Filter 420E Data Formatter 420G Report Generator 420H Calculation Engine 420I Pattern detection unit 420J Third Party Interface 420K Report Delivery Module 465 Data Search Department 475 repositories 490 Cloud-Based Analyte Processor 499 System 502 request 504 Preprocessing 506 Personally Identifiable Information (PII) 508 Number 510 Histogram 590A Histogram 590B Histogram 600 Reports 602 LCD 604 One or more buttons 605A Patient Information Module 605B Patient Name 605C Medical appointment date 605D Email Address 605E Symptoms 606 USB ports 607A Highlight Module 607B Glucose Module 607C Stability Module 607D Interval Module 607E Less Than Time Module 607F Time Frame 608 Display 609A Shade 609B Graphic Bar 609C Text Legend 609D Callout 609E Callout 609F Callout 609G Text Legend 609H Graphics Bar 609I Callout 609J Text Legend 609K text legend 609L Callout 609M Callout 609N Graphic Bar 609O Graphic Bar 612 Graphic Representation 615 Insights Module 617A Graphic Elements 617B Text Information 617C Insight 620A High and Low Period Module 622A Last 30 days 630 Equipment Module 632A Text Legend 632B Graphic Bar 632C Callout 640 Comparison Module 642A Text Legend 642B Graphic Bar 642C Callout 642D Callout 650 Daily Aggregation Module 652A Previous month 652B x-axis 652C y-axis 652D element 652E element 652F Text List 652G elements 652H element 660 Weekly Summary Module 662A x-axis 670A Continuous Glucose Level Module 670B Legend 670C Time Frame 670D Graphic Elements 670E Graphic Elements 670F Graphic Elements 670G Graphic Elements 670H Graphic Elements 670I Graphic Elements 670J Graphic Elements 670K graphic elements 670L target range line 670V target range bar 670W Shade 670X shading 670Y Shade 670Z Continuous Glucose Level Module 674A Glucose Meter Level Module 674AA Glucose Meter Level Module 674B roughly circular icon 674C roughly circular icon 674D Roughly Polygonal Icon 674E Roughly polygonal icon 674PS Transcendental Percentage Test Module 674XY Comparison Module 676A Glucose Module 676B Shade 676D Shade 687A Report Legend 690A Daily Aggregation Module 690B Glucose Data 690C Carbohydrate Consumption Data 690D Insulin Pump Data 692A Weekly Summary Module 694A Time-lapse Aggregation Module 700 Reports 702 weeks 704 Weekend 706 Time Interval 708A yen 708B yen 710A Module 710B Module 710C Module 710D Module 733A Continuous Glucose Monitor Use Device Module 733B Use Device Module for Self-Monitoring Blood Glucose Monitors 733C USE DEVICE MODULE FOR IMPLEMENTATION COMPRISING MULTIPLE DEVICES, SUCH AS CONTINUOUS GLUCOSE MONITORS AND SELF-MONITORING BLOOD GLUCOSE MONITORS 750 Glucose Distribution Module 760 Glucose Distribution Module 769A Daily Aggregation Module 769B Weekly Summary Module 770 Continuous Glucose Level Module 899 Patient Questionnaire Module 780 bar 7100 Glucose Level 7200 Carbohydrate Level 7300 Insulin Dosage 7400 callout "1" 7420 Text Description 7500 Total

Claims

1. 1. A method for generating a report regarding sensor data representative of a recipient's glucose concentration level, comprising: receiving a request to generate a report; selecting, in response to the request, at least one module from among a plurality of modules representing measurements in a user interface, the selection being performed based on metadata including information representative of at least one of the recipient and a type of device being used to measure the glucose concentration level, the metadata including a plurality of predefined templates configured for the recipient, the templates defining an arrangement of the at least one module; generating the report including the selected at least one module configured to be present in a single display of information representative of the glucose concentration level measured in the recipient, the single display being a representation correlating measurements between medication amounts, carbohydrates, and glucose over a predetermined period of time; and providing the generated report to a user interface for presentation, wherein the receiving, selecting, generating, and providing are performed by at least one processor.

2. The method of claim 1 , wherein the information representing the recipient further comprises at least one of user preferences and recipient identification information for the at least one module, and the metadata further comprises one or more rules.

3. 3. The method of claim 2, wherein the user preferences include preferences provided by the recipient, a healthcare provider, and a processor programmatically based on the metadata, and the type of device includes at least one of a continuous blood glucose monitor or a self-monitoring blood glucose monitor.

4. 3. The method of claim 2, wherein the one or more rules include one or more of the following rules: whether the at least one module can be used with the type of device; whether the at least one module can be used with the glycemic status of the recipient; and whether the at least one module can be used with expected volume data provided by the type of device.

5. The method of claim 1 , wherein the generating further comprises accessing the metadata from a repository, the metadata including a template defining an arrangement of the selected at least one module.

6. 10. The method of claim 1, wherein the single display graphically highlights when the glucose concentration level measured in the recipient is at least one of above, below, or within a predetermined target range for the glucose concentration level in the recipient.

7. 1. An apparatus comprising: at least one processor; and at least one memory containing code that, when executed by the at least one processor, provides operations, the operations comprising: selecting at least one module from a plurality of modules representing measurements in a user interface, said selection being performed based on metadata including one or more of the following rules: whether said at least one module can be used with a certain type of device; whether said at least one module can be used with the glycemic status of the recipient; and whether said at least one module can be used with expected volume data generated by said type of device, said metadata including a plurality of predefined templates configured for said recipient, said templates defining an arrangement of said at least one module; generating a report including the selected at least one module configured to present information in a single display representative of the glucose concentration level measured in the recipient, the single display being a representation correlating measurements between medication amounts, carbohydrates, and glucose over a predetermined period of time.

8. 8. The device of claim 7, wherein the selecting further comprises selecting the at least one module from among a plurality of modules stored in a repository coupled to the at least one processor if the metadata indicates that the at least one module is configured for use in a continuous blood glucose monitor.

9. 9. The device of claim 8, wherein if the metadata indicates that the at least one module is not configured for use in the continuous blood glucose monitor and another module is configured for use in the continuous blood glucose monitor, the selecting further comprises selecting the other module from among a plurality of modules.

10. 8. The apparatus of claim 7, wherein if the metadata indicates that the at least one module is configured for use on a display of a certain size for presenting the report, the selecting further comprises selecting the at least one module from among a plurality of modules.

11. 8. The device of claim 7, wherein if the metadata indicates that the at least one module is configured for use with the expected volume of data generated by a continuous blood glucose monitor, the selecting further comprises selecting the at least one module from among a plurality of modules.

12. 8. The apparatus of claim 7, wherein if the metadata indicates that the at least one module is configured for use with the glycemic condition of the recipient including a hyperglycemic condition, the selecting further comprises selecting the at least one module from among a plurality of modules, the selected at least one module providing an indication of the hyperglycemic condition.

13. The apparatus of claim 7 , wherein the selecting further comprises selecting the at least one module from among a plurality of modules if the metadata indicates a user preference for the selected at least one module.

14. The apparatus of claim 13 , wherein the user preferences include preferences provided by the recipient, a healthcare provider, or a processor programmatically based on the metadata.

15. 8. The apparatus of claim 7, wherein the at least one memory includes code that, when executed by the at least one processor, provides operations further including providing a user interface for presenting the generated report.

16. The apparatus of claim 7 , wherein the at least one memory includes code that, when executed by the at least one processor, provides operations further including receiving a request to generate the report.

17. 17. The apparatus of claim 16, wherein the selecting is dynamically selected based on an evaluation of the metadata stored in a repository coupled to the at least one processor when the request is received.

18. 8. The device of claim 7, wherein the selected at least one module presents a graphical representation of the glucose concentration level measured in the recipient in a single display.

19. A non-transitory computer-readable storage medium containing computer program code, the computer program code, when executed by at least one processor, providing operations, the operations comprising: receiving a request to generate a report; selecting at least one module from a plurality of modules stored in a repository that are representations of measurements in a user interface, the selection being performed based on metadata including information representative of at least one of a recipient, a type of device being used to measure the recipient's glucose concentration level, and at least one rule, the metadata including a plurality of predefined templates configured for the recipient, the templates defining an arrangement of the at least one module; generating the report including the selected at least one module configured to present information in a single display representative of the glucose concentration level measured in the recipient, the single display being a representation correlating measurements between medication amounts, carbohydrates, and glucose over a predetermined period of time; and providing a user interface for presenting the generated report.

20. 20. The non-transitory computer-readable storage medium of claim 19, wherein if the metadata indicates that the selected at least one module is configured for use in a continuous blood glucose monitor, the selecting further includes selecting the at least one module from among a plurality of modules stored in the repository, the metadata being stored in the repository.

Images