Systems, devices and methods using blockchain to track patient identities

Abstract

A system for bidirectional communication of patient data may include a first database having a first record including first data associated with a patient's personal ID, a second database having a second record including second data associated with a patient's user ID, and one or more processors configured to pair the first data and the second data based on shared data items contained in the first record and the second record and display combinations in which the first data is paired with the second data. A block chain is used to pair first and second records associated with different user IDs of the same patient.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit under 35 U.S.C. § 119(e) of U.S. Provisional Patent Application No. 63 / 279,015, filed November 12, 2021, which is incorporated by reference herein in its entirety and for all purposes.

[0002] [Technical field] The subject matter described herein relates generally to systems and methods for bidirectional communication of patient data. [Background technology]

[0003] Detecting and / or monitoring the levels of analytes such as glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, serum urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, uric acid, or others, can be important to the health of individuals with diabetes. Patients with diabetes mellitus can experience complications including loss of consciousness, cardiovascular disease, retinopathy, neuropathy, and nephropathy. Diabetic patients are generally required to monitor their glucose levels to ensure that their glucose levels are maintained within a clinically safe range, and may also use the information to determine if and / or when they require insulin to reduce glucose levels in the body or when they require additional glucose to increase glucose levels in the body.

[0004] A growing body of clinical data reveals a strong correlation between frequency of glucose monitoring and glycemic control. However, despite such correlation, many individuals diagnosed with a diabetic condition do not monitor their glucose levels as frequently as they should due to a combination of factors including convenience, discretionary testing, pain associated with glucose testing, and cost.

[0005] To increase patient adherence to a frequent glucose monitoring regimen, an in vivo analyte monitor system can be utilized in which a sensor control device can be worn on the body of an individual requiring analyte monitoring. To increase comfort and convenience for the individual, the sensor control device can have a small form factor and can be applied by the individual using a sensor applicator. The application process includes inserting at least a portion of a sensor that senses a user's analyte level in a bodily fluid located in a layer of the human body using an applicator or insertion mechanism such that the sensor is in contact with the bodily fluid. The sensor control device may also be configured to transmit the analyte data to another device, from which the individual, her health care provider ("HCP"), or caregiver can review the data and make treatment decisions.

[0006] However, despite their benefits, some people are hesitant to use specimen monitor systems for a variety of reasons, including the complexity and volume of data presented, the learning curve associated with the software and user interface for specimen monitor systems, and the overall lack of actionable information presented.

[0007] In addition, certain patient information, especially when it pertains to laboratory test results, currently resides in various Health Care Organization (HCO) local computer networks (e.g., electronic medical / health records). Such information is recorded and stored on EMR systems using a patient ID that is unique to each HCO. Similarly, specimen monitoring systems often store specimen measurements on a centralized database using a user ID (e.g., username, email address, etc.).

[0008] Therefore, a need exists for a system and method for two-way communication such that patient data from an HCO can be paired with data from an analyte monitoring system. Summary of the Invention

[0009] The objects and advantages of the presently disclosed subject matter will be set forth in and will be obvious from the description which follows, as well as will be learned by practice of the presently disclosed subject matter. Additional advantages of the presently disclosed subject matter will be realized and obtained by the methods and systems particularly pointed out in the specification and claims hereof, as well as the appended drawings.

[0010] To achieve the above and other advantages in accordance with the purpose of the presently disclosed subject matter, as embodied and broadly described, the presently disclosed subject matter relates to a system and method for bidirectional communication of patient data. According to an embodiment, the system for bidirectional communication may include a first database having a first record including first data associated with a patient's personal ID, a second database having a second record including second data associated with a patient's user ID, and one or more processors configured to pair the first data and the second data based on shared data items contained in the first record and the second record, and to display a combination of the first data paired with the second data.

[0011] As embodied herein, the first database can be an electronic medical record system. The first data can be a laboratory measurement HbA1c. As embodied herein, the second database can include an analyte monitor system data service. As embodied herein, the second data can include, for example, a glucose level measured by an analyte monitor system. As embodied herein, the shared data item can include an email address.

[0012] As embodied herein, the one or more processors may be configured to receive a request to read, write, edit, or delete resource data in the first or second database, and the request may be formatted according to the Fast Healthcare Interoperability Resources (FHIR) standard and the Healthcare Provider Directory (HPD) standard or an FHIR extension embodying H7. As embodied herein, the one or more processors may be further configured to generate a notification based on the first data being paired with the second data. Further, the notification may be displayed as a combination of the first data paired with the second data.

[0013] As embodied herein, the one or more processors can be further configured to perform a calculation based on the first data paired with the second data. Further, the calculation can include a calculation of a glucose derived A1c. Alternatively, the calculation can also include a calculation of an individualized HbA1c.

[0014] In accordance with the subject matter of the present disclosure, some embodiments disclose a method for bidirectional communication of patient data, the method including receiving, using one or more processors, first data associated with a personal identifier from a first database, receiving, using one or more processors, second data associated with a user identifier from a second database, pairing, using one or more processors, the first data and the second data based on shared data items contained in the first record and the second record, and displaying, using one or more processors, a combination of the first data and the second data.

[0015] As embodied herein, the first database can be an electronic medical record system. As embodied herein, the first data can be a laboratory measurement HbA1c. Alternatively or additionally, as embodied herein, the second database can include a sample monitor system data service. As embodied herein, the second data can include a glucose level measured by the sample monitor system. As embodied herein, the shared data item can include an email address. Blockchains can further enable linking different patient IDs and user IDs and can be used with the databases.

[0016] As embodied herein, the method may further include generating, using one or more processors, a notification based on the first data being paired with the second data. As embodied herein, the method may further include performing, using one or more processors, a calculation based on the first data being paired with the second data. Further, the calculation may include a calculation of a glucose derivative. Alternatively, the calculation may further include a calculation of an individualized HbA1c.

[0017] Details of the subject matter enumerated herein will be apparent from consideration of the accompanying drawings, in which like reference numerals refer to like parts, both as to their structure and operation. The components within the figures are not necessarily to scale, with emphasis instead being placed upon illustrating the principles of the subject matter of the present invention. Moreover, all illustrations are intended to convey concepts, and relative sizes, shapes, and other detailed attributes may be illustrated generally, rather than literally or precisely. [Brief description of the drawings]

[0018] [Figure 1] A system schematic diagram of an analyte monitoring system including a sensor applicator, a sensor control device, a reader device, a network, a trusted computer system, and a local computer system. [Figure 2A] FIG. 2 is a block diagram illustrating an exemplary embodiment of a reader device. [Figure 2B] FIG. 2 is a block diagram illustrating an exemplary embodiment of a sensor control device. [Figure 2C] FIG. 2 is a block diagram illustrating an exemplary embodiment of a sensor control device. [Figure 2D] FIG. 13 is an exemplary embodiment of a GUI including a sensor results interface. [Figure 2E] FIG. 13 is an exemplary embodiment of a GUI including a sensor results interface. [Figure 2F] FIG. 13 is an exemplary embodiment of a GUI including a sensor results interface. [Figure 2G] FIG. 13 is an exemplary embodiment of a GUI including a sensor results interface. [Figure 2H] FIG. 13 is an exemplary embodiment of a GUI including a sensor results interface. [Figure 2I] FIG. 13 is an exemplary embodiment of a GUI including a sensor results interface. [Figure 3A] FIG. 13 is an example embodiment of a GUI including a time within range interface. [Figure 3B]FIG. 13 is an example embodiment of a GUI including a time within range interface. [Figure 3C] FIG. 13 is an example embodiment of a GUI including a time within range interface. [Figure 3D] FIG. 13 is an example embodiment of a GUI including a time within range interface. [Figure 3E] FIG. 13 is an example embodiment of a GUI including a time within range interface. [Figure 3F] FIG. 13 is an example embodiment of a GUI including a time within range interface. [Figure 4A] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4B] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4C] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4D] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4E] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4F] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4G] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4H] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4I] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4J] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4K] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4L] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4M] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4N] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 4O] FIG. 13 is an exemplary embodiment of a GUI including a specimen level interface and a trend alert interface. [Figure 5A] FIG. 13 illustrates an example embodiment of a sensor usage interface. [Figure 5B] FIG. 13 illustrates an example embodiment of a sensor usage interface. [Figure 5C] FIG. 13 is an example embodiment of a report GUI including sensor usage information. [Figure 5D] FIG. 13 is an example embodiment of a report GUI including sensor usage information. [Figure 5E] FIG. 13 is an example embodiment of a report GUI including sensor usage information. [Figure 5F] FIG. 13 is an example embodiment of a report GUI including sensor usage information. [Figure 5G] FIG. 13 is an exemplary embodiment of a GUI associated with the analyte monitor software application. [Figure 5H] FIG. 13 is an exemplary embodiment of a GUI associated with the analyte monitor software application. [Figure 5I] FIG. 13 is an exemplary embodiment of a GUI associated with the analyte monitor software application. [Figure 5J] FIG. 13 is an exemplary embodiment of a GUI associated with the analyte monitor software application. [Figure 5K]FIG. 13 is an exemplary embodiment of a GUI associated with the analyte monitor software application. [Figure 5L] FIG. 13 is an exemplary embodiment of a GUI associated with the analyte monitor software application. [Figure 6A] 1 is a flow chart illustrating an example embodiment of a method for data backfilling in an analyte monitoring system. [Figure 6B] 1 is a flow chart illustrating an example embodiment of a method for data backfilling in an analyte monitoring system. [Figure 6C] 1 is a flow chart illustrating an example embodiment of a method for tabulating disconnection and reconnection events in an analyte monitoring system. [Figure 7] 1 is a flow chart illustrating an exemplary embodiment of a method for bad or expired sensor transmission in an analyte monitoring system. [Figure 8A] 1 is a flow chart illustrating an exemplary embodiment of a method for data fusion in an analyte monitoring system. [Figure 8B] 1 is a flow chart illustrating an exemplary embodiment of a method for data fusion in an analyte monitoring system. [Figure 8C] 1 is a graph depicting data at various stages of processing according to an exemplary embodiment of a method for data fusion in an analyte monitoring system. [Figure 8D] 1 is a graph depicting data at various stages of processing according to an exemplary embodiment of a method for data fusion in an analyte monitoring system. [Figure 8E] 1 is a graph depicting data at various stages of processing according to an exemplary embodiment of a method for data fusion in an analyte monitoring system. [Figure 9A] 1 is a flow chart illustrating an exemplary embodiment of a method for sensor migration in an analyte monitoring system. [Figure 9B] FIG. 13 is a diagram of an exemplary embodiment of a GUI that may be displayed in accordance with an exemplary embodiment of a method for sensor migration in an analyte monitoring system. [Figure 9C] FIG. 13 is a diagram of an exemplary embodiment of a GUI that may be displayed in accordance with an exemplary embodiment of a method for sensor migration in an analyte monitoring system. [Figure 9D] FIG. 13 is a diagram of an exemplary embodiment of a GUI that may be displayed in accordance with an exemplary embodiment of a method for sensor migration in an analyte monitoring system. [Figure 10A] 1 is a flow chart illustrating an example embodiment of a method for generating a sensor insertion fault system alarm. [Figure 10B] 11A-11C are diagrams of an example embodiment of a GUI that would be displayed according to an example embodiment of a method for generating a sensor insertion fault system alarm. [Figure 10C] 11A-11C are diagrams of an example embodiment of a GUI that would be displayed according to an example embodiment of a method for generating a sensor insertion fault system alarm. [Figure 10D] 11A-11C are diagrams of an example embodiment of a GUI that would be displayed according to an example embodiment of a method for generating a sensor insertion fault system alarm. [Figure 11A] 1 is a flow chart illustrating an example embodiment of a method for generating a sensor shutdown system alarm. [Figure 11B] 11A-11C are diagrams of an example embodiment of a GUI that would be displayed according to an example embodiment of a method for generating a sensor outage system alarm. [Figure 11C] 11A-11C are diagrams of an example embodiment of a GUI that would be displayed according to an example embodiment of a method for generating a sensor outage system alarm. [Figure 11D] 11A-11C are diagrams of an example embodiment of a GUI that would be displayed according to an example embodiment of a method for generating a sensor outage system alarm. [Figure 12A] FIG. 1 is a diagram of an exemplary embodiment of a system for bidirectional communication of patient data. [Figure 12B] FIG. 1 is a diagram of an exemplary embodiment of a system for bidirectional communication of patient data. [Figure 12C] FIG. 1 is a diagram of an exemplary embodiment of a system for bidirectional communication of patient data. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

[0021] The documents discussed herein are provided solely for their disclosure prior to the filing date of this application. Nothing herein should be construed as an admission that the present disclosure is not entitled to antedate such documents by virtue of prior disclosure. Further, the dates of documents provided may be different from the actual publication dates, which may need to be independently confirmed.

[0022] In general, the disclosed embodiments of the present invention include GUIs and digital interfaces for analyte monitoring systems, and related methods and devices. Thus, many embodiments include an in vivo analyte sensor that is structurally configured such that at least a portion of the sensor is or can be positioned within a user's body to obtain information regarding at least one analyte in the body. However, it should be noted that the embodiments disclosed herein can be used with in vivo analyte monitoring systems that incorporate extracorporeal functionality, as well as purely extracorporeal or ex vivo analyte monitoring systems, including completely non-invasive systems.

[0023] Additionally, for each and every embodiment of the methods disclosed herein, systems and devices capable of performing each of these embodiments are encompassed within the present disclosure. For example, embodiments of sensor control devices, reader devices, local computer systems, and trusted computer systems are disclosed, which may have one or more sensors, analyte monitor circuitry (e.g., analog circuitry), memory (e.g., for storing instructions), power sources, communication circuitry, transmitters, receivers, processors, and / or controllers (e.g., for executing instructions) capable of performing or facilitating the performance of any and every method step.

[0024] As discussed above, some embodiments described herein provide an improved GUI for an analyte monitor system that is highly intuitive and easy to use, and that gives a user quick access to physiological information. Some embodiments provide a time in range GUI for an analyte monitor system, the time in range GUI including a plurality of bars or bar segments, each bar or bar segment indicating an amount of time that a user's analyte level was in a predefined analyte range that correlates with such bar or bar segment. Another embodiment provides an analyte level / trend alert GUI for an analyte monitor system, the analyte level / trend alert GUI including a visual notification (e.g., an alert, alarm, pop-up window, banner notification, etc.), the visual notification including an alarm condition, an analyte level measurement associated with the alarm condition, and a trend indicator associated with the alarm condition. In summary, these embodiments provide a robust and easy to use interface that can increase user engagement with the analyte monitor system and enable timely and advantageous responses by the user, to name a few advantages.

[0025] In addition, some embodiments described herein provide improved digital interfaces for analyte monitor systems. Some embodiments provide improved methods, and associated systems and devices, for data backfilling, aggregating disconnection and reconnection events for wireless communication links, expired or faulty sensor transmission, fusing data from multiple devices, transferring previously activated sensors to new reader devices, generating sensor insertion failure system alarms, and generating sensor deactivation system alarms. Collectively and individually, these digital interfaces improve the accuracy and completeness of the analyte data being collected by the analyte monitor system, improve the flexibility of the analyte monitor system by allowing users to transfer between different reader devices, and improve the alarm transmission capabilities of the analyte monitor system by allowing more robust device-to-device communication during certain adverse conditions, just to name a few examples. Other improvements and advantages are also provided. Various configurations of these devices are described in detail with examples only.

[0026] However, before describing the above-mentioned aspects of the embodiments in detail, it is desirable to first describe examples of devices and their operation that may be present, for example, in an in vivo analyte monitor system, all of which may be used in conjunction with the embodiments described herein.

[0027] There are various types of in vivo analyte monitor systems. A "continuous analyte monitor" system (or "continuous glucose monitor" system), for example, may transmit data continuously, e.g., automatically according to a schedule, from the sensor control device to the reader device without requiring receipt. As another example, an "intermittent analyte monitor" system (or "intermittent glucose monitor" system or simply "intermittent" system) may transmit data from the sensor control device using a near field communication (NFC) protocol or a radio frequency identification (RFID) protocol, etc., upon scanning by the reader device or data, if desired. An in vivo analyte monitor system may operate without the need for finger stick calibration.

[0028] In vivo analyte monitor systems can be distinguished from "ex vivo" systems, which are "ex vivo" systems that contact a biological sample outside the body (or "ex vivo") and generally include a measurement device that carries a user's bodily fluid and has a port for accepting an analyte test strip that can be analyzed to determine the user's blood glucose level.

[0029] An in-vivo monitoring system may include a sensor that contacts a user's bodily fluid while positioned in the body and senses the level of an analyte contained therein. The sensor may be part of a sensor control device that resides on the user's body, the sensor control device including the electronics and power source that enable and control the analyte sensing. Sensor control devices and variations thereof may be referred to as "sensor control units," "body worn electronics" devices or units, "body worn" devices or units, or "sensor data communication" devices or units, to name a few.

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

[0031] Exemplary Embodiments of an In-Vivo Analyte Monitor System FIG. 1A is a conceptual diagram illustrating an exemplary embodiment of an analyte monitor system 100 including a sensor applicator 150, a sensor control device 102, and a reader device 120. In this case, the sensor applicator 150 can be used to deliver the sensor control device 102 to a monitoring location on a user's skin where the sensor 104 is held stationary for a period of time by an adhesive patch 105. The sensor control device 102 will be described in more detail in FIG. 2B and FIG. 2C, and can communicate with the reader device 120 through a communication path 140 using wired or wireless technology. Exemplary wireless protocols include Bluetooth, Bluetooth low energy (BLE, BTLE, Bluetooth Smart, etc.), Near Field Communication (NFC), and others. A user can view and use applications installed in memory on the reader device 120 using a screen 122 (which in many embodiments can include a touch screen) and input 121. The device battery of the reader device 120 can be recharged using a power port 123. Although only one reader device 120 is shown, the sensor control device 102 can communicate with multiple reader devices 120. Each of the reader devices 120 can communicate with each other to share data. More details regarding the reader devices 120 are provided below with respect to FIG. 2A. The reader devices 120 can communicate with a local computer system 170 through a communication path 141 using a wired or wireless communication protocol. The local computer system 170 can include one or more of a laptop, desktop, tablet, phablet, smartphone, set-top box, video game console, or other computing device, and the wireless communication can include any of a number of applicable wireless network connection protocols including Bluetooth, Bluetooth Low Energy (BTLE), Wi-Fi, or others.The local computer system 170 can communicate with the network 190 through communication path 143 by wired or wireless communication protocols as described above in a manner similar to the manner in which the reader device 120 can communicate with the network 190 through communication path 142. The network 190 can be any of a number of networks, such as private and public networks and local or wide area networks. The trusted computer system 180 can include a cloud-based platform or server and can provide authentication services, secure data storage (e.g., storage of analyte measurements received from the reader devices), report generation, and can communicate with the network 190 through communication path 144 by wired or wireless technologies. Additionally, while FIG. 1 illustrates the trusted computer system 180 and the local computer system 170 in communication with a single sensor control device 102 and a single reader device 120, it will be appreciated by those skilled in the art that each of the local computer system 170 and / or the trusted computer system 180 has the capability to be in wired or wireless communication with multiple reader devices and sensor control devices.

[0032] Additional details of suitable devices, systems, methods, components, and their operation, along with related features, are described in U.S. Pat. No. 9,913,600 to Taub et al., International Patent Publication No. WO 2018 / 136898 to Rao et al., International Patent Publication No. WO 2019 / 236850 to Thomas et al., and U.S. Patent Publication No. 2020 / 01969191 to Rao et al., the entire contents of each of which are incorporated by reference herein.

[0033] Exemplary embodiments of a reader device 2A is a block diagram illustrating an exemplary embodiment of a reader device 120, which in some embodiments may include a smartphone or a smart watch. In this case, the reader device 120 may include a display 122, an input component 121, and a processing core 206 including a communication processor 222 coupled to a memory 223 and an application processor 224 coupled to a memory 225. Also included may be a separate memory 230, an RF transceiver 228 having an antenna 229, and a power source 226 having a power management module 238. Additionally, the reader device 120 may include a multi-function transceiver 232 that may include wireless communication circuitry and may be configured to communicate with one or more antennas 234 through Wi-Fi, NFC, Bluetooth, BTLE, and GPS. As will be appreciated by those skilled in the art, these components are electrically and communicatively coupled to create a functional device.

[0034] Exemplary embodiments of a sensor control device 2B and 2C are block diagrams illustrating an exemplary embodiment of a sensor control device 102 having an analyte sensor 104 and sensor electronics 160 (including analyte monitor circuitry) that may have most of the processing functionality for rendering a final result suitable for display to a user. FIG. 2B shows a single semiconductor chip 161, which may be a custom application specific integrated circuit (ASIC). Within the ASIC 161, certain high level functional units are shown including an analog front end (AFE) 162, a power management (or control) circuit 164, a processor 166, and a communication circuit 168 (which may be implemented as a transmitter, receiver, transceiver, passive circuitry, or otherwise according to a communication protocol). In this embodiment, both the AFE 162 and the processor 166 are used as analyte monitor circuitry, although in other embodiments, either circuitry may perform the analyte monitor function. The processor 166 may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be a separate chip or distributed among (and be part of) several different chips.

[0035] Also included within the ASIC 161 is a memory 163, which may be shared by the various functional units present within the ASIC 161 or may be distributed among two or more of these functional units. The memory 163 may be a separate chip. The memory 163 may be a volatile and / or non-volatile memory. In this embodiment, the ASIC 161 is coupled to a power source 170, which may be a coin cell battery or the like. The AFE 162 interconnects with the in-vivo analyte sensor 104 and accepts measurement data therefrom and outputs these data in digital form to a processor 166, which further processes these data to provide final result glucose individual values ​​and glucose trend values, and the like. These data may then be provided to a communication circuit 168 for transmission through an antenna 171, for example, to a reader device 120 (not shown), where little further processing is required by a resident software application to display the data. For example, current glucose values ​​may be transmitted from the sensor control device 102 to the reader device 120 every minute, and past glucose values ​​may be transmitted every five minutes, according to some embodiments.

[0036] In some embodiments, to conserve power and processing resources on the sensor control device 102, digital data received from the AFE 162 may be sent to the reader device 120 (not shown) with minimal or no processing. In yet other embodiments, the processor 166 may be configured to generate certain predetermined types of data (e.g., current glucose value, past glucose value) suitable for either storage in memory 163 or transmission to the reader device 120 (not shown) and establish certain alarm conditions (e.g., sensor failure condition), while other processing and alarm functions (e.g., high / low glucose threshold alarms) may be performed using on the reader device 120. Those skilled in the art will appreciate that the methods, functions, and interfaces described herein may be performed in whole or in part by processing circuitry on the sensor control device 102, the reader device 120, the local computer system 170, or the trusted computer system 180.

[0037] FIG. 2C is similar to FIG. 2B, but includes two separate semiconductor chips 162 and 174 that can be packaged together or separately, unlike FIG. 2B. In this case, AFE 162 resides on ASIC 161. Processor 166 is integrated with power management circuitry 164 and communication circuitry 168 on chip 174. AFE 162 includes memory 163, and chip 174 includes memory 165 that can be isolated or distributed within it. In one exemplary embodiment, AFE 162 is combined with power management circuitry 164 and processor 166 on one chip, while communication circuitry 168 is on a separate chip. In another exemplary embodiment, both AFE 162 and communication circuitry 168 are on one chip, while processor 166 and power management circuitry 164 are on another chip. It should be noted that other chip combinations are possible, including three or more chips each performing a separate function as described, or sharing one or more functions to achieve fail-safe redundancy.

[0038] Exemplary Embodiments of a Graphical User Interface for an Analyte Monitor System Described herein are exemplary embodiments of GUIs for analyte monitor systems. At the outset, those skilled in the art will appreciate that the GUIs described herein include instructions stored in memory of the reader device 120, the local computer system 170, the trusted computer system 180, and / or any other device or system that is part of or in communication with the analyte monitor system 100. These instructions, when executed by one or more processors of the reader device 120, the local computer system 170, the trusted computer system 180, or any other device or system of the analyte monitor system 100, cause the one or more processors to perform the method steps described herein and / or output a GUI. Those skilled in the art will further appreciate that the GUIs described herein may be stored as instructions in the memory of a single centralized device, or in a variant may be distributed across multiple individual devices at geographically dispersed locations.

[0039] Exemplary embodiments of the sensor results interface 2D-2I depict exemplary embodiments of a sensor result interface or sensor result GUI for an analyte monitor system. In accordance with the subject matter of the present disclosure, the sensor result GUI described herein is configured to display analyte data and other health information through a user interface application (e.g., software) installed on a reader device, such as a smartphone or receiver as described with respect to FIG. 2B. One skilled in the art will also recognize that a user interface application having a sensor result interface or sensor result GUI can be implemented on a local computer system or other computer device (e.g., a wearable computer device, a smart watch, a tablet computer, etc.).

[0040] 2D, the sensor results GUI 235 depicts an interface including a first portion 236 that may include a numerical representation of a current analyte concentration value (e.g., current glucose value), a directional arrow indicating an analyte trend direction, and a textual description providing status information such as whether the user's analyte level is in range (e.g., "in range glucose"). The first portion 236 may include a color or shading that indicates the analyte concentration or trend. For example, as shown in FIG. 2D, the first portion 236 is a green shading that indicates the user's analyte level is in a target range. According to some embodiments, for example, a red shading may indicate an analyte level below a low analyte level threshold, an orange shading may indicate an analyte level above a high analyte level threshold, and a yellow shading may indicate an analyte level outside of a target range. In addition, according to some embodiments, the sensor results GUI 235 further includes a second portion 237 that includes a graphical representation of the analyte data. In particular, the second portion 237 includes an analyte trend graph reflecting an analyte concentration shown on the y-axis over a defined period of time shown on the x-axis. In some embodiments, the defined time period may be shown in 5 minute increments, with the time of data totaling 12 hours. However, one of ordinary skill in the art will recognize that other time increments and analyte data durations may be utilized and are fully within the present disclosure. The second portion 237 may further include a dot 239 indicating the current analyte concentration value on the analyte trend graph, a shaded green area 240 indicating the target analyte range, and two dotted lines 238a and 238b indicating the high and low analyte thresholds, respectively. According to some embodiments, the GUI 235 may further include a third portion 241 including a graphical indicator of the sensor life remaining and a textual informational representation.

[0041] 2E, another exemplary embodiment of a sensor results GUI 245 is shown. In accordance with the subject matter of the present disclosure, a first portion 236 is shown shaded in yellow to indicate that the user's current analyte concentration is not within the target range. In addition, a second portion 237 includes an analyte trend line 241, which may reflect past analyte levels over time, and a current analyte data point 239 (shown in yellow to indicate that the current value is outside the target range) that indicates the current analyte concentration value.

[0042] According to another aspect of the embodiments, the data on the sensor results GUI 245 is automatically updated or refreshed according to an update interval (e.g., every 2 seconds, every minute, every 5 minutes, etc.). For example, according to many of these embodiments, as analyte data is received by the reader device, the sensor results GUI 245 will update (1) the current analyte concentration value shown in the first portion 236, and (2) the analyte trend line 241 and current analyte data points 239 shown in the second portion 237. Additionally, in some embodiments, automatically updating the analyte data may prevent older historical analyte data (e.g., in the left portion of the analyte trend line 241) from being displayed any longer.

[0043] 2F is another exemplary embodiment of a sensor results GUI 250. According to the depicted embodiment, the sensor results GUI 250 includes a first portion 236 shown in orange shading indicating that the user's analyte level is above a high glucose threshold (e.g., greater than 250 mg / dL). The sensor results GUI 250 further depicts a health information icon 251, such as an exercise icon or an apple icon, that reflects a user record entry indicating that the user has exercised or eaten.

[0044] FIGURE 2G is another exemplary embodiment of a sensor results GUI 255. According to the depicted embodiment, the sensor results GUI 255 also includes a first portion 236 that is shown with an orange shading to indicate that the user's analyte level is above the high glucose threshold. As can be seen in FIGURE 2G, the first portion 236 does not report a numerical value, but instead displays the text "HI," indicating that the current analyte concentration value is outside the upper glucose reporting range limit. Conversely, although not shown in FIGURE 2G, one skilled in the art will appreciate that for an analyte concentration that is below the lower glucose reporting range limit, the first portion 236 will not display a numerical value, but will instead display the text "LO."

[0045] 2H is another exemplary embodiment 260 of a sensor result GUI. According to the depicted embodiment, the sensor result GUI 260 includes a first portion 236 that is shaded green to indicate that the user's current analyte level is in the target range. Additionally, according to the depicted embodiment, the first portion 236 of the GUI 260 includes text "Glucose Falling," which may indicate to the user that the user's analyte concentration value is expected to fall below the expected low analyte level threshold within a predetermined amount of time (e.g., expected glucose value will fall below 75 mg / dL within 15 minutes). If the user's analyte level is expected to increase above the expected high analyte level threshold within a predetermined amount of time, the sensor result GUI 260 may display the message "Glucose Increasing."

[0046] FIG. 2I is another exemplary embodiment 265 of a sensor results GUI. In accordance with the depicted embodiment, the sensor results GUI 265 depicts the first portion 236 when there is a sensor error. In accordance with the subject matter of the present disclosure, the first portion 236 includes an 3-dot dashed line 266 in place of a current analyte concentration value to indicate that the analyte value is not currently available. In some embodiments, the 3-dot dashed line 266 can indicate one or more error conditions, such as, for example, (1) a no signal condition, (2) a loss of signal condition, (3) a too hot / too cold sensor condition, or (4) an unavailable glucose level condition. Additionally, as can be seen in FIG. 2I, the first portion 236 includes a gray shade (instead of a green, yellow, orange, or red color) to indicate that the analyte data is not currently available. In addition, in accordance with another aspect of the embodiment, the second portion 237 can be configured to display historical analyte data in the analyte trend graph even when an error condition exists that prevents the display of a numerical value for the current analyte concentration in the first portion 236. However, as shown in FIG. 2I, no current analyte concentration value data points are shown on the analyte trend graph in second portion 237.

[0047] Exemplary Embodiments of the Within Time Interface Figures 3A-F depict exemplary embodiments of GUIs for an analyte monitor system. In particular, Figures 3A-F show a Time In Range (also referred to as Time In Range and / or Time In Target) GUI, each of which includes a number of bars or bar segments, each bar or bar segment indicating the amount of time that the user's analyte level is within a predefined analyte range that correlates thereto. In some embodiments, for example, the amount of time may be expressed as a percentage of the predefined amount of time.

[0048] 3A and 3B, the times in range GUI 305 includes a "custom" times in range view 305A and a "standard" times in range view 305B, with a slideable element 310 allowing the user to select between the two views. In accordance with the subject matter of the present disclosure, each of the times in range views 305A, 305B can include a number of bars, each bar indicating the amount of time the user's analyte level is in a predefined analyte range associated with it. In some embodiments, the times in range views 305A, 305B further include a date range indicator 308 indicating the relevant date for the number of displayed bars, and a data availability indicator 314 indicating the period of time for which analyte data is available for the displayed analyte data (e.g., "data available for 7 out of 7 days").

[0049] 3A, the “custom” time in range view 305A includes six bars including (from top to bottom) a first bar indicating that the user’s glucose range was above 250 mg / dL for 10% of the predetermined amount of time, a second bar indicating that the user’s glucose range was between 141 mg / dL and 250 mg / dL for 24% of the predetermined amount of time, a third bar indicating that the user’s glucose range was between 100 mg / dL and 140 mg / dL for 54% of the predetermined amount of time, a fourth bar indicating that the user’s glucose range was between 70 mg / dL and 99 mg / dL for 9% of the predetermined amount of time, a fifth bar indicating that the user’s glucose range was between 54 mg / dL and 69 mg / dL for 2% of the predetermined amount of time, and a sixth bar indicating that the user’s glucose range was below 54 mg / dL for 1% of the predetermined amount of time. Those skilled in the art will recognize that the glucose ranges and percentages of time for each bar may vary depending on the user-defined ranges and the user's available analyte data. Additionally, while Figures 3A and 3B show a predetermined amount of time 314 equal to 7 days, those skilled in the art will recognize that other predetermined amounts of time (e.g., 1 day, 3 days, 14 days, 30 days, 90 days, etc.) may be utilized and are fully within the disclosure of the present invention.

[0050] In accordance with another aspect of the embodiment, the "custom" times in range view 305A further includes a user definable custom target range 312 that includes an advantageous "edit" link that allows the user to define and / or modify the custom target range. As shown in the "custom" times in range view 305A, the custom target range 312 is defined as a glucose range between 100 mg / dL and 140 mg / dL and corresponds to the third bar 316 of the plurality of bars. In other embodiments, one of ordinary skill in the art will recognize that more than one range may be user adjustable, and such embodiments are fully within the present disclosure.

[0051] 3B, the "standard" time in range view 305B includes five bars (from top to bottom) including a first bar indicating that the user's glucose range was above 250 mg / dL for 10% of the predetermined amount of time, a second bar indicating that the user's glucose range was between 181 mg / dL and 250 mg / dL for 24% of the predetermined amount of time, a third bar indicating that the user's glucose range was between 70 mg / dL and 180 mg / dL for 54% of the predetermined amount of time, a fourth bar indicating that the user's glucose range was between 54 mg / dL and 69 mg / dL for 10% of the predetermined amount of time, and a fifth bar indicating that the user's glucose range was below 54 mg / dL for 2% of the predetermined amount of time. As with the "custom" time in range view 305A, one skilled in the art will recognize that the percentage of time for each bar may vary depending on the user's available analyte data. However, unlike the "custom" time in range view 305A, the glucose ranges shown in the "standard" view 305B cannot be adjusted by the user.

[0052] 3C and 3D depict another exemplary embodiment 320 of the Time In Range GUI having multiple views 320A and 320B similar to the views shown in FIGS. 3A and 3B, respectively. According to some embodiments, the Time In Range GUI 320 may further include one or more selectable icons 322 (e.g., radio buttons, checkboxes, sliders, switches, etc.) that allow a user to select a predefined amount of time in which the user's analyte data will be shown. For example, as shown in FIGS. 3C and 3D, the selectable icons 322 may be used to select a predefined amount of time of 7 days, 14 days, 30 days, or 90 days. Those skilled in the art will recognize that other predefined amounts of time may be utilized and are fully within the present disclosure.

[0053] 3E illustrates an exemplary embodiment 330 of a time in target GUI that may be visually output on a display of a reader device (e.g., a dedicated reader device, a measurement device, etc.). In accordance with the subject matter of the present disclosure, the time in target GUI 330 includes three bars (from top to bottom) including a first bar indicating that the user's glucose range was above the predetermined target range for 34% of the predetermined amount of time, a second bar indicating that the user's glucose range was in the predetermined target range for 54% of the predetermined amount of time, and a third bar indicating that the user's glucose range was below the predetermined target range for 12% of the predetermined amount of time. One of ordinary skill in the art will recognize that the percentage of time for each bar may vary depending on the user's available analyte data. Additionally, although FIG. 3E shows a predetermined amount of time 332 equal to the last seven days and a predetermined target range 334 of 80 mg / dL to 140 mg / dL, one of ordinary skill in the art will recognize that other predetermined amounts of time (e.g., 1 day, 3 days, 14 days, 30 days, 90 days, etc.) and / or predetermined target ranges (e.g., 70 mg / dL to 180 mg / dL) may be utilized and are fully within the scope of the present disclosure.

[0054] FIG. 3F illustrates a first bar portion indicating that the user's glucose range was "very high" or above 250 mg / dL for 1% of the predetermined amount of time (14 minutes), a second bar portion indicating that the user's glucose range was "high" or between 180 mg / dL and 250 mg / dL for 18% of the predetermined amount of time (4 hours and 19 minutes), and a third bar portion indicating that the user's glucose range was within the "target range" or between 70 mg / dL and 180 mg / dL for 78% of the predetermined amount of time (18 hours and 43 minutes). 3F depicts another example embodiment 340 of a time in range GUI including a single bar including five bar portions including (from top to bottom) a third bar portion indicating the user's glucose range was "low" or between 54 mg / dL and 69 mg / dL for 3% of a predetermined amount of time (43 minutes), a fourth bar portion indicating the user's glucose range was "very low" or below 54 mg / dL for 0% of a predetermined amount of time (0 minutes), and a fifth bar portion indicating the user's glucose range was "very low" or below 54 mg / dL for 0% of a predetermined amount of time (0 minutes). As shown in FIG. 3F, according to some embodiments, the time in range GUI 340 can display text adjacent to each bar portion indicating the actual amount of time, e.g., in hours and / or minutes.

[0055] According to one aspect of the embodiment illustrated in FIG. 3F, each bar segment of the time in range GUI 340 may include a different color. In some embodiments, the bar segments may be separated by dashed or dotted lines 342 and / or a numerical marker 344 may be written between the bar segments to indicate the range reflected by adjacent bar segments. In some embodiments, the time in range reflected by the bar segments may be further expressed as an actual amount of time (e.g., 4 hours and 19 minutes) as a percentage or both as shown in FIG. 3F. Furthermore, one skilled in the art will recognize that the percentage of time for each bar segment may vary depending on the user's analyte data. In some embodiments of the time in range GUI 340, the target range may be user configurable. In other embodiments, the target range of the time in range GUI 340 may not be user modifiable.

[0056] Exemplary Embodiments of the Analyte Level and Trend Alert Interface 4A-4O depict an exemplary embodiment of an analyte level / trend alert GUI for an analyte monitoring system. In accordance with the presently disclosed subject matter, the analyte level / trend alert GUI includes a visual notification (e.g., an alert, alarm, pop-up window, banner notification, etc.) that includes an alarm condition, an analyte level measurement associated with the alarm condition, and a trend indicator associated with the alarm condition.

[0057] 4A to 4C, there is shown a high glucose alarm 410, a low glucose alarm 420, and a severely low glucose alarm 430, each of which includes a pop-up window 402 that includes alarm condition text 404 (e.g., "Low Glucose Alarm") associated with the alarm condition, an analyte level measurement 406 (e.g., a current glucose level of 67 mg / dL), and a trend indicator 408 (e.g., a trend or directional arrow) associated with the alarm condition. In some embodiments, an alarm icon 412 may be adjacent to the alarm condition text 404.

[0058] 4D-4G, there are shown low glucose alarms 440, 445, severe low glucose alarm 450, and high glucose alarm 455, respectively. As shown in FIG. 4D, low glucose alarm 440 is similar to the low glucose alarm of FIG. 4B (e.g., includes a pop-up window including alarm condition text associated with the alarm condition, an analyte level measurement, and trend indicators associated with the alarm condition), but further includes an alert icon 442 indicating that the alarm has been configured as an alert (e.g., will display, play sound, vibrate even if the device is locked or the device's "silent" setting is active). With reference to FIG. 4E, low glucose alarm 445 is also similar to the low glucose alarm of FIG. 4B, but instead of including trend arrows, includes a text trend indicator 447. According to an aspect of some embodiments, the text trend indicator 447 can be enabled through the device's accessibility settings such that the device will "speak" the text trend indicator 447 to the user using its text-to-speech mechanism (e.g., Voiceover on iOS or Select-to-Speak on Android).

[0059] 4F, a low glucose alarm 450 is similar to the low glucose alarm of FIG. 4D (including an alert icon), but instead of displaying the analyte level measurement associated with the alarm condition and the trend indicator associated with the alarm condition, displays an out of range indicator 452 (e.g., "high" or "low") indicating that the current glucose level is above or below a predetermined reportable analyte level range. With reference to FIG. 4G, a high glucose alarm 455 is similar to the high glucose alarm of FIG. 4A (e.g., includes a pop-up window including the alarm condition text, the analyte level measurement, and the trend indicator associated with the alarm condition), but further includes instructions 457 for the user. In some embodiments, for example, the instructions can be a prompt to encourage the user to "test blood glucose." Those skilled in the art will appreciate that other instructions or prompts can be implemented (e.g., administer a correction bolus, eat, etc.).

[0060] Additionally, although Figures 4A-4G show an exemplary embodiment of an analyte level / trend alert GUI displayed on a smartphone having an iOS operating system, one skilled in the art will recognize that the analyte level / trend alert GUI can be implemented on other devices including, for example, smartphones having other operating systems, smart watches, wearables, reader devices, tablet computing devices, blood glucose meters, laptops, desktops, and workstations, to name a few. Figures 4H-4J depict exemplary embodiments of a high glucose alarm, a low glucose alarm, and a severe low glucose alarm for a smartphone having, for example, an Android operating system. Similarly, Figures 4K-4O depict exemplary embodiments of a severe low glucose alarm, a low glucose alarm, a high glucose alarm, a severe low glucose alarm (with a blood glucose test icon), and a high glucose alarm (with an out of range indicator), respectively, for a reader device.

[0061] Exemplary embodiments of the sensor usage interface 5A-5F depict exemplary embodiments of a sensor usage interface for a GUI for an analyte monitoring system. In accordance with the subject matter of the present disclosure, the sensor usage interface provides technology improvements including the ability to quantify and facilitate user engagement with the analyte monitoring system. For example, users may benefit from subtle behavioral modifications and improved predicted outcomes when the sensor usage interface provokes more frequent interactions with the device. Users may benefit from high frequency interactions that provide improvements in several metabolic parameters, as discussed in more detail below.

[0062] In some embodiments, the HCP may receive a report of the user's interaction frequency and the patient's history of metabolic parameter records (e.g., estimated HbA1c levels, time in range 70-180 mg / dL, etc.). If the HCP determines that certain patients are not as engaged as other patients in their practice, they may focus on improving the engagement of users / patients who are not as engaged as other patients. The HCP may benefit from more cumulative statistics (average number of glucose views per day, average number of glucose views before / after meals, average number of glucose views on days or times that are "under control" compared to average number of glucose views on days or times that are "out of control", etc.) that may be obtained from the records of the user's interaction frequency with the analyte monitor system and used to understand why the patient is not realizing the expected gains from the analyte monitor system. If the HCP determines that the patient is not benefiting from the analyte monitor system as expected, they may recommend improving the interaction level (e.g., increasing the interaction target level). Thus, the HCP may modify the pre-determined target interaction level.

[0063] In some embodiments, a caregiver may receive reports of the user's frequency of interaction. The caregiver may then nudge the user to improve their interaction with the analyte monitoring system. The caregiver may use this data to better understand and improve the user's level of engagement with the analyte monitoring system and modify therapy decisions.

[0064] According to some embodiments, for example, the sensor usage interface may include a visual display of one or more "view" metrics, each of which may indicate a measure of user engagement or interaction with the analyte monitor system. A "view" may include, for example, an instance in which the sensor results interface is rendered or foregrounded (in certain embodiments, to view any of the GUIs described herein). In some embodiments of the update intervals described above, the sensor results GUI 245 is automatically updated or refreshed according to an update interval (e.g., every second, every minute, every five minutes, etc.). Thus, a "view" may include one instance in which the sensor results interface is rendered or foregrounded per update interval. For example, if the update interval is every minute, rendering or foregrounding the sensor results GUI 245 several times per such minute would be considered to include only one "view." Similarly, if the sensor results GUI 245 is rendered or foregrounded for 20 consecutive minutes, the data on the sensor results GUI 245 would be considered to be updated 20 times (i.e., once every other minute). However, these updates are considered to constitute only 20 "views" (i.e., one "view" per update interval). Similarly, if the update interval is every 5 minutes, rendering or foregrounding the sensor results GUI 245 several times during such 5 minutes would be considered to include only one "view." If the sensor results interface is rendered or foregrounded for 20 consecutive minutes, it would be considered to constitute four "views" (i.e., one "view" for each of four 5 minute intervals). According to other embodiments, a "view" may be defined as the instance when a user views a sensor results interface with a valid sensor reading for the first time in a sensor life count. According to embodiments of the present disclosure, a user may receive a notification indicating when an instance of rendering or foregrounding the sensor results GUI is not counted as a "view," as described below.For example, the user may receive visual notifications indicating "results not updated," "views not counted," or "please retest glucose levels," etc. In some embodiments, as described in more detail below, the user may receive a confirmation request for each instance that is counted as a "view."

[0065] According to embodiments of the present disclosure, the one or more processors may be configured to record no more than one instance of a user actuation of the reader device during a defined period of time. By way of example and not limitation, the defined period of time may include one hour. Those skilled in the art will appreciate that the defined period of time may include any suitable period of time, such as, for example, one hour, two hours, three hours, 30 minutes, 15 minutes, etc.

[0066] According to some embodiments, a "view" may include, for example, a visual notification (e.g., a prompt, an alert, an alarm, a pop-up window, a banner notification, etc.). In some embodiments, the visual notification may include an alarm condition, an analyte level measurement associated with the alarm condition, and a trend indicator associated with the alarm condition. For example, an analyte level / trend alert GUI, such as the embodiment depicted in Figures 4A-4O, may constitute a "view."

[0067] In some embodiments, the sensor user interface may include a visual display of a "scan" metric that indicates another measure of user engagement or interaction with the analyte monitor system. A "scan" may include an instance of a user scanning a sensor control device, such as in an intermittent analyte monitor system, with a reader device (e.g., a smart phone, a dedicated reader, etc.). As described above with respect to a "view," a "scan" may include one instance per update interval of a user scanning a sensor control device with a reader device.

[0068] 5A and 5B depict exemplary embodiments of sensor usage interfaces 500 and 510, respectively. In accordance with the subject matter of this disclosure, sensor usage interfaces 500 and 510 may be rendered or displayed by a mobile app or software residing in non-transitory memory of reader device 120, for example, as described with respect to FIGS. 1 and 2A. In some embodiments, for each instance of a "view" or "scan," the software may record the date and time of the user's interaction with the system. In some embodiments, for each instance of a "view" or "scan," the software may record the current glucose value. 5A, the sensor usage interface 500 can include a defined period 508 indicating a time period (e.g., date range) over which the view metrics are measured, a total views metric 502 indicating a total number of views over the defined period 508, a views per day metric 504 indicating an average number of views per day over the defined period 508, and a percentage time sensor activity metric 506 indicating a percentage of the defined period 508 that the reader device 120 is in communication with the sensor control device 102 as described with respect to FIGs. 1, 2B, and 2C. With reference to FIG. 5B, the sensor user interface 510 can include the views per day metric 504 and the percentage time sensor activity metric 508, each measured over the defined period 508.

[0069] According to another aspect of the embodiment, while the predetermined time period 508 is shown as one week, one skilled in the art will recognize that other predetermined time periods can be utilized (e.g., 3 days, 14 days, 30 days). Additionally, the predetermined time period 508 can be a discrete time period with a start date and an end date as shown in the sensor usage interface 500 of FIGURE 5A, or can be a time period relative to the current date and time (e.g., "last 7 days", "last 14 days", etc.) as shown in the sensor usage interface 510 of FIGURE 5B.

[0070] 5C depicts an exemplary embodiment of a sensor usage interface 525 as part of an analyte monitor system report GUI 515. In accordance with the subject matter of the present disclosure, the GUI 515 is a summary report intended for a predefined time period 516 (e.g., 14 days) and includes multiple portion reports on a single report GUI including a sensor usage interface portion 525, a glucose trend interface 517 that may include a glucose trend graph, a low glucose event graph, and other related glucose metrics (e.g., glucose management indicators), a health information interface 518 that may include information logged by the user for the user's average daily carbohydrate intake and medication dosage (e.g., insulin dosage), and a comments interface 519 that may include additional information regarding the user's analyte and medication patterns presented in a narrative format. In accordance with another aspect of the embodiment, the sensor usage interface 525 may include a percentage time sensor activity metric 526, an average scans / views metric 527 (e.g., showing the average sum of scans and views), and a percentage time sensor activity graph 528. As can be seen in FIG. 5C, the axes of the percentage time sensor activity graph can be aligned with corresponding axes of one or more other graphs (e.g., average glucose trend graph, low glucose events graph), thus allowing a user to visually correlate data between multiple graphs from two or more portions of the reporting GUI by common units (e.g., time) from these aligned axes.

[0071] FIG. 5D illustrates an exemplary embodiment 530 of another analyte monitor system report GUI including sensor usage information. In accordance with the subject matter of the present disclosure, the GUI 530 is a monthly summary report including a first portion including a legend 531, which includes a plurality of graphical icons, each adjacent to a descriptive text. As shown in FIG. 5D, the legend 531 includes an icon and descriptive text for "average glucose," an icon and descriptive text for "scans / views," and an icon and descriptive text for "low glucose events." The GUI 530 further includes a second portion including a calendar interface 532. For example, as shown in FIG. 5D, the GUI 530 includes a monthly calendar interface, where each day of the month can include one or more of an average glucose metric, a low glucose event icon, and a sensor usage metric 532. In some embodiments as shown in FIG. 5D, the sensor usage metric ("scans / views") indicates an aggregate number of scans and views for each day.

[0072] 5E illustrates an exemplary embodiment of another analyte monitor system report GUI 540 including sensor usage information. In accordance with the subject matter of the present disclosure, GUI 540 is a weekly summary report including multiple sub-reports, each of which represents a different day of the week, and includes a glucose trend graph 541 that may include the user's measured glucose levels over a 24-time period, and a health information interface 543 that may include the user's average daily glucose, carbohydrate intake, and / or insulin doses. In some embodiments, glucose trend graph 541 may include a sensor usage marker 542 that indicates that a scan, view, or both occurred at a particular time during the 24-time period.

[0073] 5F illustrates an exemplary embodiment of another analyte monitor system report GUI 550 including sensor usage information. In accordance with the subject matter of the present disclosure, GUI 550 is a daily record report including a glucose trend graph 551 that may include a user's glucose levels over a 24-time period. In some embodiments, glucose trend graph 551 may include sensor usage markers 552 that indicate when a scan, view, or both occurred at a particular time during the 24-time period. Glucose trend graph 551 may further include a carbohydrate intake record marker 553 and an insulin dose record marker 554, as well as glucose event markers such as a low glucose event marker 555.

[0074] Figures 5I-5L depict various GUIs for improving usability and user privacy for the analyte monitor software. In Figure 5G, a GUI 5540 depicts a research consent interface 5540 that prompts the user to select (via buttons 5542) to either decline or consent to allowing the user's analyte data and / or other product-related data to be used for research purposes. In accordance with embodiments of the presently disclosed subject matter, the analyte data can be anonymized (de-identified) and stored in an international database for research purposes.

[0075] Referring now to FIG. 5H, a GUI 5550 depicts a “Vitamin C” warning interface 5550 that displays a warning to the user that regular use of vitamin C supplements in amounts greater than 500 mg may provide a falsely high sensor reading.

[0076] Figure 5I is a GUI 5500 depicting a first time start-up interface that may be displayed to a user when the analyte monitor software is started for the first time. In accordance with the presently disclosed subject matter, GUI 5500 may include a "Let's get started" button 5502 that, when pressed, directs the user to GUI 5510 of Figure 5J. GUI 5510 depicts a country confirmation interface 5512 that prompts the user to confirm their country. In accordance with another aspect of an embodiment, the country selected may restrict and / or enable certain interfaces within the analyte monitor software application for regulatory compliance purposes.

[0077] Turning now to FIG. 5K, GUI 5520 depicts a user account generation interface that allows a user to begin the process for generating a cloud-based account. In accordance with the subject matter of the present disclosure, a cloud-based user account can allow a user to share information with medical professionals, family, and friends, utilize a cloud-based reporting platform to review more sophisticated analyte reports, and back up the user's past sensor readings to a cloud-based server. In some embodiments, GUI 5520 can further include a "skip" link 5522 that allows a user to utilize the analyte monitor software application in a "no account mode" (e.g., without generating or linking to a cloud-based account). Selecting "skip" link 5522 can display a notification window 5524 informing the user that certain features are unavailable in the "no account mode." Additionally, notification window 5524 can prompt the user to return to GUI 5520 or to continue without account generation.

[0078] 5L is a GUI 5530 displaying a menu interface that is displayed within the analyte monitor software application while the user is in the “no account mode.” According to certain aspects of the embodiment, the GUI 5530 includes a “sign in” link 5532 that allows the user to leave the “no account mode” and either generate a cloud-based user account or sign in to an existing cloud-based user account from within the analyte monitor software application.

[0079] Those skilled in the art will understand that any of the GUIs, reporting interfaces, or portions thereof described herein are intended to be merely exemplary, and that any individual element or any combination thereof shown and / or described with respect to a particular embodiment or figure can be freely combined with any element or any combination thereof shown and / or described with respect to any of the other embodiments.

[0080] Exemplary Embodiments of a Digital Interface for an Analyte Monitoring System Described herein are exemplary embodiments of a digital interface for an analyte monitor system. In accordance with the subject matter of the present disclosure, the digital interface may include a set of instructions, routines, subroutines, and / or algorithms, such as software and / or firmware, stored in a non-transitory memory within the analyte monitor system and executed by one or more processors of one or more devices, which instructions, routines, subroutines, or algorithms are configured to enable certain functionality and inter-device communication. At the outset, those skilled in the art will appreciate that the digital interface described herein may include instructions stored in a non-transitory memory of the sensor control device 102, the reader device 120, the local computer system 170, the trusted computer system 180, and / or any other device or system that is part of or in communication with the analyte monitor system 100, as described with respect to FIGS. 1, 2A, and 2B. These instructions, when executed by one or more processors in the sensor control device 102, the reader device 120, the local computer system 170, the trusted computer system 180, or any other device or system in the analyte monitor system 100, cause the one or more processors to perform the methods described herein. Those skilled in the art will further recognize that the digital interfaces described herein may be stored as instructions in the memory of a single centralized device, or in variants may be distributed across multiple individual devices at geographically dispersed locations.

[0081] Exemplary embodiments of the method for backfilling data An exemplary embodiment of a method for data backfilling within an analyte monitor system is now described below. In accordance with the subject matter of the present disclosure, gaps in analyte data and other information may result from interruptions in the communication links between various devices within the analyte monitor system 100. These interruptions may occur, for example, when a device is turned off (e.g., the battery of a user's smartphone runs out) or when a first device temporarily moves out of wireless communication range with a second device (e.g., a user wearing the sensor control device 102 inadvertently leaves their smartphone at home when going to work). As a result of these interruptions, the reader device 120 is unable to receive analyte data and other information from the sensor control device 102. It would therefore be beneficial to have a robust and flexible method for data backfilling within an analyte monitor system to ensure that when the communication link is restored, each analyte monitor device is able to receive a complete data set as intended.

[0082] 6A is a flow diagram depicting an example embodiment 600 of a method for data backfilling in an analyte monitor system. In accordance with the presently disclosed subject matter, the method 600 may be implemented to apply data backfilling between the sensor control device 102 and the reader device 120. In step 602, analyte data and other information are communicated autonomously between a first device and a second device at predetermined intervals. In some embodiments, the first device may be the sensor control device 102 and the second device may be the reader device 120, as described above with respect to FIGS. 1, 2A, and 2B. In accordance with the presently disclosed subject matter, the analyte data and other information may include, but is not limited to, one or more of data indicative of an analyte level in a bodily fluid, a rate of change of the analyte level, an expected analyte level, an alert condition for a low analyte level or a high analyte level, a sensor fault condition, or a communication link event. According to another aspect of the embodiment, autonomously communicating at predetermined intervals can include streaming the analyte data and other information at one or more predetermined frequencies (e.g., every minute, every five minutes, every fifteen minutes, etc.) according to a standard wireless communication network protocol, such as a protocol like the Bluetooth protocol or the Bluetooth Low Energy protocol. In some embodiments, different types of analyte data or other information can be autonomously communicated between the first device and the second device at different predetermined frequencies (e.g., historical glucose data every five minutes, current glucose values ​​every minute, etc.).

[0083] In step 604, a disconnection event or condition occurs, resulting in an interruption of the communication link between the first device and the second device. As described above, a disconnection event may result from the second device (e.g., the reader device 120, a smartphone, etc.) running out of battery power or being manually turned off by a user. A disconnection event may also result from the first device being moved out of wireless communication range of the second device, the presence of a physical obstacle interfering with the first device and / or the second device, or anything else that prevents wireless communication from occurring between the first device and the second device.

[0084] At stage 606, the communication link between the first device and the second device is re-established (e.g., the first device returns within wireless communication range of the second device). Upon re-connection, the second device requests historical analyte data according to the last life count metric for which data was received. In accordance with the subject matter of the present disclosure, the life count metric may be tracked in increments of time (e.g., minutes) on the second device and may be a numerical value indicating the amount of time that has elapsed since the sensor control device was activated. For example, in some embodiments, the second device (e.g., reader device 120, smartphone, etc.) may determine the last life count metric for which data was received after re-establishing a Bluetooth wireless communication link with the first device (e.g., sensor control device 102). Then, according to some embodiments, the second device may send a request to the first device for historical analyte data and other information having a life count metric that is greater than the last life count metric determination for which data was received.

[0085] In some embodiments, instead of requesting historical specimen data associated with a life count metric greater than the last life count metric determination value for which data was received, the second device may send a request to the first device for historical specimen data or other information associated with a particular life count range.

[0086] In step 608, the first device receives the request and retrieves the requested historical specimen data from storage (e.g., non-transitory memory of the sensor control device 102) and then transmits the requested historical specimen data to the second device in step 610. In step 612, the second device receives the requested historical specimen data and stores it in storage (e.g., non-transitory memory of the reader device 120). In accordance with the subject matter of the present disclosure, when the requested historical specimen data is stored by the second device, it may be stored along with an associated life count metric. In some embodiments, the second device may output the requested historical specimen data to a display on the second device, such as a glucose trend graph of a sensor results GUI, for example, as described with respect to Figures 2D-2I. For example, in some embodiments, the requested historical specimen data may be used to fill gaps in a glucose trend graph by displaying it along with previously received specimen data.

[0087] Moreover, those skilled in the art will recognize that the data backfilling methods described above may be implemented among multiple different devices in wired or wireless communication with one another within an analyte monitoring system.

[0088] 6B is a flow diagram depicting another exemplary embodiment 620 of a method for data backfilling in an analyte monitor system. In accordance with the presently disclosed subject matter, the method 620 can be implemented to apply data backfilling between a reader device 120 (e.g., a smartphone, a dedicated reader) and a trusted computer system 180, such as, for example, a cloud-based platform for generating reports. In step 622, analyte data and other information is communicated between the reader device 120 and the trusted computer system 180 based on a number of upload triggers. In accordance with the presently disclosed subject matter, the analyte data and other information can include, but is not limited to, one or more of data indicative of an analyte level in a bodily fluid (e.g., current glucose level, historical glucose data), a rate of change of the analyte level, a predicted analyte level, alert conditions for low or high analyte level, information recorded by a user, information about the sensor control device 102, alarm information (e.g., alarm settings), wireless communication events, and reader device settings, to name a few examples.

[0089] According to another aspect of the embodiment, the upload triggers can include (but are not limited to) one or more of: starting the sensor control device 102; a user entering or deleting or recording a description; a wireless communication link (e.g., Bluetooth) being restored between the reader device 120 and the sensor control device 102; an alarm threshold being changed; an alarm being raised, updated, or cleared; an internet connection being restored; the reader device 120 being restarted; receipt of one or more current glucose readings from the sensor control device 102; the sensor control device 102 being shut down; a loss of signal alarm being raised, updated, or cleared; a loss of signal alarm being toggled on / off; a sensor results screen GUI being viewed; or a user signing into the cloud-based platform.

[0090] According to another aspect of the embodiment, the reader device 120 may "mark" the analyte data and other information transmitted to the trusted computer system 180 in order to track the transmission and reception of data between the devices. In some embodiments, for example, upon receipt of the analyte data and other information, the trusted computer system 180 may send a return response to the reader device 120 to acknowledge successful receipt of the analyte data and other information. The reader device 120 may then indicate these data as having been sent successfully. In some embodiments, the analyte data and other information may be indicated by the reader device 120 both before it is sent and after the return response is received. In other embodiments, the analyte data and other information may be indicated by the reader device 120 only after the return response is received from the trusted computer system 180.

[0091] 6B, in step 624, a disconnection event occurs that results in an interruption of the communication link between the reader device 120 and the trusted computer system 180. For example, the disconnection event may be caused by a user placing the reader device 120 in "airplane mode" (e.g., disabling the wireless communication module), by a user turning off the reader device 120, or may be caused by the reader device 120 moving out of wireless communication range.

[0092] At step 626, the communication link between the reader device 120 and the trusted computer system 180 is restored, which is one of multiple upload triggers. The reader device 120 then determines the last successful data transmission to the trusted computer system 180 based on the specimen data and other information previously marked and sent. Then, at step 628, the specimen data and other information not yet received by the trusted computer system 180 may be transmitted by the reader device 120. At step 630, the reader device 120 receives confirmation of successful receipt of the specimen data and other information from the trusted computer system 180.

[0093] 6B is described above with respect to a reader in communication with a trusted computer system, those skilled in the art will recognize that this data backfilling method can be applied between other devices and computer systems within an analyte monitor system (e.g., between a reader and a local computer system, between a reader and a medical delivery device, between a reader and a wearable computer device, etc.) These embodiments, along with variations and permutations thereof, are fully within the present disclosure.

[0094] In addition to data backfilling, an exemplary embodiment of a method for aggregating disconnection and reconnection events for wireless communication links within an analyte monitoring system is described. In accordance with the subject matter of the present disclosure, there may be many broad causes for interruptions in wireless communication links between various devices within an analyte monitoring system. Some causes may be technical in nature (e.g., the reader device is outside of wireless communication range of the sensor control device), while other causes may be related to user behavior (e.g., the user leaves their reader device at home). Thus, in order to improve connectivity and data integrity within the analyte monitoring system, it may be beneficial to collect information regarding disconnection and reconnection events between various devices within the analyte monitoring system.

[0095] 6C is a flow diagram depicting an example embodiment 640 of a method for aggregating disconnection and reconnection events for wireless communication links within an analyte monitoring system. In some embodiments, for example, the method 640 may be used to detect, record, and upload to the trusted computer system 180 Bluetooth or Bluetooth low energy disconnection and reconnection events between the sensor control device 102 and the reader device 120. In accordance with the subject matter of the present disclosure, the trusted computer system 180 may aggregate disconnection and reconnection events transmitted from multiple analyte monitoring systems. The aggregated data may then be analyzed to determine whether any conclusions can be made regarding how to improve connectivity and data integrity within the analyte monitoring system.

[0096] At step 642, analyte data and other information is communicated between the reader device 120 and the trusted computer system 180 based on a number of upload triggers such as those described above with respect to method 620 of Figure 6B. At step 644, a disconnection event occurs resulting in an interruption of the wireless communication link between the sensor control device 102 and the reader device 120. Exemplary disconnection events may include, but are not limited to, a user putting the reader device 120 into "airplane mode", a user turning off the reader device 120, the reader device 120 running out of power, the sensor control device 102 moving outside of the wireless communication range of the reader device 120, or a physical obstruction interfering with the sensor control device 102 and / or the reader device 120, just to name a few examples.

[0097] 6C , in step 646, the communication link between the sensor control device 102 and the reader device 120 is restored, which is one of multiple upload triggers. The reader device 120 then determines a disconnection time and a reconnection time, where the disconnection time is the time when the interruption of the wireless communication link between the sensor control device 102 and the reader device 120 began, and the reconnection time is the time when the wireless communication link is restored. According to some embodiments, the disconnection time and the reconnection time can be stored locally in an event log on the reader device 120. In step 648, the reader device 120 transmits the disconnection time and the reconnection time to the trusted computer system 180.

[0098] According to some embodiments, the disconnection and reconnection times may be stored in a non-transitory memory of the trusted computer system 180, such as a database, and aggregated with disconnection and reconnection times collected from other analyte monitor systems. In some embodiments, the disconnection and reconnection times may be transmitted to and stored on a cloud-based platform or server separate from the trusted computer system 180 that stores the analyte data. In yet other embodiments, the disconnection and reconnection times may be anonymized.

[0099] In addition, one skilled in the art will recognize that method 640 can be utilized to collect disconnection and reconnection times between, for example, reader device 120 and trusted computing system 180, reader device 120 and wearable computing devices (e.g., smart watches, smart glasses), reader device 120 and drug delivery devices (e.g., insulin pumps, insulin pens), sensor control device 102 and wearable computing devices, sensor control device 102 and drug delivery devices, and other devices in the analyte monitoring system, including any other combination of devices in the analyte monitoring system. One skilled in the art will further recognize that method 640 can be utilized to analyze disconnection and reconnection times for various wireless communication protocols, such as, for example, Bluetooth or Bluetooth low energy, NFC, 802.11x, UHF, cellular connections, or any other standard or proprietary wireless communication protocol.

[0100] Exemplary embodiments of improved out-of-date / bad sensor transmission Next, an exemplary embodiment of an improved expired / failed sensor transmission in an analyte monitoring system is described below. In accordance with the subject matter of the present disclosure, a sensor expired or failed condition detected by the sensor control device 102 can trigger an alert on the reader device 120. However, if the reader device 120 is in "airplane mode" or is turned off, or is outside of wireless communication range of the sensor control device 102, or is otherwise unable to wirelessly communicate with the sensor control device 102, the reader device 120 cannot receive these alerts. As a result, the user may miss information such as, for example, the need to immediately replace the sensor control device 102. Failure to take action on a detected sensor failure may also lead to the user being unaware of adverse glucose conditions (e.g., hypoglycemia and / or hyperglycemia) resulting from a deactivated sensor.

[0101] 7 is a flow diagram depicting an exemplary embodiment 700 of a method for improving an expired or failed sensor transmission in an analyte monitoring system. In accordance with the subject matter of the present disclosure, the method 700 may be performed by the sensor control device 102 to enable improved sensor transmission after a sensor expired or failed condition is detected. At step 702, a sensor expired or failed condition is detected by the sensor control device 102. In some embodiments, the sensor failed condition may include one or both of a sensor insertion failed condition or a sensor stopped condition. In some embodiments, for example, the sensor insertion failed condition or the sensor stopped condition may include, but is not limited to, one or more of a FIFO overflow detection condition, a sensor signal below a predetermined insertion failed threshold condition, a moisture intrusion detection condition, an electrode voltage above a predetermined diagnostic voltage threshold condition, an early signal attenuation (ESA) condition, or a late signal attenuation (LSA) condition, to name a few examples.

[0102] Referring again to FIG. 7 , at step 704, the sensor control device 102 ceases obtaining analyte level measurements from the analyte sensor in response to detecting the sensor fault condition. At step 706, the sensor control device 102 begins transmitting an indication of the sensor fault condition to the reader device 120 while also allowing the reader device 120 to connect to the sensor control device 102 for data backfill purposes. In accordance with the subject matter of the present disclosure, transmitting the indication of the sensor fault condition may include transmitting multiple Bluetooth or Bluetooth low energy advertising packets, each of which may include an indication of the sensor fault condition. In some embodiments, the multiple Bluetooth or BLE advertising packets may be transmitted repeatedly, continuously, or intermittently. Those skilled in the art will recognize that other modes of wirelessly broadcasting or multicasting the indication of the sensor fault condition may be implemented. In accordance with another aspect of an embodiment, in response to receiving the indication of the sensor fault condition, the reader device 120 may visually display an alert or prompt for confirmation by the user.

[0103] In step 708, the sensor control device 102 can be configured to monitor for a response or acknowledgement of receipt of the indication of the sensor fault condition from the reader device 120. In some embodiments, for example, the response or acknowledgement of receipt can be generated by the reader device 120 when a user clears an alert on the reader device 120 regarding the indication of the sensor fault condition or otherwise responds to a prompt for confirmation of the indication of the sensor fault condition. If the sensor control device 102 receives a response or acknowledgement of receipt of the indication of the sensor fault condition, in step 714, the sensor control device 102 can enter a storage state or a stopped state. In accordance with some embodiments, in the storage state, the sensor control device 102 has the ability to be put into a low power mode and restarted by the reader device 120. In contrast, in the stopped state, the sensor control device 102 cannot be restarted and must be removed and replaced.

[0104] The sensor control device 102 will stop sending the poor condition indication after a first predetermined period of time at stage 710 if it has not received an acknowledgment of the poor condition indication. In some embodiments, for example, the first predetermined period of time may be one of 1 hour, 2 hours, 5 hours, etc. Then, in stage 712, the sensor control device 102 will also stop enabling data backfill after a second predetermined period of time if it still has not received an acknowledgment of the poor condition indication. In some embodiments, for example, the second predetermined period of time may be one of 24 hours, 48 ​​hours, etc. Then, in stage 714, the sensor control device 102 enters a storage state or a stopped state.

[0105] By allowing the sensor control device 102 to continue transmitting a sensor fault condition for a predetermined period of time, embodiments of the present disclosure reduce the risk that a sensor fault alert will not be received. Additionally, while the embodiments described above have been directed to the sensor control device 102 in communication with a reader device 120, those skilled in the art will recognize that indications of a sensor fault condition can be transmitted between the sensor control device 102 and other types of mobile computing devices, such as, for example, a wearable computing device (e.g., smart watch, smart glasses) or a tablet computing device.

[0106] Exemplary Embodiments of Data Fusion in an Analyte Monitoring System Next, an exemplary embodiment of a method for fusing data received from one or more analyte monitor systems is described below. As described above with respect to FIG. 1, a trusted computer system 180, such as a cloud-based platform, can be configured to generate various reports based on analyte data and other information received from multiple reader devices 120 and sensor control devices 102. However, a large and diverse population of reader devices and sensor control devices may introduce complexities and challenges to generating reports based on the received analyte data and other information. For example, a single user may have multiple reader devices and / or sensor control devices, each of which may contain different versions, either simultaneously or sequentially over time. This may introduce yet another complication in that there may be sets of overlapping and / or overlaid data for each user. It would therefore be beneficial to have a method for fusing data in a trusted computer system for the purpose of generating reports.

[0107] FIG. 8A is a flow diagram depicting an exemplary embodiment 800 of a method for fusing data transmitted from multiple reader devices and multiple sensor control devices associated with a user to generate one or more reporting metrics. In accordance with the subject matter of the present disclosure, the method 800 can be implemented to fuse analyte data for purposes of generating various types of reporting metrics utilized for various reports. In step 802, data is received from one or more reader devices 120 and combined for fusion purposes. Next, in step 804, the combined data is de-duplicated to remove previous data transmitted from the same sensor control device and received from multiple readers. In accordance with the subject matter of the present disclosure, the process of de-duplicating the data can include (1) identifying or assigning a priority for each reader device that transmitted the received analyte data, and (2) retaining the data for the reader devices with potentially higher priority for which "duplicate" data exists. In some embodiments, for example, newer reader devices (e.g., newer models with more recent versions of software installed) are assigned a higher priority than older reader devices (e.g., older models with older versions of software installed). In some embodiments, priority may be assigned by type of device (e.g., a smart phone has a higher priority than a dedicated reader).

[0108] Continuing with reference to FIG. 8A, in step 806, a determination is made as to whether one or more of the reporting metrics to be generated require disaggregation of the overlaid data. If not, in step 808, a first type of reporting metric may be generated based on the de-duplicated data without further processing. In some embodiments, for example, the first type of reporting metric may include an average glucose level for use in reports such as a summary report or a monthly summary report (as described with respect to FIG. 5C and FIG. 5D). If it is determined that one or more of the reporting metrics to be generated require disaggregation of the overlaid data, in step 810, a method for disaggregating the overlaid data regions is performed. An exemplary embodiment of a method for disaggregating the overlaid data regions is described below with respect to FIG. 8B. Then, in step 812, a second type of reporting metric is generated based on the data that has been de-duplicated and processed to disaggregate the overlaid data segments. In some embodiments, for example, the second type of reporting metric may include a calculated low glucose event for use in reports such as a daily log report (as described with respect to FIG. 5F).

[0109] FIG. 8B is a flow diagram depicting an exemplary embodiment 815 of a method for decomposing overlapped analyte data regions that may be implemented, for example, in step 810 of method 800 described with respect to FIG. 8A. In step 817, the de-duplicated data from each reader (provided from step 804 of method 800 described with respect to FIG. 8A) may be sorted from oldest to newest. Next, in step 819, based on the reporting metric generated, the de-duplicated and sorted data is segregated according to a predetermined time period. In some embodiments, for example, if the reporting metric is a graph reflecting glucose values ​​over a particular day, the de-duplicated and sorted data may be segregated over such particular day. Next, in step 821, contiguous sections of the de-duplicated and sorted data for each reader device are segregated. In accordance with the subject matter of the present disclosure, discontinuous data points may be discarded or ignored (e.g., not used) for generating the reporting metric. In step 823, a determination is made as to whether there are any overlap areas for each consecutive section of deduplicated and sorted data of the reader device with other consecutive sections of deduplicated and sorted data from other reader devices. In step 825, for each identified overlap area, the deduplicated and sorted data from the reader device having a higher priority is kept. If in step 827 it is determined that all consecutive sections have been analyzed according to the previous steps, the method 815 ends in step 829. Otherwise, the method 815 returns to step 823 and continues with identifying and resolving any overlap areas between consecutive sections of deduplicated and sorted data for different reader devices.

[0110] 8C-8E are graphs (840, 850, 860) depicting various stages of de-duplicated and sorted data from multiple reader devices as they are processed according to method 815 for resolving overlapping data regions. Referring first to FIG. 8C, graph 840 depicts de-duplicated and sorted data from three different reader devices: a first reader 841 (reflected by circular data points), a second reader 842 (reflected by diamond data points), and a third reader 843 (reflected by square data points). One embodiment of graph 840 shows data at stage 821 of method 815 that has been de-duplicated, sorted, and isolated for a predetermined period of time. As can be seen in FIG. 8C, continuous data sections for each of the three reader devices (841, 842, and 843) are identified and three trajectories are shown. According to another aspect of the graph 840, the discrete data points 844 are not included among the three loci.

[0111] 8D, graph 850 shows data from readers 841, 842, 843 at step 823 of method 815, where three overlap areas between consecutive data sections are identified: a first overlap area 851 between all three consecutive data sections, a second overlap area 852 between two consecutive data sections (from reader device 842 and reader device 843), and a third overlap area 853 between two consecutive data sections (also from reader device 842 and reader device 843).

[0112] 8E is a graph 860 depicting the data at step 825 of step 815, where a single trace 861 illustrates the de-duplicated and sorted data from three reader devices 841, 842, 843 fused after resolving overlap regions 851, 852, and 853 by using the priority of each reader device. According to graph 860, the order of priority from highest to lowest is reader device 843, reader device 842, and reader device 841.

[0113] Although Figures 8C, 8D, and 8E show three contiguous data sections with three distinct overlap regions identified, one skilled in the art will understand that either fewer or more contiguous data sections (and non-contiguous data points) and overlap regions are possible. For example, one skilled in the art will recognize that if a user has only two reader devices, there can be fewer than three contiguous data sections and overlap regions, if any at all. Conversely, one skilled in the art will understand that if a user has five reader devices, there can be five contiguous data sections with three or more overlap regions.

[0114] Exemplary embodiments of sensor transfer An exemplary embodiment of a method for sensor migration will now be described below. In accordance with the subject matter of the present disclosure, as mobile computing and wearable technology continues to advance at a rapid pace and become more established, users will be more likely to switch or upgrade their smartphones more frequently. Thus, in the context of an analyte monitor system, it would be beneficial to have a sensor migration method that allows a user to continue using a previously activated sensor control device with a new smartphone. In addition, it would also be beneficial to ensure that historical analyte data from the sensor control device can be conveniently and securely backfilled into the new smartphone (and subsequently uploaded to a trusted computer system).

[0115] FIG. 9A is a flow diagram depicting an exemplary embodiment 900 of a method for migrating a sensor control device. In accordance with the subject matter of the present disclosure, the method 900 can be implemented within an analyte monitor system to allow a user to continue using a previously activated sensor control device with a new reader device (e.g., a smartphone). In step 902, a user interface application (e.g., a mobile software application or app) is installed on the reader device 120 (e.g., a smartphone) such that a new unique device identifier or “device ID” is generated and stored on the reader device 120. In step 904, after installing and activating the app, the user is prompted to enter their user credentials to log into the trusted computer system 180 (e.g., a cloud-based platform or server). An exemplary embodiment 930 of a GUI for prompting a user to enter their user credentials is shown in FIG. 9B. According to an aspect of an embodiment, the GUI 930 can include a username field 932 that can include a unique username or email address, and a password field 934, with or without a mask, that allows the user to enter their password.

[0116] Referring again to Figure 9A, at step 906, after the user credentials are entered into the app, a prompt is displayed requesting user approval to log into the trusted computer system 180. An exemplary embodiment of a GUI 940 for requesting user approval to log into the trusted computer system 180 is shown in Figure 9D. According to aspects of an embodiment, the GUI 940 may include a reminder as shown in Figure 9D that confirms that this login will cause the user to log off other reader devices (e.g., the user's old smartphone).

[0117] If the user approves the login, then in step 908, the user's credentials are sent to the trusted computer system 180 for subsequent verification. Additionally, according to some embodiments, the device ID may also be sent from the reader device 120 to the trusted computer system 180 and stored in non-transitory memory of the trusted computer system 180. According to some embodiments, for example, in response to receiving the device ID, the trusted computer system 180 may update a device ID field for the user's record in a database.

[0118] After the user credentials are verified by the trusted computer system 180, in step 910, the app prompts the user to scan an already-activated sensor control device 102. In accordance with the subject matter of the present disclosure, the scan can include bringing the reader device 120 in close proximity to the sensor control device 102 and having the reader device 120 transmit one or more wireless inquiry signals according to a first wireless communication protocol. In some embodiments, for example, the first wireless communication protocol can be a Near Field Communication (NFC) wireless communication protocol. However, one skilled in the art will recognize that other wireless communication protocols (e.g., infrared, UHF, 802.11x, etc.) can be implemented. An exemplary embodiment 950 of a GUI for prompting the user to scan an already-activated sensor control device 102 is shown in FIG. 9D.

[0119] 9A , in step 912, the reader device 120 scans the sensor control device 102, causing the sensor control device 102 to terminate any existing wireless communication links currently established with the user's previous reader device, if any. According to an aspect of the embodiment, the existing wireless communication links may include links established according to a second wireless communication protocol different from the first wireless communication protocol. In some embodiments, for example, the second wireless communication protocol may be a Bluetooth protocol or a Bluetooth low energy protocol. The sensor control device 102 then enters a "pairing waiting" state in which it is available to establish a wireless communication link with the reader device 120 according to the second wireless communication protocol.

[0120] At stage 914, the reader device 120 initiates a pairing sequence with the sensor control device 102 over a second wireless communication protocol (e.g., Bluetooth or Bluetooth low energy). Then, at stage 916, the sensor control device 102 completes the pairing sequence with the reader device 120. At stage 918, the sensor control device 102 begins sending current glucose data to the reader device 120 according to the second wireless communication protocol. In some embodiments, for example, the current glucose data can be wirelessly transmitted to the reader device 120 at predetermined intervals (e.g., every 1 minute, every 2 minutes, every 5 minutes).

[0121] 9A , in step 920, the reader device 120 receives current glucose data from the sensor control device 102 and stores the received current glucose data in the non-transitory memory of the reader device 120. In addition, according to some embodiments, the reader device 120 can request historical glucose data from the sensor control device 102 for backfilling purposes. According to some embodiments, for example, the reader device 120 can request historical glucose data from the sensor control device 102 for the entire wearing duration stored in the non-transitory memory of the sensor control device 102. In other embodiments, the reader device 120 can request historical glucose data for a particular predefined time range (e.g., from day 3 to present, from day 5 to present, last 3 days, last 5 days, life count>0, etc.). Other backfilling schemes (such as those described with respect to FIGS. 6A and 6B) can be implemented and are entirely within the scope of the present disclosure.

[0122] Upon receiving the request at step 922, the sensor control device 102 may retrieve the historical glucose data from the non-transitory memory and transmit it to the reader device 120. Then, at step 924, the reader device 120 may store the historical glucose data in the non-transitory memory. Additionally, according to some embodiments, the reader device 120 may display the current and / or past glucose data within the app (e.g., on a sensor results screen). In this regard, a new reader may display all available analyte data over the entire wear duration of the sensor control device. In some embodiments, the reader device 120 may transmit the current and / or past glucose data to the trusted computer system 180. At step 926, the received glucose data may be stored in the non-transitory memory (e.g., a database) of the trusted computer system 180.

[0123] In some embodiments, the received glucose data may be de-duplicated before storage in the non-transitory memory.

[0124] Exemplary embodiments of sensor inspection and sensor replacement system alarms Exemplary embodiments of autonomous sensor testing and sensor replacement system alarms and related methods are now described below. In accordance with the subject matter of the present disclosure, certain adverse conditions affecting the operation of the analyte sensor and sensor electronics may be detectable by the sensor control device. For example, an improperly inserted analyte sensor may be detected when an average glucose level measurement over a predetermined period of time is determined to be below a faulty insertion threshold. However, the sensor control device may not have sufficient alarm transmission capabilities due to its small form factor and limited power capacity. Therefore, it may be beneficial for the sensor control device to transmit an indication of the adverse condition to another device, such as a reader device (e.g., a smartphone), to alert a user of these conditions.

[0125] 10A is a flow diagram depicting an exemplary embodiment 1000 of a method for generating a sensor-insertion-failure system alarm (also referred to as a "sensor testing" system). At step 1002, a sensor-insertion-failure condition is detected by the sensor control device 102. In some embodiments, for example, the sensor-insertion-failure condition can be detected when an average glucose value over a predetermined period of time (e.g., average glucose value over 5 minutes, 8 minutes, 15 minutes, etc.) falls below a failure-of-insertion glucose level threshold. At step 1004, in response to detecting the failure-of-insertion condition, the sensor control device 102 stops obtaining glucose measurements. At step 1006, the sensor control device 102 generates and transmits a sensor test indicator to the reader device 120 via the wireless communication circuitry. Thereafter, as shown in steps 1012 and 1014, the sensor control device 102 will continue to transmit the sensor inspection indicator until either (1) it receives an acknowledgment of this indicator from the reader device 120 (step 1012), or (2) a predetermined waiting period has elapsed (step 1014), whichever occurs first.

[0126] According to another aspect of the embodiment, in step 1008, the reader device 120 will receive a sensor test indicator if a wireless communication link is established between the sensor control device 102 and the reader device 120. In step 1010, in response to receiving the sensor test indicator, the reader device 120 will display a sensor test system alarm. FIGS. 10B-10D are diagrams of an exemplary embodiment of a sensor test system alarm interface displayed on the reader device 120. In some embodiments, for example, the sensor test system alarm can be a notification box, banner, or pop-up window output on a smartphone display, such as interfaces 1020 and 1025 of FIGS. 10B and 10C. In some embodiments, the sensor test alarm can be output on a display on the reader device 120, such as a glucose meter or receiver device, for example, interface 1030 of FIG. 10D. According to these embodiments, the reader device 120 can transmit a sensor test indicator receipt to the sensor control device 102. In some embodiments, for example, a sensor check indicator receipt may be generated and sent automatically upon successful indication of a sensor check system alarm 1020, 1025, or 1030. In other embodiments, a sensor check indicator receipt is generated and / or sent in response to a predetermined user input (e.g., clearing a sensor check system alarm, pressing a confirmatory "OK" button 1032, etc.).

[0127] Thereafter, in step 1011, the reader device 120 de-registers the sensor control device 102. In accordance with the subject matter of this disclosure, for example, step 1011 may include one or more of the following: terminating the existing wireless communication link with the sensor control device 102, unpairing with the sensor control device 102, revoking authority or digital certification for the sensor control device 102, generating or modifying a record stored on the reader device 120 to indicate that the sensor control device 102 is in a storage state, or sending an update to the trusted computer system 180 indicating that the sensor control device 102 is in a storage state.

[0128] 10A, once either a sensor check indicator acknowledgement is received by the sensor control device 102 (at step 1012) or a predetermined waiting period has elapsed (step 1014), then in step 1016 the sensor control device 102 ceases transmitting the sensor check indicator. Next, in step 1018, the sensor control device 102 enters a storage state, in which the sensor control device 102 does not acquire glucose measurements, and the wireless communication circuitry is either deactivated or transitions to a dormant mode. According to one aspect, while in the "storage state", the sensor control device 102 can be rebooted by the reader device 120.

[0129] Although the method 1000 of FIG. 10A has been described with respect to glucose measurement, one skilled in the art will appreciate that the sensor control device 102 may also be configured to measure other analytes (e.g., lactate, ketones, etc.). Additionally, although the method 1000 of FIG. 10A describes certain method steps (e.g., receiving a sensor test indicator, displaying a sensor test system alarm, and sending a sensor test indicator receipt) as being performed by the reader device 120, one skilled in the art will appreciate that any or all of these method steps may be performed by other devices in the analyte monitoring system, such as, for example, a local computing system, a wearable computing device, or a drug delivery device. One skilled in the art will also appreciate that the method 1000 of FIG. 10A may be combined with any of the other methods described herein, including, but not limited to, the method 700 of FIG. 7 relating to stale sensors and / or faulty sensor transmissions.

[0130] 11A is a flow diagram depicting an example embodiment 1100 of a method for generating a sensor down system alarm (also referred to as a "sensor replacement" system alarm). At step 1102, a sensor down condition is detected by the sensor control device 102. As mentioned above, the sensor down condition may include, but is not limited to, one or more of a FIFO overflow detection condition, a sensor signal below a predetermined mis-insertion threshold condition, a moisture ingress detection condition, an electrode voltage above a predetermined diagnostic voltage threshold condition, an early signal attenuation (ESA) condition, or a terminal signal attenuation (LSA) condition, to name a few examples.

[0131] In step 1104, in response to detecting a sensor outage condition, the sensor control device 102 stops obtaining glucose measurements. In step 1106, the sensor control device 102 generates a sensor replacement indicator and transmits it to the reader device 120 through the wireless communication circuitry. Then, in step 1112, the sensor control device 102 will continue to transmit the sensor replacement indicator while determining whether a sensor replacement indicator receipt is received from the reader device 102. In accordance with the subject matter of this disclosure, the sensor control device 102 can continue to transmit the sensor replacement indicator until either (1) a predetermined waiting period has elapsed (step 1113) or (2) an acknowledgment of the sensor replacement indicator is received (step 1112) and the backfill data has been successfully transmitted to the reader device 120 (steps 1116, 1120).

[0132] 11A , if a wireless communication link is established between the sensor control device 102 and the reader device 120, then in step 1108 the reader device 120 will receive a sensor replacement indicator. In step 1110, in response to receiving the sensor replacement indicator, the reader device 120 will display a sensor replacement system alarm. FIGS. 11B-11D are diagrams of an exemplary embodiment of a sensor replacement system alarm interface displayed on the reader device 120. In some embodiments, for example, the sensor replacement system alarm can be a notification box, banner, or pop-up window output on a smartphone display, such as interfaces 1130 and 1135 of FIGS. 11B and 11C. In some embodiments, the sensor check alarm can be output on a display on the reader device 120, such as a glucose meter or receiver device, for example, interface 1140 of FIG. 11D. According to these embodiments, the reader device 120 can transmit a sensor replacement indicator receipt to the sensor control device 102 to acknowledge receipt of this indicator. In some embodiments, for example, a sensor replacement indicator receipt may be generated and sent automatically upon successful indication of a sensor replacement system alarm 1130, 1135, or 1140. In other embodiments, a sensor replacement indicator is generated and / or sent in response to a predetermined user input (e.g., clearing a sensor inspection system alarm, pressing a confirmation "OK" button 1142, etc.).

[0133] After displaying the sensor replacement system alarm and transmitting a sensor replacement indicator receipt, in step 1114, the reader device 120 may request historical glucose data from the sensor control device 102. In step 1116, the sensor control device 102 may collect and send the requested historical glucose data to the reader device 120. In accordance with the subject matter of the present disclosure, the steps of requesting, collecting, and communicating the historical glucose data may include a data backfill routine, such as the method described with respect to Figures 6A and 6B.

[0134] 11A , in response to receiving the requested historical glucose data, at step 1118, the reader device 120 may send a historical glucose data receipt to the sensor control device 102. Thereafter, at step 1119, the reader device 120 de-registers the sensor control device 102. In accordance with the subject matter of this disclosure, for example, step 1119 may include one or more of: terminating an existing wireless communication link with the sensor control device 102, unpairing with the sensor control device 102, revoking authority or digital authentication for the sensor control device 102, generating or modifying a record stored on the reader device 120 indicating that the sensor control device 102 has been deactivated, or sending an update to the trusted computer system 180 indicating that the sensor control device 102 has been deactivated.

[0135] At step 1120, the sensor control device 102 receives the historical glucose data acknowledgement. Thereafter, at step 1122, the sensor control device 102 can cease transmitting the sensor replacement indicator and enter a stopped state at step 1124, in which the sensor control device 102 does not acquire glucose measurements and the wireless communication circuitry is either stopped or in a dormant mode. In accordance with the subject matter of the present disclosure, when in the stopped state, the sensor control device 102 cannot be restarted by the reader device 120.

[0136] Although the method 1100 of FIG. 11A has been described with respect to glucose measurement, one skilled in the art will appreciate that the sensor control device 102 may also be configured to measure other analytes (e.g., lactate, ketones, etc.). Additionally, although the method 1100 of FIG. 11A describes certain method steps (e.g., receiving a sensor replacement indicator, displaying a sensor replacement system alarm, and sending a sensor replacement indicator receipt) as being performed by the reader device 120, one skilled in the art will appreciate that any or all of these method steps may be performed by other devices in the analyte monitoring system, such as, for example, a local computing system, a wearable computing device, or a drug delivery device. It will also be appreciated by one skilled in the art that the method 1100 of FIG. 11A may be combined with any of the other methods described herein, including, but not limited to, the method 700 of FIG. 7 relating to stale sensors and / or faulty sensor transmissions.

[0137] Exemplary embodiments of data integration with electronic health / medical records Described herein are exemplary embodiments of systems and methods for bidirectional communication of patient data. According to one aspect of these embodiments, as shown in FIG. 12A, a system 5000a for bidirectional communication of patient data can include a database (e.g., a hospital or health care office (HCO)) 5020, another database 5002A, and a data service 5003 (e.g., an analyte monitor system data service in some embodiments).

[0138] The analyte monitor system data service 5003 may be the trusted computer system 180 described above and may include, for example, a cloud-based server or network including software for providing services including, but not limited to, authentication and user profile management, secure data transmission and data storage, and analyte data report generation. The analyte monitor software 5004 may be a user interface application (e.g., software) as described above and may further be a reader device 120. In some embodiments, the data service 5003 may store analyte measurements generated and transmitted by multiple reader devices and sensor control devices in communication with it. In some embodiments, the data service 5003 maintains records of stored analyte measurements by associating these records with an appropriate user ID. By way of example and not limitation, user IDs may include the patient's email address, date of birth, first name, last name, address, geographic location, social security number, phone number, etc., or any combination thereof.

[0139] According to an embodiment, as can be seen in FIG. 12A, the hospital 5020 can include an electronic medical / health record component 5006 in communication with a clinical laboratory 5021. The clinical laboratory 5021 can include a laboratory information system or LIS system 5007, a laboratory equipment manager 5008, and one or more laboratory diagnostic machines 5009A, 5009B (two shown). The one or more laboratory diagnostic machines 5009A, 5009B can communicate with the data system 5001 using a data link, which can include wired or wireless technology. The one or more laboratory diagnostic machines 5009A, 5009B are configured to receive patient samples 5010A, 5010B, respectively, and perform laboratory analyses on the received samples. In operation, the electronic medical / health record component 5006 generates and sends a request to perform a laboratory analysis for a particular patient to the LIS system 5007. The LIS system 5007 sends the request to the Laboratory Equipment Manager 5008 which sends the request to the appropriate Laboratory Diagnostic Machine 5009A, 5009B. Once the patient sample is received by the Laboratory Diagnostic Machine 5009A, 5009B, the laboratory analysis is performed and the results from this analysis are sent to the Laboratory Equipment Manager 5008 which sends them to the LIS system 5007 which in turn sends them to the Electronic Medical / Health Record component 5006.

[0140] According to embodiments, the patient samples 5010A, 5010B can include, but are not limited to, any other biological fluid or sample known to those skilled in the art, such as blood, urine, etc. According to embodiments, the laboratory analysis can include, but is not limited to, analyzing how well organs, such as the kidneys, liver, thyroid, heart, etc. are functioning. By way of example and not limitation, the results of the laboratory analysis can include the patient's HbA1c, cholesterol, lipid panel, CBC, etc.

[0141] According to an embodiment, the electronic medical / health record (EMR) 5006 generates a sample ID that corresponds to the patient's personal ID (or patient ID). The sample ID is then sent to the LIS system 5007 along with the generated order. Thus, the patient ID remains unique to the EMR 5006, and within the clinical laboratory 5021 environment, only the sample ID is associated with the order. Once the laboratory analysis is completed and the results from this analysis are sent to the electronic medical / health record 5006, the electronic medical / health record 5006 pairs the sample ID for these results with the appropriate patient ID. Thus, the records of the results from the laboratory analysis can be associated with the patient ID. By way of example and not limitation, the patient ID can include the patient's email address, date of birth, first name, last name, address, geographic location, social security number, phone number, etc., or any combination thereof. The patient ID corresponds to an identification metric that is unique for each patient in the HCO. In some embodiments, the patient ID is unique to each hospital. Thus, the same patient cannot have the same patient ID across different HCOs. In other words, the same patient can have different patient IDs in different HCOs.

[0142] As can be seen in FIG. 12A, database 5002A may be a database maintained on a remote cloud server in communication with data services 5003 and electronic medical / health record 5006, and may include one or more processors (not shown). Database 5002A may receive records of results from laboratory analyses with associated patient IDs from EMR 5006, and may also receive records of specimen measurements with associated user IDs from data services 5003. The one or more processors may then pair results from laboratory analyses based on the specimen measurements and shared data items contained within these records. By way of example and not limitation, a test result for a patient ID may be paired with a specimen measurement for a user ID if the patient ID matches the user ID. By way of example and not limitation, the shared data items may include a patient's email address, date of birth, first name, last name, address, geographic location, social security number, phone number, or the like, or any combination thereof. The one or more processors may further receive a request to read, write, edit, or delete resource data in the first or second database, the request formatted in accordance with the Fast Healthcare Interoperability Resources (FHIR) standard and a FHIR extension that embodies the Healthcare Provider Directory (HPD) standard or H7.

[0143] According to an embodiment, one or more processors of database 5002A can perform calculations based on the test results and the analyte measurements. By way of example and not limitation, if the test results include HbA1c and the analyte measurements include glucose measurements, the one or more processors can perform calculations of a glucose derived A1c or a kinetic model for determining A1c. Additional details of the calculation of the kinetic model for determining glucose derived A1c or A1c are described in U.S. Patent Publication No. 2018 / 0235524 to Dunn et al., International Patent Publication No. WO 2020 / 086934 to Xu, U.S. Provisional Patent Application No. 62 / 939,970, U.S. Provisional Patent Application No. 63 / 015,044, U.S. Provisional Patent Application No. 63 / 081,599, U.S. Provisional Patent Application No. 62 / 939,956, U.S. Provisional Patent Application No. 63 / 015,044, and U.S. Provisional Patent Application No. 63 / 081,599, the entire contents of each of which are incorporated herein by reference.

[0144] According to an embodiment, database 5002A may communicate with electronic medical / health record 5006 according to the Fast Healthcare Interoperability Resources (FHIR) standard as disclosed in U.S. Patent Publication No. 20017 / 0270532, the entire contents of which are incorporated herein by reference. In some embodiments, database 5002A may communicate with electronic medical / health record 5006 using SMART on FHIR. According to an embodiment, database 5002A may communicate with data service 5003 according to the Hypertext Transfer Protocol Secure (HTTPS) protocol or the Representational State Transfer (REST) ​​protocol.

[0145] According to an embodiment, as can be seen in Figure 12B, database 5002B is similar to database 5002A in that it is in communication with data services 5003 and electronic medical / health record 5006 and may include one or more processors (not shown). Database 5002B is similar to database 5002A in all respects except that it may be located at hospital 5020 rather than on a remote cloud server, and may communicate with data services 5003 using a medical integration API (as shown) rather than HTTPS or REST. Thus, because database 5002B resides on the premises of hospital 5020, database 5002B can communicate with EMR 5006, which may not have the ability to communicate with databases located on remote cloud servers due to, for example and without limitation, network firewalls, network policy configurations, and / or lack of VPN capabilities. Additionally, in this case, all records received by the one or more processors reside on the premises of the hospital 5020, thus mitigating privacy and overall data concerns by ensuring that no records relating to patient identities are sent outside the hospital 5020.

[0146] In accordance with an embodiment, as can be seen in FIG. 12B, data service 5003 can communicate directly with EMR 5006 or lab equipment manager 5008, thereby eliminating the need for databases 5002a and 5002b (shown in FIGS. 12A-12B). Thus, data service 5003 can include one or more processors performing the same functions as the one or more processors on database 5002a discussed above. In addition, data service 5003 can communicate with electronic medical / health records 5006 according to the Fast Healthcare Interoperability Resources (FHIR) standard, as disclosed in U.S. Patent Publication No. 20017 / 0270532, the entire contents of which are incorporated herein by reference. In some embodiments, database 5002A can communicate with electronic medical / health records 5006 using SMART on FHIR. In some embodiments, the data service 5003 may communicate with the EMR 5006 such that it may receive records from the EMR 5006 or the lab equipment manager 5008 using blockchain technology. In some embodiments, details of a suitable digital path and corresponding validation systems and methods are described in U.S. Patent No. 10,991,158 to Luthra et al., the entire contents of which are incorporated herein by reference.

[0147] In accordance with the subject matter of the present disclosure, a system for managing a patient's health, wellness, and more is provided that includes a sensor configured to be positioned in at least partial contact with interstitial fluid within a user's body. In one embodiment, the system manages diabetes and can use a glucose sensor 104. The system further includes sensor electronics 160 configured to be coupled to the glucose sensor and configured to process data indicative of a plurality of monitored glucose levels from the glucose sensor. The system further includes a network 190 including one or more servers and at least one processor configured to receive or store the processed data associated with the user in a database, such as 5002A or 5002B. The databases 5002A and 5002B can reside on a server, on multiple servers, or on a distributed server network, such as the network 190 including one or more cloud servers. The system further includes a reader device 120 configured to receive the processed data from the sensor electronics, and the server 180 receives the processed data from the reader device. The system further includes one or more processors configured to generate a blockchain and record a first record on the blockchain, the first record including the first data and an associated individual ID. The one or more processors are configured to record a second record on the blockchain, the second record including the second data and an associated individual ID. The one or more processors are further configured to access the first record recorded on the first blockchain and pair the first data and the second data on the blockchain based on shared data items contained in the first record and the second record.

[0148] According to the subject matter of the present disclosure, there is provided a system for bidirectional communication of patient data using a blockchain including a first database having a first record including first data associated with a patient's personal ID and a second database having a second record including second data associated with a patient's user ID. The system further includes one or more processors configured to generate a blockchain and record the first record including the first data and the associated personal ID on the blockchain. The one or more blockchains can be implemented on a server, on multiple servers, or on a distributed server network, such as a network 190 including one or more cloud servers. The one or more processors are configured to record the second record including the second data and the associated personal ID on the blockchain. The one or more processors are further configured to access the first record recorded on the first blockchain and pair the first data and the second data on the blockchain based on the shared data items contained in the first record and the second record.

[0149] In accordance with the subject matter of the present disclosure, there is provided a method for bidirectional communication of patient data, comprising: receiving first data from a diagnostic system using one or more processors; receiving from a user a personal ID associated with the first data using one or more processors; generating a block chain using one or more processors; recording a first record on the block chain using one or more processors, the first record including the first data and an associated personal ID; accessing the first record recorded on the block chain using one or more processors; receiving a second record from a second database using one or more processors, the second record including second data associated with the user ID; pairing the first data and the second data on a block of the block chain based on shared data items contained in the first record and the second record using one or more processors; and displaying the combination of the first data and the second data using one or more processors.

[0150] Using the blockchain in this manner improves bidirectional communication of patient data. On the blockchain, the two data records are paired based on shared data items contained in the first record and the second record. The shared data items may be email addresses, names and dates of birth, public encryption keys, or any other unique identifiers. Further, in accordance with the subject matter of the present disclosure, a system may include a first database that is an electronic medical record system, and a first data that is a laboratory measurement HbA1c. The system may further include a second database that is a sample monitor system data service, and a second data that is a glucose level measured by the sample monitor system. Furthermore, the system may generate a notification that is displayed as a combination of the first data and the second data based on the first data being paired with the second data. Because the system allows for the use of FHIR standards, including the Healthcare Provider Directory (HPD) standard or FHIR extensions that embody H7, the system allows for programmable hooks that could be linked to one or more data sets. Further, it is contemplated that the system may enable programming of these hooks with SMART applications that would be plugged into the EMR or EMR5006 system, including provided through the provider's EMR or EMR5006 system. The system may further perform calculations including glucose derived A1c or personalized HbA1c based on the pairing of the first data with the second data.

[0151] Further, in accordance with the subject matter of the present disclosure, the method can include a first database being an electronic medical record system and a first data being a laboratory measured HbA1c. The method can further include a second database being an analyte monitor system data service and a second data being a glucose level measured by the analyte monitor system. The method can further include generating a notification based on the first data being paired with the second data. Furthermore, the method can perform a calculation based on the first data being paired with the second data, which can include a glucose derived A1c or a personalized HbA1c. In yet another embodiment, the notification can be directed to the user with a request to evaluate the reported outcome, such as to identify prior activities or other factors that may be consistent with the first data and the second data to provide further insight into the health of the monitored patient. In another embodiment, the block chain is enhanced by associating other types of recorded patient information with the analyte monitor events. For example, if an identified glucose-derived A1c is outside the expected range, a notification may be triggered prompting the patient to answer a question asking about their current condition, which may generate an ancillary situation to help the physician improve management issues that require more patient-driven management.

[0152] Further discussion of blockchain technology is provided herein for illustrative purposes. A blockchain-based database allows for the storage of records with a public key and a private key that is unique to a user. Advantages of a blockchain database include the immutable properties of transaction records when updated on the blockchain. The blockchain database includes a distributed transaction ledger that stores information accessible to database 5002A or 5002B. Due to the nature of the distributed ledger, blockchain transactions are immutable. Blockchain confirmation transactions cryptographically ensure that the integrity of the ledger can be verified from any particular node on the network. Blocks on the blockchain can include a block ID and data content.

[0153] As discussed above, database 5002A may receive records of results from laboratory analysis with associated patient IDs. Also as discussed in more detail above, each hospital may generate different patient IDs for results related to a patient. In addition, specimen measurements from data services use an associated user ID, but multiple specimen measurement systems may have different user IDs. These user IDs may not be associated with each other. In blockchain, each user record would be considered to associate each user ID and patient ID with the user. That is, a user record in blockchain would be considered to have a complete list of all associated user IDs and patient IDs. The blockchain record would be used to link all patient IDs arriving from EMR 5006 with all user IDs arriving from data services 5003. This allows for the integration of records related to different hospitals and specimen measurement services or systems. To allow for linking of patient IDs to specific users, a request can be made to users at the hospital seeking consent to share patient IDs with the blockchain database. In yet another embodiment, it is contemplated that any provider system may make a request to a patient for authorization or sharing of patient-generated health data. The request made at the hospital is a non-limiting example of how a patient request may be made to share patient-generated health data.

[0154] Exemplary embodiments of a digital interface for combining data from an analyte monitoring system with data from an electronic health record According to embodiments, reports of the combination of data from the analyte monitor system and test results from the EMR can be received by the HCP, caregiver, and / or analyte monitor system user. According to embodiments, it is contemplated that a provider can access reports or dashboards with reports directly through the EMR system using a SMART-FHIR based application. According to embodiments, an HCP can receive different reports or "dashboards" from multiple caregivers and / or users. By way of example and not limitation, an HCP can receive a detailed report showing the combined data. An example of a detailed report can include a graphical representation of analyte measurements over a period of time with laboratory measurements (e.g., HbA1c in certain embodiments), with various icons representing different test results. According to embodiments, the period can be selected by the HCP and can include, but is not limited to, 1 day, 5 days, 7 days, 14 days, 2 weeks, 1 month, 3 months, or any other period that may be clinically appropriate. The HCP can use the combined data to provide a target to the patient, for example and without limitation, "HbA1c level of 6.4% at next visit."

[0155] In some embodiments, the user may receive insights or encouragement based on the combined data. By way of example and not limitation, the user may receive a notification. The notification may include, but is not limited to, "Based on your lab results and sample measurements, your HbA1c is predicted to be x." In some embodiments, the notification may further explain, "With exercise / changes in diet / etc., your HbA1c levels could drop to Y."

[0156] Depending on the embodiment, the combined data may be used in conjunction with any of the graphical user interfaces described above. Depending on the embodiment, a user may personalize any of the graphical interfaces described above to additionally display the data received from the EMR 5006.

[0157] Although the presently disclosed subject matter has been described herein with reference to certain figures and examples, those skilled in the art will recognize that various modifications and improvements can be made to the presently disclosed subject matter without departing from the scope of the present disclosure. Moreover, although individual features of one embodiment of the presently disclosed subject matter may be discussed herein or shown in the drawings in one embodiment and not discussed or shown in other embodiments, it should be apparent that individual features of one embodiment can be combined with one or more features of another embodiment or features from multiple embodiments.

[0158] In addition to the specific embodiments claimed below, the presently disclosed subject matter also relates to other embodiments having any other possible combinations of the dependent features claimed below and the features disclosed above. It should therefore be appreciated that the specific features provided in the dependent claims and the specific features disclosed above can be combined with each other in other ways within the presently disclosed subject matter, and thus the presently disclosed subject matter also particularly relates to other embodiments having any other possible combinations. Thus, the above descriptions of specific embodiments of the presently disclosed subject matter have been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the presently disclosed subject matter to the disclosed embodiments.

[0159] The description herein merely illustrates the principles of the presently disclosed subject matter. Various modifications and alterations to the described embodiments will be apparent to those skilled in the art in light of the teachings herein. Accordingly, the disclosure herein is intended to be illustrative without limiting the scope of the subject matter.

Claims

1. 1. A system for managing diabetes, comprising: a glucose sensor configured to be positioned in at least partial contact with interstitial fluid within a user's body; sensor electronics coupled to the glucose sensor and configured to process data indicative of a plurality of monitored glucose levels from the glucose sensor; one or more processors configured to receive the processed data associated with the user and to store the processed data in a health record database; a first database having a first record including first data associated with a patient's personal ID; Including, The one or more processors: Generate a block chain, recording the first record on the blockchain, the first record including the first data and the associated personal ID; recording a second record on the blockchain that includes second data and the associated personal ID; accessing the recorded first record on the first block chain; and pairing the first data and the second data on a block of the block chain based on the shared data items contained in the first record and the second record; It is configured as follows: system.

2. a reader device configured to receive the processed data from the sensor electronics; and a server receiving the processed data from the reader device; The system of claim 1 .

3. the first database is an electronic medical record system; The system of claim 1 .

4. The first data is a laboratory measurement of HbA1c; The system of claim 1 .

5. the second database includes a analyte monitoring system data service; The system of claim 1 .

6. the second data includes a glucose level measured by an analyte monitoring system. The system of claim 1 .

7. the shared data items include email addresses; The system of claim 1 .

8. The shared data item includes a public key. The system of claim 1 .

9. a server including the one or more processors; The system of claim 1 .

10. a distributed server network including the one or more processors; The system of claim 1 .

11. 1. A system for bidirectional communication of patient data, comprising: a first database having a first record including first data associated with a patient's personal ID; a second database having a second record including second data associated with a user ID of the patient; Generate a block chain, recording the first record on the blockchain, the first record including the first data and the associated personal ID; recording the second record on the blockchain, the second record including the second data and the associated personal ID; accessing the first record recorded on the first block chain; and pairing the first data and the second data on a block of the block chain based on a shared data item contained in the first record and the second record; one or more processors configured to Including, the system.

12. the first database is an electronic medical record system; The system of claim 11.

13. The first data is a laboratory measurement of HbA1c; The system of claim 11.

14. the second database includes a analyte monitoring system data service; The system of claim 11.

15. the second data includes a glucose level measured by an analyte monitoring system. The system of claim 11.

16. the shared data items include email addresses; The system of claim 11.

17. The shared data item includes a public key. The system of claim 11.

18. The one or more processors are further configured to generate a notification based on the first data being paired with the second data. The system of claim 11.

19. The notification displays the first data paired with the second data.

20. The system of claim 18.

20. The one or more processors are further configured to perform a calculation based on the first data being paired with the second data. The system of claim 11.

21. The calculation includes calculating glucose derived A1c.

21. The system of claim 20.

22. The calculation includes calculating individual HbA1c.

21. The system of claim 20.

23. 1. A method for bidirectional communication of patient data, comprising: receiving, using one or more processors, first data from a diagnostic system; receiving, using the one or more processors, from a user a personal ID associated with the first data; generating a chain of blocks using the one or more processors; recording, using the one or more processors, a first record on the blockchain that includes the first data and the personal ID associated with the first data; accessing the first record recorded on the block chain using the one or more processors; receiving, using the one or more processors, a second record from a second database, the second record including second data associated with a user ID; using the one or more processors, pairing the first data and the second data on a block of the chain of blocks based on shared data items contained in the first record and the second record; displaying, using the one or more processors, a combination of the first data and the second data; A method comprising:

24. the first database is an electronic medical record system; 24. The method of claim 23.

25. The first data is a laboratory measurement of HbA1c; 24. The method of claim 23.

26. the second database includes a analyte monitoring system data service; 24. The method of claim 23.

27. the second data includes a glucose level measured by an analyte monitoring system.

24. The method of claim 23.

28. the shared data items include email addresses; 24. The method of claim 23.

29. The shared data item includes a public key.

24. The method of claim 23.

30. using the one or more processors to generate a notification based on the first data being paired with the second data.

24. The method of claim 23.

31. using the one or more processors to perform a calculation based on the first data being paired with the second data.

24. The method of claim 23.

32. The calculation includes calculating glucose derived A1c.

32. The method of claim 31 .

33. The calculation includes calculating individual HbA1c.

32. The method of claim 31 .

Images