Architecture of a distributed system for continuous glucose monitoring

Abstract

To receive glucose data from a continuous glucose sensor and control the use and redistribution of the data so that the data is used in an intended manner.SOLUTION: In one aspect, a method includes: preparing data including glucose levels using a continuous glucose sensor unit; wirelessly transmitting the data relating to the glucose levels to a display device from the continuous glucose sensor unit; automatically forwarding the data relating to the glucose levels from the display device to a cloud computing architecture; and storing the data relating to the glucose levels in separate groups at the cloud computing architecture.SELECTED DRAWING: Figure 4

Description

Technical Field

[0001] Cross - Reference to Related Applications This application claims the benefit of U.S. Provisional Patent Application No. 62 / 160,475, filed on May 12, 2015, and U.S. Provisional Patent Application No. 62 / 249,043, filed on October 30, 2015. The entire contents of the foregoing patent applications are incorporated by reference as part of the disclosure of this application.

[0002] This disclosure relates to a continuous glucose monitor for wirelessly transmitting data regarding glucose values and controlling the display and distribution of such data.

Background Art

[0003] Continuous glucose monitors are becoming increasingly popular as an easy way to monitor glucose levels. Before using a continuous glucose monitor, a user may find that, for example, they need to sample their blood glucose levels several times throughout the day, such as in the morning, around lunchtime, and in the evening, using test strips that determine glucose levels from a small blood sample. A continuous glucose monitor replaces these test strips and provides electronic monitoring and display of glucose levels.

[0004] In addition to monitoring glucose levels, continuous glucose monitors can generate and track various other data regarding glucose levels. For example, a continuous glucose monitoring system can track a number of data points including patient identification information, timestamps, alerts established by the user, diagnostic information of an electronic unit associated with the continuous glucose monitor, and various other information. A continuous glucose monitor can transmit this information to a display device so that the user can view the glucose levels.

[0005] Initially, continuous glucose monitors wirelessly transmitted glucose level data to a dedicated display. This dedicated display was a medical device designed to show the user glucose levels, trend patterns, and other information. However, with the increasing popularity of smartphones and software applications (apps) running on them, some users prefer to avoid the need to carry a dedicated display. Instead, some users prefer to monitor their glucose levels using a dedicated software app running on their mobile computing or smart device, such as a smartphone, tablet, or wearable device like a smartwatch or smart glasses. By using a software app on such a smart device, the continuous glucose monitoring system can transmit glucose and continuous glucose monitor information to other devices, software applications, and servers. These other devices, software applications, and servers can provide enhanced glucose monitoring, allow additional users to track a person's glucose levels (e.g., a parent monitoring their child's glucose levels), provide technical support for system operation, and provide access to patient medical data to several other systems and applications. [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] This disclosure describes systems and methods for controlling the distribution and use of data having multiple sensitivity categories (e.g., restricted, less restricted, etc.) across a distributed architecture. An exemplary embodiment enables data to be sent from a continuous glucose monitor to one or more connected display devices and transferred to a cloud computing architecture. Several challenges may arise with respect to the distribution of data of varying sensitivities, such as medical data, including, but not limited to, restricting access to restricted data such as proprietary, confidential, or patient identification information of third parties and certain system components, while selectively allowing access to other less sensitive data, ensuring that unauthorized entities cannot access restricted data, and providing a system that can receive, store, and selectively allow access to large amounts of data. [Means for solving the problem]

[0007] In one exemplary embodiment, a continuous glucose monitor divides data into several categories before transmission. These categories may be based on whether the data identifies a patient, contains proprietary information about system operation (e.g., error codes, calibration formulas, raw data, calibration data, etc.), or contains information that can be accessed by third parties and other system components. These categories are referred to herein as public data and private data. In other embodiments, a display or cloud computing architecture may divide data into several categories. The cloud computing architecture can then store the data separately and restrict access to only one or more of the data categories based on the entity requesting access. Different systems can synchronize data at different times.

[0008] In other embodiments, different data streams containing different data types may be sent to and stored separately on the server. The data streams may overlap, for example, if a continuous glucose monitor sends data streams to two connected displays, each of which forwards its data (along with any other data generated by the displays) to the server. This results in two separate data streams from the two displays, which should be duplicate data. The cloud computing architecture allows for the separate storage of data streams, enabling easy permission or restriction of access to the data, and also allowing the data streams to be compared to ensure correct system operation. In addition, each display can actually transmit multiple data streams, where the data is divided into one or more categories as needed to allow for easy classification and permission-based access. For example, each display can transmit two data streams, resulting in four data streams associated with a single continuous glucose monitor. The server can then resume transmissions from each particular display based on the most recent transmission received from that display.

[0009] A continuous glucose monitor transmits data categories at the same time or at different times. For example, a continuous glucose monitor might transmit some data in real time, e.g., every 5 minutes, and other data as part of a periodic bulk transfer, e.g., every hour. A cloud computing architecture stores real-time data and bulk data separately. In addition, different components within the cloud computing architecture store real-time data and bulk data for different periods. This allows for quick access to more recent data, such as data generated within the last 30 days, without requiring a single server to store extremely large amounts of data. Instead, the cloud computing architecture stores long-term data in separate storage devices.

[0010] In other exemplary embodiments, the continuous glucose monitor may encrypt at least some of the data before transmission. Encryption prevents unauthorized third parties from accessing the data. The continuous glucose monitor encrypts some or all of the data, and only devices authorized to access a particular data type can obtain the decryption key. For example, the continuous glucose monitor sends multiple data fragments to a display that has the sole key to decrypt part of the data. The display forwards the data to a server that has the key used to decrypt part or all of the data. In this manner, the continuous glucose monitor encrypts private data that remains encrypted during distribution through the system until it is received by the server.

[0011] Other exemplary embodiments address a common interface for accessing the described distributed system architecture. The system or system components may be approved medical devices that require new approval for certain changes to the system design or operation. Nevertheless, third parties may request access to medical data, using a variety of different types of requests. When a third party creates new software applications and servers, modifications to the system are required to grant the requested access. For example, a third-party application might request access to glucose levels for the past week to integrate them with dietary information. Another application might request access to glucose levels to provide recommendations for insulin injections. These applications may have different interfaces and request access to different data types (e.g., real-time vs. bulk, glucose levels with or without patient identification information, etc.). To address these issues, the cloud computing architecture implements a hub-and-spoke topology that provides a set of common application programming interfaces. Third parties may interface with the regulatory-approved common application programming interfaces. In addition, the system provides users with single sign-on, eliminating the need for users to log into separate systems when accessing various system modules.

[0012] In addition, the exemplary embodiment controls access to a patient's medical information through remote monitoring of a specific patient. A remote monitor is a person other than the patient who uses a continuous glucose monitor to access the patient's glucose levels. For example, a parent or guardian who can monitor a child's glucose levels may be considered a remote monitor. Maintaining confidential personal identification information by system components can be problematic because the information may fall under HIPPA and other regulations. This may include information that identifies the remote monitor itself and location or other information that identifies the remote monitor. To avoid storing identification information about remote monitors, remote monitors can register with the system using an anonymous identifier generator, and the system can, for example, store a unique number that associates the remote monitor's anonymous identification number with a display. Therefore, the cloud computing architecture does not need to receive or store any specifically identifying information of the remote monitors.

[0013] Other embodiments address challenges related to missed data transmissions from a continuous glucose monitor. For example, a smartphone may be turned off or out of range, and therefore miss data transmissions. Consequently, the display indicates that some data is missing, and the user may not even receive an alarm when their glucose level falls below or rises above a specified level, because the display is not communicating with the continuous glucose monitor. This same problem of missing data applies equally to other components, including additional displays, third-party applications, and other components within the cloud computing architecture, through the System. To address this challenge, embodiments identify when a particular device is missing data. The missing data is then selectively provided to the device as part of a process called backfilling. For example, the display searches for missing data within the last six hours. Upon identifying missing data, the display requests and receives the missing data from the continuous glucose monitor, another display, or another system component (i.e., "backfills" the missing data). Depending on the component, the display or other system components also search for additional time intervals up to a specified maximum number of days, such as one or 30 days, to backfill any other missing data. The display then reveals to the user which data was received on schedule or when it was sent (i.e., "in time") compared to the data received by the backfill process after the delay. This makes it easy for the user to identify why the display did not generate an alarm at a given time to evaluate against the alarm limit, for example, because no glucose levels were received because the device was out of range.

[0014] Another challenge arises regarding distinguishing between data received as scheduled at the time of transmission and data received through a backfill process. A user might be confused or infer that there was an error in the alarm if they missed an alarm because their device was out of range, but upon checking their smartphone, they find glucose data available within the time frame the alarm should have been issued. However, the smartphone did not have the data at the time of the alarm, but instead backfilled the data afterward. To address this issue, in some embodiments, the display and cloud computing architectures store instructions on whether the data was received as scheduled at the time of transmission or later as part of a backfill process. The cloud computing architecture stores that data separately, along with instructions for distinguishing the data for subsequent technical support and other issues. In addition, multiple displays send separate data streams to the cloud computing architecture, which stores those data streams separately, along with instructions on which display sent the data. This allows the cloud computing architecture to identify which display transferred the data, helping to identify the cause of any problems.

[0015] One embodiment describes a method for securely transmitting glucose level data. This method may include preparing data containing glucose levels using a continuous glucose monitor, wirelessly transmitting the glucose level data from a transmitter associated with the continuous glucose monitor to at least one display device, automatically transferring the glucose level data from the display device to a cloud computing architecture, and storing the glucose level data in a separate group within the cloud infrastructure. The glucose level data may include measured glucose values ​​and diagnostic data.

[0016] Optionally, or otherwise, the above method may further include, by means of a display device, additional data along with data relating to glucose levels, and the automatic data transfer includes automatically transferring the additional data and data relating to glucose levels.

[0017] Optionally, or otherwise, the glucose level data may include a first dataset and a second dataset, and the storage of glucose level data into separate groups may include storing the first dataset on a first server and the second dataset on a second server. Optionally, or otherwise, the first dataset may include real-time data, which includes one or more of the following: glucose value, current status of a continuous glucose sensor, and timestamp associated with measurement results used to obtain glucose value; and the second dataset may include at least one of the following: information for calibrating a continuous glucose monitor and information used for technical support of a continuous glucose monitor.

[0018] Optionally, the above method may further include: encrypting a first dataset by a transmitter; encrypting a second dataset by a transmitter; decrypting and displaying the first dataset by at least one display device; preventing at least one display device from decrypting the second dataset; and decrypting the second dataset by a cloud infrastructure.

[0019] Optionally, the above method may further include storing a first key for decrypting a first dataset by at least one display device, storing a second key for decrypting a second dataset by a cloud infrastructure, and preventing at least one display device from accessing the second key.

[0020] Optionally, or otherwise, the above method may further include transferring a subset of glucose level data from the cloud infrastructure to a second display device, the subset of data including at least one of current glucose levels and historical glucose levels.

[0021] Optionally, or otherwise, the above method may further include the cloud infrastructure selectively deciding whether to allow one or more requesting systems to access the first and second datasets. The requesting systems may include a technical support system, at least one third-party application, and a data warehouse, and the cloud infrastructure may allow the technical support system to access the first and second datasets, at least one third-party application to access the first dataset, and the data warehouse to access the first and second datasets.

[0022] Optionally, or otherwise, the display device may include at least one of a smartphone or a display.

[0023] In another embodiment, a system for monitoring glucose level data is disclosed. This system may comprise a continuous glucose sensor configured to prepare glucose level data, a wireless transmitter configured to transmit glucose level data, a display device configured to receive transmitted glucose level data and automatically transfer the data, and a cloud computing architecture configured to receive automatically transferred data and store glucose level data in separate groups. The glucose level data includes measured glucose values ​​and diagnostic data.

[0024] Optionally, or alternatively, the above-described system may further be configured to include additional data along with data regarding glucose levels and to automatically transfer the additional data and the data regarding glucose levels.

[0025] Optionally, or alternatively, in the above-described system, the data regarding glucose levels may include a first data set and a second data set, and the storing of the data regarding glucose levels into separate groups may include separately storing the first data set in a first server and the second data set in a second server.

[0026] Optionally, or alternatively, in the above-described system, the first data set may include real-time data, the real-time data including one or more of a glucose value, a current state of a continuous glucose sensor, and a time stamp associated with a measurement result used to obtain the glucose value, and the second data set may include at least one of information for calibrating a continuous glucose monitor and information used for technical support of the continuous glucose monitor.

[0027] Optionally, or alternatively, in the above-described system, the transmitter may further be configured to encrypt the first data set and the second data set, at least one display device may further be configured to decrypt and display the first data set, at least one display device may not be able to decrypt the second data set, and the cloud infrastructure may further be configured to decrypt the second data set.

[0028] Optionally, or alternatively, in the above-described system, at least one display device may further be configured to store a first key for decrypting the first data set, the cloud infrastructure may further be configured to store a second key for decrypting the second data set, and at least one display device may not be able to access the second key.

[0029] Optionally, or alternatively, in the above-described system, the cloud infrastructure may be further configured to transfer a subset of data regarding glucose levels to a second display device, the subset of data including at least one of the current glucose level and past glucose levels.

[0030] Optionally, or alternatively, in the above-described system, the cloud infrastructure may be further configured to selectively determine whether to permit access to a first data set and a second data set by one or more requesting systems. The requesting systems may include a technical support system, at least one third-party application, and a data warehouse, and the cloud infrastructure may be further configured to permit access to the first data set and the second data set by the technical support system, permit access to the first data set by at least one third-party application, and permit access to the first data set and the second data set by the data warehouse.

[0031] Optionally, or alternatively, in the above-described system, the display device may include at least one of a smartphone or a display.

[0032] In another aspect of this disclosure, a computer-readable medium is described which, when executed by one or more processors, includes instructions for a method of securely transmitting glucose level data. The instructions may include preparing glucose level data using a continuous glucose monitor; wirelessly transmitting glucose level data from a transmitter associated with the continuous glucose monitor to at least one display device; automatically transferring glucose level data from the display device to a cloud computing architecture; and storing glucose level data in a separate group within the cloud infrastructure. Glucose level data may include measured glucose values ​​and diagnostic data.

[0033] Optionally, or otherwise, instructions may include additional data along with glucose level data by a display device, and automatic data transfer may include automatically transferring the additional data and glucose level data.

[0034] Optionally, or otherwise, the instructions may include data relating to glucose levels, including a first dataset and a second dataset, and the storage of data relating to glucose levels into separate sets includes storing the first dataset and the second dataset separately by a cloud infrastructure.

[0035] Optionally, the instruction may include a first dataset, which may include real-time data, which may include one or more of the following: glucose values, the current status of the continuous glucose sensor, and timestamps associated with the measurement results used to obtain the glucose values; and a second dataset may include at least one of the following: information for calibrating the continuous glucose monitor and information used for technical support of the continuous glucose monitor.

[0036] Optionally, or otherwise, the instruction may include: encrypting a first dataset by a transmitter; encrypting a second dataset by a transmitter; decrypting and displaying the first dataset by at least one display device; preventing at least one display device from decrypting the second dataset; and decrypting the second dataset by a cloud infrastructure.

[0037] Optionally, or otherwise, the instruction may include storing a first key for decrypting a first dataset by at least one display device, storing a second key for decrypting a second dataset by a cloud infrastructure, and preventing at least one display device from accessing the second key.

[0038] Optionally, or otherwise, the instruction may include transferring a subset of glucose level data from a cloud infrastructure to a second display device, the subset of data including at least one of current glucose levels and historical glucose levels.

[0039] Optionally, or otherwise, the instruction may include the cloud infrastructure selectively deciding whether to allow one or more requesting systems to access the first and second datasets.

[0040] Optionally, or otherwise, the instruction may include a request system including a technical support system, at least one third-party application, and a data warehouse, wherein the cloud infrastructure grants the technical support system access to the first and second datasets, grants at least one third-party application access to the first dataset, and grants the data warehouse access to the first and second datasets.

[0041] For example, various other embodiments of systems, methods, and computer-readable media related to securely transmitting glucose level data are also disclosed herein, including methods for encrypting and transmitting glucose level data from a continuous glucose monitor, systems for encrypting and transmitting glucose level data from a continuous glucose monitor, one or more computer-readable media containing instructions that, when executed by one or more processors, perform the method for encrypting and transmitting glucose level data from a continuous glucose monitor, methods for controlling access to glucose level data, systems for controlling access to glucose level data, one or more computer-readable media containing instructions that, when executed by one or more processors, perform the method for controlling access to glucose level data, methods for updating glucose level data in a distributed architecture, systems for updating glucose level data in a distributed architecture, one or more computer-readable media containing instructions that, when executed by one or more processors, perform the method for updating glucose level data in a distributed architecture, methods for synchronizing glucose level data in a distributed architecture system, systems for synchronizing glucose level data in a distributed architecture system, and one or more computer-readable media containing instructions that, when executed by one or more processors, perform the method for synchronizing glucose level data in a distributed architecture system.

[0042] A system for securely collecting, analyzing, and reporting data on glucose monitoring levels using multiple continuous glucose monitors is further described herein. In one embodiment, the system comprises: multiple continuous glucose monitors (CGMs); multiple display devices that receive data from the multiple CGMs, wherein the data is classified into multiple categories based on data type; a cloud server architecture comprising multiple servers that intermittently receive data from the multiple display devices, wherein the data routed to a specific server among the multiple servers is determined by data type, and the intermittency basis differs depending on the data type; multiple remote monitor display devices that receive data from one of the multiple servers, wherein the data sent to each of the multiple remote monitor display devices depends on data type and the display device that sent the data to one of the multiple servers, and the data is sent to the multiple remote monitor display devices immediately after being received by one of the multiple servers; and an analysis and reporting engine to which at least a portion of the data received by the multiple servers is sent, the transmitted data is analyzed, and a report is generated by the analysis and reporting engine.

[0043] In one embodiment, a plurality of servers, including a cloud server architecture, include at least one real-time server and a bulk data collector.

[0044] In one embodiment, the data types include real-time data and bulk data.

[0045] In one embodiment, real-time data is routed from multiple display devices to a real-time server, and bulk data is routed from multiple display devices to a bulk data collector. In another embodiment, real-time data is routed from multiple display devices to a real-time server on a more intermittent basis than the intermittent basis in which bulk data is routed from multiple display devices to a bulk data collector. In yet another embodiment, real-time data is routed from multiple display devices to a real-time server every 5 minutes, and bulk data is routed from multiple display devices to a bulk data collector every hour.

[0046] In one embodiment, the system further includes a locator service, and multiple display devices connect to a cloud server architecture through the locator service.

[0047] In one embodiment, at least one of the multiple display devices includes a smartphone.

[0048] In one embodiment, at least one of the multiple remote monitoring display devices includes a smartphone.

[0049] In one embodiment, the multiple display devices include at least 150,000 devices.

[0050] In one embodiment, at least one of a plurality of remote monitoring display devices further includes an application that may be run by at least one of the plurality of remote monitoring display devices. In one embodiment, the application on at least one of the plurality of remote monitoring display devices must be open and running to receive data ready to be sent to at least one of the plurality of remote monitoring display devices, otherwise the data ready to be sent to at least one of the plurality of remote monitoring display devices is held by one of the plurality of servers.

[0051] In one embodiment, at least one of a group of remote monitoring display devices that receive data from one of a group of servers receives a notification that the data is ready to be sent to at least one of the group of remote monitoring display devices. The notification may include a text message.

[0052] In one embodiment, when one of a plurality of servers attempts to send data to at least one of a plurality of remote display devices, an application that may be run by at least one of the plurality of remote display devices wakes up. In one embodiment, after the application wakes up, the application requests the data to be sent from one of the plurality of servers.

[0053] A method for securely collecting, analyzing, and reporting data on glucose monitoring levels using multiple continuous glucose monitors is also disclosed. In one embodiment, the method includes: receiving data from multiple continuous glucose monitors (CGMs) using multiple display devices; classifying the data into multiple categories based on data types; transmitting the data from the multiple display devices to a cloud server architecture comprising multiple servers that intermittently receive data from the multiple display devices, wherein the data routed to a specific server among the multiple servers is determined by the data type, and the intermittency basis differs depending on the data type; receiving data from one of the multiple servers using multiple remote monitor display devices, wherein the data sent to each of the multiple remote monitor display devices depends on the data type and the display device that sent the data to one of the multiple servers, and the data is sent to the multiple remote monitor display devices immediately after being received by one of the multiple servers; and receiving at least a portion of the data received by the multiple servers using an analysis and reporting engine, wherein the received data is analyzed and a report is generated by the analysis and reporting engine. In one embodiment, the multiple servers, including the cloud server architecture, include at least one real-time server and a bulk data collector.

[0054] In one embodiment, classifying data into multiple categories based on data type may include classifying data as real-time data and bulk data. Real-time data may be routed from multiple display devices to a real-time server, and bulk data may be routed from multiple display devices to a bulk data collector.

[0055] In one embodiment, real-time data is routed from multiple display devices to a real-time server on a more intermittent basis than bulk data is routed from multiple display devices to a bulk data collector on an intermittent basis. For example, real-time data may be routed from multiple display devices to a real-time server every 5 minutes, while bulk data may be routed from multiple display devices to a bulk data collector every hour.

[0056] In one embodiment, the method may further utilize a locator service, and multiple display devices connect to a cloud server architecture through the locator service.

[0057] In one embodiment, at least one of the multiple display devices includes a smartphone.

[0058] In one embodiment, at least one of the multiple remote monitoring display devices includes a smartphone.

[0059] In one aspect of this method, the multiple display devices include at least 150,000 devices.

[0060] In one embodiment, at least one of a plurality of remote monitoring display devices further includes an application that may be run by at least one of the plurality of remote monitoring display devices. In one embodiment, the application on at least one of the plurality of remote monitoring display devices must be open and running to receive data ready to be sent to at least one of the plurality of remote monitoring display devices, otherwise the data ready to be sent to at least one of the plurality of remote monitoring display devices is held by one of the plurality of servers.

[0061] In one embodiment, at least one of a group of remote monitoring display devices that receive data from one of a group of servers receives a notification that the data is ready to be sent to at least one of the group of remote monitoring display devices. For example, the notification may include a text message.

[0062] In one embodiment, when one of a plurality of servers attempts to send data to at least one of a plurality of remote display devices, an application that may be run by at least one of the plurality of remote display devices wakes up. In one embodiment, after the application wakes up, the application requests the data to be sent from one of the plurality of servers.

[0063] Other systems, methods, features, and / or advantages will become apparent to those skilled in the art by examining the following drawings and modes for carrying out the invention. All such additional systems, methods, features, and / or advantages are intended to be included within the scope of this description and protected by the appended claims.

[0064] The accompanying drawings incorporated herein, and which constitute part thereof, illustrate embodiments and, together with this description, serve to illustrate the principles of the Method and System. [Brief explanation of the drawing]

[0065] [Figure 1] An illustrative system for monitoring glucose levels and controlling access to and use of medical data is shown. [Figure 2] This diagram illustrates an example of how to provide data streams to a cloud computing architecture. [Figure 3] This diagram illustrates an example of a system using the cloud computing architecture of this technology. [Figure 4] This diagram illustrates an example method for storing data in separate groups. [Figure 5] This diagram illustrates an example system for encrypting medical data. [Figure 6] This diagram illustrates an example method for encrypting medical data. [Figure 7] This diagram illustrates an example of how to provide a common interface through which data can be accessed. [Figure 8] This diagram illustrates an example system that processes requests from a display to a cloud computing architecture. [Figure 9A] This diagram illustrates an example of a continuous glucose monitoring application running on a display. [Figure 9B] This diagram illustrates an example of a system using a cloud server architecture that implements the described technologies. [Figure 9C] The data and control flow related to the example locator service are illustrated in the diagram. [Figure 9D] This flowchart illustrates a method for securely collecting, analyzing, and reporting glucose monitoring level data using multiple continuous glucose monitors. [Figure 10] This diagram illustrates an example method for backfilling missing data. [Figure 11] This diagram illustrates an example method for backfilling missing data. [Figure 12A] This section illustrates various diagrams that depend on the operation of the display. [Figure 12B] This section illustrates various diagrams that depend on the operation of the display. [Figure 13] An illustrative computer for use with the disclosed embodiments is shown. [Modes for carrying out the invention]

[0066] This disclosure relates to techniques for receiving glucose data from a continuous glucose sensor and controlling the use and redistribution of that data so that it is used in the intended manner.

[0067] When used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless otherwise explicitly indicated by the context. Ranges may be expressed herein as “about” a particular value and / or “about” another particular value. When such ranges are expressed, another embodiment includes that particular value and / or that other particular value. Similarly, when a value is expressed as an approximation by the use of the antecedent “about,” it is understood that that particular value forms another embodiment. It is further understood that each endpoint of those ranges is significant both in relation to and independently of the other endpoint.

[0068] "Optional" or "optional" means that the event or situation described thereafter may or may not occur, and that the description includes both instances in which the event or situation occurs and instances in which it does not occur.

[0069] Throughout this specification and in the claims, the word “comprise,” and variations thereof such as “comprising” and “comprises,” mean “including, but not limited to,” and are not intended to exclude, for example, other additions, components, integers, or steps. “Exemplary” means “an example,” and is not intended to indicate a preferred or desirable embodiment. “Etc.” is used for illustrative purposes only and not in a restrictive sense.

[0070] Components and features that may be used to perform the disclosed methods and systems are disclosed herein. While these and other components are disclosed herein, and combinations, subsets, interactions, groups, etc., of these components are disclosed, specific references to various individual and collective combinations, and their substitutions, may not be explicitly disclosed, it is understood that each is specifically intended and described herein for all methods and systems. This applies to all aspects of this application, including, but not limited to, steps in the disclosed methods. Therefore, where various additional steps may be performed, it is understood that each of these additional steps may be performed using any particular embodiment or combination of embodiments of the disclosed methods.

[0071] Distributing glucose information, related health information, and continuous glucose monitoring device information across the entire system to other systems and applications presents challenges related to protecting patient confidentiality. Glucose information, diagnostic information, and other confidential or proprietary information are not suitable for replication to all additional systems and applications. Since additional systems and applications should not have access to all of the data, it would be beneficial to classify and categorize the data and protect some or all of the data from being redistributed in a manner that ensures patient confidentiality.

[0072] In one illustrative example, a continuous glucose monitor can transmit glucose levels, a timestamp indicating when the monitor obtained the glucose level measurement, and patient identification information to the display. The display then forwards this information to a server repository, which also stores information from several other patients. Some applications may request access to this information and receive glucose levels, timestamps, and patient identification information. For example, a patient might want their clinic to access this information. However, patient identification information is not necessary to provide technical support to a user experiencing problems with a continuous glucose monitor. Therefore, patient identification information should be excluded in this example, and technical support would be limited in terms of identifying the patient.

[0073] Another issue that arises with storing data associated with continuous glucose monitors on a server is how to organize and store the data. Such data may include, for example, data on patient glucose levels, raw or calibrated data from the continuous glucose monitor, alert data including alert levels, defect detection data, etc. Tens of thousands of patients may use continuous glucose monitors that periodically transfer large amounts of data to the server. The process of receiving, storing, and providing selective access to third parties, authorized users, and additional system components places a heavy processing load on the server. In one illustrative example, a continuous glucose monitor takes glucose level readings and associated timestamps every 5 minutes. The display transfers the glucose level and timestamp, along with the additional data described below, to the server for storage. As a result, in this example, the server receives 288 glucose levels, timestamps, and additional data per day from a single user. For 20,000 continuous glucose monitors operating over a month, the server receives more than 175 million data transmissions, including glucose levels, timestamps, and additional data. The server should archive this information, control access to parts of it, search for selected portions of the information, and forward those selected portions to authorized entities. This places a considerable processing load on the server.

[0074] A further challenge is that a continuous glucose monitor can wirelessly transmit data such as glucose levels, timestamps, and other relevant information to multiple displays, and each display can forward that data to a server. In one illustrative example, the continuous glucose monitor transmits data to a receiver with a display, as well as to a smartphone, smartwatch, personal computer, tablet, or other type of display. In this example, two data streams for each user are sent to the server, resulting in duplicate data. In addition, two data streams from two displays associated with the same continuous glucose monitor will differ because one display may be offline, for example, if the smartphone is turned off or out of wireless range from the continuous glucose monitor. The two data streams may also differ for other reasons. In one example, two displays may use different calibration values, resulting in different glucose levels based on the same dataset received from the continuous glucose monitor. Therefore, it would be beneficial to systematize, store, and provide accurate copies of the data received from multiple displays.

[0075] Another challenge arises regarding the security of data transmission across the entire system. Some components within a distributed architecture may be granted access to certain data, while others should not. Therefore, it would be beneficial to restrict access to data for unauthorized users and limit access to authorized users to only a subset of the data. In addition, numerous other devices or software applications may access data stored on the server. Considering the potential of such numerous other devices or software applications, it would be beneficial to provide a standardized interface to enable access to the data. However, this can be particularly difficult in the field of medical devices, where the system may be required to obtain regulatory approval as a medical device. Once approved, changes to the system may require further regulatory approval, which can be a time-consuming and costly process. Therefore, a modular standardized interface that can accommodate many different third-party components and adapt to different requirements from those third-party components without requiring changes to the system design would be beneficial.

[0076] This disclosure relates to systems and methods for controlling the distribution and use of data having multiple sensitivity categories (e.g., restricted, less restricted, etc.) across a distributed architecture. In some exemplary embodiments, the architecture by the Technology enables data to be sent from a medical device (e.g., a continuous glucose monitor) to one or more connected display devices (e.g., a smartphone, tablet, or wearable smart device such as a smartwatch or smart glasses), and to be distributed according to various levels of sensitivity of the data, such as proprietary, confidential, or patient identification information in the case of medical data, and provided to a cloud computing system designed to control access to the data by third parties and / or certain system components based on the determined level of sensitivity. In some embodiments of the Technology, such third parties and / or certain system components are prevented from accessing restricted data without permission, while selectively permitted to access other less sensitive data, such as providing a system that can receive, store, and selectively grant access to large amounts of data, ensuring that unauthorized entities cannot access restricted data. While some examples of distributed architectures are described for continuous glucose monitoring, other exemplary embodiments are discussed below throughout this specification, and the claims should not be limited to addressing embodiments related to continuous glucose monitoring.

[0077] The method and system can be more readily understood by referring to the following detailed description of preferred embodiments and the examples included therein, as well as the figures and the descriptions before and after them.

[0078] Figure 1 illustrates an exemplary system for monitoring glucose levels and controlling access to and use of data associated with such monitoring. Such data may be defined as having multiple categories, each category having one or more levels of confidentiality. The system disclosed in Figure 1 may be used for data storage and distribution, and data within different categories or with different levels of confidentiality may be treated differently within the system. For example, data that identifies or could be used to identify a patient should not be copied to all third parties. Only third parties with appropriate permissions or authorizations should be able to access this data. Furthermore, other data, such as glucose levels, may be misused by third parties. As an example, a third party receiving monitored glucose levels may make incorrect recommendations to a user on how to control their insulin pump. The system in Figure 1 allows some data to be treated differently from others by dividing it into categories such as public data, private data, real-time data (e.g., raw or calibrated), and other bulk data, as described below. The system in Figure 1 allows some data to be treated differently from others by providing permission-based access to the data. Furthermore, the system in Figure 1 can store and provide access to large amounts of data. For example, the system in Figure 1 can temporarily store some data, such as data within the most recent defined period (e.g., 15 days, 30 days, 60 days, etc.), in a cloud computing architecture, and periodically transfer other data, such as data older than 30 days, to a longer-term storage device.

[0079] Referring to Figure 1, the continuous glucose sensor units 100a-c acquire a series of measurement results regarding glucose levels in a patient. The continuous glucose sensor units 100a-c can be attached, for example, to the patient's abdominal region. A small sensor extends into the patient's body, and glucose readings can be acquired, for example, using subcutaneous glucose or blood glucose readings. The continuous glucose sensor units 100a-c can also be transcutaneous, intravascular, or non-invasive devices.

[0080] The continuous glucose sensor units 100a-c include several components for acquiring glucose measurement results, storing data, calculating glucose levels, and communicating with displays 104a-e. The displays 104a-e may be dedicated receivers associated with the continuous glucose sensor units 100a-c, including, but not limited to, wearable smart devices such as smartphones, smartwatches, and smart glasses, personal computers, tablets, and various other computing devices. Although not illustrated, the continuous glucose sensor units 100a-c include non-volatile memory for storing historical data regarding glucose values, a processor, a battery, and a wireless transmitter. The continuous glucose sensor units 100a-c include transmitters 102a-c that can provide any type of wireless communication, such as Bluetooth® connection, Wi-Fi connection, RF connection, etc., for communication with displays 104a-e and other computing devices. In some embodiments, the wireless communication occurs between paired authenticated devices and uses encryption and other cryptographic techniques to ensure, for example, that the communication remains confidential.

[0081] Although illustrated as a single unit, parts of the continuous glucose sensor unit 100a-c may be detachable from the rest of the continuous glucose sensor unit. For example, reusable electronic components of sensor units 100a-c, which may be referred to as "transmitters" such as transmitter 102 (e.g., data transmitter and / or receiver, battery, memory, or / or processor), may be detachable from the disposable parts of the sensor unit (e.g., sensor needle) and may be reused with new disposable parts. Furthermore, the continuous glucose sensor unit 100a-c may include other components to facilitate data communication. For example, the continuous glucose sensor unit 100 may include wired ports such as USB ports and Ethernet ports to communicate with other devices and provide data on glucose levels.

[0082] The continuous glucose sensor units 100a-c in Figure 1 can obtain samples at predetermined intervals such as every few seconds, every 30 seconds, every minute, every 5 minutes, or on demand in response to the occurrence of an event (e.g., a command from the user, detection of user action, e.g., user movement). The wireless transmitters 102a-c may be turned off or put into a low-power state to conserve battery life while one or more measurement results are acquired over a period of time, and then the transmitters can be woken up and wirelessly transmit one or more measurement results in batch transfer to the displays 104a-e. For example, the continuous glucose sensor units 100a-c wake up the wireless transmitters every 5 minutes, transfer data (and any other data) regarding glucose measurement results generated over the past 5 minutes, and transfer that data to the displays 104a-e. The wireless transmitters 102a-c may then be turned off again to conserve battery life. An example of data transfer every 5 minutes is provided, but it is understood that longer or shorter periods may be used, and that these periods may be set by the user via displays 104a~c.

[0083] Furthermore, in the example of Figure 1, it is understood that the continuous glucose sensor unit 100a and displays 104a-104b may be used by a first patient, the continuous glucose sensor unit 100b and displays 104c-d may be used by a second patient, the continuous glucose sensor unit 100c and display 104 may be used by a third patient, and many other patients may use the continuous glucose sensor units and associated displays. Displays 104a-e or continuous glucose sensor units 100a-c transmit data to a distributed cloud computing architecture 106, also referred to as the cloud computing infrastructure, which is described in more detail below.

[0084] The data transmitted between the continuous glucose sensor units 100a-c and the displays 104a-e may be of any data type relating to glucose value monitoring and the operation of the continuous glucose sensor units 100a-c. For example, the continuous glucose sensor units 100a-c periodically exchange calibration data with each of the displays 104a-e upon initial startup to maintain the accuracy of glucose measurement results. The user samples their glucose level using a single-point glucose meter and inputs the value displayed by the test kit into one of the displays 104a-e, which is then used to calibrate the associated continuous glucose sensor unit. Similarly, data may also be exchanged between the displays 104a-e and other physiological monitoring devices (e.g., temperature detection devices, blood pressure monitors, blood oxygen content monitors, etc.), or between the continuous glucose sensor units 100a-c and other physiological monitoring devices.

[0085] Other examples of data exchanged include current or voltage values ​​(e.g., raw values) measured by the continuous glucose sensor unit, converted glucose values ​​(e.g., calibrated or estimated glucose values) (e.g., in mg / dL units), and timestamps associated with the time each measurement result or value was sampled, alerts regarding glucose levels exceeding a predetermined threshold, defects detected by the system, firmware version, hardware versions of the continuous glucose sensor and transmitter, calibration status, times when the sensor was started and / or stopped, battery voltage, encryption information, transmitter identifier number, etc. This data may also be transmitted from a service server, such as a server associated with the manufacturer of the continuous glucose sensor unit. The continuous glucose sensor units described as 100a-c may be used in conjunction with other medical devices disclosed in the embodiments. For example, the sensor units shown in Figure 1 as continuous glucose sensor units 100a-c may be any analyte sensors, and the transmitted data may reflect analyte values ​​generated by the analyte sensor unit. Any type of data transmitted between a continuous glucose sensor unit 100a-c and a display 104a-e, or a display 104a-e and a distributed cloud computing architecture 106, or between any one of the continuous glucose sensor units 100a-c and displays 104a-e and any other physiological monitoring device or any other system, device, or person may be considered a data point.

[0086] The displays 104a-e may be computing devices comprising displays, such as visual display screens, auditory displays including speakers, tactile displays, and any other types of displays. In some embodiments, for example, the displays 104a-e may be used as dedicated displays and used with their respective continuous glucose sensor units 100a-c, where dedicated does not necessarily exclude the display of data from the continuous glucose sensor units. For example, the combination of the continuous glucose sensor unit 100 and the display 104 may, in one embodiment, be an approved medical device, such as a Class III medical device.

[0087] The display 104 includes a processor for calculating glucose levels based on received measurement results, a memory for storing glucose levels, a port for wired communication, and a wireless communication circuit, such as Bluetooth®, Wi-Fi, or an RF circuit. In the embodiment, for example, displays 104a to 104c receive glucose level data from continuous glucose sensor units 100a to 100c at predetermined time intervals. In addition, the display 104 can determine the historical trend of whether the user's glucose level is decreasing, remaining stable, or increasing. Displays 104a to 104e display glucose readings over a long period of time so that the user can easily monitor their glucose level and display the actual value of the current glucose level.

[0088] Displays 104a-e may be any type of display associated with a personal computer, tablet, or smartphone running an application for displaying data related to glucose levels. Consequently, displays 104a-e include hardware components typically associated with a personal computing device, such as a processor, memory, wireless connectivity, and USB ports.

[0089] Displays 104a to 104e can run multiple applications, such as software applications ("apps"), which include processor-executable instructions related to glucose monitoring, health information, exercise activity, insulin injection control and monitoring, and eating habits. In one embodiment, the continuous glucose sensor unit 100a transmits multiple data streams, and display 104a receives the same data that the continuous glucose sensor unit 100a transmits to display 104b. Display 104a may be a dedicated display associated with the continuous glucose sensor unit 100a, and display 104b may be a general-purpose computing device, such as a smartphone. An example smartphone may run one or more applications specifically for use with the continuous glucose sensor unit 100a, as well as other applications. The dedicated application controls the use of medical data received from the continuous glucose sensor unit 100a, such as the distribution of data to other applications running on the smartphone, thereby protecting confidentiality and user preferences, as described in more detail below. For example, the dedicated application may also connect to and provide information to other third-party applications.

[0090] In some embodiments, displays 104a-e receive and display the entire dataset received from each of the continuous glucose sensor units 100a-c. For example, display 104 displays the actual glucose level associated with the measurement results obtained by the sensor. The continuous glucose sensor unit 100, the operating system running on display 104, or a dedicated application running on (the above-mentioned) display 104 may restrict the reception and display of the actual glucose level by a third-party application. In some embodiments, instead, a third-party application may receive a more comprehensive indicator of the glucose level, such as whether the glucose level is low, normal, or high. Further details regarding the data types that can be sent to and displayed by display 104 are provided below.

[0091] The displays 104a-e or the continuous glucose sensor units 100a-c transmit data to the distributed cloud computing architecture 106. The distributed cloud computing architecture 106 organizes and stores the data and provides access to that data by other computers, applications, and third parties. The distributed cloud computing architecture 106 includes multiple different servers, storage systems, and software applications that run both locally and on a distributed network. Figure 3 provides a schematic diagram of an example embodiment of the distributed cloud computing architecture 106, which is discussed below in this patent document.

[0092] Communication within this system may be subject to several security protocols. For example, communications such as HTTPS and SSL communications may be encrypted and secured. The cloud computing architecture 106 may include a firewall that allows only specific secure communications on designated ports. In addition, a system including the distributed cloud computing architecture 106 may use authenticated sessions with login names and passwords for web service methods that users or remote monitors (as described herein) may use to gain access to, read, or modify that information. Login names and passwords may be stored securely using hashing and encryption, and patient data, including all data posts from the display, may similarly be encrypted and stored securely by the cloud computing architecture 106.

[0093] Another security measure includes using authenticated sessions that time out after a short period of inactivity and may also have a maximum length. The server may maintain an audit trail or historical log of all access to the system and all changes made to the system. In addition, third parties accessing data stored by the cloud computing architecture 106 may be required to authenticate themselves and may be further restricted to patients who are already acquainted with the third party. That is, in some examples, consumer privileges may require the consumer to already know the patient's internal identifier with the system, which would have already been provided by the patient with whom the consumer initiated any exchange of identification information.

[0094] Figure 2 illustrates an exemplary method for transmitting and storing data streams separately. Considering that a system using the disclosed technology can assist tens of thousands of continuous glucose sensor units 100, each capable of sending data through multiple displays 104, in transmitting data to a cloud computing architecture 106, there may be cases where the processing request is too large for the cloud computing architecture 106 to receive a single data stream and divide it into parts that should be assigned to different categories (e.g., public vs. private). One solution is to divide the data stream before transmission to the cloud computing architecture 106, thereby allowing the cloud computing architecture 106 to store the data stream separately and read it quickly. This may result in redundant data, but this may be preferable as it allows the cloud computing architecture 106 to compare public streams received from both, for example, a first display device and a second display device, and determine if the two match. If any discrepancies exist, technical support can determine if there is a problem with the system operation and provide a solution. For example, calibration errors in displays 104a to e can be detected by comparing data streams received from separate displays between displays 104a to e.

[0095] Another potential challenge is that servers in the distributed cloud computing architecture 106 must be able to retrieve data quickly. A large number of data streams will flow into the cloud computing architecture 106, making high-speed retrieval a critical issue. Therefore, tracking the data streams and ensuring that the data is retrieved at a given time would be advantageous.

[0096] In Figure 2, the continuous glucose sensor unit (e.g., continuous glucose sensor unit 100a) provides data to a first display (e.g., display 104a) and a second display (e.g., display 104b) in process 200, either automatically or upon request from either of these two displays. The continuous glucose sensor unit 100a divides the data into two streams: a public data stream and a private data stream. For example, public data generally includes information presented to the patient in charts or reports, such as glucose values, monitor / calibration values, time adjustments, patient event entries (e.g., meals, carbohydrates, exercise), sensor activation / deactivation times, and which transmitter was used and when, while private data generally includes information about the system and devices equipped with the system, such as battery level, screen duration, error logs, raw sensor signals, proprietary algorithm inputs / outputs, and memory stack dumps.

[0097] Public and private data may include either or both real-time data and bulk data. Bulk data may include, for example, data points, such as system software version information, diagnostic information, other proprietary data, and stored readings, such as glucose levels recorded over a period of time, such as one or two hours, while real-time data may include, for example, data points, such as monitored glucose levels, timestamps associated with monitored values, glucose monitor status, etc. Generally, real-time data is data transmitted by the continuous glucose sensor unit 100 or display 104 when it is created or immediately after it is created (for example, periodically, such as every minute, every five minutes, every ten minutes), while bulk data is data stored in the continuous glucose sensor unit 100 or display 104 for a longer period than real-time data (for example, one hour) and may be transmitted at a lower frequency than real-time data. As described in more detail below, some data (bulk or real-time, private or public) may be encrypted, while other data may not.

[0098] Furthermore, the display 104 can transmit data at different times. For example, displays 104a-e can send real-time data and bulk data to the cloud computing architecture 106. In some embodiments, both real-time data and bulk data may be sent to the cloud computing architecture 106 on a periodic basis, and each data type may have different or the same update period. For example, real-time data may be provided to the cloud computing architecture every 5 minutes, and bulk data may be provided every hour. The bulk data and real-time data transmitted from the continuous glucose sensor unit 100 to the display 104 may be the same as or different from the bulk data and real-time data transmitted from the display 104 to the cloud computing architecture 106. For example, the bulk data and real-time data transmitted from the display 104 to the cloud computing architecture 106 may include information about the interaction between the display 104 or the user and the display 104. These are merely illustrative update periods, and any period is contemplated by the embodiments disclosed herein.

[0099] In processes 202 and 204, the first display 104a and the second display 104b can send their data separately to a server in the cloud computing architecture 106. The data may include a private header, a private data section, a public header, public content, and / or metadata describing the post and the timing of the display that created the post. The first and second displays 104a-b can send the data automatically or in response to a request from the cloud computing architecture 106. Displays 104-b can also add additional data to the data received from the continuous glucose monitor 100a before sending it.

[0100] Displays 104a and 104b can send data to the cloud computing architecture 106 upon reception or after collecting data over a period of time. For example, the continuous glucose monitor 100a can provide bulk data to display 104a every hour, and display 104a can provide the bulk data to the cloud computing architecture 106 after collecting it for three hours.

[0101] In some embodiments, multiple displays 104a-b associated with the same continuous glucose monitor 100a provide data, so the cloud computing architecture 106 may receive redundant data from multiple sources. However, this data may not actually be redundant because it may differ slightly depending on when it was acquired by the displays 104. For example, one display 104a may have been out of range and therefore received backfilled data, as described below. The other display 104b may have received the data from the continuous glucose monitor 100a as scheduled. All or part of the data may be stored separately in data streams of either or both of the displays 104 and the cloud computing architecture 106. This allows the audit trail to determine when and from which device the data was sent.

[0102] Furthermore, different alerts may be configured for each display device 104a-b. For example, a user may want their phone to provide alerts during the day and their receiver display to provide alerts at night. For example, if a user misses an alert, technical support can access the data stream associated with the specific display from which the user should have received the alert and determine whether that display received the data in real time or as backfilled data because it missed one or more transmissions from the continuous glucose sensor unit. If a missed alarm arrives when the display missed a transmission, the display does not have the data to issue the alarm at that time, allowing technical support to diagnose the problem. Backfilled data can be tagged differently by the display from real-time data so that it can be distinguished to the cloud computing architecture 106. Since the tags can be in metadata format, the cloud computing architecture 106 does not need to examine the data separately to determine whether the data was acquired in real time or as backfilled data. Further examples and descriptions of data backfilling are provided below.

[0103] In process 206, the cloud computing architecture 106 stores data separately from the first display 104a and the second display 104b. The data can be stored by using metadata to provide timestamps indicating when the data was received by or posted to the cloud computing architecture 106. Thus, the cloud computing architecture 106 tracks the time when past posts were received from a particular display device. Posts may include new data or data that was previously sent, interrupted due to an error or other system anomaly, and subsequently resent. The metadata enables the displays and the cloud computing architecture 106 to track past attempted message transmissions from the displays and message transmissions received by the cloud computing architecture 106. One or more servers in the cloud computing architecture 106 do not need to examine the actual data that was sent; instead, they rely on metadata to efficiently store the information and then retrieve that information.

[0104] When new data records are created in this system, multiple other computers and services with the appropriate permissions or authorizations may be alerted about this data by requesting notifications from the cloud computing architecture 106. For example, a remote monitoring device, operable by a remote monitor user that remotely monitors the glucose status of a user of a continuous glucose sensor unit 100, can receive information about glucose levels by requesting notifications of glucose levels for a specific patient that the remote monitoring device monitors through the cloud computing architecture 106. Thus, while third-party applications can obtain public information, including glucose levels, or other information they are authorized to receive, the technical support team can also access proprietary data.

[0105] Figure 3 illustrates an exemplary embodiment of a system using the cloud computing architecture 106. Several challenges exist related to the reception and storage of large amounts of data. One such challenge is simply the volume of data. Receiving data from displays 104a and 104b on a periodic basis, such as every five minutes, places a considerable load on the server for storing the data. This can be exacerbated by thousands of additional displays associated with other patients, all of whom send data to the same server. The cloud computing architecture 106 can not only store long-term data that may be used by third parties, technical support, and other systems, but also provide high-speed access to recent data from a large number of patients. In addition, security issues arise to ensure that data is received, stored securely, and that only authorized devices can access the data. Furthermore, it may be desirable that some data be sent through displays but not accessible to the displays. One example is system diagnostic information sent from a transmitter to a server via a telephone, which may be used by technical support but is proprietary and should not be displayed to the user. For example, the system of the cloud computing architecture 106 shown in Figure 3 can allow different data to be handled differently at different access levels by different system components.

[0106] In an example embodiment shown in Figure 3, the cloud computing architecture 106 includes a service server 300 and / or a backend computer architecture 306. Displays 104a and 104b transmit data to the service server 300. The service server 300 provides functions for storing, retrieving, and coordinating notifications regarding glucose levels in the system. In one embodiment, displays 104a and 104b transmit data to the service server 300 using, for example, an HTTPS web service. The data includes, for example, glucose values, raw data, diagnostic data, and other types of information, such as exercise information or other health-related information. In some embodiments, displays 104a and 104b automatically send data to the service server 300. The data may include data from the continuous glucose sensor unit 100, as well as additional data added by the display 104.

[0107] Displays 104a-b can transmit data from two or more categories. For example, displays 104a-b can transmit both public and private data as real-time data (e.g., glucose values, event entry information, sensor activation / deactivation, and associated timestamps) and bulk data (e.g., calibration, technical support-related information, alert timing-related information), as described herein.

[0108] Real-time data may be provided, for example, every 5 minutes from the continuous glucose sensor unit 100 and / or display 104. Bulk data may be provided, for example, every hour from the continuous glucose sensor unit 100 and / or display 104. In some embodiments, bulk data may include internal system data, such as system operation data, which would typically not be provided to any third party. Real-time data points and bulk data points may be different or overlap. For example, bulk data may also include glucose values, which are also real-time data values. Data may be sent directly from one display 104, such as a smartphone, to another type of display 104, such as a personal computer or other computing device, which uploads the data to a service server 300. For example, in some embodiments, display 104a may be a smartphone or dedicated receiver device that receives data from the continuous glucose sensor unit 100a, and display 104b may be a personal computer, where the smartphone or receiver provides data to the personal computer, which uploads the data via a wired or wireless link. In other embodiments, display 104a may be a dedicated display device associated with the continuous glucose sensor unit 100a that receives data from the continuous glucose sensor unit 100a, and if it is intended to provide the data to the service server 300 or via a personal computer, it provides the data via a cradle communication device ("cradle"). For example, the dedicated display device may be installed in the cradle to connect the two devices. The cradle may include a network connection for uploading data to the service server 300. In another embodiment, display 104b is a smartphone that uploads data using an application. Real-time data and bulk data can be synchronized with the service server 300 in different ways, for example, at different time intervals, to facilitate separate storage and retrieval of real-time data and bulk data by the cloud computing architecture 106.

[0109] In one embodiment, a transmitter 102 within the continuous glucose monitor 100 can separate bulk data from real-time data. The transmitter 102 can encrypt all or part of the bulk data and send it to the service server 300 through the associated display 104 using a key stored in the transmitter 100. In some embodiments, the display 104 does not have a decryption key for the encrypted bulk data and therefore simply functions as a pass-through for the encrypted bulk data, while the shared service server 300 and backend 306 may include a decryption key for the encrypted bulk data. The transmitter 102 can also encrypt all or part of the real-time data using, for example, Bluetooth® encryption or other techniques, and the display 104 can receive the real-time data, decrypt some or all of it for use and display, and transfer the real-time data to the shared service server 300 for storage.

[0110] The service server(s) 300 stores data for a predetermined period, such as 30 days, and, together with the backend computer(s) 306, synchronizes the data with other devices, applications, and external parties. The service server(s) 300 and the backend computer(s) 306 can use different levels of security for different data types. In an example embodiment shown in Figure 3, the service server(s) 300 includes a shared service server(s) 304 and a data synchronization server(s) 302. The shared service server(s) 304 stores real-time data separately from bulk data. For example, the display can send data separately or together, and the data can be divided into real-time data and bulk data by the continuous glucose sensor unit(s) 100, the display(s) 104, or the service server(s) 300. In one embodiment, the shared service server(s) 304 stores data for only a predetermined period. For example, this enables high-speed retrieval and access to shared data and also limits the amount of data stored in the shared service server(s) 304. In some embodiments, the shared service server 304 stores only data for the past 30 days, ensuring that the data is stored only for the period during which other devices need to access it. In other embodiments, the shared service server 300 can store data for periods longer than 30 days or for periods shorter than 30 days.

[0111] The service server 300 assists in collecting data posts for each patient and each system. Clients, such as a patient display 104, a device associated with other services 318, a remote monitoring device, or other system components, then request data by specifying a particular range of data for each patient. The range of data may be based on the time the data was posted to the server. In some embodiments, each data transmission by a display may be assigned a post identifier. It may be requested to retrieve all data posts arriving after a post identifier, which can similarly be tracked by the client.

[0112] In some embodiments, the system according to an embodiment of the cloud computing architecture 106 maintains a separate record "stream" of posted information for each patient source display 104, such as a smartphone and / or receiver, for use with the continuous glucose sensor unit 100. Each post can identify the source type by indicating which display posted the data. This results in overlapping posts of patient data from multiple sources. In some embodiments, the service server 300 reduces the complexity of post display devices by storing these data post streams separately, allowing display devices to make incremental posts only for their own built-in continuous data. Consumers can then maintain or report on the differences between streams, or combine the content of the streams as desired / as needed.

[0113] An example of another device that accesses recent data through the shared service server 304 is a remote monitor 322 that receives data in real time. The remote monitor 322 is a person who monitors the glucose levels of another patient. The remote monitor 322 can monitor the patient's glucose status using a display 316 such as a smartphone, tablet, or personal computer that can communicate with the service server 300. For example, the remote monitor 322 may be a parent or guardian who accesses and monitors their child's glucose levels using a display 316a and / or 316b that can be operated by the remote monitor 322. In some embodiments, the patient's display 104a sends glucose data to the shared service server 304, and the shared service server 304 stores the glucose data for a period of time, for example, up to 30 days. The remote monitor 322's display 316a requests glucose data from the shared service server 304 by requesting and obtaining permission to access the glucose data of a specific patient.

[0114] One of the challenges that may arise with respect to the remote monitor 322 is that the storage of any identifying information of the remote monitor may be subject to interaction with government privacy laws and regulations, such as the HIPPA regulations under the Health Insurance Portability and Liability Act (HIPPA) in the United States, or other similar laws or regulations in other countries. To avoid involvement with any privacy laws or regulations, it would be preferable to avoid storing non-patient (i.e., remote monitor 322) information in the cloud computing architecture 106. Therefore, in some embodiments, the cloud computing architecture 106 does not receive or store any personal information of any remote monitor. Instead, the remote monitor 322 may be assigned a digital signature or other secure anonymous identifier 308 associated with the remote monitor 322, but the relationship is not stored in the cloud computing architecture 106. For example, the registration process for the remote monitor 322 may generate a unique number that is an anonymous identification number of the remote monitor user. Communication within the system according to an embodiment of the cloud computing architecture 106, such as between the shared service server 304 and the remote monitor display device 316a, uses an anonymous identifier 308 instead of information that would identify the remote monitor 322.

[0115] In some embodiments, the cloud computing architecture 106 includes one or more servers communicating with a backend computer architecture 306, such as a service server(s) 300. The backend server(s) 306 can receive real-time data from a shared service server(s) 304 and bulk data from a data synchronization server(s) 302. In some embodiments, the backend server(s) 306 stores historical data older than 30 days and receives requests for access to data older than 30 days through other service devices 318.

[0116] The backend server(s) 306 may function as a data warehouse capable of storing data permanently or for a long period for archiving purposes. In some embodiments, for example, a technical support unit 314 provides automated technical support to users and patients for any problems with system operation. The technical support unit 314 receives glucose data and other real-time and bulk data and can permanently store that data to assist with future technical support issues. For example, a patient can establish alerts on displays 104a, 104b when glucose levels reach a specified level or experience a specified rate of change. If an alert is not sent on display 104, and the patient misses the alert, the patient can call the technical support service center 324 to determine why the alert was not issued. Similarly, for example, a patient may have problems that are automatically addressed and / or resolved by the technical support unit 314 of the backend server(s) 306. In this regard, the technical support service center 324 may simply provide human interaction to the patient when addressing and / or resolving problems via the technical support unit 314. The technical support unit 314 can determine why the patient did not receive an alert. In one example, data may have been missed by display 104a because it was out of wireless range from the continuous glucose sensor unit 100, and therefore display 104a did not have the data that should have issued an alert. However, in such an example, the data may have been backfilled to display 104a afterward, as described in more detail below, and therefore the patient viewing display 104a would be convinced that display 104a had the data at the correct time.

[0117] For example, a backend server(s) 306, including a technical support unit 314, stores instructions on whether data was received in real time by each display 104a, 104b, or as part of a backfill process. By determining that the data in display 104a has been backfilled, the technical support unit 314 can notify the patient that their device did not have data at the relevant time when an alarm should have been issued. Similarly, a technical support service communicating with the technical support unit 314 of the backend server(s) 306 can notify the patient that their device did not have data at the relevant time when an alarm should have been issued. Thus, the cloud computing architecture in Figure 3 distinguishes data based on whether it was received in real time by a specific device, such as display 104a, display 104b, service server(s) 300, etc., or as part of a backfill process.

[0118] In the embodiment shown in Figure 3, the backend server(s) 306 also includes a product monitoring server 310 that monitors product usage, updates the continuous glucose sensor unit, and updates software on the display and other system devices. For example, the product monitoring server 310 can determine when the sensor associated with the patient's continuous glucose sensor unit 100 should be replaced and automatically send an email to the patient as a reminder to order a new sensor.

[0119] In the embodiment shown in Figure 3, the backend server(s) 306 also includes a single sign-on server 312. The single sign-on server 312 provides single sign-on to patients and users accessing several different applications and the system. For example, if the system consists of separate systems, applications, and components, the user experience may not be seamless because the user must log in to separate systems. In one illustrative example, display 104 may run an application used to monitor continuous glucose levels and an application for controlling insulin injections. The application for controlling insulin injections requests glucose information and therefore may require two or even three separate logins (a login for the application for monitoring glucose levels, a login for the application for controlling insulin injections, and a login for accessing glucose levels through the insulin injection application). This can be cumbersome for the user. One example solution to the challenges presented by the disclosed technology is to have the application for monitoring glucose levels open other applications in a web view and allow the use of single sign-on, thereby eliminating the need for the user to enter login information once and not have to re-enter it when the user is directed to other modules of the system. For example, within a continuous glucose monitoring application, icons may be provided for other applications, such as an application to view reports with more detailed statistics on glucose levels. When the user selects the icon, the application launches a web view. In this example, the web view request can provide the user with a virtually seamless experience of accessing other services by bypassing the shared service server 300 and directly accessing the server hosting the second application.

[0120] Therefore, smartphones and other displays can log in to this system through a cloud infrastructure using a single sign-on server 312. For example, a transmitter identifier may be printed on the continuous glucose sensor unit 100 and used as sign-on to correlate that particular transmitter with a particular patient. In addition, or or alternatively, for example, a user may have a login name and password, and various different encryption algorithms may be used in the authentication process.

[0121] Other services 318 may include several other services that request access to patient data. In some embodiments, other services 318 may include computer-based data services, such as databases, data management programs, and / or portals, to interface with users or computers accessing the data. As an example, a physician 320 using a computing device such as a personal computer, smartphone, or tablet may request access to patient data stored by the service server 300 through other services 318. For example, the physician may request recent and historical glucose levels to analyze whether to change insulin injection dosages and track the patient's progress between clinic visits. In one embodiment, other services 318 receive real-time data through the service server 300 for a period of time, for example, the past 30 days. Other services 318 may synchronize the data and periodically store the data through the service server 300. For example, several other applications may request data hourly, others daily, and others weekly to have data from the service server 300. For example, other services 318 may include applications that request data from both individual patients and patient classes for data analysis. If other services 318 request data that exceeds the age range stored by service server 300, the request is sent to backend server 306, which stores long-term archived bulk data and real-time data, for processing. The timing at which various components of this system can request access to bulk data and real-time data may differ. For example, the cloud computing architecture 106 may limit other services 318's access to data to once a day, allow full access at all times, or allow access at various other timeframes.

[0122] It is understood that other embodiments of the cloud computing architecture 106 in Figure 3 may include fewer or additional components. In addition, a system according to an embodiment of the cloud computing architecture 106 may include multiple cloud computing architectures such that all displays send data to a single cloud computing architecture. For example, multiple connected cloud computing architectures may be used across different geographical regions, but other arrangements are also possible to distribute the computing load.

[0123] Refer here to Figure 4, which illustrates a method for storing data in separate groups. In some embodiments, the continuous glucose sensor unit 100 and the display 104 may create and transmit different data types (e.g., real-time data and bulk data, private data and public data) that may need to be processed differently. Specifically, data such as data containing proprietary information about system operation and data that may be used to identify patients may not all be suitable for retransmission to third parties or other system components. Separating data so that it can be processed differently, including different storage locations, different policies for controlling access to the data, and different storage periods, may present some challenges. The data may include data about glucose levels, data about the functionality of the system, user-system interactions, and other data types.

[0124] In process 400, the continuous glucose sensor unit 100 prepares data, including glucose levels and other data, for transmission. The data may include, for example, measured glucose values ​​and diagnostic data. The data may include a first dataset (e.g., real-time data) and a second dataset (e.g., bulk data). The real-time data may include one or more of the following: glucose values, the current status of the continuous glucose sensor, and timestamps associated with measurement results used to obtain glucose values. The bulk data may include one or more of the following: information for calibrating the continuous glucose sensor unit 100, and information used for technical support of the continuous glucose sensor unit 100. For example, information for calibrating the continuous glucose sensor unit 100 may include the aforementioned values ​​sampled by a patient using a test kit. In some embodiments, the electronic unit of the continuous glucose sensor unit 100 (e.g., transmitter 102) prepares the data by aggregating and / or formatting the data to be transmitted into a certain form or group. For example, as described in more detail below, the continuous glucose sensor unit 100 may encrypt some or all of the data. In some embodiments, the data is prepared in a format that corresponds to datasets that can be prepared differently for each different dataset, for example, real-time data and bulk data.

[0125] In process 402, the continuous glucose sensor unit 100 transmits glucose data and other data to one or more displays 104, some of which may be encrypted. In some embodiments, each display 104 can store a decryption key to decrypt some but not all of the encrypted data, thereby controlling the patient's access to certain data types. For example, a display 104 can decrypt real-time data including glucose levels, and then generate and display a graph including current and historical glucose levels over a period such as the last hour, six hours, or a day. In some embodiments, the display 104 does not have a key to decrypt bulk data such as system diagnostic information and / or raw data values ​​in order to keep its data confidential.

[0126] In process 404, one or more displays 104 transfer data to a cloud computing architecture 106, also referred to as a cloud computing infrastructure or cloud infrastructure. Process 404 may occur automatically without user request, for example, when data is received or at a predetermined time. The displays can send different data types to the cloud computing architecture 106 at different times. In addition, the displays 104 can receive further data from the continuous glucose sensor unit 100 and add it to the data, and automatically transfer this additional data to the cloud computing architecture 106. Such additional data may include, for example, the time of an alarm, the time the data was viewed on the display, and data that is further processed by the displays 104.

[0127] In process 406, the cloud computing architecture 106 stores data in separate groups. In some embodiments, for example, a shared service server 304 may store real-time data, and a backend server 306 may store bulk data. Various components of the cloud computing architecture 106 may store decryption keys for both data groups to restrict access to certain data types. For example, a backend server 306 may store decryption keys for both real-time and bulk data, and therefore technical support (e.g., a technical support unit 314) may have access to both data types. However, other services 318 may not store decryption keys for bulk data so that other services 318 cannot access the bulk data. As a result, the cloud computing architecture 106 selectively decides whether to allow access to different data categories (e.g., a first dataset and a second dataset) by one or more requesting systems attempting to access the data categories. For example, in some embodiments, the cloud computing architecture 106 may include a table that identifies the requesting systems. A data request received by the cloud computing architecture 106 can identify the system making the request, so that the requesting system can access only a specific data category.

[0128] Herein, we refer to Figures 5 and 6, which illustrate exemplary embodiments of encryption systems and methods for encrypting data, respectively. Figures 5 and 6 provide techniques for protecting sensitive data from unauthorized access by third parties. A challenge in this area is the ability to distribute data to entities authorized to receive only a subset of the data. For example, cloud computing architecture 106 may allow service access to data that does not identify patients, but may deny service access to patient identification data or system diagnostic data. At the same time, cloud computing architecture 106 may grant full access to system diagnostic data to other entities, such as technical support, but may not necessarily grant full access to patient identification data. Various levels of security and authorization can be used to control access to data by system components, such as the techniques illustrated in Figures 4 and 5.

[0129] Conceptually, the system in Figure 5 places messages in a box locked by the transmitter 102. Only intended recipients, such as service servers 300 and / or backend servers 306, possess the key. In some embodiments, the transmitter 102 sends the message to a display 104, such as a smartphone or a dedicated receiver, and the display 104 sends the encrypted message to the service server 300. The display 104 functions as a pass-through without having the ability to decrypt all of the data.

[0130] Specifically, the transmitter 102a includes memory 500, which may be any kind of non-volatile memory capable of storing a public key 506, a private key 504, and private data 502. The public key 506 is a public encryption key, for example, a key for RSA 1024 encryption. The private key 504 is an additional private key used for another level of encryption, such as an advanced encryption standard. The private data 502 may include, for example, the aforementioned bulk data. The private key 504 may be stored in the transmitter 102a during the manufacturing process.

[0131] Transmitter 102a sends to each of displays 104a and 104b a private key 504 wrapped with a public key 506, as shown in 508, and also sends protected data wrapped with the private key 504, as shown in 510. Displays 104a and 104b do not possess the public key 506 and therefore cannot access the private key 504 or use the private key 504 to access the private data 502. Instead, the private data 502 includes data that passes through displays 104a and 104b and is sent to the service server(s) 300 for decryption. In this manner, displays 104a and 104b are restricted from accessing certain private data, while the cloud computing architecture 106 can access this data. Specifically, the backend 306 stores the private key, as shown in 514.

[0132] Although not illustrated, as described below, the transmitter 102 also transmits to the user other data that displays 104a and 104b decrypt and display. This data may include, for example, real-time data and may be encrypted according to the Bluetooth® encryption scheme and other techniques. Display 104b may be connected to a PC uploader program 512 that can run on a personal computer, tablet, or other computing device.

[0133] Referring to Figure 6, for example, corresponding methods for encrypting and transmitting data that can be implemented by device and cloud computing system architectures according to this technology are described. In process 600, transmitter 102 encrypts a first dataset. For example, transmitter 102 encrypts real-time data, including glucose values, using Bluetooth® encryption. In process 602, transmitter 102 encrypts a second dataset, such as bulk data containing proprietary information that should not be accessible by display 104. The second dataset may be encrypted using advanced encryption standards and various other techniques.

[0134] Transmitter 102 transmits a first dataset and a second dataset to display(s) 104 in process 604. Transmitter 102 transmits the first dataset and the second dataset together or at different times. For example, the first real-time dataset may be transmitted every 5 minutes, while the bulk data may be transmitted every hour. In this manner, transmitter 102 transmits these two datasets, each encrypted using a different technique, to display(s) 104 as separate data streams.

[0135] In process 606, display(s) 104 decrypts the first dataset. Display(s) 104 presents the data to the user on the user interface, uploads the data to the cloud computing architecture 106, provides the data to other applications, and stores the data in local memory. Display(s) 104 can transfer both the first and second datasets to the cloud computing architecture 106 in process 608. Process 608 occurs automatically, periodically, or in response to requests from the user or the cloud computing architecture 106 upon receiving the data. In some embodiments, each display receives the first and second datasets in different streams at different times and automatically transfers those streams to the cloud computing architecture 106 upon receipt. In this manner, the cloud computing architecture 106 receives the first and second datasets, each encrypted differently, at different times.

[0136] In process 610, the second dataset is decrypted. In one embodiment, the second dataset, or a portion thereof, may be decrypted by the cloud computing architecture 106. In another embodiment, the second dataset (or a portion thereof) may be sent to another location, such as an inulin provider, which has the key and can decrypt the second dataset. Display(s) 104 does not have the decryption key to access the second dataset, but the cloud computing architecture 106 (e.g., within the shared service server(s) 300 and / or backend server(s) 306) and / or other location (e.g., the insulin provider) contains the decryption key. In some embodiments, the cloud computing architecture 106 receives and decrypts the first dataset and provides it to both local short-term storage in the cloud service server and long-term storage in the backend.

[0137] Here, we refer to Figure 7, which illustrates an exemplary method for providing a common interface through which data can be accessed. The cloud computing architecture 106 can provide an integrated system with many different components, including third-party systems. However, in some examples, this can be problematic from a regulatory standpoint, as the entire system may have to undergo regulatory review every time a change is made to any one component. To address this problem, for example, the cloud computing architecture 106 may be configured such that each module can be considered independent from a regulatory standpoint, thereby allowing each module to undergo separate regulatory review. Specifically, the cloud computing architecture 106 can provide a set of standard application program interfaces to provide a known format for interface, allowing various components to be built and maintained separately.

[0138] Another challenge facing the cloud computing architecture 106 is how to handle numerous requests for access to data from different patients. For example, requests may arise from several different servers, computing devices, and software applications, each capable of receiving and processing various request formats and responses. If the cloud computing architecture system 106 is modified to adapt to each new type of request and response, the system may need to be recertified as a medical device, which can be a time-consuming and costly process. Therefore, the method in Figure 7 provides a common interface through which requests are received, ensuring a modular system that does not need to be modified for new types of requests.

[0139] For example, cloud computing architecture 106 uses a hub-and-spoke framework, where the hub includes rules defining what information can be accessed by each specific spoke. In this way, those spokes access only the appropriate information and / or information required by that spoke. Examples of spokes include remote monitoring applications, third-party applications, and other services.

[0140] In process 700, the cloud computing architecture 106 defines rules for controlling access to data. These rules may include user permissions, remote monitor approval processes, third-party and other software application approval processes, and rules for controlling access from the components of the cloud computing architecture 106 itself. For example, remote monitors may not need access to proprietary bulk data, while technical support may. Other examples of rules include controlling the amount of data that can be accessed and controlling the timing of when data can be accessed. Such rules may be enforced when the system is prepared for users, or they may be enforced by an administrator with the permissions and authority to set such rules in the cloud computing architecture 106. Such permissions and authority may need to comply with privacy laws and regulations.

[0141] In process 702, the cloud computing architecture 106 provides a set of application programming interfaces for accessing data. These application programming interfaces define standardized interfaces from which data requests can be received. The standardized interfaces are provided to third parties and application developers to create requests that adhere to the application programming interfaces. In process 704, a computing device or application submits a request to the cloud computing architecture 106 through one of the application programming interfaces.

[0142] Next, in process 706, the cloud computing architecture decides whether to grant the request for access to the data based on the rules defined in process 700. For example, the cloud computing architecture 106 identifies the requester and determines whether the requester should be granted access to the requested data. If the cloud computing architecture determines in process 706 that the requester should not access the requested data, then in process 708, the cloud computing architecture 106 rejects the request. If the cloud computing architecture 106 determines in process 706 that the requester should access the requested data, then in process 710, the cloud computing architecture 106 grants the request. Processes 704-710 may be performed by several different components within the cloud computing architecture. For example, requests for recent data may flow through service server 300, while requests for older, archived data may be handled by backend server 306.

[0143] Figures 8 and 9A-9D illustrate exemplary methods and system diagrams according to embodiments of the disclosed technology for processing requests from computing devices such as the display 104 to the cloud computing architecture 106. As described above, processing requests from several different servers and applications may present challenges to the cloud computing architecture 106. One solution is to provide the cloud computing architecture 106 with a common application programming interface, as shown in Figure 7. Another solution involves using an application (app) running on the display 104 to format the requests in a common format. Figures 8 and 9 provide an example of using an application running on the display 104 to format the requests in a common format.

[0144] Referring to Figure 8, the display 104 includes a continuous glucose monitoring application 800 and several other applications 802a, 802b. The continuous glucose monitoring (CGM) application 800 may be an application designed to interface with both the transmitter 102 of the continuous glucose sensor unit 100 and the cloud computing architecture 106. Applications 802a, 802b provide data requests 804 to the CGM application 800, and the CGM application 800 may include rule logic, as described above in relation to Figure 7, for determining whether the data requests of applications 802a, 802b in the request should be allowed.

[0145] If the request should be permitted and the data is to be stored locally, the CGM application 800 provides a data response as shown in 810. In some embodiments, the CGM application 800 forwards the data request 806 to the cloud computing architecture 106, which determines whether to permit the request using the technique described in Figure 7. If the request should be permitted, the cloud computing architecture 106 sends a data response 808 to the CGM application 800, which then forwards the data response 810 to the requesting application 802a or 802b.

[0146] Figure 9A illustrates an exemplary embodiment of the user interface of a CGM application 800 running on display 104. The CGM application 800 displays glucose level information on 904, including charts of recent glucose levels, current glucose levels (e.g., 86 mg / dL), and trend patterns (e.g., rising, stable, or falling). In some embodiments, the CGM application 800 displays icons 900 and 902 as links to other applications, such as applications 802a and 802b shown in Figure 8. In this example, icon 900 links to an exercise application, and icon 902 links to an insulin application. These links within the CGM application 800 allow the user to log in to multiple applications using a single login, as described above with respect to single sign-on 312 in Figure 3. In addition, these links can provide the user with a convenient way to access other information stored by different applications related to glucose levels and trends, whether from the same or different manufacturers.

[0147] Figure 9B illustrates an exemplary embodiment of a system using a cloud server architecture 106 to perform an aspect of the technology described. In this illustration, the display 104a includes a smartphone running an application such as the CGM application 800 described in relation to Figure 8. In other examples, the display 104a may be a computing device, such as a laptop computer, desktop computer, tablet, PDA, or wearable computing device. For example, the display 104a communicates with the continuous glucose sensor unit 100. The display 104a may communicate wirelessly with the continuous glucose sensor unit 100, or it may be connected to the continuous glucose sensor unit 100 via a wired or optical cable.

[0148] The display 104a can receive multiple data types from the continuous glucose sensor unit 100 and transmit these data types to a cloud server architecture 910, which is an example embodiment of the cloud computing architecture 106. The data transmitted from the display 104a to the cloud server architecture 910 may be transmitted at different times based on the classification assigned to the data. The data may be classified as real-time data and bulk data. Real-time data may be transmitted from the display 104a to the cloud server architecture 910 at a higher frequency, such as every minute, every 5 minutes, or every 10 minutes, while bulk data may be transmitted from the display 104a to the cloud server architecture 910 at a relatively lower frequency than real-time data, such as every 30 minutes, every hour, or every 2 hours.

[0149] In the case of real-time information, data transmitted from the continuous glucose sensor unit 100 is received by the display 104a and sent to the real-time server 908, which is included as part of the cloud server architecture 910. The real-time information includes one or more of the following: estimated glucose values ​​(EGV) (multiple), glucose concentration change rate information, CGM alert information, raw sensor data, and / or other types of public or private data discussed herein. Real-time data differs from bulk data because it may be necessary to take immediate or timely action based on the real-time data. Furthermore, the real-time server 908 is configured to process large amounts of real-time data rapidly. For example, the glucose monitoring system may have up to 150,000 or more users, and each user may transmit up to 288 values ​​per day from their respective display 104a to the real-time server 908.

[0150] Due to the volume and frequency of data to be managed by the real-time server 908, a locator service may be used in some cases. An example of a locator service and associated data and control flow is shown in Figure 9C. At the start of an application session, a client application running on a smartphone, such as the aforementioned CGM application 800, calls the locator service (launched, for example, on the real-time server 908) and receives a URL to use for subsequent calls. Input parameters typically include the application name, application version, and country code. The locator service uses these parameters to determine where to go for all other services (hence the term "locator"). This approach provides the real-time server 908's ability to scale out without requiring application changes and the server's ability to provide different service embodiments for different application revisions or countries. Existing applications that do not use the locator service continue to function. The locator service includes logic for determining where to dynamically send application requests.

[0151] Referring again to Figure 9B, information can be transmitted from the real-time server 908 to the remote monitor 316b using various mechanisms. The remote monitor 316b may be a device such as a smartphone running an application (app) such as a remote monitoring app, which is designed to display to the remote monitor user at least some of the data associated with glucose data from the CGM application 800 described in relation to Figure 8. For example, in one example, at least some, but not all, of the real-time information is pushed from the real-time server 908 to one or more remote monitors 316b. The real-time information may be sent to the remote monitor 316b on a periodic basis, such as every 30 seconds, every minute, every 2 minutes, every 5 minutes, every 10 minutes, etc. In some embodiments, the real-time server 908 can monitor the real-time information for trends and tendencies and make the remote monitor 316b aware of the trends. When data is pushed to the remote monitor 316b, the remote monitor 316b may request that the remote monitoring application on the device 316b be opened and launched. If the remote monitoring application is not open and launched on the remote monitor 316b, the data is queued at the real-time server 908. In some embodiments, when the remote monitoring application is opened on the remote monitor 316b, data is automatically pushed to the remote monitor 316b. In some embodiments, when the remote monitoring application is opened on the remote monitor 316b, the user is notified that data is awaiting. Subsequently, for example, using the remote monitoring application, the user of the remote monitor can request that data be sent from the real-time server 908 to the remote monitor 316b. In some embodiments, if the remote monitoring application is not open and running on the remote monitor 316b, a notification such as a text message (e.g., SMS or MMS) is sent from the real-time server 908 to the remote monitor 316b because the remote monitor 316b does not have real-time data available to trigger an alert on its own when the remote monitoring application is closed (e.g., in the background of an iPhone®).

[0152] In some embodiments, the real-time server 908 interfaces with a remote monitoring application on the remote monitor 316b and wakes up the remote monitoring application. Once the remote monitoring application is woken up, it requests data from the real-time server 908.

[0153] The remote monitor 316b is authorized to access certain information from the real-time server 908. This information is limited to one or more specified continuous glucose sensor units 100 and their respective displays 104 (e.g., operating CGMapp 800). The remote monitor 316b is not authorized to access data. In some embodiments, the remote monitor 316b can send a request to the real-time server 908, and data associated with at least one of the one or more continuous glucose sensor units 100 and their respective displays 104 that the remote monitor 316b is authorized to read is sent to the remote monitor 316b after the request. In some embodiments, the remote monitor 316b may be a smartphone. In some embodiments, the real-time server 908 may include a Class II device as defined by the U.S. Food and Drug Administration (FDA), and the data is processed according to its classification.

[0154] In some embodiments, the cloud server architecture 910 further includes a bulk data collector (BDC) 912 and a bulk data distributor (BDD) 914. In some embodiments, the BDC 912 and BDD 914 are data processing engines operating on one or more computers, e.g., servers, communicating with each other. In some embodiments, the display 104a sends the bulk data (as described herein) to the BDC 912 on an intermittent basis. For example, the display 104a may send the bulk data from the display 104a to the BDC 912 every hour. In some embodiments, the bulk data is uploaded from the continuous glucose sensor unit 100 to a computer 916, e.g., a personal computer. At least a portion of the bulk data is then sent from the computer 916 to the BDC 912. As described above, the data may be sent from the computer 916 to the BDC 912 on a periodic basis. For example, the data may be sent from the computer 916 to the BDC 912 every hour. Data transmitted to the BDC912 may include private and public data (as described herein). In some embodiments, the BDC912 may include a Class II device as defined by the U.S. Food and Drug Administration (FDA), and the data will be processed according to its classification.

[0155] As described above, the cloud server architecture 910 also includes a BDD 914. The BDD 914 provides fan-out capability for data received from the BDC 912. For example, at least a portion of the data from the BDC 912 may be provided to one or more of the technical support tools 922 and the long-term data warehouse 918. Warehouse data may include public and private data. The technical support tools 922 may include, for example, sharing support tools, repository tools, and transmitter tools. The sharing support tools (tools that provide technical support-related insights to the display 104a and remote monitor 316b) include the ability to present data tables and data charts sent from the display 104a (automatically) and the continuous glucose sensor unit 100 (on demand by the user). In some embodiments, a data table can present all data sent from the display 104a and the continuous glucose sensor unit 100 to a data server (real-time server 908 or bulk data collector 912), categorized by data type (e.g., EGV data, logs, etc.) and data source (display 104a or continuous glucose sensor unit 100). In some embodiments, a data chart presents the data from the table in a visual form in chronological order. The data source may be identified within the chart. The repository tool supports data visualization of the data from the display 104a and the continuous glucose sensor unit 100 as data tables and data charts. The repository tool includes support for data visualization of the continuous glucose sensor unit 100. For example, if a user returns a receiver for investigation, the receiver can be downloaded using this tool to further investigate the complaint internally.

[0156] At least some of the data from BDD914 may be provided to Repository 920 for analysis and / or reporting. This information is generally referred to as retrospective data. Retrospective data can generally be defined as bulk data and any real-time data generated in the past. For example, real-time data not generated within the last 5 minutes may be considered retrospective data. In some embodiments, BDD914 may include Class II devices as defined by the FDA, and the data will be processed according to that classification.

[0157] Generally, access to the data shown in Figure 9B is controlled. For example, an authorization manager (not shown in Figure 9B) is used to control third-party access to the BDD 914, retrospective data 920, and data warehouse 918. In some embodiments, the authorization manager may be token-based. Access to certain data may be permitted or restricted based on a token held by the third party during access. Optionally, or otherwise, a patient may grant a third party access to information about that particular patient. For example, an adult patient may provide remote monitoring 316b. Based on the response from the third party, the token may be customized to the third party's authority. In some embodiments, a third party may access certain information (e.g., data about a particular patient) by using logins to social media websites such as Google, Facebook, or Twitter.

[0158] Figure 9D is a flowchart illustrating a method for securely collecting, analyzing, and reporting data on glucose monitoring levels using multiple continuous glucose monitors. In process 9002, data is received from multiple continuous glucose monitors (CGMs), e.g., continuous glucose sensor units 100, by multiple display devices (e.g., displays 104). In process 9004, the data is classified into multiple categories based on data type. In some embodiments, the classification of data into multiple categories based on data type includes classifying the data as real-time data and bulk data. In some embodiments, the display 104 classifies the received data into multiple categories based on data type, while in other embodiments, the continuous glucose sensor unit 100 performs process 9004 before process 9002 to classify the data into multiple categories based on data type. In such embodiments, the continuous glucose sensor unit 100 can classify only a portion of the data, so the display 104 can classify the received unclassified data and / or reclassify the received classified data.

[0159] In process 9006, classified data is transmitted from multiple display devices to a cloud server architecture according to this technology, for example, cloud server architecture 106. The cloud server architecture 106 includes at least multiple servers that intermittently receive data from multiple display devices, such as a system according to cloud server architecture 910. The multiple servers of the cloud server architecture may include at least one real-time server and a bulk data collector, for example, real-time server 908 and BCC912, respectively. In some embodiments, the cloud server architecture may further include a locator service, and the multiple display devices connect to the cloud server architecture through the locator service. The data routed to a particular server among the multiple servers is determined by the data type, and the intermittent basis or transmission from display devices to the server may differ depending on the data type. For example, real-time data is routed from multiple display devices to the real-time server, and bulk data is routed from multiple display devices to the bulk data collector. Real-time data may be routed from multiple display devices to the real-time server on a more frequent intermittent basis than bulk data is routed on an intermittent basis from multiple display devices to the bulk data collector. For example, real-time data is routed from multiple display devices to a real-time server every 5 minutes, and bulk data is routed from multiple display devices to a bulk data collector every hour.

[0160] In process 9008, data is received by multiple remote monitoring display devices (e.g., remote monitor 316b) from one of multiple servers, e.g., real-time server 908. The data sent to each of the multiple remote monitoring display devices may depend on the data type and the display device that sent the data to one of the multiple servers. In some embodiments of process 9008, the data is sent to the multiple remote monitoring display devices immediately after being received by one of the multiple servers of the cloud server architecture. On the other hand, in some embodiments of process 9008, the cloud server architecture (e.g., real-time server 908) processes the data according to rules associated with each remote monitor 316 and sends the data according to the rules to the respective remote monitoring devices. In process 9010, at least a portion of the data received by the multiple servers is routed to the analysis and reporting engine. In some embodiments of process 9010, the BDD 914 of the cloud server architecture provides at least a portion of the data to one or more of the technical support tools 922, the data warehouse 918, and / or repositories 920. The data is analyzed, and a report is generated by the analysis and reporting engine.

[0161] Backfill Figure 10 illustrates an exemplary method for backfilling data. One challenge that may arise when providing data to multiple displays and distributed cloud computing architectures is ensuring that each application or device contains the most up-to-date data. For example, a user may turn off an application, such as a CGM application 800, so that an application running on a display device (e.g., display 104) does not receive data. Alternatively, the display may be turned off. Even if the display is on and has received data, it may be turned off or disconnected from the network when the display has successfully transferred the data to the cloud computing architecture. If an application or device does not receive data, the data is not up-to-date. Figures 10 and 11 describe exemplary methods that allow data to be backfilled into an application to keep it up-to-date. Up-to-date may mean that the application or server has all available data.

[0162] Further challenges arise regarding the use of multiple data streams in the overall system described herein. For example, real-time data streams and bulk data streams may be sent separately to multiple displays 104 by a continuous glucose sensor unit 100 that transfers those data streams to a cloud computing architecture 106. The cloud computing architecture 106 receives multiple copies of the data streams from different displays connected to a common continuous glucose monitor and stores them separately. For example, due to the ability of displays to add different calibration values ​​and their own additional data to the data stream, there may also be some differences in the data streams depending on which display transfers the data to the cloud computing architecture 106.

[0163] Another challenge may arise regarding whether the user can distinguish whether the data was acquired at the scheduled time ("scheduled data") or acquired as part of a backfill process. Therefore, the user interface can display the data differently depending on whether it was acquired on schedule or backfilled. For example, backfilled data may be displayed differently. In one non-limiting example, as shown in Figure 12B, backfilled data may be indicated using a dashed line 1204 on a line indicating glucose levels. Another way to indicate backfilled data to distinguish it from scheduled data is to use line segments of different colors for backfilled data and scheduled data. Referring to Figures 12A and 12B, in some embodiments, the display 104 may have an orientation sensor, such as one available in a smartphone, so that in portrait view 1200, backfilled data points are displayed the same as real-time data points, but when the display is oriented to landscape mode 1202, the backfilled data may be displayed differently. For example, a summary or condensed version of the data may be displayed in portrait view 1200, but when oriented to landscape mode 1202, further details may be displayed.

[0164] Returning to Figure 10, in process 1000, a continuous glucose monitor (e.g., continuous glucose sensor unit 100) transmits data. The data may include both real-time data and bulk data, which can be encrypted as described above. The glucose values ​​are time-stamped to track when the continuous glucose monitor sampled the glucose levels and to facilitate checks to ensure that various system components have complete datasets containing all glucose samples.

[0165] In some embodiments, the continuous glucose monitor transmits data periodically, for example, every 5 minutes, allowing the monitor and associated transmitter to be kept in a low-power state to conserve battery life. In other embodiments, the continuous glucose monitor transmits data at intervals other than 5 minutes. Both real-time data and bulk data may be transmitted within each period, or real-time data may be transmitted every 5 minutes while bulk data is transmitted at a lower frequency, such as every hour.

[0166] Next, in process 1002, display devices (multiple) communicating with a continuous glucose monitor such as display(s) 104 distribute the received data, which may include both real-time data and bulk data. The display(s) distribute the data to a cloud computing architecture 106, which may include both short-term storage (e.g., up to 30 days) in a service server 300, etc., and long-term storage in a backend server 306, etc. The display can distribute real-time data and bulk data to the cloud computing architecture 106 as separate data streams.

[0167] Next, in process 1004, components of the data communication ecosystem using this technology can identify missing data. Because the data stream is distributed throughout the system, it is possible that one or more components that should have received the data during distribution may not receive it. For example, a display may be out of wireless range from a continuous glucose monitor, or the network connection within the cloud computing architecture may be down. In some embodiments, computing devices such as servers within the cloud infrastructure may be down or undergoing maintenance, and therefore may not receive the data when it is distributed.

[0168] Various components of this system can determine if any data is missing. For example, the display 104 itself can determine if any real-time data is missing by examining a timestamp associated with a glucose value or other marker indicating the order of the data (e.g., each glucose value is associated with a sequentially numbered value). If there is a gap in the timestamp or other marker, for example, if glucose values ​​were not received for 15 minutes, even though glucose values ​​were expected to be received every 5 minutes from the continuous glucose sensor unit 100, the display 104 will identify the data as missing. Similarly, a cloud computing architecture 106, including, for example, a service server(s) 300 and a backend server(s) 306, can determine if any data is missing by examining a timestamp or other marker. In addition, a third-party application can determine if any data is missing. In some embodiments, a data synchronization server 302 can determine if any display 104, service server(s) 300, or backend server(s) 306 is missing data. In this way, the cloud computing architecture 106 can determine whether each component with missing data should backfill the missing data.

[0169] Process 1006 determines whether a component that identifies data as missing will retrieve that data. There may be a maximum time limit for data backfilling. For example, data that has been missing for more than the past 6 hours may not be backfilled to the display 104, which has missed many transmissions from the continuous glucose sensor unit 100. Other components of the system, such as the backend server(s) 306, may, in some embodiments, backfill all missing data without time limits. Similarly, components of the ecosystem, such as the display 104, may backfill only certain data categories after a certain period of time has elapsed (e.g., 6 hours), while not backfilling others. Furthermore, the backfill period may be less than the period during which data may not have been available. For example, bulk data may be backfilled even after a 6-hour window of data loss, while real-time data may not be backfilled. Furthermore, the backfill period may be less than the period during which data may not have been available. For example, data may have been unavailable to the display for the past 6 hours, and when data becomes available, the display may backfill only the missing data from the past 2 hours, rather than the entire 6 hours. In another example, display 104 may be out of touch for an extended period (e.g., 6 hours), but the display may backfill only a subset of that time (e.g., 2 hours) within a given period to conserve resources (e.g., battery life) of the system's components. After a certain period of time, some of the data may be outdated for a particular component of the system, and backfilling may consume too much battery power for one or more components of the system (e.g., transmitter 102), and / or a component of the system requesting the backfilled data (e.g., display 104) may be configured to display only a specific range of data, such as the past 6 hours, and to backfill beyond a range that may be unnecessary, so a decision may be made to backfill the data.By selectively backfilling data, the need for computers and memory can also be reduced.

[0170] If a component determines that it should not acquire missing data, the method in Figure 10 can return to identifying any additional missing data. For example, display 104 may determine that it has missed data for 10 consecutive hours. In this example, display 104 may determine that it will not acquire data older than the last 6 hours, or the transmitter 102 of the continuous glucose sensor unit 100 may have only stored data from the last 6 hours, and process 1004 returns to identifying any further missing data within the last 6 hours.

[0171] If missing data should be retrieved, in process 1008, the component backfills the missing data. In some embodiments, the component backfills from the oldest available data (or the oldest desired period) to the most recent period. In other embodiments, the component backfills from the most recent data to the oldest data. The process of backfilling missing data can occur with respect to individual streams, such as real-time data or bulk data, or both streams. For example, display 104 can request missing data from either the continuous glucose sensor unit 100 or the service server(s) 300. The service server(s) 300 may also have missing data, and in some embodiments, it may receive, for example, four data streams associated with a single continuous glucose sensor unit 100. The continuous glucose sensor unit 100 sends the real-time data stream and the bulk data stream to each connected display, such as two displays, resulting in four streams. Other components within the cloud computing architecture 106, such as the service server(s) 300 and the backend server(s) 306, can store not only the indication of which continuous glucose sensor unit(s) 100 sent the data, but also the indication of which display sent the data. In this manner, the components of the cloud computing architecture 106 can store separate data streams (e.g., real-time and bulk) for each display. This is helpful for troubleshooting technical support issues by the backend server(s) 306. When a system component receives backfilled data, it also stores an indication that the data was backfilled rather than received during the initial distribution. This is also helpful for diagnostic issues, such as when the aforementioned alarms are missed.

[0172] In addition, the storage of multiple data streams from multiple displays associated with a single continuous glucose sensor unit 100 enables the cloud computing architecture 106 to authenticate the data streams with each other. For example, a real-time data stream from a first display can be compared with a real-time data stream from a second display, and any differences may be pointed out. These differences may indicate that the two displays are not using the same calibration values ​​or that there is another system problem. Upon detection of any differences, a prompt will be displayed to the user on either display, for example, a prompt to update the calibration values. The comparison of the two streams also allows for confirmation that the data is being effectively captured by both displays.

[0173] Figure 11 illustrates another exemplary method for backfilling missing data. In some cases, the amount of data to be backfilled should be limited. For example, a user may turn off their display 104 for an extended period (e.g., turn off their smartphone) or replace their smartphone. However, if the user has owned their continuous glucose monitor (e.g., continuous glucose sensor unit 100) for an extended period, backfilling all previous data would conges the system and be unnecessary. As a result, the method in Figure 11 searches for any missing data within a specified time interval up to the longest possible time, for example, 1 day, 12 hours, 6 hours, 1 hour, 30 minutes, 10 minutes, 5 minutes, 1 minute, etc.

[0174] In process 1100, a system component searches for missing data within a first time interval. As described above, any system component, such as the display 104, service server(s) 300, backend server(s) 306, 316, or other remote monitoring displays, can search for any missing data. The first time interval may vary depending on the device searching for the missing data. For example, a user's computing device such as the display 104 may have a relatively limited amount of memory compared to a server. The display 104 may search to backfill missing data within an interval of 6 to 24 hours, while the service server 300 may search for missing data going back to the most recent 30 days. In some embodiments, the display 104 may automatically send backfill data when it receives backfill data, but the display may need to request data from the transmitter 102 of the continuous glucose sensor unit 100. This may be because the transmitter 102 may have a more limited power source (e.g., battery) than the display 104. In process 1102, the system components backfill any missing data found during the first time interval described above.

[0175] Next, in process 1104, the system components search for missing data within additional time intervals. Following the example above, display 104 searches for missing data within the last 6 hours and can backfill any missing data by requesting it from the continuous glucose sensor unit 100. The display then searches for missing data within additional time intervals, such as another 6 hours. Needless to say, other time intervals can also be used. The most recent time interval may be the first time interval from which data starting from the most recent is backfilled, or the search may start from the oldest period and search for newer data that may have been missed. In process 1106, the components backfill any missing data from additional time intervals.

[0176] In process 1108, the system component determines whether the maximum interval has been reached. For example, if display 104 has already explored for the past 24 hours, display 104 stops exploring in process 1110. However, if there is an additional time interval until the maximum interval for which a particular component should explore, process 1104 continues to repeatedly explore for data to be backfilled.

[0177] In addition, the backfill techniques disclosed herein are applicable to various system components and applications. One of the challenges that may arise is the provision and backfilling of data to a remote monitoring application or remote monitoring device. Real-time data can reach the remote monitoring device, but the remote monitoring device may be offline or out of wireless range. The remote monitor can set up alerts to be triggered when a patient's glucose level exceeds a specified level, such as over 200 mg / dL, for a certain period, such as one hour. If data points do not arrive consecutively at the remote monitoring device, it is not possible to track or issue alarms. Furthermore, if only 30 minutes of data is backfilled when the device comes back online, this does not meet the alarm criteria, as the exemplary alarm depends on one hour of data. To address this problem, the remote monitoring device may backfill within the aforementioned specified time range, such as six hours. In one embodiment, the data may be sent to the remote monitoring application in chronological order from oldest to newest. In some embodiments, a server(s) of the cloud computing architecture 106, such as a real-time server 908 or a service server 300, initiates an alert to send to a remote monitoring device, such as a remote monitor 316b, indicating that backfilled data is being provided. The data provided to the remote monitoring device as backfilled data may appear on the remote monitoring device's display differently from the data provided in its normal cycle. This helps the remote monitoring device understand whether or not a certain action should be taken based on the backfilled data. As described above, remote monitoring settings can be configured through a server (e.g., real-time server 908 or service server 300). In one illustrative example, the remote monitor may not want to know that an adult or person in charge "decreased in level" six hours before the adult or person in charge is thought to have taken action on their own to improve the situation.Therefore, the remote monitoring device can configure the data sent in the backfill so that, for example, old data is not displayed, the backfill period is defined, the backfill is defined in the order from newest to oldest or oldest to newest, or certain data points are not backfilled.

[0178] Generally, data is backfilled in order from oldest to newest (most recent). This can cause some confusion with alarms when the oldest data begins to be backfilled, and an alarm state may exist. For example, glucose levels may fall to an alarm level after a certain period of time, or remain at a level that triggers an alarm. However, this state may have occurred, for example, four hours earlier, when the display that started receiving backfill data was not receiving real-time data. Instead of triggering an alarm on display 104 or the remote monitoring device 316 for remote monitoring, the server may be configured to continue backfilling data and decide whether the alarm state clears itself. Alternatively, servers in the cloud computing architecture 106 (e.g., real-time server 908 or service server 300) may be configured so that old backfilled alarms are not triggered unless there is a rule instructing the server associated with a particular display to trigger them. For example, the person being monitored could be a child, in which case the remote monitor (e.g., a parent) might want to know that the child experienced an alarm condition, even if the condition occurred in the past and has already been corrected on their own. Thus, the parent's monitoring device (e.g., display 316) may be triggered for an alarm even if the condition occurred several hours ago. The remote monitor display 316a may also be configured to indicate that the alarm is based on backfill data rather than current data.

[0179] Figure 13 illustrates an exemplary computer. The computing devices of the cloud computing architecture 106, including the continuous glucose sensor unit 100, the display 104, and associated servers, as well as other system components, may include all or some of the components shown in Figure 13.

[0180] A computer may include one or more hardware components, such as a central processing unit (CPU) 1321, a random access memory (RAM) module 1322, a read-only memory (ROM) module 1323, a storage device 1324, a database 1325, one or more input / output (I / O) devices 1326, and an interface 1327. Alternatively, or in addition, a computer may include one or more software components, such as a computer-readable medium containing computer-executable instructions for performing methods relating to the exemplary embodiments. It is intended that one or more of the hardware components listed above may be implemented using software. For example, storage device 1324 may include a software partition associated with one or more other hardware components. It is understood that the components listed above are illustrative and not intended to be limiting.

[0181] The CPU 1321 may include one or more processors, each configured to execute instructions and process data to perform one or more computer-associated functions for monitoring glucose levels. The CPU 1321 may be communicatively connected to RAM 1322, ROM 1323, storage device 1324, database 1325, I / O device 1326, and interface 1327. The CPU 1321 may be configured to perform various processes by executing a set of computer program instructions. Computer program instructions may be loaded into RAM 1322 for execution by the CPU 1321.

[0182] RAM1322 and ROM1323 may each include one or more devices for storing information associated with the operation of CPU1321. For example, ROM1323 may include a memory device configured to access and store controller-related information, including information for identifying, initializing, and monitoring the operation of one or more components and subsystems. RAM1322 may include a memory device for storing data associated with one or more operations of CPU1321. For example, ROM1323 may load instructions into RAM1322 for execution by CPU1321.

[0183] The storage device 1324 may include any type of mass storage device configured to store information that the CPU 1321 may need to perform processes according to the disclosed embodiments. For example, the storage device 1324 may include one or more magnetic and / or optical disk devices, e.g., hard drives, CD-ROMs, DVD-ROMs, or any other type of mass media device.

[0184] Database 1325 may include one or more software and / or hardware components that cooperate to store, organize, sort, filter, and / or arrange data used by CPU 1321. For example, database 1325 may obtain data on glucose levels, associated metadata, and health information monitoring. It is intended that database 1325 may store further and / or information other than those listed above.

[0185] The I / O device 1326 may include one or more components configured to communicate information with a user associated with the controller. For example, the I / O device may include a console with an integrated keyboard and mouse to enable the user to maintain an image database, update associations, and access digital content. The I / O device 1326 may also include a display with a graphical user interface (GUI) for outputting information to a monitor. The I / O device 1326 may also include peripheral devices, such as a printer for printing information associated with the controller, a user-accessible disk drive (e.g., a USB port, floppy, CD-ROM, or DVD-ROM drive) to enable the user to input data stored on a portable media device, a microphone, a speaker system, or any other suitable type of interface device.

[0186] Interface 1327 may include one or more components configured to transmit and receive data over a communication network, such as the Internet, a local area network, a workstation peer-to-peer network, a direct link network, a wireless network, or any other suitable communication platform. For example, Interface 1327 may include one or more modulators, demodulators, multiplexers, demultiplexers, network communication devices, wireless devices, antennas, modems, and any other types of devices configured to enable data communication over a communication network.

[0187] Examples

[0188] The following embodiments illustrate some of the embodiments of the Art. Other exemplary embodiments of the Art may be presented before the following fist embodiment or after the following listed embodiments.

[0189] In some embodiments of this technology (Example 1), a method for securely transmitting glucose level data includes: preparing data containing glucose levels using a continuous glucose monitor; wirelessly transmitting glucose level data from a transmitter associated with the continuous glucose monitor to at least one display device; automatically transferring glucose level data from the display device to a cloud computing architecture; and storing glucose level data in a separate group within the cloud infrastructure.

[0190] Example 2 includes the method of Example 1, wherein the data relating to glucose levels includes measured glucose values ​​and diagnostic data.

[0191] Example 3 further includes the method of Example 1, wherein the display device includes additional data along with glucose level data, and automatic data transfer includes automatically transferring the additional data and glucose level data.

[0192] Example 4 includes the method of Example 1, wherein the glucose level data comprises a first dataset and a second dataset, and the storage of glucose level data into separate groups includes storing the first dataset on a first server and the second dataset on a second server.

[0193] Example 5 includes the method of Example 4, wherein the first dataset includes real-time data, the real-time data includes one or more of the following: glucose value, current status of a continuous glucose sensor, and timestamp associated with measurement results used to obtain the glucose value, and the second dataset includes at least one of the following: information for calibrating a continuous glucose monitor and information used for technical support of a continuous glucose monitor.

[0194] Embodiment 6 further includes the method of Embodiment 5, comprising: encrypting a first dataset with a transmitter; encrypting a second dataset with a transmitter; decrypting and displaying the first dataset with at least one display device; preventing at least one display device from decrypting the second dataset; and decrypting the second dataset with a cloud infrastructure.

[0195] Embodiment 7 further includes the method of Embodiment 6, which also includes storing a first key for decrypting a first dataset using at least one display device, storing a second key for decrypting a second dataset using a cloud infrastructure, and preventing at least one display device from accessing the second key.

[0196] Example 8 further includes transferring a subset of glucose level data from a cloud infrastructure to a second display device, wherein the subset of data includes at least one of current glucose levels and historical glucose levels, and comprises the method of Example 1.

[0197] Example 9 includes the method of Example 1, further comprising the cloud infrastructure selectively deciding whether to allow one or more requesting systems to access the first and second datasets.

[0198] Example 10 includes the method of Example 9, wherein the requesting system includes a technical support system, at least one third-party application, and a data warehouse, and the cloud infrastructure grants the technical support system access to a first dataset and a second dataset, grants the at least one third-party application access to the first dataset, and grants the data warehouse access to the first dataset and the second dataset.

[0199] Example 11 includes the method of Example 1, wherein the display device includes at least one of a smartphone or a display.

[0200] In some embodiments of this technology (Example 12), a system for monitoring glucose level data includes a continuous glucose sensor configured to prepare glucose level data, a wireless transmitter configured to transmit glucose level data, a display device configured to receive transmitted glucose level data and automatically transfer the data, and a cloud computing architecture configured to receive automatically transferred data and store glucose level data in separate groups.

[0201] Example 13 includes the system of Example 12, wherein data regarding glucose levels includes measured glucose values ​​and diagnostic data.

[0202] Example 14 includes the system of Example 12, wherein the display device includes additional data along with glucose level data, and is further configured to automatically transfer the additional data and glucose level data.

[0203] Example 15 includes the system of Example 12, wherein the glucose level data comprises a first dataset and a second dataset, and the storage of glucose level data into separate groups includes storing the first dataset on a first server and the second dataset on a second server separately.

[0204] Example 16 includes the system of Example 15, wherein the first dataset includes real-time data, the real-time data includes one or more of the following: glucose value, current status of the continuous glucose sensor, and timestamp associated with the measurement result used to obtain the glucose value, and the second dataset includes at least one of the following: information for calibrating the continuous glucose monitor and information used for technical support of the continuous glucose monitor.

[0205] Embodiment 17 includes the system of Embodiment 16, wherein the transmitter is further configured to encrypt a first dataset and a second dataset, at least one display device is further configured to decrypt and display the first dataset, at least one display device is unable to decrypt the second dataset, and the cloud infrastructure is further configured to decrypt the second dataset.

[0206] Embodiment 18 further includes the system of Embodiment 17, wherein at least one display device is further configured to store a first key for decrypting a first dataset, and a cloud infrastructure is further configured to store a second key for decrypting a second dataset, and at least one display device cannot access the second key.

[0207] Example 19 further includes the system of Example 12, wherein the cloud infrastructure is configured to transfer a subset of glucose level data to a second display device, and the subset of data includes at least one of current glucose levels and historical glucose levels.

[0208] Example 20 includes the system of Example 12, further configured so that the cloud infrastructure selectively decides whether to allow one or more requesting systems to access the first and second datasets.

[0209] Example 21 includes the system of Example 20, wherein the requesting system includes a technical support system, at least one third-party application, and a data warehouse, and the cloud infrastructure is further configured to allow the technical support system access to a first dataset and a second dataset, to allow at least one third-party application access to the first dataset, and to allow the data warehouse access to the first dataset and the second dataset.

[0210] Example 22 includes the system of Example 12, wherein the display device includes at least one of a smartphone or a display.

[0211] In some embodiments of the present technology (Example 23), one or more computer-readable media include instructions that, when executed by one or more processors, perform a method for securely transmitting glucose level data, which includes: preparing glucose level data using a continuous glucose monitor; wirelessly transmitting glucose level data from a transmitter associated with the continuous glucose monitor to at least one display device; automatically transferring glucose level data from the display device to a cloud computing architecture; and storing glucose level data in a separate group within the cloud infrastructure.

[0212] Example 24 includes the computer-readable medium of Example 23, which contains glucose level data including measured glucose values ​​and diagnostic data.

[0213] Example 25 further includes the computer-readable medium of Example 23, wherein the method includes additional data along with glucose level data by a display device, and automatic data transfer includes automatically transferring the additional data and glucose level data.

[0214] Example 26 includes the computer-readable medium of Example 23, wherein the glucose level data includes a first dataset and a second dataset, and the storage of the glucose level data into separate groups includes the cloud infrastructure storing the first dataset and the second dataset separately.

[0215] Example 27 includes the computer-readable medium of Example 26, wherein the first dataset includes real-time data, the real-time data includes one or more of the following: glucose value, current status of a continuous glucose sensor, and a timestamp associated with the measurement result used to obtain the glucose value, and the second dataset includes at least one of the following: information for calibrating the continuous glucose monitor and information used for technical support of the continuous glucose monitor.

[0216] Example 28 includes the computer-readable medium of Example 27, wherein the method further comprises: encrypting a first dataset by a transmitter; encrypting a second dataset by a transmitter; decrypting and displaying the first dataset by at least one display device; preventing at least one display device from decrypting the second dataset; and decrypting the second dataset by a cloud infrastructure.

[0217] Example 29 includes the computer-readable medium of Example 28, wherein the method further includes storing a first key for decrypting a first dataset by at least one display device, storing a second key for decrypting a second dataset by a cloud infrastructure, and preventing at least one display device from accessing the second key.

[0218] Example 30 further comprises a method for transferring a subset of glucose level data from a cloud infrastructure to a second display device, wherein the subset of data includes the computer-readable medium of Example 23, which includes at least one of current glucose levels and historical glucose levels.

[0219] Example 31 includes the computer-readable medium of Example 23, further comprising a method that selectively determines whether a cloud infrastructure allows one or more requesting systems to access a first dataset and a second dataset.

[0220] Example 32 includes the computer-readable media of Example 31, wherein the requesting system includes a technical support system, at least one third-party application, and a data warehouse, and the cloud infrastructure allows the technical support system access to the first dataset and the second dataset, allows at least one third-party application access to the first dataset, and allows the data warehouse access to the first dataset and the second dataset.

[0221] Example 33 includes the computer-readable medium of Example 23, wherein the display device includes at least one of a smartphone or a display.

[0222] In some embodiments of the present technology (Example 34), a method for encrypting and transmitting glucose level data from a continuous glucose monitor, the method comprising: encrypting a first dataset by a transmitter associated with the continuous glucose monitor; encrypting a second dataset by the transmitter; wirelessly transmitting the first dataset and the second dataset to at least one display device; decrypting the first dataset by the display device; preventing the display device from decrypting the second dataset; automatically transferring the first dataset and the second dataset to a cloud infrastructure; and decrypting the second dataset by the cloud infrastructure.

[0223] Example 35 includes the method of Example 34, wherein the first dataset includes real-time data, the real-time data includes one or more of the following: glucose value, current status of a continuous glucose sensor, and timestamp associated with measurement results used to obtain the glucose value, and the second dataset includes at least one of the following: information for calibrating a continuous glucose monitor and information used for technical support of a continuous glucose monitor.

[0224] Example 36 includes the method of Example 34, wherein the transmitter uses an advanced encryption standard when encrypting the first and second datasets.

[0225] Example 37 further includes the method of Example 34, which also includes storing a first dataset on a first server in the cloud infrastructure and storing a second dataset on a second, different server in the cloud infrastructure.

[0226] Example 38 includes the method of Example 34, wherein the display device includes at least one of a display or a smartphone.

[0227] Example 39 includes the method of Example 34, wherein the automatic transfer includes transferring a first dataset and a second dataset through a personal computer connected to a display, and the connection includes either a wired or wireless connection.

[0228] In some embodiments of the present technology (Example 40), a system for encrypting and transmitting glucose level data from a continuous glucose monitor, the system comprising: a transmitter associated with a continuous glucose monitor configured to encrypt a first dataset and a second dataset and to wirelessly transmit the first dataset and the second dataset; at least one display device configured to receive the first dataset and the second dataset, decrypt the first dataset, and automatically transfer the first dataset and the second dataset; and a cloud infrastructure configured to receive the first dataset and the second dataset from at least one display device and to decrypt the second dataset, wherein at least one display device is unable to decrypt the second dataset.

[0229] Example 41 includes the system of Example 40, wherein the first dataset includes real-time data, the real-time data includes one or more of the following: glucose value, current status of a continuous glucose sensor, and timestamp associated with measurement results used to obtain the glucose value, and the second dataset includes at least one of the following: information for calibrating a continuous glucose monitor and information used for technical support of a continuous glucose monitor.

[0230] Example 42 includes the system of Example 40, wherein the transmitter uses an advanced encryption standard when encrypting the first and second datasets.

[0231] Example 43 includes the system of Example 40, further comprising a first server in a cloud infrastructure configured to store a first dataset, and a second server in a cloud infrastructure configured to store a second dataset.

[0232] Example 44 includes the system of Example 40, wherein the display device includes at least one of a display or a smartphone.

[0233] Embodiment 45 includes the system of Embodiment 40, further comprising a personal computer configured to receive a first dataset and a second dataset from at least one display device and to transfer the first dataset and the second dataset to a cloud infrastructure.

[0234] In some embodiments of the present technology (Example 46), one or more computer-readable media include instructions that, when executed by one or more processors, perform a method for encrypting and transmitting glucose level data from a continuous glucose monitor, which includes: encrypting a first dataset by a transmitter associated with a continuous glucose monitor; encrypting a second dataset by the transmitter; wirelessly transmitting the first and second datasets to at least one display device; decrypting the first dataset by the display device; preventing the display device from decrypting the second dataset; automatically transferring the first and second datasets to a cloud infrastructure; and decrypting the second dataset by the cloud infrastructure.

[0235] Example 47 includes the computer-readable medium of Example 46, wherein the first dataset includes real-time data, the real-time data includes one or more of the following: glucose value, current status of a continuous glucose sensor, and timestamp associated with measurement results used to obtain the glucose value, and the second dataset includes at least one of the following: information for calibrating a continuous glucose monitor and information used for technical support of a continuous glucose monitor.

[0236] Example 48 includes the computer-readable medium of Example 46, wherein the transmitter uses an advanced encryption standard when encrypting the first and second datasets.

[0237] Example 49 includes the computer-readable medium of Example 46, further comprising the method of storing a first dataset on a first server in a cloud infrastructure and storing a second dataset on a second server in a cloud infrastructure.

[0238] Example 50 includes the computer-readable medium of Example 46, wherein the display device includes at least one of a display or a smartphone.

[0239] Example 51 includes the computer-readable medium of Example 46, wherein the automatic transfer includes transferring a first dataset and a second dataset through a personal computer connected to a display, and the connection includes either a wired or wireless connection.

[0240] In some embodiments of the present technology (Example 52), a method for controlling access to glucose level data includes: defining a set of rules for controlling access to glucose level data in a cloud infrastructure; providing a set of application programming interfaces for accessing glucose level data; receiving requests for glucose level data through at least one of the application programming interfaces; determining whether to permit the request for glucose level data based on the set of rules and the data request; and providing access to glucose level data when it is determined that access should be permitted.

[0241] Example 53 further includes receiving requests through a common application and providing requests to a cloud infrastructure, and includes the method of Example 52, wherein the provision of access includes providing data relating to glucose levels to at least one of the application programming interfaces through the common application.

[0242] Example 54 includes the method of Example 53, further comprising providing a single login, including a username and password, to a common application and multiple applications using an application program interface.

[0243] Example 55 includes the method of Example 53, further comprising using at least one of the application program interfaces to launch a web interface from a common application in response to a request to the application.

[0244] Example 56 includes the method of Example 55, further comprising providing an icon for a second application within a common application, receiving an icon selection, directly accessing a server hosting the second application, and executing the results of the server access in the common application.

[0245] Example 57 includes the method of Example 52, further comprising: receiving a request for a second display device to access data relating to glucose levels via a cloud infrastructure; the cloud infrastructure storing an anonymous identifier associated with the second display device; and providing the glucose level data to the second display device.

[0246] In some embodiments of this technology (Example 58), a system for controlling access to glucose level data includes one or more display devices that include a plurality of application programming interfaces for accessing glucose level data, the display devices are configured to receive requests for glucose level data through at least one of the application programming interfaces, and the cloud infrastructure is configured to define a plurality of rules for controlling access to glucose level data, to determine whether to allow a request for glucose level data based on the plurality of rules and data requests, and to provide access to glucose level data when it is determined that access should be allowed.

[0247] Example 59 further includes a common application that runs on one or more display devices configured to receive and provide requests to a cloud infrastructure, and includes the system of Example 58, wherein the cloud infrastructure provides access to data relating to glucose levels by providing the common application to at least one of the application programming interfaces.

[0248] Example 60 includes the system of Example 59, in which a single login, including a username and password, accesses a common application and multiple applications using an application program interface.

[0249] Example 61 includes the system of Example 59, wherein one or more display devices are further configured to launch a web interface from a common application in response to a request for the application, using at least one of the application program interfaces.

[0250] Embodiment 62 includes the system of Embodiment 61, wherein one or more display devices are further configured to provide icons for a second application within a common application, receive icon selections, directly access a server hosting the second application, and execute the results of the server access in the common application.

[0251] Example 63 further includes a second display device configured to provide a cloud infrastructure with requests to access data relating to glucose levels, and the cloud infrastructure is further configured to store an anonymous identifier associated with the second display device and to provide the second display device with data relating to glucose levels, thereby including the system of Example 58.

[0252] In some embodiments of the present technology (Example 64), one or more computer-readable media include instructions that, when executed by one or more processors, perform a method for controlling access to glucose level data, which includes: defining a set of rules for controlling access to glucose level data in a cloud infrastructure; providing a set of application programming interfaces for accessing glucose level data; receiving requests for glucose level data through at least one of the application programming interfaces; determining whether to permit the requests for glucose level data based on the set of rules and data requests; and providing access to glucose level data when it is determined that access should be permitted.

[0253] Example 65 further includes the computer-readable medium of Example 64, wherein the method includes receiving a request through a common application and providing the request to a cloud infrastructure, and the provision of access includes providing data relating to glucose levels to at least one of the application program interfaces through the common application.

[0254] Example 66 includes the computer-readable medium of Example 65, further comprising a method for providing a single login, including a username and password, to a common application and multiple applications using an application program interface.

[0255] Example 67 includes the computer-readable media of Example 65, wherein the method further includes initiating a web interface from a common application in response to a request to the application using at least one of the application program interfaces.

[0256] Example 68 includes the computer-readable medium of Example 67, wherein the method further includes providing an icon for a second application within a common application, receiving an icon selection, directly accessing a server hosting the second application, and executing the results of the access to the server in the common application.

[0257] Example 69 includes the computer-readable medium of Example 68, further comprising: a method receiving a request for a second display device to access data relating to glucose levels via a cloud infrastructure; the cloud infrastructure storing an anonymous identifier associated with the second display device; and providing the glucose level data to the second display device.

[0258] In some embodiments of this technology (Example 70), a method for updating glucose level data in a distributed architecture includes: obtaining one or more data points relating to glucose levels from a transmitter associated with a continuous glucose monitor; distributing one or more data points among one or more display devices and one or more servers; identifying missing data points from among the display devices or servers, wherein the missing data point is one of the one or more data points; and providing the missing data point to at least one display device or server when the missing data point falls within a specified period.

[0259] Example 71 includes the method of Example 70, wherein missing data points are backfilled and sent to a display device or server after distribution.

[0260] Example 72 includes the method of Example 70, further comprising identifying one or more missing data points from a display device or server, and providing one or more missing data points to a display device or server.

[0261] Example 73 includes the method of Example 70, further comprising: identifying one or more missing data points between display devices or servers; determining which of the one or more missing data points were created within a subset of a specified time interval; and providing the missing data points created within the subset of the specified time interval.

[0262] Example 74 includes the method of Example 73, further comprising displaying one or more data points and missing data points, and displaying an indication that the missing data points contain backfilled data.

[0263] Example 75 includes the method of Example 70, wherein at least one display device or server receiving the missing data points was turned off or disconnected when the missing data points first became available.

[0264] Example 76 includes the method of Example 70, further comprising: identifying one or more missing data points between display devices or servers; determining the number of missing data points to backfill based on the devices that have lost data; and providing the determined number of missing data points to the display devices or servers.

[0265] Example 77 includes the method of Example 70, further comprising storing an instruction that the missing data point contains backfilled data on one or more display devices or servers provided with the missing data point.

[0266] Example 78 includes the method of Example 70, further comprising storing an indication that one or more data points have been received in real time by one or more display devices and one or more servers.

[0267] Example 79 includes the method of Example 70, further comprising connecting multiple display devices to a transmitter, distributing one or more data points to the multiple display devices, and transferring one or more data points from the multiple display devices to one or more servers, along with an indication of which display device transferred the data.

[0268] Example 80 includes the method of Example 79, further comprising receiving one or more data points during the distribution of multiple datasets, and displaying the one or more data points received during the distribution differently from missing data points.

[0269] Example 81 includes the method of Example 70, wherein the specified period includes the past 6 hours.

[0270] In some embodiments of this technology (Example 82), a system for updating glucose level data in a distributed architecture includes a transmitter associated with a continuous glucose monitor configured to acquire multiple datasets of glucose levels and distribute the multiple datasets among one or more display devices and one or more servers, wherein the one or more display devices and one or more servers are configured to identify missing datasets from among the multiple datasets, request missing datasets, and receive missing datasets when they enter a specified period of time.

[0271] Example 83 includes the system of Example 82, wherein the missing dataset is backfilled and sent to one or more display devices or servers after distribution.

[0272] Example 84 includes the system of Example 82, wherein one or more display devices and one or more servers are configured to identify multiple missing datasets from between the display devices or servers, request multiple missing datasets, and receive multiple missing datasets.

[0273] Example 85 includes the system of Example 82, wherein one or more display devices and one or more servers are configured to identify multiple missing datasets, determine which of the multiple missing datasets were created within a specified time interval subset, and request the missing datasets created within the specified time interval subset.

[0274] Example 86 includes the system of Example 85, wherein one or more display devices are configured to display multiple datasets and missing datasets, and to display an indication that the missing datasets contain backfilled data.

[0275] Example 87 includes the system of Example 82, wherein when the missing dataset first becomes available, one or more display devices or servers receiving the missing dataset are turned off or disconnected.

[0276] Example 88 includes the system of Example 82, wherein multiple missing datasets are identified between display devices or servers, the number of missing datasets to backfill based on the devices that have lost data is determined, and the determined number of missing datasets are provided to the display devices or servers.

[0277] Example 89 includes the system of Example 82, wherein at least one display device or server provided with a missing dataset stores an instruction that the missing dataset contains backfilled data.

[0278] Embodiment 90 includes the system of Embodiment 89, wherein one or more display devices and one or more servers store instructions that multiple datasets have been received in real time.

[0279] Example 91 includes a plurality of display devices connected to a transmitter, where multiple data sets are distributed among the plurality of display devices, and the multiple data sets are transferred from the plurality of display devices to one or more servers along with an indication of which display device transferred the data set, including the system of Example 82.

[0280] Example 92 includes the system of Example 82, where multiple data sets are received during the distribution of the multiple data sets, and the multiple data sets received during distribution are displayed differently from the missing data sets.

[0281] Example 93 includes the system of Example 82, where the defined period includes the past six hours.

[0282] In some embodiments according to the present technology (Example 94), one or more computer-readable media, when executed by one or more processors, obtain multiple data sets regarding glucose levels from a transmitter associated with a continuous glucose monitor, distribute the multiple data sets between one or more display devices and one or more servers, identify a missing data set among the multiple data sets, where the missing data set is one of the multiple data sets, and provide the missing data set to at least one display device or server when the missing data set falls within a defined period, including instructions for performing a method of updating data regarding glucose levels in a distributed architecture.

[0283] Example 95 includes the computer-readable media of Example 94, where the missing data set includes backfilled data sent to a display device or server after distribution.

[0284] Example 96 includes the computer-readable media of Example 94, where the method further includes identifying multiple missing data sets between a display device or servers and providing the multiple missing data sets to a display device or server.

[0285] Example 97 includes the computer-readable medium of Example 94, wherein the method further includes identifying a plurality of missing data sets between display devices or servers, determining which of the plurality of missing data sets were created within a subset of a specified time interval, and providing the missing data sets created within the subset of the specified time interval.

[0286] Example 98 includes the computer-readable medium of Example 95, wherein the method further includes displaying a plurality of data sets and missing data sets, and displaying an indication that the missing data sets include backfilled data.

[0287] Example 99 includes the computer-readable medium of Example 94, wherein at least one display device or server that receives the missing data sets is off or disconnected when the missing data sets first become available.

[0288] Example 100 includes the computer-readable medium of Example 95, wherein the method further includes identifying a plurality of missing data sets between display devices or servers, determining the number of missing data sets to backfill based on the devices that are missing data, and providing the determined number of missing data sets to a display device or server.

[0289] Example 101 includes the computer-readable medium of Example 100, wherein the method further includes storing, by one or more display devices or servers to which the missing data sets are provided, an indication that the missing data sets include backfilled data.

[0290] Example 102 includes the computer-readable medium of Example 101, wherein the method further includes storing, by one or more display devices and one or more servers, an indication that a plurality of data sets were received in real time.

[0291] Example 103 includes the computer-readable media of Example 94, wherein the method further includes connecting multiple display devices to a transmitter, distributing multiple datasets to multiple display devices, and transferring the multiple datasets from the multiple display devices to one or more servers, along with instructions on which display device transferred the datasets.

[0292] Example 104 includes the computer-readable medium of Example 94, further comprising the method of receiving multiple datasets during the distribution of multiple datasets, and displaying the multiple datasets received during the distribution differently from missing datasets.

[0293] Example 105 includes the computer-readable medium of Example 94, where the specified period includes the past 6 hours.

[0294] In some embodiments of this technology (Example 106), a method for synchronizing glucose level data in a distributed architecture system includes: providing a plurality of glucose level datasets from a transmitter associated with a continuous glucose monitor to a first display device and a second display device; providing the plurality of datasets from the first display device and the second display device to a server; and having the server store the plurality of datasets separately based on whether the plurality of datasets were received from the first display device or the second display device.

[0295] Example 107 further includes the method of Example 106, which further includes tagging a plurality of datasets as having been received by the first display device using a first display device, and tagging a plurality of datasets as having been received by the second display device using a second display device.

[0296] Example 108 includes the method of Example 106, further comprising: including a first alert on a first display device for when the glucose level reaches a first defined level or experiences a first rate of change; and creating a second alert on a second display device for when the glucose level reaches a second defined level or experiences a second rate of change.

[0297] Example 109 includes the method of Example 106, further comprising configuring when to provide multiple datasets from a first display device to a server, and configuring when to provide multiple datasets from a second display device to a server.

[0298] Example 110 includes the method of Example 106, wherein the server includes a distributed cloud computing system that includes multiple connected computing devices.

[0299] In some embodiments of this technology (Example 111), a system for synchronizing glucose level data in a distributed architecture system includes: a transmitter associated with a continuous glucose monitor configured to provide multiple datasets of glucose levels; a first display device and a second display device configured to receive and provide multiple datasets; and a server configured to receive multiple datasets and to store the multiple datasets separately based on whether the datasets were received from the first display device or the second display device.

[0300] Example 112 includes the system of Example 111, wherein a first display device tags multiple datasets as having been received by the first display device, and a second display device tags multiple datasets as having been received by the second display device.

[0301] Example 113 includes the system of Example 111, wherein a first display device is configured to provide a first alert when the glucose level reaches a first specified level or experiences a first rate of change, and a second display device is configured to provide a second alert when the glucose level reaches a second specified level or experiences a second rate of change.

[0302] Embodiment 114 includes the system of Embodiment 111, wherein a first display device is configured to provide a plurality of datasets to the server at a first predetermined time, and a second display device is configured to provide a plurality of datasets to the server at a second predetermined time.

[0303] Example 115 includes the system of Example 111, wherein the server includes a distributed cloud computing system that includes multiple connected computing devices.

[0304] In some embodiments of the present technology (Example 116), one or more computer-readable media include instructions that, when executed by one or more processors, perform a method for synchronizing glucose level data in a distributed architecture system, which includes: providing a plurality of datasets relating to glucose levels from a transmitter associated with a continuous glucose monitor to a first display device and a second display device; providing the plurality of datasets from the first display device and the second display device to a server; and having the server store the plurality of datasets separately based on whether the plurality of datasets were received from the first display device or the second display device.

[0305] Example 117 includes the computer-readable medium of Example 116, further comprising the method of tagging a plurality of datasets as received by the first display device using a first display device, and tagging a plurality of datasets as received by the second display device using a second display device.

[0306] Example 118 includes the computer-readable medium of Example 116, further comprising: the method creates a first alert on a first display device when the glucose level reaches a first specified level or experiences a first rate of change; and creates a second alert on a second display device when the glucose level reaches a second specified level or experiences a second rate of change.

[0307] Example 119 includes the computer-readable medium of Example 116, further comprising: the method sets when to provide a plurality of data sets from a first display device to a server; and sets when to provide a plurality of data sets from a second display device to a server.

[0308] Example 120 includes the computer-readable medium of Example 116, wherein the server includes a distributed cloud computing system comprising a plurality of connected computing devices.

[0309] In some embodiments of this technology (Example 121), a system for securely collecting, analyzing, and reporting data on glucose monitoring levels using multiple continuous glucose monitors includes: multiple continuous glucose monitor (CGM) devices; multiple display devices that receive data from the multiple CGM devices, wherein the data is classified into multiple categories based on data type; a cloud server architecture including multiple servers that receive data from the multiple display devices on an intermittent basis, wherein the data routed to a specific server among the multiple servers is determined by data type, and the intermittent basis differs depending on the data type; multiple remote monitor display devices that receive data from one of the multiple servers, wherein the data sent to each of the multiple remote monitor display devices depends on the data type and the display device that sent the data to one of the multiple servers, and the data is sent to the multiple remote monitor display devices immediately after being received by one of the multiple servers; and an analysis and reporting engine to which at least a portion of the data received by the multiple servers is sent, the transmitted data is analyzed, and a report is generated by the analysis and reporting engine.

[0310] Example 122 includes the system of Example 121, in which multiple servers, including a cloud server architecture, include at least one real-time server and a bulk data collector.

[0311] Example 123 includes one of the systems from Examples 121 to 122, in which the data types include real-time data and bulk data.

[0312] Example 124 includes the system of Example 123, in which real-time data is routed from multiple display devices to a real-time server, and bulk data is routed from multiple display devices to a bulk data collector.

[0313] Example 125 includes the system of Example 124, wherein real-time data is routed from multiple display devices to a real-time server on a more intermittent basis than the intermittent basis in which bulk data is routed from multiple display devices to a bulk data collector.

[0314] Example 126 includes the system of Example 125, in which real-time data is routed from multiple display devices to a real-time server every 5 minutes, and bulk data is routed from multiple display devices to a bulk data collector every hour.

[0315] Example 127 further includes a locator service and includes any of the systems from Examples 121 to 126, in which multiple display devices connect to a cloud server architecture through the locator service.

[0316] Example 128 includes one of the systems from Examples 121 to 127, in which at least one of the multiple display devices is a smartphone.

[0317] Example 129 includes one of the systems from Examples 121 to 128, in which at least one of the multiple remote monitoring display devices includes a smartphone.

[0318] Example 130 includes one of the systems from Examples 121 to 129, in which the multiple display devices include at least 150,000 devices.

[0319] Example 131 includes any of the systems from Examples 121 to 130, wherein at least one of a plurality of remote monitoring display devices further includes an application that can be performed by at least one of the plurality of remote display devices.

[0320] Example 132 includes the system of Example 131, wherein an application on at least one of the multiple remote monitoring display devices must be open and running to receive data ready to be sent to at least one of the multiple remote monitoring display devices, otherwise the data ready to be sent to at least one of the multiple remote monitoring display devices is held by one of the multiple servers.

[0321] Example 133 includes any of the systems in Examples 121 to 132, wherein at least one of a plurality of remote monitoring display devices that receives data from one of a plurality of servers receives a notification that the data is ready to be sent to at least one of the plurality of remote monitoring display devices.

[0322] Example 134 includes the system of Example 133, wherein the notification includes a text message.

[0323] Example 135 includes the system of Example 131, wherein when one of the multiple servers attempts to send data to at least one of the multiple remote display devices, an application that may be running on at least one of the multiple remote display devices wakes up.

[0324] Example 136 includes the system of Example 135, wherein after the application wakes up, the application requests that data be sent from one of several servers.

[0325] In some embodiments of this technology (Example 136), a method for securely collecting, analyzing, and reporting data on glucose monitoring levels using multiple continuous glucose monitors includes: receiving data from multiple continuous glucose monitor (CGM) devices using multiple display devices; classifying the data into multiple categories based on data types; transmitting the data from the multiple display devices to a cloud server architecture including multiple servers that receive data from the multiple display devices on an intermittent basis, wherein the data routed to a specific server among the multiple servers is determined by the data type, and the intermittent basis differs depending on the data type; receiving data from one of the multiple servers using multiple remote monitor display devices, wherein the data sent to each of the multiple remote monitor display devices depends on the data type and the display device that sent the data to one of the multiple servers, and the data is sent to the multiple remote monitor display devices immediately after being received by one of the multiple servers; and receiving at least a portion of the data received by the multiple servers using an analysis and reporting engine, wherein the received data is analyzed and a report is generated by the analysis and reporting engine.

[0326] Example 138 includes the method of Example 137, wherein a plurality of servers, including a cloud server architecture, include at least one real-time server and a bulk data collector.

[0327] Example 139 includes any of the methods from Examples 137 to 138, wherein the classification of data into multiple classifications based on data type includes classifying the data as real-time data and bulk data.

[0328] Example 140 includes the method of Example 139, wherein real-time data is routed from multiple display devices to a real-time server, and bulk data is routed from multiple display devices to a bulk data collector.

[0329] Example 141 includes the method of Example 140, wherein real-time data is routed from multiple display devices to a real-time server on a more intermittent basis than the intermittent basis in which bulk data is routed from multiple display devices to a bulk data collector.

[0330] Example 142 includes the method of Example 141, wherein real-time data is routed from multiple display devices to a real-time server every 5 minutes, and bulk data is routed from multiple display devices to a bulk data collector every hour.

[0331] Example 143 further includes a locator service and includes any of the methods of Examples 137 to 142, wherein multiple display devices connect to a cloud server architecture through the locator service.

[0332] Example 144 includes any of the methods from Examples 137 to 143, wherein at least one of the multiple display devices is a smartphone.

[0333] Example 145 includes any of the methods from Examples 137 to 144, wherein at least one of the multiple remote monitoring display devices includes a smartphone.

[0334] Example 146 includes any of the methods from Examples 137 to 145, wherein the multiple display devices include at least 150,000 devices.

[0335] Example 147 includes any of the methods from Examples 137 to 146, wherein at least one of a plurality of remote monitoring display devices further includes an application that can be performed by at least one of the plurality of remote display devices.

[0336] Example 148 includes the method of Example 147, wherein an application on at least one of a plurality of remote monitoring display devices must be open and running to receive data ready to be sent to at least one of the plurality of remote monitoring display devices, otherwise the data ready to be sent to at least one of the plurality of remote monitoring display devices is held by one of the plurality of servers.

[0337] Example 149 includes any of the methods in Examples 137 to 148, wherein at least one of a group of remote monitoring display devices that receives data from one of a group of servers receives a notification that the data is ready to be sent to at least one of the group of remote monitoring display devices.

[0338] Example 150 includes the method of Example 149, wherein the notification includes a text message.

[0339] Example 151 includes the method of Example 147, wherein when one of a plurality of servers attempts to send data to at least one of a plurality of remote display devices, an application that may be running on at least one of the plurality of remote display devices wakes up.

[0340] Example 152 includes the method of Example 151, wherein, after the application wakes up, the application requests that data be sent from one of several servers.

[0341] Any combination of one or more computer-readable media may be used. The computer-readable media may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any preferred combination thereof. More specific examples (non-exclusive list) of computer-readable storage media include: electrical connectors with one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any preferred combination thereof. Program code embodied on the computer-readable media may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber cables, RF, or any preferred combination thereof.

[0342] Computer program code can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java®, Smalltalk, C++, etc., and traditional procedural programming languages ​​such as the C programming language or similar languages. The program code can be executed entirely on a computing unit.

[0343] It is understood that each block in a flowchart and / or block diagram, as well as combinations of blocks in a flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions are provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device such that instructions executed by the processor of the computer or other programmable data processing device generate means for performing the function / action specified in the block(s) of the flowchart and / or block diagram, thereby enabling the production of a machine.

[0344] It should be understood that the various techniques described herein may be implemented in relation to hardware, software, or, where appropriate, a combination thereof. Therefore, the methods and apparatus of the subject matter of this disclosure, or certain aspects or parts thereof, may take the form of program code (i.e., instructions) embodied on a tangible medium such as a floppy diskette, CD-ROM, hard drive, or any other machine-readable storage medium, and when the program code is loaded into and executed by a machine such as a computing device, that machine becomes an apparatus for implementing the subject matter of this disclosure. When program code is executed on a programmable computer, the computing device generally includes a processor, processor-readable storage medium (including volatile and non-volatile memory and / or memory elements), at least one input device, and at least one output device. One or more programs may implement or utilize processes described in relation to the subject matter of this disclosure, for example, using an application programming interface (API), reusable control means, etc. Such programs may be implemented in a high-level procedural or object-oriented programming language to communicate with a computer system. However, programs may be implemented in assembly language or machine language, if desired. In either case, the language may be a compiled or interpreted language and may be combined with a hardware embodiment.

[0345] Although this specification includes details of many specific embodiments, these should not be construed as limiting the scope of the claims. Certain features described herein in relation to separate embodiments may be implemented in combination in a single embodiment. Conversely, various features described in relation to a single embodiment may be implemented separately in multiple embodiments or in any preferred partial combination. Furthermore, features may be described above as functioning in a particular combination, and may even be initially claimed as such, but one or more features from the claimed combination may, in some cases, be removed from the combination, and the claimed combination may cover partial combinations or variations of partial combinations.

[0346] Similarly, while operations are shown in a specific order in the diagrams, this should not be understood as requiring that such operations be performed in a specific or sequential order shown to obtain the desired result, or that all illustrated operations may be performed. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged in multiple software products.

[0347] It should be understood that the logical operations described herein with respect to various figures may be implemented as (1) a series of computer actions or program modules (i.e., software) invoked on a computing device, (2) interconnected mechanical logic circuits or circuit modules (i.e., hardware) within the computing device, and / or (3) a combination of software and hardware in the computing device. Therefore, the logical operations discussed herein are not limited to any particular combination of hardware and software. This embodiment is a matter of choice depending on the performance and other requirements of the computing device. Accordingly, the logical operations described herein may be referred to as actions, structural devices, actions, or modules. These actions, structural devices, actions, and modules may be implemented in software, firmware, proprietary digital logic, and any combination thereof. It should also be understood that more or fewer actions may be performed than those shown in the figures and described herein. These actions may be performed in an order different from that described herein. It will be apparent to those skilled in the art that various modifications and variations may be made without departing from the scope or spirit. Other embodiments will become apparent to those skilled in the art with consideration of this specification and the practices of the invention disclosed herein. This specification and its examples are intended to be illustrative only, and the true scope and spirit are shown by the following claims. [Explanation of symbols]

[0348] 100a~c Continuous Glucose Sensor Unit 102a~c Radio transmitter 104a~e Display 106 Distributed Cloud Computing Architectures

Claims

1. A system for securely collecting, analyzing, and reporting data on glucose monitoring levels using multiple continuous glucose monitors, Multiple continuous glucose monitoring (CGM) devices, A plurality of display devices that receive data from the plurality of CGM devices, wherein the data is classified into a plurality of categories based on the data type, A cloud server architecture comprising multiple servers that intermittently receive the data from the multiple display devices, wherein the data routed to a specific server among the multiple servers is determined by the data type, and the intermittent basis differs depending on the data type, A plurality of remote monitoring display devices that receive data from at least one of the plurality of servers, wherein the data sent to each of the plurality of remote monitoring display devices depends on the data type and the display device that sent the data to at least one of the plurality of servers, and a data table presenting the data categorized by the data type and the display device that sent the data to at least one of the plurality of servers is presented to the plurality of remote monitoring display devices via a shared support tool from the cloud server architecture, The system comprises an analysis and reporting engine, wherein at least a portion of the data received by the plurality of servers is transmitted to the analysis and reporting engine, the transmitted data is analyzed, and a report is generated by the analysis and reporting engine.

2. The system according to claim 1, wherein the data types include real-time data and bulk data.

3. The system according to claim 1 or 2, wherein the plurality of servers in the cloud server architecture include at least one real-time server and a bulk data collector.

4. The system according to claim 3, wherein real-time data is routed from the plurality of display devices to the real-time server, and bulk data is routed from the plurality of display devices to the bulk data collector.

5. The system according to claim 4, wherein the real-time data is routed from the plurality of display devices to the real-time server on an intermittent basis that is more frequent than the intermittent basis on which the bulk data is routed from the plurality of display devices to the bulk data collector.

6. The system according to claim 5, wherein the real-time data is routed from the plurality of display devices to the real-time server every five minutes, and the bulk data is routed from the plurality of display devices to the bulk data collector every hour.

7. The system according to any one of claims 1 to 6, further comprising a locator service, wherein the plurality of display devices connect to the cloud server architecture through the locator service.

8. The system according to any one of claims 1 to 7, wherein at least one of the plurality of display devices includes a smartphone, tablet, desktop computer, laptop computer, or wearable display device.

9. The system according to any one of claims 1 to 8, wherein at least one of the plurality of remote monitoring display devices includes a smartphone, tablet, desktop computer, laptop computer, or wearable display device.

10. The system according to any one of claims 1 to 9, wherein the plurality of display devices include at least 150,000 devices.

11. The system according to any one of claims 1 to 10, wherein at least one of the plurality of remote monitoring display devices further comprises an application that can be performed by at least one of the plurality of remote monitoring display devices.

12. The system according to claim 11, wherein the application on at least one of the plurality of remote monitoring display devices must be open and running to receive the data that is ready to be sent to at least one of the plurality of remote monitoring display devices, otherwise the data that is ready to be sent to at least one of the plurality of remote monitoring display devices is held by one of the plurality of servers.

13. The system according to any one of claims 1 to 12, wherein at least one of the multiple remote monitoring display devices that receives data from one of the multiple servers receives a notification that data is ready to be sent to at least one of the multiple remote monitoring display devices.

14. The system according to claim 13, wherein the notification includes a text message.

15. The system according to claim 11, wherein when one of the plurality of servers attempts to send the data to at least one of the plurality of remote monitoring display devices, the application which can be executed by at least one of the plurality of remote monitoring display devices wakes up.

16. The system according to claim 15, wherein after the application wakes up, the application requests that the data be sent from one of the plurality of servers.

17. A method for securely collecting, analyzing, and reporting data on glucose monitoring levels using multiple continuous glucose monitors, Multiple display devices receive data from multiple continuous glucose monitor (CGM) devices, Classifying the aforementioned data into multiple categories based on the data type, The transmission of data from the plurality of display devices to a cloud server architecture comprising a plurality of servers that receive the data from the plurality of display devices on an intermittent basis, wherein the data routed to a specific server among the plurality of servers is determined by the data type, and the intermittent basis differs according to the data type, The receiving of data from at least one of the multiple servers by multiple remote monitoring display devices, wherein the data sent to each of the multiple remote monitoring display devices depends on the data type and the display device that sent the data to at least one of the multiple servers, and the data is sent to the multiple remote monitoring display devices immediately after being received by at least one of the multiple servers, and a data table presenting the data categorized by the data type and the display device that sent the data to at least one of the multiple servers is presented to the multiple remote monitoring display devices from the cloud server architecture via a shared support tool, and the receiving of data. The method comprising receiving, by an analysis and reporting engine, at least a portion of the data received by the plurality of servers, wherein the analysis and reporting engine is configured to analyze the received data and generate a report.

18. The method according to claim 17, wherein classifying the data into a plurality of classifications based on data type includes classifying the data as real-time data and bulk data.

19. The method according to claim 17 or 18, wherein the plurality of servers in the cloud server architecture include at least one real-time server and a bulk data collector.

20. The method according to claim 19, wherein real-time data is routed from the plurality of display devices to the real-time server, and bulk data is routed from the plurality of display devices to the bulk data collector.

21. The method according to claim 20, wherein the real-time data is routed from the plurality of display devices to the real-time server on an intermittent basis that is more frequent than the intermittent basis on which the bulk data is routed from the plurality of display devices to the bulk data collector.

22. The method according to claim 21, wherein the real-time data is routed from the plurality of display devices to the real-time server every five minutes, and the bulk data is routed from the plurality of display devices to the bulk data collector every hour.

23. The method according to any one of claims 17 to 22, further comprising a locator service, wherein the plurality of display devices connect to the cloud server architecture through the locator service.

24. The method according to any one of claims 17 to 23, wherein at least one of the plurality of display devices includes a smartphone, tablet, desktop computer, laptop computer, or wearable display device.

25. The method according to any one of claims 17 to 24, wherein at least one of the plurality of remote monitoring display devices includes a smartphone, tablet, desktop computer, laptop computer, or wearable display device.

26. The method according to any one of claims 17 to 25, wherein the plurality of display devices include at least 150,000 devices.

27. The method according to any one of claims 17 to 26, wherein at least one of the plurality of remote monitoring display devices further comprises an application that can be performed by at least one of the plurality of remote monitoring display devices.

28. The method according to claim 27, wherein the application on at least one of the plurality of remote monitoring display devices must be open and running to receive the data that is ready to be sent to at least one of the plurality of remote monitoring display devices, otherwise the data that is ready to be sent to at least one of the plurality of remote monitoring display devices is held by one of the plurality of servers.

29. The method according to any one of claims 17 to 28, wherein at least one of the plurality of remote monitoring display devices that receives data from one of the plurality of servers receives a notification that data is ready to be sent to at least one of the plurality of remote monitoring display devices.

30. The method according to claim 29, wherein the notification includes a text message.

31. The method according to claim 27, wherein when one of the plurality of servers attempts to send the data to at least one of the plurality of remote monitoring display devices, the application which can be executed by at least one of the plurality of remote monitoring display devices wakes up.

32. The method according to claim 31, wherein, after the application wakes up, the application requests that the data be sent from one of the plurality of servers.

Images