Systems and methods for distributing continuous glucose data

Abstract

To provide systems and methods for monitoring glucose values.SOLUTION: The present disclosure relates to systems, devices and methods for receiving biosensor data acquired by a medical device, e.g., relating to glucose concentration values, and controlling the access and distribution of the data. In some embodiments, systems and methods are disclosed for monitoring glucose levels, displaying data relating to glucose values and metabolic health information, and controlling distribution of glucose data between applications executed on a computer, such as a smartphone. In some embodiments, systems and methods are disclosed for controlling access to medical data such as continuously monitored glucose levels, synchronizing health data relating to glucose levels between multiple applications executed on a computer, and / or encrypting data.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] Incorporation by reference of related applications This patent application claims the benefit of U.S. Provisional Patent Application No. 62 / 114,386, filed Feb. 10, 2015, and U.S. Provisional Patent Application No. 62 / 269,035, filed Dec. 17, 2015. Each of the foregoing applications is hereby incorporated by reference in its entirety into this specification, and each is hereby made explicitly a part of this specification.

[0002] This disclosure relates to continuous glucose monitors for wirelessly transmitting data related to glucose values and controlling the display and distribution of that data.

Background Art

[0003] Continuous glucose monitors are gaining popularity as an easy way to monitor glucose levels. In the past, patients would sample their blood glucose levels several times throughout the day, such as in the morning, around lunch, and in the evening. Those levels could be measured by taking a small sample of the patient's blood and measuring the glucose level with a test strip or glucose meter. However, this technique has the drawback that the patient does not have to take a blood sample and the user does not know what the user's blood glucose levels are between samples throughout the day.

[0004] One potentially dangerous time frame is at night because a patient's glucose level can drop dangerously low during sleep. As a result, continuous glucose monitors have gained popularity by including a sensor that continuously measures the patient's glucose level and wirelessly transmits the measured glucose level to a display. This allows the patient or the patient's caregiver to monitor the patient's glucose level throughout the day and further to set an alarm for when the glucose level reaches a defined level or experiences a defined change.

[0005] Initially, continuous glucose monitors wirelessly transmitted data related to glucose levels to a dedicated display. The dedicated display is a medical device designed to display glucose levels, trend patterns, and other information to the user. However, with the increasing popularity of smartphones and applications running on smartphones, some users prefer to avoid the need to carry a dedicated display. Instead, some users prefer to monitor their glucose levels using an application running on a smartphone.

[0006] A computing device running an application can communicate with the continuous glucose monitor and display glucose levels and other information. In addition, a computing device running an application can share glucose levels with other applications, servers, or devices within a cloud computing infrastructure. In one example, the computing device and the application can share their glucose levels with another smartphone or other computing device running an application for overall health monitoring. Sharing or resending medical data presents risks because the medical data could be compromised or misused, whether it is for another application, device, or server. Additional applications can provide incorrect recommendations to the user or resend confidential medical information to additional devices or applications, causing a breach of patient confidentiality.

[0007] This disclosure is directed to overcoming these and other problems. SUMMARY OF THE INVENTION

[0008] Certain embodiments of the present disclosure generally relate to techniques for controlling and protecting the resending of a patient's medical data. In an exemplary embodiment, a medical device, such as a continuous glucose sensor, transmits medical data to a computing device that executes a software application, such as a smartphone, tablet, smartwatch, or other wearable and / or mobile computing device. A computing device that executes a software application, illustratively described as a smartphone, can control the redistribution and use of this medical data. The redistribution can be to one or more third-party applications running on the smartphone, or to a remote computing device such as a server, or to a separate smart device. A set of control means operates to limit the ability of a separate application to obtain or use medical data outside of its intended use. In one exemplary embodiment, the medical data can be delayed before being provided to other software applications on the computing device, or to other computing devices that execute the application or device, in order to control the recommended use by a third party in a situation that may present an immediate health risk. In other exemplary embodiments, the medical data can be encrypted to control access to the medical data by other applications and devices. A device authorized to use the medical data can receive a key to decrypt all or part of the data. In another exemplary embodiment, software running on a continuous glucose monitor or display distinguishes a subset of medical data, such as data that presents little risk of violating patient confidentiality, and provides the reduced data set to additional applications and devices. These embodiments, as well as others described in more detail below, protect patient confidentiality and control the redistribution of medical data.

[0009] For example, certain embodiments address several problems that arise in connection with providing glucose levels to different applications running on a computing device such as a smartphone. For example, a third party may create an application that accesses data related to glucose levels. The third party application may use the accessed data to provide a warning to the user when the glucose level drops excessively or rises excessively, for example. However, the third party application does not properly account for the calibration level and the accurate correspondence between the wirelessly transmitted data and the actual glucose level. As a result, for example, the third party application may incorrectly calculate the glucose level based on the received data and notify the user (e.g., the patient or the patient's monitor) that the patient's glucose level is too high or too low when the level is actually within an acceptable range, or even worse, the third party application may indicate that the patient's monitored glucose level is within the acceptable glucose range when the patient's actual glucose level is dangerously low. Also, for example, the third party application may inappropriately identify trends or miss alarms based on the monitored glucose levels because the developer of the application did not properly set up the application to take into account important clinical risk factors for glucose. Also, for example, the third party application may fail to notify the user when the patient's level enters a dangerous range due to a software bug or the developer's lack of proficiency in appropriate clinical risk levels for glucose. Accordingly, example embodiments control the display and use of medical data by applications.

[0010] In addition, third-party applications may not have been submitted to the U.S. Food and Drug Administration for approval. Obtaining approval for a medical device is a time-consuming and costly process. Unapproved applications often have security flaws that are not acceptable for confidential medical data. For example, a user may permit a third-party application to access data related to glucose levels, but be unaware that the approved application also provides that data to additional third-party applications. These additional third-party applications may distribute medical data to additional applications, Internet servers, or data repositories without the user's full knowledge. This creates a serious security risk that medical data can be breached and sent to unauthorized parties. Accordingly, certain embodiments control the distribution of medical data between applications. Specifically, software running on a computing device such as a smartphone can encrypt the data before distributing it to other third-party applications.

[0011] While aware of the risks associated with using applications running on a computing device such as a smartphone to monitor medical information, using a smartphone to monitor health information can provide a more comprehensive view of a user's health. Many applications for monitoring health information are available on smartphones. Some of this information can directly affect a user's glucose level. For example, a user installs an application on their smartphone to record exercise activities. Exercise directly affects glucose levels. As a result, example embodiments integrate health information from other applications with data related to glucose levels on a single display. This enables the user to easily determine activities that affect their glucose level and the extent of that impact.

[0012] Additional issues related to the use of an application running on a computing device, such as a smartphone, that can display data related to glucose levels are how to handle missing data. The transmitter can send data related to glucose levels continuously or periodically, but the user may turn off their smartphone, run out of battery, or place it out of the transmission range. When the user runs the application, it will be missing data that was not received because the smartphone was off or out of range. This can cause confusion for the user viewing the old data that is displayed. As a result, in some embodiments, backfill data is provided to an application that did not receive data due to, for example, a disruption in communication between the transmitter and the application running on the computing device. This may enable the user to view their glucose level history trend data even when transmissions are missed.

[0013] In one example embodiment of the technology of the present disclosure, a method for monitoring glucose values includes receiving health data including glucose measurements and associated timestamps transmitted via a wireless connection in a first application operable on a mobile computing device; determining, by the first application, that a duration between a current time and the timestamp meets a predetermined delay amount; and providing, by the first application, the glucose measurements to a second application operable on the mobile computing device only after the predetermined delay amount.

[0014] In another exemplary embodiment of the technology of the present disclosure, a system for monitoring glucose values includes a sensor configured to obtain a glucose measurement of a certain amount of glucose; a wireless transmitter for transmitting the glucose measurement and a timestamp associated with the glucose measurement; a mobile computing device including a wireless receiver configured to receive the glucose measurement, a memory for storing data including the received glucose measurement, a processor for processing the data, and a first software application including instructions stored in the memory, which, when executed by the processor, determines when the duration between the current time and the timestamp meets a predetermined delay amount, and when it is determined that the duration meets the predetermined delay amount, provides the glucose measurement to a second software application on the mobile computing device. The second software application is operable to receive the glucose measurement when it is provided by the first software application after a predetermined delay amount.

[0015] In another exemplary embodiment of the technology of the present disclosure, a method for controlling the distribution of data related to glucose levels between applications running on a computing device includes receiving, in a mobile computing device, a plurality of data values related to glucose level monitoring; separating, in a first application operable on the mobile computing device, the plurality of data values into a first data set and a second data set according to a predetermined criterion, wherein the first data set includes data values restricted from the second data set; and providing the second data set to a second application operable on the mobile computing device.

[0016] In another exemplary embodiment of the technology of the present disclosure, a method for controlling access to data related to glucose levels on a mobile computing device includes receiving data related to glucose levels using a first application operable on a smartphone, encrypting at least a subset of the data, providing the encrypted data subset to a second application operable on the smartphone, providing the encrypted data subset to a third application operable on the smartphone via the second application, and providing a key to the third application to decrypt the encrypted data subset.

[0017] In another exemplary embodiment of the technology of the present disclosure, a method for synchronizing data related to glucose levels between two applications running on a mobile computing device includes obtaining, by a first application, a first data set related to glucose levels over a first period, running a second application configured to display information related to glucose levels, providing the first data set to the second application, obtaining a second data set related to glucose levels in a second period, determining that the second application has not received the second data set, and backfilling the second data set to the second application.

[0018] In another exemplary embodiment of the technology of the present disclosure, a method for determining the safety compliance levels of two or more medical devices and modifying medical data based on the safety compliance levels includes receiving continuous glucose measurements from a wireless receiver, determining the compliance level of a medical device, and providing the continuous glucose measurements to the medical device based on the determined compliance level. When the medical device meets a high compliance level, the continuous glucose measurements are provided to the medical device in real time. When the medical device does not meet a high compliance level, the continuous glucose measurements are provided to the medical device after a predetermined delay.

[0019] Other systems, methods, features, and / or advantages will be apparent to those skilled in the art from the following drawings and detailed description. All such additional systems, methods, features, and / or advantages are intended to be included within this specification and protected by the accompanying claims.

Brief Description of the Drawings

[0020]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5

Figure 6A

Figure 6B

Figure 7

Figure 8

Figure 9A

Figure 9B

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

[0021] Exemplary embodiments described in this disclosure relate 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. Some embodiments, among other things, control which applications receive the data, provide security means for maintaining the privacy of medical data, and display glucose levels and other health information to applications running on a smartphone. Thus, the embodiments provide the user with the convenience of accessing medical data, such as glucose levels, on a smartphone while maintaining privacy and security when redistributing the medical data to other applications and devices. Certain embodiments are described as displaying medical data on a smartphone, but it is understood that other display devices, including tablets, personal computers, smartwatches, cloud applications, etc., may be used.

[0022] To illustrate some embodiments disclosed herein, an environmental example will now be described in detail.

[0023] This example environment generally includes a networked system of one or more wearable medical devices that measure one or more health characteristics of a patient and / or administer one or more treatments to the patient in communication with an electronic device(s). The health characteristics to be monitored can include, in this example, the host's glucose concentration, but alternatively or additionally can be any one or more of the other health characteristics described herein. The treatments administered to the patient can include, for example, insulin administration using an insulin pump, but in other examples can be any one or more of the other treatments described herein.

[0024] Regarding this environmental example, one or more body-worn medical devices can each generate data and provide that data to consumer electronic devices such as smartphones, tablets, smartwatches, or other wearable and / or mobile computing devices. In the following examples and other examples described, a smartphone is used. The smartphone can include a dedicated application that configures the smartphone to receive and process data (e.g., wirelessly transmitted) provided by the body-worn medical device. Examples of data provided by the body-worn medical device can include, for example, glucose measurements, insulin delivery amounts, diagnostic information regarding the medical device, and timestamps associated therewith. The smartphone can thus use the dedicated application to perform various functions, such as generating charts and user-perceivable alarms using the data. The smartphone can use the dedicated application to receive and generate other data, such as data from the smartphone user (e.g., user identification information), the interaction between the user and the dedicated application, dedicated application diagnostic information, etc. In some embodiments, the dedicated application can include a set of dedicated applications operable on one or more computing devices of the patient user and / or non-patient user to manage access to the patient user's data obtained by the medical device. In one example, the set of dedicated applications can include a first dedicated application operable on the patient user's smartphone to process biomedical data and provide it to the patient user wearing the body-worn medical device, a second dedicated application operable on the patient user's smartphone to provide the patient user with control over how the biomedical data can be shared with others (e.g., a remote monitor), and / or a third dedicated application operable on another user's device (e.g., the remote monitor's smartphone) to remotely monitor authorized data from the biomedical data.

[0025] The dedicated application can be one or more applications downloaded from a remote server using a smartphone. In one example, the smartphone is an iPhone (registered trademark) commercially available from Apple, Inc., and the application is a so-called "app" downloaded from the App Store commercially operated by Apple, Inc.

[0026] There may be cases where it is desirable for the dedicated application to provide some or all of the data generated by the body-worn medical device and the data generated by the dedicated application to other applications (e.g., third-party applications (plural)) resident on a smartphone or other communicably connected computing system (e.g., a third-party smartphone (e.g., a caregiver or family member) or a corporate system (e.g., an electronic health record operated by Mayo Clinic located in Rochester, Minnesota, or Epic located in Verona, Wisconsin)). The third-party application may have other capabilities that provide advantages to the user over the dedicated application, such as being able to process the provided data in different ways (e.g., having higher processing power or capabilities to generate different useful charts or insights), and / or being able to integrate the provided data with other data (e.g., integrating glucose and insulin data provided by the dedicated application with meal data and exercise data generated by the third-party application).

[0027] In this exemplary environment, the dedicated application provides either all the data or the selected data to the delivery application running on the smartphone. The delivery application functions to facilitate the delivery of the data collected from and thereby generated by the dedicated application to other application(s) running on the smartphone. The delivery application can be another so-called "app" running on the smartphone. The delivery application can include an application programming interface (API) that permits other applications, such as the dedicated application resident on the smartphone and third-party applications, to provide data and access the data from the delivery application. In this manner, the dedicated application can provide data to the delivery application, which data is then made available to third-party applications on the smartphone. These third-party applications can obtain, process, and output the data in any way the application can do. As a specific example, the third-party application can include a meal tracking function that obtains glucose generation data provided by the dedicated application via the delivery application. The third-party application can integrate the glucose data with the meal information to provide useful insights to the user, similar to correlating the ups and downs of the user's glucose level with meals.

[0028] However, in some implementations, it may be desirable to limit the data to which a third-party application has access. For example, a user may not want some or all third-party applications to have access to confidential information such as patient-identifiable information. Or, for example, in the case of certain types of medical information where government regulations prohibit access by other applications unless there is an application approved by a relevant government agency, certain types of information may be more highly regulated by government regulations. Additionally, security considerations can be a factor in limiting which applications can access the data. For example, even if regulations do not prohibit the exchange of data, it may be desirable to limit access to certain types of data so that third-party applications do not use the data in an unsafe manner (e.g., accidentally prompt the user to perform clinically dangerous medical procedures).

[0029] Thus, an example implementation in this example environment can limit the distribution of data to third-party applications. In some implementations, only certain types of data are provided to the distribution application such that third-party applications cannot access that data, at least directly. In some implementations, some or all of the data is encrypted before being provided to the distribution application. In this way, only third-party applications that have the key to decrypt the encrypted data can use the encrypted data accessed from the distribution application. Such keys may, in some implementations, only be provided to approved third-party applications that meet regulatory and / or security requirements. Other methods of limiting access to some or all of the data may be used as well or instead, as described elsewhere in this specification.

[0030] Regarding the example environment, it may be desirable to limit access to health measurement data by third-party applications to so-called retrospective measurement data. Retrospective measurement data is data that is no longer actionable data. That is, actionable data is data that can be used with sufficient timeliness to enable effective actions to prevent or respond to harmful changes in a patient's physiological state. Actionable data can be so-called real-time continuous glucose measurements and can also include predicted continuous glucose measurements (e.g., glucose values predicted for a future period such as 5 minutes or 1 hour ahead). Using an example of glucose data, actionable continuous glucose measurement data is glucose measurement data that can be used to treat a patient's current clinical state of diabetes (e.g., impending or actual hypoglycemia, or impending or actual hyperglycemia, etc.). In contrast, retrospective continuous glucose data is data that is not used to treat a user's current clinical state because the data is considered too old to provide a value for making a decision on how to treat the patient. Although not necessarily useful for treating the current clinical state, retrospective data is still very useful for inferring insights regarding a patient's health. Examples include comparing a patient's glucose level over time with carbohydrates (``carbs'') and / or drugs orally ingested by the patient to gain insights into how the carbs and / or drugs are affecting the patient's glucose level, and thereby modifying the treatment plan relevant to the patient.

[0031] It is understood that what constitutes actionable data can be influenced by various factors. For example, what constitutes actionable data can be influenced by how quickly the clinical state of a health condition associated with one or more monitored health characteristics changes from a non - harmful physiological state to a harmful physiological state. To explain, the clinical state of diabetes can change relatively quickly (e.g., from within a safe glucose concentration range to an unhealthy glucose concentration range), but the time frame for such a change is typically on the order of more than about 30 minutes. In contrast, the monitored health state associated with the state of the heart can change much more quickly, on the order of minutes or even seconds. Thus, actionable data associated with monitoring a diabetic condition (e.g., continuous glucose data) can span a longer time frame than data associated with monitoring the state of the heart (e.g., EKG and heart rate data).

[0032] Thus, in the example environment described above, retrospective glucose data can be accessed by a third - party application, via a delivery application, from a dedicated application as described above, but the third - party application is prevented from accessing non - retrospective glucose data such as actionable and predicted glucose data.

[0033] In some implementations, for example, retrospective data is data that indicates a monitored health characteristic of a host that is older than one of 1 minute, 5 minutes, 15 minutes, 30 minutes, 1 hour, 3 hours, 5 hours, 12 hours, 24 hours, or 1 day. For example, in one implementation of monitoring a host's glucose level, continuous glucose data that is older than 3 hours is considered retrospective glucose data. In contrast, continuous glucose data measured within the past 3 hours is considered non - retrospective data, including actionable data.

[0034] The following is a further detailed example that may include some of the aforementioned features of the example environment, but does not necessarily include any of the aforementioned features.

[0035] FIG. 1 shows an exemplary system for monitoring glucose levels and controlling access to and use of medical data. Referring to FIG. 1, a continuous glucose sensor unit 100 obtains a series of measurements related to a user's glucose level. The continuous glucose sensor unit 100 can be worn, for example, in the abdominal region of a patient. A small sensor can be extended into the patient's body to obtain glucose value readings using, for example, subcutaneous glucose or blood glucose readings. The continuous glucose sensor unit 100 can also be a transdermal device, an intravascular device, or a non-invasive device.

[0036] The continuous glucose sensor unit 100 can include several components for obtaining glucose measurements, storing data, calculating glucose levels, communicating with a dedicated display 104 and / or other computing devices 106 (such as a smartphone, referred to herein as display 106 for convenience), and performing other tasks. For example, although not shown, the continuous glucose sensor unit 100 can include a non-volatile memory for storing historical data regarding glucose values, a processor, a battery, and a wireless transmitter. The wireless transmitter provides any type of wireless communication 102a and 102b, including, for example, Bluetooth (registered trademark, same hereinafter) connections (such as low energy Bluetooth (BLE)), Wi-Fi connections, RF connections, etc. The wireless communications 102a and 102b occur between paired and authenticated devices in some embodiments and use encryption and other cryptographic techniques to ensure that the communication remains confidential.

[0037] Although shown as a single unit, a portion of the sensor unit 100 may be removable from the remainder of the continuous glucose sensor unit. For example, the reusable electronic device portion (e.g., transmitter, battery, memory) of the sensor unit 100 may be removable from the disposable portion of the sensor unit (and, for example, reused with a new disposable portion). Further, the continuous glucose sensor unit 100 may include other components to facilitate data communication. For example, the continuous glucose sensor unit 100 may include a wired port, such as a USB port, an Ethernet® port, etc., to communicate with other devices and provide data related to glucose levels, system data, etc.

[0038] The continuous glucose sensor unit 100 of FIG. 1 takes samples at predetermined intervals, such as every 2 - 3 seconds, every 30 seconds, every minute, every 5 minutes, or on demand in response to the occurrence of an event (e.g., detection of a user action such as a command from the user, movement of the user, etc.). The wireless transmitter can be stopped or placed in a low power state to conserve battery life, during which one or more measurements are taken over a period of time, and then the transmitter is woken up again to wirelessly transmit the one or more measurements in a batch transfer to the dedicated display 104 and / or the display 106. For example, the continuous glucose sensor unit 100 can wake up the wireless transmitter every 5 minutes and transfer data related to the glucose measurements (and any other data) generated over the past 5 minutes, and transfer that data to the dedicated display 104 and / or the display 106. Thereafter, the wireless transmitter may be stopped again to conserve battery life. Although an example of transferring data every 5 minutes has been presented, longer or shorter periods may be used, and it will be understood that the period can be configured by the user via the dedicated display 104 and / or the display 106.

[0039] Data transmitted between the continuous glucose sensor unit 100 and the dedicated display 104 and / or the display 106 can be any type of data related to monitoring the glucose value and the operation of the continuous glucose sensor unit. For example, the continuous glucose sensor unit 100 exchanges calibration data with the dedicated display 104 and / or 106 at startup and periodically to maintain the accuracy of the glucose measurement. The user samples their glucose level using a point-of-care glucose meter, enters the value displayed by the test kit into one of the displays 104 and 106, and that value calibrates the continuous glucose sensor unit 100. Other examples of data exchanged include the amount of current or potential measured by the continuous glucose sensor, e.g., the glucose value converted to mg / dL units, and the timestamp associated with each measurement or value when it was sampled, alerts related to glucose levels exceeding a predetermined threshold, detected defects within the system, etc. Although described as a continuous glucose sensor unit 100, other medical devices may be used with the embodiments of the present disclosure. For example, the continuous glucose sensor unit 100 can be an analyte sensor, and the data transmitted can reflect the analyte value.

[0040] The dedicated display 104 can be a dedicated display for use in combination with the continuous glucose sensor unit 100. In one embodiment, the combination of the continuous glucose sensor unit 100 and the dedicated display 104 can be an approved medical device, such as a Class III medical device. The dedicated display 104 receives data related to glucose levels from the continuous glucose sensor unit 100 at predetermined time intervals. In some embodiments, the dedicated display 104 can include a dedicated application 108 for receiving and displaying at least a portion of the entire data set received from the continuous glucose sensor unit 100. For example, the dedicated display 104 displays the actual glucose level associated with the measurements taken by the sensor. In some embodiments, the display 104 is designed to receive, process, and / or store data, but has a limited user interface, for example, a small display configured to display limited user functions or limited information (e.g., recently measured analyte concentration values and trend arrows). In some examples, the user interface of the display 104 can include a small number of input buttons (e.g., physical buttons or virtual buttons on an interactive display screen) to enable the user to input information (e.g., glucose concentration values from a point-of-care blood glucose device and / or calibration information including settings such as alarms, rules). In some examples, the display 104 can include an audible alarm and / or a vibration motor alarm. By limiting the functionality of the display 104, the display 104 can be easily carried by the user and, moreover, without the need for a larger secondary computing device, track the user's glucose monitoring information (by the sensor unit 100), convey it to the user, and provide the user with an interactive device for providing other important health information and alerts.The display 104 can be coupled to another computing or display device (e.g., display 106) to display enhanced glucose and health-related information that a user may desire to view, such as detailed reports based on retrospective analysis of data.

[0041] In some embodiments, the display 106 can include a dedicated application 108 for receiving and displaying at least a portion of the entire data set received from the continuous glucose sensor unit 100. The display 106 can include one or more third-party applications, such as an approved third-party application 110 (approved for the management of health data) and / or another third-party application 112 (not approved for the management of health data), to which certain data received from the continuous glucose sensor unit 100 is provided or access to which is permitted. In some embodiments, the transmitter of the sensor unit 100, the operating system running on the display 106, or the dedicated application 108 operating on the display 106 can restrict the third-party application from receiving and displaying the actual glucose level. Instead, the third-party application can receive a more general indication of the glucose level, such as whether the glucose level is low, normal, or high. Additional details regarding the types of data that can be sent to and displayed by the dedicated display 104 and the display 106 are provided below.

[0042] The dedicated display 104 includes a processor for calculating the glucose level based on the received measurement values, a memory for storing the glucose level, a wired communication port, and wireless communication circuits such as Bluetooth, Wi-Fi, and RF circuits. Additionally, the dedicated display 104 can determine the historical trend of whether the user's glucose level is decreasing, remaining stable, or increasing. As shown in the example of FIG. 1, the dedicated display 104 presents the glucose reading values over time and displays the actual value of the current glucose level so that the user can easily monitor the glucose level. In the example of FIG. 1, the dedicated display 104 indicates that the current glucose level is 94 mg / dL.

[0043] The display 106 can be any type of display associated with a personal computer, tablet, or smartphone that runs an application for displaying data related to the glucose level. As a result, the display 106 includes hardware components typically associated with a personal computing device, including a processor(s), memory, wireless connection, USB port, and the like.

[0044] Display 106 executes a plurality of applications 108 - 116 related to control and monitoring of glucose monitoring, health information, exercise activities, insulin infusion, eating habits, etc. In one embodiment, display 106 receives the same data that continuous glucose sensor unit 100 transmits to dedicated display 104. Display 106 includes a dedicated application 108 created by the manufacturer or related parties of continuous glucose sensor unit 100. The dedicated application 108, display 106, and / or continuous glucose sensor unit 100 can be an approved medical device. For example, continuous glucose sensor unit 100, dedicated display 104, and dedicated application 108 can be an approved Class III medical device, either alone or in combination. The dedicated application 108 controls the distribution of medical data received from continuous glucose sensor unit 100 to other third - party applications 110 and 114 that execute on display 106 in order to maintain confidentiality obligations and user preferences, as described in more detail below. Although not shown, the dedicated application 108 is connected to other third - party applications 112, 116 and can provide information to them, for example, via an application (such as approved third - party application 110 in the example shown in FIG. 1) with which the dedicated application 108 is directly communicating.

[0045] In the embodiment shown in FIG. 1, the dedicated application 108, or the operating system running on the display 106, provides data related to glucose levels to the authorized third-party application 110. For example, the dedicated application 108 receives glucose data from the continuous glucose sensor unit 100, determines what data sets should be provided to the authorized third-party application 110, and provides that data to the third-party application 110. The user can configure, via the dedicated application 108, what types of medical data are to be provided to the authorized third-party application 110. In this manner, the third-party application 110 receives the same data set as received by the dedicated application 108, or a reduced data set, which may be provided as encrypted data. Although the dedicated application 108 has been described as controlling what data is provided to the third-party application 110, the operating system or other software program running on the display 106 can also separate the data received from the continuous glucose sensor unit 100 and provide it to the applications 108-116, with various restrictions as necessary.

[0046] The approved third - party application 110 can also share data with additional third - party applications 114, 116. The approved third - party application 110 obtains medical data from the continuous glucose sensor unit 100 or the dedicated application 108 and provides it to additional applications 114, 116, which presents a security risk. The system of FIG. 1 can restrict applications 114, 116 from providing medical data to additional applications, network storage sites, or other entities in an unauthorized manner. A user may want some third - party applications, such as the approved third - party application 116, to access the medical data provided to application 110. As an example, the dedicated application 108 provides glucose levels to an approved third - party application 110 that controls an insulin infusion pump. In this example, the user wants the third - party application 110 to share the glucose levels with the third - party application 116 to provide effective feedback and enable more accurate control of insulin infusion.

[0047] The dedicated application 108 can restrict other applications, such as those designed to calculate the distance a user has run during exercise, from receiving glucose data. The third - party application 110 and / or the dedicated application 108 can still import exercise information so that the user can easily track metabolic health information that affects their glucose levels. Additional examples of restricting, encrypting, or otherwise protecting the medical data provided to third - party applications 110 - 116 are described below.

[0048] Refer to FIG. 2A to illustrate an exemplary method for providing glucose data to an application that includes a dedicated application and third-party application(s). For example, the method may be implemented to control the accessibility of a user's confidential health data, such as glucose levels, to third-party applications in order to protect the user's safety and privacy. For example, even when calibration is performed by a sensor to yield a calibration value, a third-party application may be untrustworthy, i.e., may not correctly use data related to glucose levels. In some cases, for example, the transmitter may send raw sensor data and the third-party application may not have the correct formula to convert this raw sensor data to glucose levels. The conversion process may include using a specific calibration for a given individual and sensor, and the third-party application may create an inaccurate glucose level from the raw sensor data without access to this information. This can lead to a potentially dangerous situation where the user does not receive notifications through the third-party application. In some embodiments, for example, the method of FIG. 2A can control the timing of redistributing medical data by delaying data related to glucose values, e.g., before providing it to a third-party application, thereby correcting both of the aforementioned situations. This delay prevents reliance on the accuracy of third-party applications in potentially harmful health situations. Instead, the user will rely on the dedicated display 104 or dedicated application 108 for real-time, i.e., non-delayed, recommendations based on glucose levels.

[0049] In process 200, a continuous glucose sensor samples glucose levels and associates the samples with timestamps. In one embodiment, the timestamp is when the continuous glucose sensor unit 100 generates a glucose data point, although in other embodiments, a batch of samples measured within a certain time range may be timestamped.

[0050] In process 202, the transmitter sends the glucose measurement values and the associated timestamps to dedicated display 104 and / or display 106. The transmitter can send the measurement values and timestamps continuously at defined intervals such as every five minutes, or on demand in response to a request from the user or the device. In one embodiment, the continuous glucose sensor and transmitter can wake up from a low-power sleep state every five minutes, acquire a sample, and transmit the data before returning to the low-power sleep state. In other embodiments, the continuous glucose sensor may make multiple measurements and each measurement value may be sent every five minutes, or the processor in continuous glucose sensor unit 100 may process the measurement values to provide less-than-complete measurement values. As an example, the data processing unit on continuous glucose sensor unit 100 may average the measurement values taken over a period of time and transmit the average value along with the timestamp associated with the time of the first sample, the last sample, or the average sample.

[0051] In one embodiment, the data transmitted from continuous glucose sensor unit 100 also includes other data related to the monitoring of the patient's glucose level. For example, continuous glucose sensor unit 100 transmits sensor calibration information, patient information, the type of sensor used to generate the measurement values, system diagnostic information, rate-of-change information, trends (e.g., an increase, steady state, or decrease in glucose value, or a numerical value representing the rate of change), alarm or alert information, and / or metadata including the system state. Examples of system states include warm-up (which can be the interval while the sensor is warming up and calibrating after installation of a new sensor), active, and offline.

[0052] In some embodiments, the continuous glucose sensor unit 100 encrypts data related to glucose levels before transmission. When Bluetooth communication is used, in addition to the standard encryption provided by the Bluetooth device, encryption may be performed by a data processing unit on the continuous glucose sensor unit 100. Further, in some embodiments, the continuous glucose sensor unit 100 may transmit data only to paired and authenticated devices. One-way or two-way authentication techniques may be used to ensure that the continuous glucose sensor unit 100 transmits data only to authorized devices.

[0053] As an example, a transmitter identifier can be printed on the continuous glucose sensor unit 100. The user may enter this transmitter identifier number into displays 104, 106 as part of a pairing process to authenticate the displays 104, 106 for communication with the continuous glucose sensor unit 100. The continuous glucose sensor unit 100 and the displays 104, 106 exchange a secret security key and a public security key during the pairing process or when the user enters the transmitter identifier. By authenticating and pairing the devices, the system can securely transmit data between the continuous glucose sensor unit 100 and the displays 104, 106 associated with that sensor. For example, multiple users with continuous glucose sensors 100 may be in a public place. In one embodiment, the displays 104, 106 can be paired and authenticated with the continuous glucose sensor unit 100 associated with them so that the user does not receive data from other sensors within the wireless network range.

[0054] In process 204, dedicated display 104 and display 106 receive data related to glucose levels and associated timestamps from continuous glucose sensor unit 100. Display 106 receives glucose measurements and associated timestamps, for example, using dedicated application 108 or the operating system of display 106. Dedicated application 108 receives the data and distributes the data to other applications such as third-party applications 114, 116, etc., according to a set of control means regarding the redistribution of the data described in more detail below. In some example implementations, dedicated application 108 may use encryption, provide less than complete received data, and maintain the confidentiality of the user's medical data using other techniques.

[0055] In process 206, display 106 is a first application, also referred to as dedicated application 108 in the embodiment of FIG. 1, that displays data values. The first application 108 displays each of the received measurements on a graph so that the user can easily view their glucose levels over a period of time. For example, sensor 100 may send glucose level readings to each of displays 104 and 106 every five minutes.

[0056] The first application 108 may run in the background so that the display of glucose values does not actually occur until the user causes the first application to be displayed. The first application 108 receives measurement values and handles any processing required for display. For example, in some embodiments where the continuous glucose sensor unit 100 transmits raw data values and timestamps, the first application 108 can convert the raw data values into measurement units such as mg / dL that are familiar to the user. The process of converting the raw data values may be performed by the continuous glucose sensor unit 100, for example, before transmission to the display 104 and / or the display 106. The first application 108 runs such processes in the background and prepares the measurement values for display, for example, when the user selects the first application and brings it to the foreground.

[0057] The first application 108 may be part of an approved medical device. As a result, in some embodiments, the first application 108 may handle certain types of glucose measurement values that would otherwise be restricted from other applications due to regulatory and / or safety concerns. Such certain types of glucose measurement values may be one or more of real-time glucose measurement values, actionable glucose measurement values, and predicted glucose measurement values, as opposed to retrospective glucose measurement values. In embodiments where the sensor unit 100 sends raw data values to the display 106, the first application 108 can use calibration values entered by the user and appropriate conversion formulas for a particular user and sensor. Thus, the first application 108 maintains the accuracy level required for an approved medical device.

[0058] In some embodiments, the first application 108 alerts the user when the glucose level drops below or rises above a defined level. The first application 108 can intensify the alert gradually based on the current time or the user's activity. For example, an alert that the glucose level has dropped to a low level at night may indicate that the user is asleep and that a louder volume should be used for the alert. In some embodiments, a data processing unit running on the dedicated display 104 or the display 106 samples data from the accelerometer. Based on the accelerometer data indicating that the user's body is inactive, the first application 108 may determine that the user may be asleep, and as a result, the first application intensifies the alarm gradually.

[0059] In addition, the user can set an alert to trigger a warning to the user when their glucose level is trending in a particular direction or has changed by a particular amount within a given period. The operating system or the dedicated application 108 tracks the glucose level and issues an alarm or warning when appropriate. Thus, the user can obtain accurate recommendations regarding the management of their glucose level through the first application 108. For example, the user may choose to eat additional food, exercise, control insulin injection, and / or perform other tasks based on the real-time display of glucose data provided by the first application.

[0060] In process 208, the first application 108 determines the amount of delay to be used before providing data related to glucose levels to third-party applications. The amount of delay can be set by the manufacturer or the user. In some exemplary embodiments, the amount of delay can be, for example, from 5 minutes to 3 hours, although other values may be selected. The delay is to limit third-party applications 110-116 from providing real-time recommendations to the user based on limited data to ensure that accurate health recommendations are made through the first application 108 based on the current glucose level.

[0061] The first application 108 can select the amount of delay based on which third-party application it provides the data to. For example, the approved third-party application 116 may have a shorter delay than other third-party applications, such as third-party application 112 (which is not approved by the provider of the first application 108 in the example of FIG. 1). Additionally, the first application 108 can control the type of data provided to each third-party application. In one embodiment, the third-party application may receive the same data as the dedicated application 108, or limited data such as less data points, averaged data points, or an indicator of whether the glucose level is low, normal, or high without any specific data points. Additional examples of providing data to various applications are provided below.

[0062] In process 210, the first application 108 provides measurement values and associated timestamps to a third-party application after a delay. The third-party application is also referred to as the second application. In one embodiment, the dedicated application 108 provides an indicator of the amount of delay to the third-party application so that the third-party application can show the user the time and / or delay associated with the displayed measurement values. Thus, the third-party application displays the delayed data and an indicator of the amount of delay or the time at which the continuous glucose sensor unit 100 acquired the measurement values.

[0063] According to some implementations, process 210 can occur either by the first application 108 automatically providing data to the second application after a delay or by the second application requesting the data. As an example of requesting data, the second application may be stopped for a period of time and, when executed, may request all past data from the first application 108. In response, the first application 108 provides all data except for data within a predetermined amount of delay. After startup, the second application continues to request data from the first application or the first application automatically provides data to the second application periodically. For example, process 210 can be implemented using an application programming interface (API) of the dedicated application 108 that facilitates the transfer of data to other applications such as a third-party application resident on a smartphone.

[0064] The implementation form of the method of FIG. 2A enables the continuous glucose sensor unit 100 to send data to a display that executes a plurality of applications. The first application 108 can use real-time data for display, for alerting the user, or for other processing. The continuous glucose sensor unit 100 provides data indicating the glucose level and a timestamp indicating when the glucose level was sampled. The first application 108 optionally displays the glucose level and the timestamp and delays for a predetermined amount of time before providing the glucose level and the timestamp to a third party, i.e., a second application. The third party, i.e., the second application, receives and uses the delayed glucose level. The third-party application can use the delayed glucose level, for example, for display. In some embodiments, the third party, i.e., the second application, receives a reduced data set or averaged data as described below. Additionally, in some embodiments, the second application can receive some data in real time and other data after a delay.

[0065] In some implementations of the example method shown in FIG. 2A, the dedicated application 108 receives, in process 104, health data including glucose measurements and associated timestamps, or continuously generated glucose measurements each with an associated timestamp. In process 208, the dedicated application 108 determines the amount of delay to be used before providing any of the received health data (e.g., glucose measurement data) to another third-party application, and determines that the duration between the current time and the timestamp meets the determined amount of delay. The determined amount of delay may be input into the dedicated application or may be a predetermined default amount of delay. For example, the delay can be pre-determined to be 3 hours or some other period considered to make the data retrospective. In such an implementation, in process 210, the dedicated application 108 provides only the retrospective glucose measurement(s) to the third-party application device only after a predetermined amount of delay. Similarly, in some implementations, in process 210, the dedicated application 108 provides the glucose measurement(s) and / or any other health data determined to be delayed to the third-party application only after the determined amount of delay.

[0066] In such an implementation form, for example, the dedicated application 108 can be a medical device software application that configures the mobile computing device to receive and process medical data (such as glucose measurement values (plural) provided by the continuous glucose sensor unit 100, etc.). The third-party application is not an approved medical device software application, that is, it has not been approved by a government regulatory agency with the authority to regulate medical device technology. Therefore, the implementation form of the method in the example of FIG. 2A enables such an unapproved third-party application to access and integrate medical data in a manner that complies with government regulations for medical devices and / or medical data, not only benefiting the end user (such as patient users and their caregiver network, remote monitors, etc.) but also being beneficial to the medical data obtained, processed, and protected by the medical device software application, such as the dedicated application 108, and to display such data on a third-party application that can integrate and enhance the medical data. The third-party application can obtain, process, and output medical data in any way that the third-party application can perform. In an exemplary example, the third-party application can include a meal tracking function that can be integrated with glucose measurement data provided by the dedicated application 108 obtained according to the method in the example of FIG. 2A. The third-party application can integrate glucose data with meal information, for example, by correlating the rise and fall of the user's glucose level with meals, to provide useful insights to the user.

[0067] In some embodiments, for example, the method as in the example of FIG. 2A can include a process for creating a data subset from the received health data, in which a first data subset and a second data subset are generated according to a predetermined criterion (e.g., by splitting the received health data into subsets and / or by generating at least some new or modified data based on the received health data). The method as in the example of FIG. 2A can include a process for controlling which data subsets should be provided to third-party application(s) after determining the delay to be provided to the determined subset.

[0068] Figure 2B shows an exemplary method for controlling the timing of delivery to an application and the categorization of glucose data. The exemplary method of Figure 2B will be described with reference to the system of Figure 1 and the methods of Figures 2A and 5 for illustrative purposes, but may be used in systems and / or processes other than those described in the exemplary embodiments of Figure 2B. As shown in Figure 2B, this exemplary method includes process 204 in which dedicated display 104 and / or display 106 receive data related to glucose levels and associated timestamps from continuous glucose sensor unit 100. The received data can include continuously generated glucose level measurements and the timestamps associated with them. For example, display 106, such as a mobile computing device like a smartphone, receives glucose measurements and associated timestamps using dedicated application 108 or the operating system of display 106. The exemplary method of Figure 2B includes process 252 in which the first application 108 separates the received data into a first data set and a second data set. In some implementations of process 252, the first application divides the continuously generated glucose measurements into first and second data sets based on a predetermined criterion, such as the category or type of data (e.g., that which can be identified by a data field or metadata of the data), the timestamp of the data, the data size, the data source, or other elements associated with the received data. In some implementations of the exemplary method, the received data includes additional health data or medical data, and process 252 includes the first application 108 creating a data set related to the continuously generated glucose measurements, from which the first and second data sets are formed. The exemplary method of Figure 2B includes process 254 in which the first application 108 restricts access to the second data set to one or more of a second application, such as third-party applications 110 - 116.The method that is an example of FIG. 2B includes process 208 where the first application 108 determines the amount of delay to be used before providing data to a third-party application, such as a 5-minute, 3-hour, or other time delay value that can be set by, for example, the manufacturer and / or the user. In some example embodiments of the method of FIG. 2B, process 208 can be implemented before process 252, and in other example embodiments, process 208 can be implemented after process 252, for example, after process 254. The delay restricts third-party applications 110 - 116 from providing real-time recommendations to the user based on limited data to ensure that accurate health recommendations are made through the first application 108 based on the current glucose level. The method that is an example of FIG. 2B includes process 210 where the first application 108 provides the first data set to a second application (e.g., one or more of the third-party applications) after the delay.

[0069] Figure 3 shows an example method for integrating glucose levels with health information. The method of Figure 3, and other methods described herein, are described with reference to the system of Figure 1 for illustrative purposes. The methods of the present disclosure may be used with systems and different components of systems other than those described in the example embodiments. As shown in Figure 1, the third-party application 110 can provide a unified way for the user to access health information. The display 106 can execute a plurality of applications related to health information. As some examples, applications that perform sleep pattern tracking, food and calorie intake monitoring, exercise tracking, calorie burned measurement, blood pressure monitoring, insulin infusion control and recording, heart rate monitoring, nutritional supplement and medication intake monitoring, etc. can be mentioned. These third-party applications, such as third-party applications 114, 116, etc., provide information to the approved third-party application 110 that stores the user's health-related information. Many different types of health information, whether diabetes-related or not, can generally affect glucose levels and an individual's health. Therefore, the method of Figure 3 obtains health information from a third-party application that functions as a health information repository and distribution interface for other applications to deposit and access health information. The dedicated application can integrate the health information from the third-party application for display with the glucose levels, so that the user can track the correlation between the health information and the glucose levels.

[0070] In process 300, the dedicated application 108 obtains glucose data as described above. Next, in process 302, the dedicated application 108 accesses a health application (also referred to herein as a distribution application) that functions as a repository of health information. For example, the health application can include an approved third-party application 110. In some implementations, the third-party application 110 can function as a repository that receives health information from a third-party application 114 that tracks exercise activities and from an approved third-party application 116 that controls insulin administration, and stores it.

[0071] In some implementations of process 302, the dedicated application 108 can access the health application via a standardized application program interface. The dedicated application 108 can check the health application for new data upon the occurrence of an event. The event can be, for example, an amount of time, the startup or start of an application, the detection that a glucose level exceeds a threshold, and other events. As a specific example, the dedicated application can periodically (e.g., every 15 minutes), in response to detecting that the glucose level has risen or fallen to a defined level, in response to detecting the rate of change of the glucose level, on demand in response to a request from the user, or when the dedicated application 108 is executed, access the health application to check for updated data in a predetermined pattern of one or more health characteristics being monitored (e.g., patterns indicating that the person being monitored has eaten, administered insulin, and is exercising or sleeping). In addition, the third-party application 110 or the operating system running on the display 106 can push information to the dedicated application 108 in response to the occurrence of any of the aforementioned events.

[0072] As an example, in process 300, the continuous glucose monitor 100 sends glucose measurement values and associated timestamps to the dedicated application 108. In process 302, when the dedicated application 108 detects that the glucose level has dropped by a specified amount, such as by dropping 50 mg / dL within, for example, a 30-minute interval, it accesses the health application 110. For example, a sharp drop in the glucose level signal may indicate that the user is exercising, which indicates that the health application may have received or be receiving exercise information from another application that tracks exercise activity. In response to detecting a change in the glucose level, the dedicated application 108 obtains health information from the health application 110 in process 304 described below.

[0073] In process 304, the dedicated application 108 obtains health information from the health application via a standardized interface. The health application automatically provides the dedicated application 108 with health information in response to an event as described above or in response to a request from the dedicated application 108. The health application can include a standardized application program interface that provides a list of acceptable commands and a format for any responses. For example, the dedicated application 108 can send commands such as reading exercise activity and receiving a response having two variables, one indicating the type of activity (e.g., running, weightlifting, walking, swimming, etc.) and the other indicating the duration of the activity. Although an example has been presented, it will be understood that other application program interfaces can be used to exchange information between the dedicated application 108 and the health application.

[0074] This health information can include, for example, indicators that the user has taken a particular drug, the dosage of the drug, and the time the drug was taken; nutritional information such as calories and sugar consumed; body measurements such as the user's height, weight, blood pressure, and heart rate; insulin information indicating the time and dosage of insulin injected by the user; and other types of health information.

[0075] As another exemplary example, the dedicated application 108 detects a given rate of change of the glucose level and prompts the user for health-related information. The user directly enters health-related information into a health application such as the dedicated application 108 or an approved third-party application 110. For example, the dedicated application 108 can detect a sudden increase in the glucose level and prompt the user to enter meal information, or detect a decrease in the glucose level and prompt the user to enter exercise activity. Additionally, prompts from other distributed systems such as a cloud that monitors the user's glucose values, or from another application that monitors the glucose values, can trigger prompts to enter or access health information.

[0076] The dedicated application 108 can control and configure the types of health information to be obtained from the health application. As an example, a user may feel secure about the dedicated application 108 accessing, for example, exercise and nutrition information, but may not feel secure about it accessing medical records. In one embodiment, before providing any health information to the user, the dedicated application 108 prompts the user to confirm that the dedicated application 108 can access the desired health information from the health application. The user provides permissions regarding the category of health information or only regarding specific items of health information. For example, one user may permit access to all health information related to the medications taken, while another user may want to limit the medication intake to only insulin. The dedicated application 108 stores the data and creates control means for obtaining the authorized information. Additionally, the dedicated application 108 enables the user to revoke permissions at any time to prevent the dedicated application 108 from accessing some or all of the health information stored by the health application.

[0077] The dedicated application may obtain health information from other applications or from hardware on the dedicated display 104 or the display 106. For example, the display 106 may include an accelerometer. The dedicated application 108 may obtain health information in the form of accelerometer values indicating exercise activity by directly accessing the accelerometer values, accessing the operating system on the display 106, or through any other application.

[0078] In process 306, the dedicated application may display glucose data in conjunction with the health information obtained from the health application 110. An example of a display is shown in FIG. 4, although other display configurations may be used. FIG. 4 is a chart in which glucose levels are shown along the y-axis and time is shown along the x-axis. Curve 402 shows the continuous glucose levels based on data received from a continuous glucose sensor.

[0079] As shown in FIG. 4, the user's continuous glucose level 402 can be exemplified as changing over a certain period starting at 9:30 am. A first example of health information is shown at 408, where the display indicates that a workout was recorded shortly before 10:30 am. A third-party application can track exercise activities and record the start of a workout. For example, in certain implementations of process 304, the health application obtains the workout record from the third-party application while the workout is in progress or after the workout is completed. In this example, the dedicated application 108 may access the health information at 10:30 am and receive an indication that the workout was recorded at 10:25 am. Although not shown, the user can select the workout-recorded icon 408 to display more information about that workout, such as the duration of the workout, calories burned, and any other information that the third-party application provides to the health application and that the dedicated application also has access to. As shown along the continuous glucose level 402, the glucose level dropped sharply shortly after the workout. Thus, the integrated display provides an easy way for the user to correlate glucose levels with specific activities and health information.

[0080] The display also shows an alarm such as that shown at 410, where the glucose level has dropped below a specified amount or is trending downward at a specified rate. Thereafter, at 412, the dedicated application 108 displays integrated health information indicating that a meal has been recorded in the dedicated application 108, the health application, or another application. In one embodiment, the dedicated application 108 accesses the health application again at 11:45 am and determines that new health information in the form of a meal record has been entered into the health application. The user can select the meal-recorded icon 412 and receive any additional information related to the meal, such as the amount of calories and sugar consumed.

[0081] In one embodiment, the dedicated application 108 automatically accesses health information in the example shown in FIG. 4. As illustrated, the glucose level was dropping from approximately 10 AM until 11:30 AM when the level stabilized and began to rise. The dedicated application 108 detects the change from a steadily decreasing glucose level to a constant or rising glucose level and uses this change as a trigger to access health information from the health application 110. This change indicates that the user was engaged in other activities that affected the glucose level. In this example, this other activity is the meal that the user consumed, but it could also be, for example, the user administering glucagon. The process of automatically accessing the health application may be done instead of or in addition to other techniques such as periodic access.

[0082] The user interface 414 can also include additional information so that the user can track their glucose levels and health information. For example, the current glucose level can be indicated at 404, and the current trend of the glucose level can be indicated at 406. The current trend level can be over a certain period, such as the most recent 5 minutes, 10 minutes, or 30 minutes, or another interval. This trend can also be shown as a downward arrow indicating a decreasing glucose level, a horizontal arrow indicating a steady glucose level, or an upward arrow indicating an increasing glucose level. Additionally, although not shown, the display can present other information, such as a red light indicating a caution due to the glucose level being outside the desired range, or a green light indicating that the glucose level is acceptable.

[0083] The integration of health information and glucose levels was described as importing health information into the dedicated application 108, but in a health information application such as any of the third-party applications 110 - 116, the glucose level may be integrated with the health information. For example, a food application enables the user to take a photo of their food and determine the type and nutritional value of the food from the photo. The food application obtains the glucose value from the dedicated application 108 and overlays a chart similar to the chart shown in FIG. 4 on the food image. As a result, the user can easily associate changes in the glucose value with a specific type of food consumed based on the stored food image. In other applications, the integration of the glucose level can enable the application to better identify patients in need of attention, develop a custom analysis theory for patient care, improve the clinical outcomes of diabetes, and monitor the patient risk between doctor clinic visits.

[0084] Figure 5 shows an example method for separating data related to glucose levels for different applications. The continuous glucose sensor unit 100 transmits confidential medical data to displays 104 and 106. The amount and type of data provided to the various applications can be restricted to ensure proper use of the medical data. In one embodiment, the determination regarding the amount and type of data to be distributed can be based on the security level provided by each application and / or user preferences. The method of Figure 5 allows a full set of medical data, including actual glucose levels, timestamps, and other data, to be separated into different sets depending on the application receiving the medical data. By this method, it is possible to protect confidential medical data after it is received from the continuous glucose sensor unit 100 and before it is further distributed to the display device and the applications running on the display device. Unapproved applications often have security flaws that are not acceptable for confidential medical data. For example, an application may redistribute confidential medical information without any restrictions on redistribution, causing a cascading effect that can violate a patient's privacy or, in extreme cases, endanger the patient's health. As another example, an application may be vulnerable to attacks if it does not use encryption or other security forms. Thus, the method of Figure 5 separates data related to glucose levels to control and limit the type of data provided to the various applications.

[0085] In process 500, a first application, such as dedicated application 108, receives data related to glucose levels from continuous glucose sensor unit 100. This data includes, for example, multiple glucose level measurements, associated time stamps indicating when those measurements were taken, as well as calibration information, patient information, the type of sensor used to generate the measurements, system diagnostic information, rate of change information, trends (e.g., an increase, steady state, or decrease in glucose value), alarm or alert information, and / or metadata including system state. This data may include the user's personally identifiable information, calibration data for continuous glucose sensor unit 100, system diagnostic information, and / or other private health information about the patient. This data can also be generated by the user via user input to dedicated application 108 or another application 110 - 116, or can be generated by the operating system or dedicated application 108 pulling data from a server. In some implementations, dedicated application 108 obtains data from continuous glucose sensor unit 100 as described above.

[0086] In process 502, the first application 108 separates its data into a first set and a second set according to a predetermined criterion, such as an established control means. The established control means includes, for example, rules for restricting access to the complete data set for a third-party application, which may be based on user preferences or default control means. For example, the user may establish control means such that the first application 108 provides data to an approved third-party application 110, also referred to as the second application. The first application 108 can include control means based on user input or predetermined default settings based on user preferences to determine what type of data is provided to the second data set for the third-party application. Also for example, the first application 108 can include default control means independent of the user's preferences to establish rules for restricting access to specific data for a third-party application, such as to prevent access to data that could endanger the health of a patient. Examples of data separated into the second data set for the third-party application can include only glucose values averaged over a specified interval (e.g., glucose values sampled over 15 minutes rather than the whole), and / or generalized indicators of glucose levels rather than actual measurements, where the exemplary indicators include low, normal, or high, and the boundaries of what levels constitute low, normal, or high are defined by the system or the user. In some implementations, where the data is determined to be appropriate for both the first data set and the second data set based on a predetermined criterion, the second data set can include the same data as the first data set.

[0087] In one embodiment, process 502 includes separating data into subsets using metadata associated with the type of data. For example, metadata related to calibration of a continuous glucose sensor, system diagnostic information, patient identification information, and / or system state may be excluded from the second data set. Another example of data associated with glucose values is an estimated error range. A continuous glucose sensor unit 100, a dedicated display 104, or a display 106 using a first application 108 may associate the estimated error range with a measurement taken by the sensor. The estimated error range may be included in the first data set, the second data set, or both in some embodiments.

[0088] The first application 108 may separate data in various ways, such as logically in software or physically in memory. For example, the first application 108 may store a replicated copy of the data in memory regarding the first data set and the second data set on a device, such as the sensor unit 100, the display 104, the display 106, or another computing device that is communicating securely with the device on which the first application 108 is running. Or it may store a record in a logical database of which data belongs to each set. Or it can store a single data set such that restricted values are provided only to the first application and not to the second application. In other embodiments, the continuous glucose sensor unit 100 can also separate the data into two sets before transmitting it, or the operating system of the device (e.g., the display 106) on which the first application 108 is running can also perform the separation. Additionally, although described as separating data to provide a single or reduced data set to a particular application, the first application 108 can also restrict other applications (e.g., third - party applications or additional applications as part of a suite of dedicated applications) by giving them access to a particular type of data based on defined rules. The defined rules are, in some implementations, set by the manufacturer and / or the user of the system. In such cases, the type of data to which access is granted may be read by other applications communicating with the first application 108 and not necessarily provided to other applications as described later in process 506.

[0089] In process 504, the first application 108 stores a first data set. For example, the first application 108 can store the first data set on the display 104, the display 106, the sensor unit 100, and / or another computing device that is communicating securely with the device on which the first application 108 is running. In one embodiment, the first data set includes a complete data set received from the continuous glucose sensor unit 100. The first application 108 stores the first data set in the memory of the display 106 and makes it available for display, as shown, for example, in the user interfaces of FIGS. 4 and 6A. Referring to FIG. 6A, the user interface 600 displays a first data set that includes a plurality of continuous glucose levels shown over a period of time to assist the user in monitoring glucose levels.

[0090] In process 506, the first application 108 or the operating system running on the display 106 provides a second data set to a second application. The second data set includes a reduced data set suitable for use by a third-party application. For example, FIG. 6B shows a user interface 602 in which a third-party application is displaying a second data set indicative of a healthy state with normal glucose levels. In one embodiment, the third-party application also displays other health information, such as the user's blood pressure and the time since the user last ate, obtained from the dedicated application 108 or another third-party application.

[0091] The first application 108 can provide a second dataset to a second application by pushing data to the second application, sending a notification to the second application to tell it to request data, or making data accessible in response to a request from the second application. The second dataset may be provided periodically, on demand, or in response to a particular event. For example, when the user launches the second application, the second application requests any updated data, including the second dataset, since the second application was last launched.

[0092] Although two datasets have been described, the system can also create additional sets for each application. The user may choose to provide data related to glucose levels to multiple applications, and each application can receive a dataset based on the permissions given to that application. In this embodiment, the method of FIG. 5 may be executed multiple times to create additional datasets.

[0093] FIG. 7 shows an example method for controlling the redistribution of medical data by encrypting data related to glucose levels. One way to control access to medical data is to encrypt the data before transmitting it from a continuous glucose sensor to other applications or before distributing medical data or a subset thereof. Third-party applications may share that data with other applications, and other applications may also distribute the data to servers, the Internet, and other devices. As a result, when a transmitter or dedicated application provides data related to glucose levels to other applications, it is necessary to control the manner in which other applications can access and redistribute the data. In the example of FIG. 7, dedicated application 108 or sensor unit 100 can encrypt the data before providing it to other applications, improving security and providing a way to prevent unauthorized third parties from using the data without permission. Specifically, unauthorized third parties do not have the key to decrypt the data.

[0094] FIG. 7 relates to encrypting data before providing it to third-party applications. The key for decrypting the data can be provided to authorized third-party applications. As a result, referring to FIG. 1, authorized third-party application 116 can access glucose data through authorized third-party application 110, but authorized third-party application 110 or other third-party applications, such as 114, etc., can be prevented from accessing the data. In this example embodiment, authorized third-party application 110 can function as a pass-through for providing information to other applications.

[0095] The decryption key can be provided to an authorized third party in various ways. For example, in some implementations, the authorized third-party application 116 receives the key for decrypting data directly from the dedicated application 108, through the third-party application 110, or from another source.

[0096] In process 700, a first application such as the display 106 and the dedicated application 108 receives data related to glucose levels from the continuous glucose sensor unit 100 as described above. The first application 108 stores and displays the data in process 702 as described above. For example, the first application displays the continuous levels of glucose over a period of time, the current glucose level, and the trending glucose level.

[0097] In process 704, the first application 108 or the operating system running on display 106 encrypts the glucose data. The encrypted data may include all of the data received from the continuous glucose sensor unit 100, a subset of the data received as previously described with reference to FIGS. 5, 6A, and 6B, and also other data generated by the dedicated application 108. Encryption can be performed using a variety of different techniques, including, among others, public key / private key encryption. The type and amount of data encrypted by the first application 108 or the operating system can vary depending on the application receiving the data. For example, one receiving application may receive all of the data in real time, another receiving application may receive the data after a first delay, such as 15 minutes, and another application may receive the data after a longer delay, such as 3 hours. Also, for example, the first application 108 may encrypt all of the data using one encryption technique with a first encryption key and encrypt a separate subset of the data using another encryption technique with a different encryption key, where the data set and corresponding decryption key can be received only by the intended application. Additionally, encryption software on a third-party application can decrypt only a certain type of data and / or decrypt the data only after a predetermined amount of delay. The first application 108 or the operating system can provide the same or different data to each application such that a certain type of data related to glucose levels can be restricted from any given application. In some embodiments, the first application 108 or the operating system provides the encrypted data in real time but provides the key after a predetermined amount of delay, preventing the receiving application from decrypting the data until the authorized time.

[0098] In process 706, the first application 108 or the operating system may provide the encrypted data to a second application such as an approved third-party health application 110. In some embodiments, the data provided to the second application includes a key for decrypting the information, but in some embodiments, the key is not provided.

[0099] In an example of providing data to a second application without a decryption key, the second application functions as a pass-through entity because it provides the data to another application in process 708 and provides the encrypted data but does not have an independent ability to decrypt it itself. Referring to FIG. 1, an example is shown in which a third-party application 110 provides encrypted data to an approved third-party application 116. It will be understood that although described as a third party or third-party application, neither application 110 nor 116 need be from a third party.

[0100] In process 710, a third party (e.g., third-party application 116 in the above example) that receives encrypted data from a second application (e.g., third-party health application 110 in the above example) may receive a decryption key. The decryption key may be provided to the third party directly from the first application 108, from the operating system running on the display 106, through the third-party application 110, from another application, or from another source such as a server on the Internet. In some embodiments, the first application 108 controls which third parties receive the decryption key, for example, by user configuration, to control the future use of the data.

[0101] The encryption technique may change periodically or on demand such that a new decryption key is required to access the data. Thus, a user can require that the data be encrypted and the key be provided only over a defined period of time. As an example, a physician may use a third-party application to control insulin infusion. The operating system running on the dedicated application 108 or the display 106 encrypts the glucose data and transmits it from the continuous glucose sensor unit 100 through an approved third-party application 110 to an application used by the user's physician's clinic. The physician's application enables healthcare providers to monitor glucose levels and make recommendations to the user. However, if the user switches physicians, the first application can revoke the permission to receive or decrypt the data by not allowing the approved third-party application 110 to provide the data to the physician's application and by changing the encryption key.

[0102] FIG. 8 shows an example method for providing data to an application and monitoring whether the data is up-to-date. One problem that occurs when providing data to multiple displays and multiple applications running on the displays is ensuring that each application or display contains the most recent data. For example, a user may stop an application so that it does not receive data from a first application. In other embodiments, the application may be inactive, the display may be turned off or out of range of the wireless transmission, or the application may receive data in response to a user request. If an application does not receive glucose data over a period of time, the application will not be up-to-date. Thus, the method of FIG. 8 enables backfilling the application with old data to bring the application up-to-date. Up-to-date may mean that the application has all the data that it can utilize. For example, in a situation where an application receives data after a predetermined delay as described above, up-to-date may mean that the application has all the available data up to the predetermined delay.

[0103] In processes 800 and 802 of FIG. 8, display 106 receives glucose data and provides that data to a first application, as described above. In process 804, an operating system that includes first application 108, or that runs on display 106 or in some implementations includes a second application, determines whether the glucose data within the second application is up to date. In one embodiment, first application 108 maintains a record of when it provided glucose data to the second application. The second application acknowledges receipt of the glucose data and enables accurate record keeping of the most recent data provided to and thereby received by the second application. In other embodiments, the second application sends to the first application an indication of the time associated with its most recent glucose value, which may be, for example, periodic, intermittent, or in response to a query or request by first application 108 or the operating system running on display 106. In any of the exemplary embodiments, a determination is made as to whether the second application is up to date and includes the most recent glucose level from continuous glucose sensor unit 100.

[0104] The second application may be considered up to date when it has received data up to any given amount of delay, as described with reference to, for example, FIG. 2A. If the second application is up to date, first application 108 provides any new glucose data in process 810. However, if the second application is not up to date, first application 108 calculates the amount of data to backfill in process 806.

[0105] In one embodiment, the first application 108 determines the amount of backfill data based on a specified time range, for example, by excluding data that is beyond a given age (outside the time range). For example, the first application 108 stores continuous glucose data over a period of several days, weeks, or even months. If the second application has been stopped for a long time, or if it is installed and run for the first time, the first application 108 may backfill data within the past 6 hours. Since 6 hours is only presented as an example, the first application 108 can also use other durations. Also, in some implementations, the user may request that additional data be backfilled to the second application beyond any default range. The user may also enter the start date and end date of the period for which data is to be backfilled to the second application.

[0106] The process 806 for calculating the amount of data to be backfilled may be performed automatically, in response to a request from the user, or after the user is prompted regarding whether to backfill and responds affirmatively. After process 806, in process 808, the first application 108 provides the backfilled data to the second application, which may be implemented using, for example, an application program interface. Once the first application 108 has backfilled the selected range of data to the second application, in process 810, the first application 108 provides any new glucose data to the second application. Alternatively, the first application 108 may first provide the current glucose data and then backfill the previous data.

[0107] Figures 9A and 9B show an example user interface for displaying data related to glucose levels and an indicator of whether the data has been backfilled. In FIG. 9A, the user interface 900 provided by the first or second application may include a chart in portrait mode that illustrates glucose levels over a period of time as described in the embodiments described herein. However, when the user rotates the display 106 to landscape mode, the user interface 902 shows an indicator 904 that data within a given range has been backfilled.

[0108] The display can also indicate that data has been backfilled using other techniques. For example, the line indicating the sampled glucose levels may use a different color or pattern in intervals that include backfilled data. A user who uses a second application for alerts when the glucose value drops below a specified level may wonder why an alert was not received from the second application at times corresponding to low glucose values. However, if the display uses lines of different colors or otherwise characterizes the line to indicate that data has been backfilled, the user can confirm that the second application did not have a glucose value when an alert should have occurred.

[0109] The embodiments of FIGS. 8, 9A, and 9B were described as backfilling a second application, but it will be understood that the continuous glucose sensor unit 100 can also directly provide data backfilled to a first application, a second application, or a dedicated display 104. For example, the dedicated display 104 or the display 106 may be outside the wireless range of the continuous glucose sensor unit 100. In another example, the user may stop the dedicated application 108. In either situation, the dedicated display 104 or the dedicated application 108 may not have the current glucose value. The continuous glucose sensor unit 100 can detect that the glucose value is old and provide backfilled data over a specified period in the same manner as described in FIG. 8. That is, the continuous glucose sensor unit 100 can transmit data starting from when it last received confirmation that the dedicated display 104 or the display 106 received glucose data. Alternatively or additionally, the dedicated display 104 or the display 108 can detect that it only stores old data and request a backfill of glucose values over a given period.

[0110] FIG. 10 shows an example method for determining a compliance level of a medical device and providing data related to a glucose level to the medical device based on that compliance level. The example of FIG. 10 illustrates a method for controlling the type of data provided to another application based on the compliance level of the other application. This ensures that the dedicated application 108 provides data only to trusted applications or provides a reduced data set to a particular application compared to others.

[0111] In process 1000, display 106 receives glucose data from continuous glucose sensor unit 100 as described above. In process 1002, dedicated application 108 determines the compliance level of another application or third party that requests access to data related to glucose levels. The dedicated application 108 can determine the compliance level in various ways. For example, the dedicated application 108 accesses a list of applications stored in memory or online that indicates whether the application is approved by the Food and Drug Administration as a medical device, and if approved, accesses the corresponding classification of that medical device. In another embodiment, the application may provide an indication of its classification and security level to the dedicated application 108.

[0112] For example, when the compliance level of the application is high, such as for a Class III medical device, the dedicated application 108 provides the glucose data to the application in process 1004. For example, the dedicated application 108 can provide data related to glucose levels to the application in real time. However, when the compliance level is lower, such as when the application is not a medical device, the dedicated application 108 provides data related to glucose levels with restrictions in process 1006. For example, the restrictions can include encrypting the data, providing a reduced data set, delaying the data, or any combination of the embodiments described above with reference to FIGS. 1-10. In both situations of providing data without restrictions in process 1004 or providing data with restrictions in process 1006 (e.g., as described with reference to FIGS. 2, 5, and / or 7), the user may control the preference for which application should receive the data and what data set should be provided.

[0113] FIG. 11 shows an example system for monitoring glucose levels. The system of FIG. 11 may be used in conjunction with the system of FIG. 1 and the foregoing embodiments. Specifically, any of the methods of the present disclosure can be used in conjunction with any of the systems of the present disclosure. However, it will be understood that the methods of the present disclosure can be used with other system architectures and that the systems of the present disclosure can implement other methods.

[0114] As in the embodiment of FIG. 1, the system shown in FIG. 11 includes a continuous glucose sensor unit 100, wireless connections 102a - b, a dedicated display 104, and one or more displays 106 that execute an application. The dedicated display 104 may be connected to a computer 1102 using either a wired or wireless connection. The computer 1102 can be, for example, a personal computer, tablet, laptop, smartphone, or server. Additionally, the dedicated display 104 may be connected to the display 106, and the display 106 may be connected to the computer 1102.

[0115] The computer 1102 and the display 106 may be connected to a cloud storage 1104 that can store data related to glucose values, health information, system calibration, and other information related to continuous glucose monitoring for a long period of time. The cloud storage 1104 includes a plurality of storage devices, computers, and network connections. Communication between the dedicated display 104, the computer 1102, the display 106, and the cloud storage 1104 may use encryption to prevent unauthorized access to medical data.

[0116] Cloud storage 1102 is connected to a backend system 1106. The backend system 1106 provides technical support 1108 for users who configure and use a continuous glucose monitor. The backend system 1106 also monitors system information such as the version of software running on the continuous glucose monitor 100, dedicated display 104, display 106, and computer 1102. The backend system 1106 provides updates on demand or pushes updates to the dedicated display 104, display 106, continuous glucose sensor unit 100, and other system components that use network connections in a secure manner.

[0117] Another display 1110 may also be connected to the cloud storage 1102. The display 1110 may include dedicated applications 1112 and one or more third-party applications 1114 similar to those described above. The user of the continuous glucose sensor unit 100 may permit additional people to monitor their glucose levels and other health information. For example, a child may wear a continuous glucose monitor and have an associated dedicated display 104 and display 106. This child may designate one or both of their parents as additional users who can access the child's glucose levels and other health information using the display 1110. The display 1110 may be, for example, a parent's smartphone.

[0118] The dedicated display 104 or display 106 provides continuous glucose data to the cloud storage 1104. The cloud storage 1104, the backend system 1106, and / or the display 1102 can monitor the continuous glucose data. The display 1102 receives and displays the continuous glucose values as described above, either without restrictions similar to the dedicated application 108 or under the influence of restrictions similar to a third-party application. The restrictions may, in some embodiments, be set by the dedicated display 104 or display 106. In other embodiments, the display 1110 sets restrictions on the data it receives through an authenticated process between the user of the continuous glucose monitor 100, the user of the display 1100, and the backend system 1106. For example, the user may contact the backend system to establish authentication (e.g., by communication via a computer or phone), such as calling a representative of the technical support 1108 and answering security questions before establishing the proper operation of the system, or performing this process online. Once completed, the user of the continuous glucose sensor unit 100 or the user of the display 1110 may be restricted in their ability to change the data received by their device or the operation of the system. This can prevent the dedicated display 104 or display 106 from restricting the monitoring by the display 1110. For example, there may be situations where the user of the sensor unit 100 and / or the display 104 or 106, who must continuously maintain responsible monitoring, wishes to restrict the monitoring using the display 1110, such as when a child eats a lot of sugary foods that can cause a rapid increase in glucose levels at a birthday party. The processes and control means of the present disclosure regarding user authentication and data access consider various use cases such as the foregoing.

[0119] FIG. 12 shows an example computer for monitoring glucose levels. The continuous glucose sensor unit 100, dedicated display 104, display 106, computer 1102, cloud storage 1104, backend system 1106, and display 1110 may all include the components shown in FIG. 12.

[0120] The computer may include one or more hardware components, such as a central processing unit (CPU) 1221, random access memory (RAM) module 1222, read-only memory (ROM) module 1223, storage 1224, database 1225, one or more input / output (I / O) devices 1226, and interface 1227. Alternatively and / or additionally, the computer may include one or more software components, such as a computer-readable medium including computer-executable instructions for performing the methods associated with the example embodiments. It is contemplated that one or more of the hardware components listed above may be implemented using software. For example, storage 1224 may include software segments associated with one or more other hardware components. The components listed above are merely examples and are not intended to be limiting.

[0121] CPU 1221 may include one or more processors, each configured to execute instructions and process data to perform one or more functions associated with the computer for monitoring glucose levels. CPU 1221 may be communicatively coupled to RAM 1222, ROM 1223, storage 1224, database 1225, I / O device 1226, and interface 1227. CPU 1221 may be configured to execute a sequence of computer program instructions for performing various processes. The computer program instructions may be loaded into RAM 1222 for execution by CPU 1221.

[0122] RAM 1222 and ROM 1223 may each include one or more devices for storing information associated with the operation of CPU 1221. For example, ROM 1223 may include a memory device configured to access and store information associated with controller 1220, including information for identifying, initializing, and monitoring the operation of one or more components and subsystems. RAM 1222 may include a memory device for storing data associated with one or more operations of CPU 1221. For example, ROM 1223 may load instructions for execution by CPU 1221 into RAM 1222.

[0123] Storage 1224 may include any type of mass storage device configured to store information that CPU 1221 may require to execute a process according to an embodiment of the present disclosure. For example, storage 1224 may include one or more magnetic and / or optical disk devices, such as a hard drive, CD-ROM, DVD-ROM, or any other type of mass media device.

[0124] Database 1225 may include one or more software and / or hardware components that cooperate to store, organize, sort, filter, and / or array data used by CPU 1221. For example, database 1225 may obtain data related to glucose level monitoring, associated metadata, and health information. Database 1225 is assumed to be capable of storing additional information and / or information different from that listed above.

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

[0126] The interface 1227 may include one or more components configured to transmit and receive data via a communication network such as, for example, 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, the interface 1227 may include one or more modulators, demodulators, multiplexers, demultiplexers, network communication devices, wireless devices, antennas, modems, and any other type of device configured to enable data communication via a communication network.

[0127] Any combination of one or more computer-readable media may be utilized. 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 suitable combination of the foregoing. More specific examples (non-exhaustive list) of the computer-readable storage medium include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The program code embodied on the computer-readable media may be transmitted using any appropriate medium including, but not limited to, wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0128] The computer program code for may be written in any combination of one or more programming languages including object-oriented programming languages such as Java (registered trademark), Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code may be executed entirely on the computing unit.

[0129] FIG. 13 illustrates an example method for verifying the accuracy of information stored by a third-party application. When distributing confidential medical data, there is a problem that the recipient may not accurately remember the data, or may not remember any data at all due to system errors. This can lead to problems such as false recommendations regarding glucose levels and user confusion when the recipient displays different data from the provider. In one example, the dedicated application 108 needs to send data to the health application and verify that the health application has accurately received and stored the data.

[0130] In process 1300, the dedicated application 108 writes glucose data to the health application. The health application can be any type of application that receives glucose data from the dedicated application 108. The dedicated application 108 can write actual measurement values or test data to the health application.

[0131] In process 1302, the dedicated application 108 reads back the glucose data from the health application. Using the application programming interface, the read data can be requested again from the health application. By reading back the written value, the dedicated application 108 can verify in process 1304 that the data related to the glucose value has been properly received, processed, and stored by the third-party health application. If the read data does not match the written data, the dedicated application 108 issues a notification to the user, or the health application determines that it should not receive data related to glucose values in the future. In one embodiment, the dedicated application 108 writes a predetermined test glucose value and time to the health application. Then the dedicated application 108 reads back the glucose value associated with the predetermined time and determines whether the two match.

[0132] FIG. 14 shows an example method for providing data from a third-party application to a dedicated application. This method can be used to verify whether the data and / or data source is trustworthy and reliable. By implementing this method, the system of the present disclosure can receive data from an external device or system in an automated manner with security measures and without the need for manual data entry by the user. For example, the continuous glucose sensor unit 100 may need to input glucose values from an external glucose meter device such as a one-point blood glucose (BG) meter with respect to maintaining the accuracy of glucose measurements through initial calibration and / or periodic calibration updates or verification of the continuous glucose sensor unit 100, or may benefit therefrom. In such a case, the user samples their glucose level using a blood glucose meter that can send the user's test results to the user's mobile device (e.g., display 106) and / or the cloud. The BG value determined by the external blood glucose meter device can be used for the initial calibration or periodic calibration of the continuous glucose sensor unit 100. The user's mobile device (e.g., display 106) includes an application (e.g., third-party application 112 or 114) that collects and at least temporarily stores the BG value, and the BG value may be provided to a health application (e.g., third-party health application 110) on the user's device. As described above, inaccurate measurements can lead to various potentially dangerous situations where the user acts based on incorrect glucose readings and / or does not receive notifications to perform appropriate actions or receives false positive notifications regarding their physiological condition. Therefore, accurate glucose values for the calibration of the continuous glucose sensor unit 100 are very important.Therefore, the method of FIG. 14 provides an essential verification function in the process of transferring such data from a third-party application to a dedicated application of a user associated with the continuous glucose sensor unit 100, while at the same time automating the data transfer and minimizing the risk of inaccurate data due to user data entry errors, thereby also creating convenience and safety for the user. For example, with regard to the calibration of the continuous glucose sensor unit 100, the method can reduce potential errors such as when the user reads a BG value of "68" (mg / dL) from a one-point blood glucose meter and enters "98" (mg / dL) into the user interface of a mobile device (e.g., display 106).

[0133] In process 1400, the dedicated application 108 requests data (e.g., blood glucose data) from a health application, also referred to in this example as the third-party health application 110 shown in FIG. 1. The health application 110 can be any type of application that receives blood glucose data from a point-of-care blood glucose meter, data storage on a device or in the cloud, or via another application, also referred to in this example as the third-party applications 112, 114, or 116 shown in FIG. 1. In some implementations of process 1400, the dedicated application 108 requests data from other third-party applications 112, 114, or 116. The dedicated application 108 can request data by accessing the health application 110 (or in some implementations, other third-party applications) through a standardized application program interface. The dedicated application 108 can request data from the health application 110 based on the occurrence of an event. The event can be, for example, a specific time or amount of time since a previous data request or event, the startup or initiation of the dedicated application 108 or the health application 110, or another event. In one specific example, the dedicated application 108 accesses the health application 110 to request glucose data daily at a specific time in the morning and at a specific time in the evening.

[0134] Additionally or alternatively, in process 1401, the dedicated application 108 receives from the health application 110 a communication that data (e.g., blood glucose data) is available for reading. In some implementations of process 1401, the dedicated application 108 receives from other third-party applications 112, 114, or 116 a communication that data is available.

[0135] In process 1402, dedicated application 108 obtains blood glucose data from health application 110 or other third-party applications. In some implementations, dedicated application 108 can obtain data through a standardized application program interface that provides a list of acceptable commands and the format for any responses regarding the application it is communicating with. For example, dedicated application 108 can send commands such as reading a blood glucose value and receiving a response with two or more variables (a numerical value and the unit of the associated blood glucose measurement, as well as something indicating the timestamp when the measurement was obtained). Although an example has been presented, it will be understood that other application program interfaces can be used to exchange information between dedicated application 108 and third-party applications. In some implementations, health application 110 or the operating system running on user's display 106 can push blood glucose data to dedicated application 108 after process 1400 or 1401, or in response to the occurrence of any of the aforementioned events.

[0136] The blood glucose data obtained includes metadata associated with each blood glucose measurement, such as the unit of the measurement (e.g., a concentration unit such as mg / dL), the timestamp when the measurement was obtained, parameters associated with the measurement (e.g., information associated with chemical analysis, etc.), the code associated with the external blood glucose meter device or the test strip used in the meter, and so on.

[0137] In process 1404, dedicated application 108 verifies the blood glucose data obtained from health application 110 or other third-party applications to detect whether it is obtained from an authorized source. In some implementations, dedicated application 108 analyzes the metadata to verify the source of the blood glucose measurement data. For example, dedicated application 108 processes the metadata to identify one or more codes associated with an external blood glucose meter device or test strips used in the meter, and checks against a list of authorized devices and / or test strips to perform a validity verification of the reliability of the blood glucose measurement data. If the identified code matches an authorized device or related component, dedicated application 108 approves the blood glucose data.

[0138] In an optional process 1406, the dedicated application 108 presents a notification to the user to accept the verified blood glucose data for calibration of the continuous glucose sensor unit 100. In some implementations, the notification is presented as a pop-up window of the dedicated application 108 on the display screen of the user's device (e.g., display 106) that runs the dedicated application 108. In some implementations, the notification is presented on the user's device (e.g., display 106) as a notification in the form of a banner, badge, sound, and / or alert via an operating system operating on the user device. In some implementations, the notification is to the user via a text message, email, IM, automated call, or other communication. In some embodiments, the notification includes an option for the user to respond affirmatively or negatively regarding acceptance of the verified blood glucose data, and / or an option for the user to manually enter the blood glucose data. If the user responds negatively, or chooses to manually enter the blood glucose data, the dedicated application 108 may provide an interface for receiving the data entry of the blood glucose data by the user.

[0139] FIG. 15 shows a schematic diagram depicting an example of a user interface of a dedicated application 108 that presents a notification to accept verified blood glucose data for calibration of a user's continuous glucose sensor unit. In display screen 1501, the user interface presents options for the user to respond affirmatively (“Yes”) or negatively (“No”) regarding the use of the verified blood glucose data by the dedicated application 108. In this example, a BG value of “107 mg / dl at 9:59 AM” obtained from a “Verio meter” is shown as having been obtained from a “Health app”. If the user selects “Yes”, the user interface displays a display screen 1502 indicating a return to the main view of the dedicated application 108, which in this example is shown as displaying the current glucose value and trend from the continuous glucose sensor unit 100. If the user selects “No”, the user interface displays a display screen 1503 presenting a prompt for entering the BG meter value to be used for calibration.

[0140] FIG. 16 shows an illustration of another example of a display screen of the home screen or main view 1502 of the dedicated application 108. In the example shown in FIG. 16, the home screen can present health information such as insulin on board, exercise, and nutrition information in various formats including text and / or graphical interfaces. Such health information can be presented near the glucose data provided by the continuous glucose sensor unit 100, as previously described with respect to FIGS. 4, 6A, 9A, and 9B.

[0141] Referring back to FIG. 14, in process 1408, the dedicated application 108 sends the verified data to the continuous glucose sensor unit 100.

[0142] FIG. 17 shows an exemplary schematic diagram of the data flow between an external sensor device (e.g., a one-point blood glucose meter) and a dedicated application 108 on a user's device (e.g., in this example, on this smartphone). As shown in this schematic diagram, the one-point blood glucose meter wirelessly transmits blood glucose data to a third-party application (e.g., an approved third-party application 116 shown in FIG. 1, etc.) for processing, storage, display, and / or other purposes. The third-party application then provides the blood glucose data to the dedicated application 108 via a health application operating on the user's device. For example, upon receiving the blood glucose data from the third-party application, the health application can store the blood glucose data in storage within the cloud and manage storage and accessibility using the health application's database. The health application can provide the blood glucose data to the dedicated application according to the method of FIG. 14.

[0143] FIG. 18 shows a schematic view of a user using a plurality of body-worn sensors and / or actuator devices that can provide health information related to glucose data monitored by the continuous glucose sensor unit 100. Examples of body-worn sensor devices include medical devices such as pedometers, pulse oximeters, insulin pumps, gastric pacemakers, blood pressure monitors, ECG monitors, and cardiac pacemakers. In the example of FIG. 18, the user is wearing the continuous glucose sensor unit 100, which communicates via BLE with the user's mobile device (e.g., display 106 of a smartphone, etc.), where the data received from the sensor unit 100 is managed by a dedicated application 108. The user is also using an insulin pump that communicates with the user's smartphone using third-party applications such as third-party applications 110-116. In a closed-loop environment, tertiary sensors and devices are not considered. However, if third-party applications resident on the smartphone that are directly or indirectly associated with these tertiary sensors and devices can connect and interact with the dedicated application, the information collected and / or processed by the third-party applications can be included and utilized in the dedicated application for the user's health management. For example, a third-party application associated with a heart rate monitor (HRM) can aggregate information from the HRM and provide that information to a health application or the dedicated application of the sensor unit 100. Using the technology described above, heart rate data can be stored and displayed simultaneously with glucose information sensed from the continuous glucose sensor unit 100. In this manner, for example, a patient user can view this information and then infer knowledge. Also, for example, secondary observers such as healthcare providers may be provided access to the information, and this healthcare provider can utilize the information as determined by the provider for various purposes ranging from information provision to data analysis.

[0144] Furthermore, for example, when a patient user utilizes an exercise monitor such as a BLE pedometer or other exercise-related device, the dedicated application 108 and / or the health application 110 can aggregate the pedometer data into a comprehensive dataset that includes glucose data, HRM data, and data from other sensors or actuators. By way of illustration, in such an event, when exercise is being performed and the exercise sensor provides information to the user's mobile device, the information obtained from the exercise device is aggregated within the dataset and analyzed to align or associate it with things such as the sensed glucose level from the exercise data. Thus, since the system environment of the present disclosure automatically enters annotations or event markers within the patient user's glucose monitoring application, there is no need for the patient user to do so.

[0145] The system environment of the present disclosure can perform automated data entry of events and activities with a significant level of detail and granularity that may be inconvenient or impossible for the patient user to do themselves, and when it occurs at that predetermined interval. For example, the predetermined interval may be, such as for an event at a predetermined interval or time limit, for example, the heart rate per minute at a granularity of 15-second intervals, or the calories burned every 30 seconds, etc., and the threshold across this interval can trigger the automated data entry of events including glucose data in accordance with the techniques described in this patent document.

[0146] Also, information aggregated from such a tertiary sensor and / or actuator device may provide information regarding potential motion artifacts of data collected from other sensing devices including the continuous glucose sensor unit 100. Such motion artifacts may be in the form of true / false presence, and / or data confidence level, and / or scale value. This information may be sent or provided to the continuous glucose sensor unit 100, or the technical support service of the sensor unit 100, via, for example, a dedicated application 108 or a health application 110, for further processing and decision-making, and / or as an input to a data processing algorithm.

[0147] It will be understood that each block of the flowchart diagrams and / or block diagrams, as well as combinations of blocks in the flowchart diagrams and / or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other provider data processing apparatus, create means for implementing the functions / acts specified in the block(s) of the flowchart and / or block diagram.

[0148] The term first application has been referred to as dedicated application 108, but it will be understood that the first application may be any one of third-party applications 110 to 116, or another application. Similarly, the second application has been referred to as approved third-party application 110 and health application, but the second application may also be dedicated application 108, any one of third-party applications 112 to 116, or another application. Further, certain applications 110 to 116 have been described as third-party applications, but it will be understood that applications 110 to 116 do not need to be provided by a third party.

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

Examples

[0150] The following examples illustrate some embodiments of the present technology. Other embodiments of the present technology that serve as examples may be presented before the following clenched-fist examples or after the following listed examples.

[0151] In some embodiments of the present technology (Example 1), a method for monitoring glucose values includes receiving a glucose measurement value and a timestamp transmitted via a wireless connection, where the measurement value is related to a certain amount of glucose; displaying the measurement value by a first application upon reception; determining when the duration between the current time and the timestamp meets a predetermined delay amount; and providing the measurement value to a second application only after the predetermined delay amount.

[0152] Example 2 further includes receiving a plurality of continuously generated glucose measurement values; providing the plurality of continuously generated glucose measurement values to a first application; delaying each of the plurality of continuously generated glucose measurement values by a predetermined amount of time after each is received; and providing each of the plurality of continuously generated glucose measurement values to a second application after the delay, and includes the method described in Example 1.

[0153] Example 3 includes the method described in Example 1, where the glucose measurement value is provided to the second application after a delay in response to the execution of the second application.

[0154] Example 4 includes the method described in Example 1, where the delay is between 5 minutes and 3 hours.

[0155] Example 5 further includes obtaining metabolic health information from the second application, where the metabolic health information affects the glucose level; and using the first application to display the glucose measurement value simultaneously with the metabolic health information, and includes the method described in any one of Examples 1 to 4.

[0156] Example 6 is to obtain metabolic health information using a first application, where the metabolic health information affects glucose levels, and to further include displaying glucose measurement values simultaneously with the metabolic health information using the first application, and includes the method according to any one of Examples 1 to 4.

[0157] Example 7 is to create a dataset related to continuous glucose monitoring, divide the dataset into a first dataset and a second dataset, provide the first dataset and the second dataset to a first application, restrict access to the second dataset by a second application, and further include providing the first dataset to the second application, and includes the method according to Example 1.

[0158] Example 8 includes the method according to Example 7, where restricting access includes not sending the second dataset to the second application.

[0159] Example 9 further includes encrypting the first dataset before providing the first dataset to the second application, and includes the method according to any one of Examples 1 to 4, 7, or 8.

[0160] Example 10 further includes determining, by the first application, a data subset related to continuous glucose monitoring for providing to the second application, and includes the method according to any one of Examples 1 to 4, 7, or 8.

[0161] Example 11 further includes restricting the second application from further distributing the measurement values to additional applications, and includes the method according to any one of Examples 1 to 4, 7, or 8.

[0162] Example 12 includes providing a time stamp to a second application, reading measurement values and the time stamp from the second application, comparing the read measurement values with the measurement values provided to the second application, determining whether the read measurement values match the provided measurement values, comparing the read time stamp with the time stamp provided to the second application, and determining whether the read time stamp matches the provided time stamp, and includes the method according to any one of Examples 1 to 4, 7, or 8.

[0163] Example 13 includes further configuring whether to provide measurement values to a second application, and includes the method according to any one of Examples 1 to 4, 7, or 8.

[0164] Example 14 includes encrypting measurement values before providing the measurement values to a second application, transmitting the encrypted measurement values from the second application to a third application, and providing a key for decrypting the encrypted measurement values to the third application, and includes the method according to any one of Examples 1 to 4, 7, or 8.

[0165] In some embodiments of the present technology (Example 15), a system for monitoring glucose values includes a sensor configured to obtain a glucose measurement value of a certain amount of glucose; a wireless transmitter configured to transmit the glucose measurement value and a time stamp associated with the glucose measurement value; a computing device including a wireless receiver configured to receive the glucose measurement value; and a computer-readable medium. A first application that, when executed by a processor, displays the glucose measurement value and determines when the duration between the current time and the time stamp satisfies a predetermined delay amount, and a second application that, when executed by the processor, receives the glucose measurement value after the predetermined delay amount are included in the computer-readable medium.

[0166] Example 16 includes the system described in Example 15, further comprising a second computing device configured to receive glucose measurement values and display the glucose amount in real time.

[0167] Example 17 includes the system described in Example 15, wherein the computing device includes a smartphone.

[0168] Example 18 includes the system described in Example 15, wherein a wireless receiver receives a plurality of continuously generated glucose measurement values, a processor provides the plurality of continuously generated glucose measurement values to a first application, the processor delays each of the plurality of continuously generated glucose measurement values by a predetermined amount of time, and the processor provides each of the plurality of continuously generated glucose measurement values to a second application after the delay.

[0169] Example 19 includes the system described in any one of Examples 15 to 18, wherein the glucose measurement values are provided to the second application after a delay in response to the execution of the second application.

[0170] Example 20 includes the system described in any one of Examples 15 to 18, wherein the delay is between 5 minutes and 3 hours.

[0171] Example 21 includes the system described in any one of Examples 15 to 18, wherein a processor obtains metabolic health information that affects the glucose level from the second application, and the first application displays the glucose measurement values simultaneously with the metabolic health information.

[0172] Example 22 includes the system described in any one of Examples 15 to 18, wherein a processor obtains metabolic health information using the first application, the metabolic health information affects the glucose level, and the first application displays the glucose measurement values simultaneously with the metabolic health information.

[0173] Example 23 includes the system described in Example 15, further configured such that a processor creates a dataset related to continuous glucose monitoring, divides the dataset into a first dataset and a second dataset, provides the first dataset and the second dataset to a first application, restricts access by a second application to the second dataset, and further provides the first dataset to the second application.

[0174] Example 24 includes the system described in Example 23, restricted in that a second application does not send the second dataset to the second application.

[0175] Example 25 includes the system described in any of Examples 15 - 18, 23, or 24, where the first dataset is encrypted before being provided to the second application.

[0176] Example 26 includes the system described in any of Examples 15 - 18, 23, or 24, further configured such that a first application determines a data subset related to continuous glucose monitoring for providing to a second application.

[0177] Example 27 includes the system described in any of Examples 15 - 18, 23, or 24, further restricted in that a second application is restricted from further distributing measurements to an additional application.

[0178] Example 28 includes the system according to any one of Examples 15 to 18, 23, or 24, which is further configured such that a first application provides a time stamp to a second application, reads measurement values and a time stamp from the second application, compares the read measurement values with the measurement values provided to the second application to determine whether the read measurement values match the provided measurement values, compares the read time stamp with the time stamp provided to the second application, and determines whether the read time stamp matches the provided time stamp.

[0179] Example 29 includes the system according to any one of Examples 15 to 18, 23, or 24, which is further configured to receive an input for controlling whether the processor provides measurement values to a second application.

[0180] Example 30 further includes the system according to any one of Examples 15 to 18, 23, or 24, where the measurement values are encrypted before being provided to the second application, the encrypted measurement values are transmitted from the second application to a third application, and a key is provided to the third application to decrypt the encrypted measurement values.

[0181] In some embodiments of the present technology (Example 31), a computer-readable medium containing instructions that, when executed by a processor, perform a method for monitoring glucose values. The method includes receiving glucose measurement values and a time stamp transmitted via a wireless connection, where the glucose measurement values indicate a certain amount of glucose, providing the glucose measurement values to a first application for display, determining when the duration between the current time and the time stamp meets a predetermined delay amount, and providing the glucose measurement values to a second application after the predetermined delay amount.

[0182] Example 32 includes the computer-readable medium described in Example 31, which, when executed by a processor, receives a plurality of successively generated glucose measurements, provides the plurality of successively generated glucose measurements to a first application, delays each of the plurality of successively generated glucose measurements by a predetermined amount of time after receiving each of them, and further provides each of the plurality of successively generated glucose measurements to a second application after the delay.

[0183] Example 33 includes the computer-readable medium described in Example 31, which, when executed by a processor, further includes instructions to provide a glucose measurement to a second application after a delay in response to the second application being executed.

[0184] Example 34 further includes the computer-readable medium described in Example 31, where the delay is between 5 minutes and 3 hours.

[0185] Example 35 includes the computer-readable medium described in any one of Examples 31 to 34, which, when executed by a processor, further includes instructions to obtain metabolic health information that affects glucose levels from a second application and use a first application to display a glucose measurement simultaneously with the metabolic health information.

[0186] Example 36 includes the computer-readable medium described in any one of Examples 31 to 34, which, when executed by a processor, further includes instructions to obtain metabolic health information that affects glucose levels using a first application and use the first application to display a glucose measurement simultaneously with the metabolic health information.

[0187] Example 37 includes the computer-readable medium described in Example 31, which, when executed by a processor, creates a dataset related to continuous glucose monitoring, divides the dataset into a first dataset and a second dataset, provides the first dataset and the second dataset to a first application, restricts access by a second application to the second dataset, and further includes instructions to provide the first dataset to the second application.

[0188] Example 38 includes the computer-readable medium described in Example 37, in which access is restricted by the second application not sending the second dataset to the second application.

[0189] Example 39 includes the computer-readable medium described in any of Examples 31 - 34, 37, or 38, which, when executed by a processor, further includes instructions to encrypt the first dataset before providing the first dataset to the second application.

[0190] Example 40 includes the computer-readable medium described in any of Examples 31 - 34, 37, or 38, which, when executed by a processor, further includes instructions to determine a data subset related to continuous glucose monitoring for providing to the second application.

[0191] Example 41 includes the computer-readable medium described in any of Examples 31 - 34, 37, or 38, which, when executed by a processor, further includes instructions to restrict the second application from further distributing measurement values to additional applications.

[0192] Example 42 includes a computer-readable medium according to any of Examples 31-34, 37, or 38, which, when executed by a processor, provides a timestamp to a second application, reads measurement values and a timestamp from the second application, compares the read measurement values with the measurement values provided to the second application to determine whether the read measurement values match the provided measurement values, compares the read timestamp with the timestamp provided to the second application, and further includes instructions for determining whether the read timestamp matches the provided timestamp.

[0193] Example 43 includes a computer-readable medium according to any of Examples 31-34, 37, or 38, which, when executed by a processor, further includes instructions for configuring whether to provide measurement values to a second application.

[0194] Example 44 includes a computer-readable medium according to any of Examples 31-34, 37, or 38, which, when executed by a processor, further includes instructions for encrypting measurement values before providing them to a second application, transmitting the encrypted measurement values from the second application to a third application, and providing a key for decrypting the encrypted measurement values to the third application.

[0195] In some embodiments of the present technology (Example 45), a method for displaying data related to glucose values and metabolic health information using a continuous glucose monitor includes obtaining data related to glucose levels using a first application and accessing a second application configured to store metabolic health information, where the metabolic health information affects the glucose level, accessing the metabolic health information from the second application, and displaying the data related to the glucose levels simultaneously with the metabolic health information.

[0196] Example 46 includes the method described in Example 45, in which data related to glucose levels and metabolic health information are displayed using a first application.

[0197] Example 47 further includes monitoring a second application to determine when metabolic health information is provided to the second application and displaying a prompt to request approval to obtain metabolic health information from the second application, and includes the method described in Example 45.

[0198] Example 48 includes the method described in Example 45, in which the metabolic health information includes at least one of dietary intake, exercise, or insulin infusion.

[0199] Example 49 further includes monitoring data related to glucose levels, and includes the method described in any one of Examples 45 to 48, in which the second application is automatically accessed when the glucose level reaches a specified level.

[0200] Example 50 further includes monitoring data related to glucose levels, and includes the method described in any one of Examples 45 to 48, in which the second application is automatically accessed when the glucose level changes by a specified amount.

[0201] Example 51 further includes monitoring data related to glucose levels and requesting an input of metabolic health information when the glucose level reaches a specified level or changes by a specified amount, and includes the method described in any one of Examples 45 to 48.

[0202] Example 52 includes the method described in any one of Examples 45 to 48, in which the metabolic health information indicates an activity level, and the activity level is determined by an accelerometer.

[0203] Example 53 includes the method described in any one of Examples 45 to 48, in which the continuous glucose monitor includes a smartphone.

[0204] In some embodiments of the present technology (Example 54), a system for integrating data related to glucose values with metabolic health information, comprising a wireless receiver configured to receive data related to glucose values, a memory configured to store the data and metabolic health information, and a processor. The processor is configured to access metabolic health information using a second application configured to obtain data related to glucose levels from the memory and control the storage of metabolic health information affecting the glucose levels, obtain metabolic health information from the second application, and display data related to glucose levels and metabolic health information simultaneously on a display.

[0205] Example 55 includes the system described in Example 54, wherein data related to glucose levels and metabolic health information are displayed using a first application.

[0206] Example 56 includes the system described in Example 54, wherein the processor is further configured to monitor the second application to determine when metabolic health information is provided to the second application and display a prompt requesting approval to obtain metabolic health information from the second application.

[0207] Example 57 includes the system described in Example 54, wherein the metabolic health information includes at least one of dietary intake, exercise, or insulin injection.

[0208] Example 58 includes the systems described in Examples 54-57, wherein the processor is further configured to monitor data related to glucose levels and automatically access the second application when the glucose level reaches a specified level.

[0209] Example 59 includes the systems described in Examples 54 - 57, further configured such that the processor monitors data related to glucose levels and automatically accesses a second application when the glucose level changes by a specified amount.

[0210] Example 60 includes the systems described in Examples 54 - 57, further configured such that the processor monitors data related to glucose levels and requests an input of metabolic health information when the glucose level reaches a specified level or changes by a specified amount.

[0211] Example 61 includes the systems described in Examples 54 - 57, where the metabolic health information indicates an activity level determined by an accelerometer.

[0212] In some embodiments of the present technology (Example 62), a computer - readable medium containing instructions that, when executed by a processor, perform a method for integrating data related to glucose values with metabolic health information. The method includes obtaining data related to glucose levels using a first application, accessing a second application configured to store metabolic health information, where the metabolic health information affects the glucose level, obtaining the metabolic health information from the second application, and simultaneously displaying the data related to glucose levels and the metabolic health information.

[0213] Example 63 includes the computer - readable medium described in Example 62, where the data related to glucose levels and the metabolic health information are displayed using a first application.

[0214] Example 64 includes the computer-readable medium described in Example 62, which, when executed by a processor, further includes instructions to monitor a second application to determine when metabolic health information is provided to the second application and to display a prompt requesting approval to obtain metabolic health information from the second application.

[0215] Example 65 includes the computer-readable medium described in Example 62, wherein the metabolic health information includes at least one of dietary intake, exercise, or insulin infusion.

[0216] Example 66 includes the computer-readable medium described in any one of Examples 62 to 65, which, when executed by a processor, further includes instructions to monitor data related to glucose levels, and the second application is automatically accessed when the glucose level reaches a specified level.

[0217] Example 67 includes the computer-readable medium described in any one of Examples 62 to 65, which, when executed by a processor, further includes instructions to monitor data related to glucose levels, and the second application is automatically accessed when the glucose level changes by a specified amount.

[0218] Example 68 includes the computer-readable medium described in any one of Examples 62 to 65, which, when executed by a processor, further includes instructions to monitor data related to glucose levels and to request an input of metabolic health information when the glucose level reaches a specified level or changes by a specified amount.

[0219] Example 69 includes the computer-readable medium described in any one of Examples 62 to 65, wherein the metabolic health information indicates an activity level, and the activity level is determined by an accelerometer.

[0220] In some embodiments of the present technology (Example 70), a method for controlling the distribution of data related to glucose levels among applications running on a computer, the method comprising: receiving a plurality of data values related to glucose level monitoring; separating the plurality of data values into a first data set and a second data set, wherein the first data set includes values restricted from the second data set; providing the first data set to a first application running on the computer; and providing the second data set to a second application running on the computer.

[0221] Example 71 includes the method according to Example 70, wherein the plurality of data values are separated into a first data set and a second data set based on permissions given to the second application.

[0222] Example 72 includes the method according to Example 70, wherein the first data set and the second data set are controlled to be displayed differently by the first application and the second application.

[0223] Example 73 includes the method according to any one of Examples 70 - 72, wherein the first data set includes a value indicating a glucose level, and the first application displays the value.

[0224] Example 74 includes the method according to any one of Examples 70 - 72, wherein the second data set includes an indicator of glucose level, the indicator including low, normal, or high, and the second application displays the indicator.

[0225] Example 75 includes the method according to any one of Examples 70 - 72, wherein the data values include actual measurement values and estimated error ranges.

[0226] Example 76 includes the method according to any of Examples 70 to 72, in which the first dataset and the second dataset include the historical trend of glucose levels over a period of time, and the first application and the second application display the historical trend.

[0227] In some embodiments of the present technology (Example 77), a computer having security means for controlling the distribution of data related to glucose levels between applications, the computer comprising: a wireless receiver configured to receive a plurality of data values related to glucose levels; and a processor configured to separate the plurality of data values into a first dataset and a second dataset, wherein the first dataset includes restricted values from the second dataset, provide the first dataset to a first application running on the computer, and provide the second dataset to a second application running on the computer.

[0228] Example 78 includes the computer according to Example 77, in which a plurality of data values are separated into a first dataset and a second dataset based on permissions given to the second application.

[0229] Example 79 includes the computer according to Example 77, in which the first dataset and the second dataset are controlled to be displayed differently by the first application and the second application.

[0230] Example 80 includes the computer according to Example 77, in which the first dataset includes values indicating glucose levels, and the first application displays the values.

[0231] Example 81 includes the computer according to any one of Examples 77 to 80, wherein the second data set includes an indicator of glucose level, the indicator includes low, normal, or high, and the second application displays the indicator.

[0232] Example 82 includes the computer according to any one of Examples 77 to 80, wherein the data values include actual measurement values and estimated error ranges.

[0233] Example 83 includes the computer according to any one of Examples 77 to 80, wherein the first data set and the second data set include a historical trend of glucose levels over a period of time, and the first application and the second application display the historical trend.

[0234] In some embodiments of the present technology (Example 84), a computer-readable medium including instructions that, when executed by a processor, perform a method for controlling the distribution of glucose-level-related data between applications running on a computer, the method including receiving a plurality of data values related to glucose-level monitoring, separating the plurality of data values into a first data set and a second data set, wherein the first data set includes restricted values from the second data set, providing the first data set to a first application running on the computer, and providing the second data set to a second application running on the computer.

[0235] Example 85 includes the computer-readable medium according to Example 84, wherein the plurality of data values are separated into a first data set and a second data set based on permissions given to the second application.

[0236] Example 86 includes the computer-readable medium described in Example 84, wherein the first dataset and the second dataset are controlled to be displayed differently by the first application and the second application.

[0237] Example 87 includes the computer-readable medium described in Example 84, wherein the first dataset includes a value indicating a glucose level, and the first application displays the value.

[0238] Example 88 includes the computer-readable medium according to any one of Examples 84 to 87, wherein the second dataset includes an indicator of glucose level, the indicator includes low, normal, or high, and the second application displays the indicator.

[0239] Example 89 includes the computer-readable medium according to any one of Examples 84 to 87, wherein the data value includes an actual measurement value and an estimated error range.

[0240] Example 90 includes the computer-readable medium according to any one of Examples 84 to 87, wherein the first dataset and the second dataset include a historical trend of glucose levels over a period of time, and the first application and the second application display the historical trend.

[0241] In some embodiments of the present technology (Example 91), a method for controlling access to data related to glucose levels, including receiving data related to glucose levels using an application running on a smartphone, displaying the data using the application, encrypting a subset of the data, providing the encrypted data subset to a second application, providing the encrypted data subset from the second application to a third application, and providing a key to the third application to decrypt the encrypted data subset.

[0242] Example 92 includes the method described in Example 91, in which a key for decrypting an encrypted data subset is provided to a second application.

[0243] In some embodiments of the present technology (Example 93), a system for controlling access to data related to glucose levels, comprising a wireless receiver configured to receive data related to glucose levels, and a processor configured to use an application to display the data, encrypt a subset of the data, provide the encrypted data subset to a second application, provide the encrypted data subset from the second application to a third application, and provide a key to the third application for decrypting the encrypted data subset.

[0244] Example 94 includes the system described in Example 93, in which a key for decrypting an encrypted data subset is provided to a second application.

[0245] In some embodiments of the present technology (Example 95), a computer-readable medium including instructions that, when executed by a processor, implement a method for controlling access to data related to glucose levels, the method including receiving data related to glucose levels using an application running on a smartphone, displaying the data using the application, encrypting a subset of the data, providing the encrypted data subset to a second application, providing the encrypted data subset from the second application to a third application, and providing a key to the third application for decrypting the encrypted data subset.

[0246] Example 96 includes the computer-readable medium described in Example 95, where a key for decrypting an encrypted data subset is provided to a second application.

[0247] In some embodiments of the present technology (Example 97), a method for synchronizing data related to glucose levels between two applications running on a computer, comprising: obtaining, by a first application, a first data set related to glucose levels over a first period; running a second application configured to display information related to glucose levels; providing the first data set to the second application; obtaining a second data set related to glucose levels in a second period; determining that the second application has not received the second data set; and backfilling the second data set to the second application.

[0248] Example 98 includes the method described in Example 97, further comprising backfilling a second data set to a second application after receiving a request to backfill data.

[0249] Example 99 includes the method described in Example 97, further comprising automatically backfilling a second data set to a second application.

[0250] Example 100 includes the method described in any of Examples 97 to 99, further comprising displaying a first data set in real time by a first application and displaying a second data set by a second application after a predetermined delay.

[0251] Example 101 includes the method described in any of Examples 97 to 99, further comprising obtaining metabolic health information from a second application, where the metabolic health information affects glucose levels, and displaying the first data set simultaneously with the metabolic health information.

[0252] Example 102 further includes restricting a portion of a first data set from being accessed by a second application, and providing the first data set to the second application includes providing a portion of the first data set, and includes the method according to any one of Examples 97 to 99.

[0253] Example 103 includes determining that the second application has not received a second data set, and includes determining that the second data set is older than a threshold amount, and includes the method according to any one of Examples 97 to 99.

[0254] In some embodiments of the present technology (Example 104), a computer for synchronizing data related to glucose levels between two applications, the computer comprising: a wireless receiver configured to receive a first data set related to glucose levels over a first period; a memory configured to store the first data set using a first application; a processor, the processor executing a second application configured to display information related to glucose levels, providing the first data set to the second application, obtaining a second data set related to glucose levels in a second period, determining that the second application has not received the second data set, and a processor configured to backfill the second data set to the second application.

[0255] Example 105 further includes a user interface for receiving a request to backfill data, and the processor is further configured to backfill the second data set to the second application after receiving the request to backfill data, and includes the computer according to Example 104.

[0256] Example 106 includes the computer described in Example 104, further configured such that the processor automatically backfills a second dataset to a second application.

[0257] Example 107 further includes a display configured to display a first dataset in real time using a first application and display a second dataset after a predetermined delay amount using a second application, the computer described in any of Examples 104 - 106.

[0258] Example 108 further includes the computer described in any of Examples 104 - 106, wherein the processor is further configured to obtain metabolic health information from a second application, the metabolic health information affecting glucose levels, and the display is configured to display the first dataset simultaneously with the metabolic health information.

[0259] Example 109 further includes the computer described in any of Examples 104 - 106, wherein the process is further configured to restrict access to a portion of the first dataset by a second application, and providing the first dataset to the second application includes providing a portion of the first dataset.

[0260] Example 110 includes the computer described in any of Examples 104 - 106, further configured such that the processor determines that a second dataset is older than a threshold amount.

[0261] In some embodiments of the present technology (Example 111), a computer-readable medium comprising instructions which, when executed by a processor, perform a method for synchronizing data related to glucose levels between two applications running on a computer, the method comprising: obtaining, by a first application, a first dataset related to glucose levels over a first period; executing a second application configured to display information related to glucose levels; providing the first dataset to the second application; obtaining a second dataset related to glucose levels of a second period; determining that the second application has not received the second dataset; and backfilling the second dataset to the second application. A computer-readable medium.

[0262] Example 112 includes the computer-readable medium according to Example 111, further comprising instructions which, when executed by a processor, backfill a second dataset to a second application after receiving a request to backfill data.

[0263] Example 113 includes the computer-readable medium according to Example 111, further comprising instructions which, when executed by a processor, automatically backfill a second dataset to a second application.

[0264] Example 114 includes the computer-readable medium according to any one of Examples 111 to 113, further comprising instructions which, when executed by a processor, display a first dataset in real time by a first application and display a second dataset with a predetermined delay amount by a second application.

[0265] Example 115 includes a computer-readable medium according to any one of Examples 111 to 113, which, when executed by a processor, further includes instructions to obtain metabolic health information that affects glucose levels from a second application and display a first dataset simultaneously with the metabolic health information.

[0266] Example 116 includes a computer-readable medium according to any one of Examples 111 to 113, which, when executed by a processor, further includes instructions to restrict access to a portion of the first dataset by a second application, and providing the first dataset to the second application includes providing a portion of the first dataset.

[0267] Example 117 includes a computer-readable medium according to any one of Examples 111 to 113, which includes determining that the second application has not received a second dataset, including determining that the second dataset is older than a threshold amount.

[0268] In some embodiments of the present technology (Example 118), a method for determining the safety compliance level of two or more medical devices and modifying medical data based on the safety compliance level, the method comprising receiving continuous glucose measurements from a wireless receiver, determining the compliance level of the medical device, and providing the continuous glucose measurements to the medical device based on the determined compliance level, wherein when the medical device meets a high compliance level, the continuous glucose measurements are provided to the medical device in real time, and when the medical device meets a high compliance level, the continuous glucose measurements are provided to the medical device after a predetermined delay.

[0269] Example 119 includes the method according to Example 118, wherein the medical device meeting a high compliance level includes a Class 3 medical device.

[0270] Example 120 includes the method according to Example 118 or 119, wherein the medical device includes a software application that runs on a smartphone.

[0271] In some embodiments of the present technology (Example 121), a system for determining the safety compliance level of two or more medical devices and modifying medical data based on the safety compliance level, comprising a wireless receiver configured to receive continuous glucose measurements from a wireless receiver, and a processor configured to determine the compliance level of the medical device and provide continuous glucose measurements to the medical device based on the determined compliance level, wherein when the medical device meets a high compliance level, the continuous glucose measurements are provided to the medical device in real time, and when the medical device meets a high compliance level, the continuous glucose measurements are provided to the medical device after a predetermined delay.

[0272] Example 122 includes the system according to Example 121, wherein the medical device that meets a high compliance level includes a Class 3 medical device.

[0273] Example 123 includes the system according to Example 121 or 122, wherein the medical device includes a software application that runs on a smartphone.

[0274] In some embodiments of the present technology (Example 124), a computer-readable medium comprising instructions that, when executed by a processor, determine a safety compliance level of two or more medical devices and execute a method for modifying medical data based on the safety compliance level, the method comprising receiving continuous glucose measurements from a wireless receiver, determining a compliance level of a medical device, and providing the continuous glucose measurements to the medical device based on the determined compliance level, wherein when the medical device meets a high compliance level, the continuous glucose measurements are provided to the medical device in real time, and when the medical device meets a high compliance level, the continuous glucose measurements are provided to the medical device after a predetermined delay.

[0275] Example 125 includes the computer-readable medium according to Example 124, wherein the medical device meeting a high compliance level includes a Class 3 medical device.

[0276] Example 125 includes the computer-readable medium according to Example 124 or 125, wherein the medical device includes a software application running on a smartphone.

[0277] In some embodiments of the present technology (Example 127), a method for validating calibration data of a sensor device, in a first application executed by a mobile computing device, receiving data associated with an analyte measurement value from a second application on the mobile computing device, wherein the first application is a dedicated application for a continuous analyte sensor device worn by a user communicating with the mobile computing device, and the analyte measurement value is obtained from the user by a single measurement medical device, receiving, and by the first application, determining the source of the received data by analyzing metadata corresponding to the analyte measurement value of the received data, and by the first application, processing the data as calibration data of the continuous analyte sensor device.

[0278] Example 128 includes the method according to Example 127, wherein the metadata includes one or more of a unit associated with the analyte measurement value, a timestamp when the analyte measurement value was obtained, a parameter associated with the measurement technique or analysis technique of the measurement analyte, or one or more codes associated with the single measurement medical device or a consumable part of the single measurement medical device.

[0279] Example 129 includes the method according to Example 127, further including, upon reception, displaying the received data on a display screen of the mobile computing device by the first application.

[0280] Example 130 includes the method according to Example 129, including a user interface that presents a notification to the user such that the displayed data is accepted as calibration data for calibration of the continuous analyte sensor device.

[0281] Example 131 includes the method described in Example 130, where the notification includes a notification including a pop-up window of a dedicated application, a new display screen of the dedicated application, or a banner, a badge, a sound, and / or a vibration.

[0282] Example 132 includes the method described in Example 130, where the notification includes a text message, an email, or an instant message.

[0283] Example 133 further includes receiving a positive or negative response to accepting the data as calibration data, and includes the method described in Example 130.

[0284] Example 134 further includes displaying, on a display screen of a mobile computing device, a prompt for a user to manually enter an analyte measurement obtained by a single measurement medical device, and includes the method described in Example 129 or 130.

[0285] Example 135 further includes receiving the manually entered analyte measurement and processing, by a first application, the manually entered analyte measurement as calibration data for a continuous analyte sensor device, and includes the method of Example 134.

[0286] Example 136 further includes processing calibration data in a calibration process of continuously obtained analyte measurements of a user obtained by a continuous analyte sensor device by a first application, where the continuously obtained analyte measurements are provided to the first application on the mobile computing device, and includes the method described in Example 127.

[0287] Example 137 further includes providing the processed data to a continuous analyte sensor device for use in a calibration process of continuously obtained analyte measurements by the continuous analyte sensor device, and includes the method described in Example 127.

[0288] Example 138 includes the method described in Example 127, where an analyte measurement is provided to a second application by a single-measurement medical device via a wireless connection to a mobile computing device.

[0289] Example 139 includes the method described in Example 127, which includes analyzing metadata to identify one or more codes associated with a single-measurement medical device or a consumable part of a single-measurement medical device, and determining that the one or more codes are included among authorized devices for performing a validity verification of the authenticity of data obtained from the authorized devices.

[0290] Example 140 includes the method described in Example 127, where a continuous analyte sensor device obtains glucose measurements from a user and the data associated with the analyte measurements includes the level of blood glucose.

[0291] In some embodiments of the present technology (Example 141), a method for obtaining calibration data of a sensor device, in a first application executed by a mobile computing device, receiving data associated with an analyte measurement value from a second application on the mobile computing device, wherein the first application is a dedicated application for a continuous analyte sensor device worn by a user communicating with the mobile computing device, and the analyte measurement value is obtained from the user by a single measurement medical device; receiving; and displaying, by the first application, the received data on a display screen of the mobile computing device, including a user interface that presents a notification to the user so that the displayed data is accepted as calibration data for calibration of the continuous analyte sensor device; receiving a positive or negative response to accepting the data as calibration data; and when the received response is a negative response, the method further includes: displaying, by the first application, a prompt to the user for manually entering an analyte measurement value obtained by the single measurement medical device on the display screen of the mobile computing device; receiving the manually entered analyte measurement value; and processing, by the first application, the manually entered analyte measurement value as calibration data for the continuous analyte sensor device.

[0292] Example 142 includes the method according to Example 141, wherein the notification includes a notification including a pop-up window of the dedicated application, a new display screen of the dedicated application, or a banner, badge, sound, and / or vibration.

[0293] Example 143 includes the method according to Example 141, wherein the notification includes a text message, an email, or an instant message.

[0294] Example 144 further includes processing calibration data in a calibration process of continuously obtained analyte measurements of a user obtained by a continuous analyte sensor device by a first application, wherein the continuously obtained analyte measurements are provided to the first application on a mobile computing device, and includes the method described in Example 141.

[0295] Example 145 includes the method described in Example 141, and further includes providing calibration data to a continuous analyte sensor device for use in a calibration process of continuously obtained analyte measurements by the continuous analyte sensor device.

[0296] Example 146 includes the method described in Example 141, wherein analyte measurements are provided to a second application by a single measurement medical device via a wireless connection with a mobile computing device.

[0297] Example 147 includes the method described in Example 141, wherein a continuous analyte sensor device obtains glucose measurements from a user, and data associated with the analyte measurements includes levels of blood glucose.

[0298] In some embodiments of the present technology (Example 148), a medical device software application for managing glucose data received from a glucose sensor is disclosed. This medical device software application is on a computer-readable medium of a mobile computing device and includes instructions that, when executed by a processor of the mobile computing device, cause the mobile computing device to receive one or more glucose measurements generated by the glucose sensor (where the one or more glucose measurements include an associated timestamp), assign the received one or more glucose measurements as retrospective glucose data or actionable glucose data based on a predetermined amount of time difference between the timestamp and the current time, and cause a third-party software application operable on the mobile computing device to be provided with the retrospective glucose data.

[0299] Example 149 includes the medical device software application described in Example 148, where the third-party software application is not an approved medical device software application approved by a government regulatory agency having the authority to regulate medical device technology.

[0300] Example 150 includes the medical device software application described in Example 148, where the third-party software application is configured to provide at least some capabilities different from those of the medical device software application, including processing auxiliary data and integrating the auxiliary data with the retrospective glucose data, and the auxiliary data includes one or more of insulin data, meal data, or exercise data.

[0301] Example 151 includes the medical device software application described in Example 148, wherein the medical device software application includes instructions that, when executed by a processor, cause a mobile computing device to create a dataset related to one or more glucose measurements, divide the dataset by generating a first dataset and a second dataset according to a predetermined criterion, restrict access to the first dataset for a third-party software application, and provide the second dataset to the third-party software application.

[0302] Example 152 includes the medical device software application described in Example 148, wherein the medical device software application includes instructions that, when executed by a processor, cause a mobile computing device to encrypt one or more received glucose measurements or assigned retrospective glucose data before providing the retrospective glucose data to a third-party software application, transmit instructions to the third-party software application to provide the encrypted retrospective glucose data to a second third-party software application operable on the mobile computing device, and provide a key to the second third-party software application to decrypt the encrypted retrospective glucose data.

[0303] In some embodiments of the present technology (Example 153), a medical device software application for managing glucose data received from a glucose sensor is disclosed. This medical device software application is on a computer-readable medium of a mobile computing device and includes instructions that, when executed by a processor of the mobile computing device, cause the mobile computing device to receive one or more glucose measurements generated by a glucose sensor, split the one or more glucose measurements into a first data set and a second data set according to a predetermined criterion (the first data set includes data values restricted from the second data set), and cause a third-party software application operable on the mobile computing device to be provided with the second data set.

[0304] Example 154 includes the medical device software application described in Example 153, where the third-party software application is not an approved medical device software application approved by a government regulatory agency with the authority to regulate medical device technology.

[0305] Example 155 includes the medical device software application described in Example 153, configured to provide at least some capabilities different from those of the medical device software application, where the third-party software application includes processing auxiliary data and integrating the auxiliary data with retrospective glucose data, and the auxiliary data includes one or more of insulin data, meal data, or exercise data.

[0306] Example 156 includes the medical device software application described in Example 153, wherein one or more received glucose measurements include an associated timestamp, and the medical device software application includes instructions that, when executed by a processor, cause a mobile computing device to assign the one or more received glucose measurements as retrospective glucose data or actionable glucose data based on a predetermined amount of time difference between the timestamp and the current time, and cause a third-party software application operable on the mobile computing device to be provided with the retrospective glucose data.

[0307] Example 157 includes the medical device software application described in Example 153, wherein the medical device software application includes instructions that, when executed by a processor, cause the mobile computing device to encrypt one or more received glucose measurements or a second data set before providing the second data set to a third-party software application, transmit instructions to the third-party software application to provide the encrypted second data set to a second third-party software application operable on the mobile computing device, and cause the second third-party software application to be provided with a key to decrypt the encrypted retrospective glucose data.

[0308] This specification includes many details of specific implementation forms, but these should not be construed as limiting the scope of the claims. Certain features described herein in the context of separate implementation forms may be implemented in combination in a single implementation form. Conversely, the various features described in the context of a single implementation form may be implemented separately in multiple implementation forms or in any suitable partial combination. Furthermore, features may be described as functioning in a particular combination and may even be initially claimed as such, but one or more features in a claimed combination may optionally be deleted from that combination, and the claimed combination may be directed to a partial combination or a variation of a partial combination.

[0309] Similarly, operations are shown in the drawings in a particular order, but this should not be understood as requiring that such operations be performed in the particular order or sequential order shown in order to obtain a desirable result, or that all of the illustrated operations be performed. In certain circumstances, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the above-described implementation forms should not be understood as requiring such separation in all implementation forms, and it should be understood that the described program components and systems may generally be integrated together within a single software product or packaged into multiple software products.

[0310] It should be understood that the logical operations described herein with respect to the various figures can be implemented as (1) a series of computer-implemented acts or program modules (i.e., software) running on a computing device, (2) interconnected mechanical logic circuits or circuit modules within the computing device (i.e., hardware), and / or (3) a combination of software and hardware of the computing device. Thus, the logical operations detailed herein are not limited to any particular combination of hardware and software. The implementation form is a matter of choice depending on the performance of the computing device and other requirements. Therefore, the logical operations described herein are variously referred to as operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules may be implemented in software, firmware, dedicated digital logic, and any combination thereof. It should also be understood that more operations or fewer operations than those shown in the figures and described herein may be performed. These operations may be performed in an order different from that described herein.

Description of Reference Numerals

[0311] 100 Sensor 104 Dedicated Display 106 Display 108 Dedicated Application 110~116 Third-Party Applications 414 User Interface 600 User Interface 602 User Interface 900 User Interface 902 User Interface 1102 Computer 1104 Cloud Storage 1106 Back-End System 1110 Display 1112 Dedicated Application 1114 Third-party application 1221 Central processing unit 1222 Random access memory (RAM) module 1223 Read-only memory (ROM) module 1224 Storage 1225 Database 1226 Input / output (I / O) device 1227 Interface 1501 Display screen 1502 Display screen 1503 Display screen

Claims

1. 1. A method for monitoring glucose levels, comprising: Receiving health data including glucose measurements and associated timestamps transmitted over a wireless connection in a first application operable on the mobile computing device; determining, by the first application, that a duration between a current time and the timestamp satisfies a predetermined delay amount; providing, by the first application, the glucose measurement to a second application operable on the mobile computing device only after the predetermined amount of delay.

2. 2. The method of claim 1, wherein the first application comprises a medical device software application that configures the mobile computing device to receive and process glucose data including the glucose measurements provided by a continuous glucose monitoring sensor device, and the second application comprises a third party software application.

3. 3. The method of claim 2, wherein the third party software application is configured to provide at least some capabilities different from those of the first application, including processing auxiliary data and integrating the auxiliary data with the glucose data.

4. The method of claim 3 , wherein the auxiliary data includes one or more of insulin data, diet data, or exercise data.

5. The method of claim 2 , wherein the third party software application is not an approved medical device software application approved by a government regulatory agency with authority to regulate medical device technology.

6. The method of claim 1 , further comprising displaying, by the first application, the glucose measurement on a display screen of the mobile computing device.

7. The received health data includes a plurality of consecutively generated glucose measurements and an associated timestamp for each glucose measurement, the method comprising: delaying each of the plurality of successively generated glucose measurements by the predetermined amount of time; and providing each of the plurality of successively generated glucose measurements to the second application after the delay.

8. The method of claim 1 , wherein the glucose measurement is provided to the second application after the predetermined amount of time in response to the second application being executed by the mobile computing device.

9. 2. The method of claim 1, wherein the delay is from 5 minutes to 3 hours.

10. Obtaining metabolic health information that affects glucose levels; The method of any one of claims 1 to 9, further comprising: using the first application to simultaneously display the glucose measurement with the metabolic health information.

11. The method of claim 10 , wherein the metabolic health information is obtained by the first application from the second application.

12. the metabolic health information is indicative of an amount of activity determined using motion data generated by an accelerometer of the mobile computing device; or 11. The method of claim 10, wherein the metabolic health information includes at least one of food intake, exercise, or insulin infusion.

13. generating, by the first application, a data set related to the continuously generated glucose measurements from the received health data; partitioning the data set by generating a first data set and a second data set according to predetermined criteria by the first application; restricting access to the second data set for the second application; The method of claim 7 , further comprising: providing the first data set to the second application.

14. The method of claim 13 , wherein restricting access comprises not sending the second data set to the second application.

15. The method of claim 13 , further comprising encrypting the first data set prior to providing the first data set to the second application.

16. 14. The method of claim 13, wherein dividing the data set into the first data set comprises averaging the consecutively generated glucose measurements over a predetermined interval to generate an average glucose value included in the first data set.

17. 14. The method of claim 13, wherein dividing the data set into the first data set includes generating a generalized index of the continuously generated glucose measurements over a predetermined interval included in the first data set, the generalized index representing the continuously generated glucose measurements falling within one of a defined low range, a defined normal range, and a defined high range.

18. The method of any one of claims 1-9 or 13-17, further comprising restricting, by the first application, the second application from further delivering the glucose measurement value to additional applications.

19. providing, by the first application, the timestamp to the second application; reading, by the first application, the glucose measurement and the timestamp from the second application; comparing the measured value by the first application with the measured value provided to the second application; determining, by the first application, whether the read measurement matches the provided measurement; comparing the read timestamp by the first application with the timestamp provided to the second application; The method of any one of claims 1 to 9 or 13 to 17, further comprising: determining, by the first application, whether the read timestamp matches the provided timestamp.

20. encrypting the glucose measurement prior to providing the glucose measurement to the second application; sending instructions to the second application to provide the encrypted measurements to a third application operable on the mobile computing device; The method of any one of claims 1 to 9 or 13 to 17, further comprising: providing the third application with a key for decrypting the encrypted measurements.

21. 21. The method of claim 20, wherein the providing includes providing the key to the second application with a communication to the second application to cause the third application to provide the key.

22. The method of any one of claims 1 to 9 or 13 to 17, wherein the mobile computing device comprises a smartphone.

23. 1. A system for monitoring glucose levels, comprising: a sensor configured to obtain a glucose measurement of a glucose amount; a wireless transmitter for transmitting the glucose measurement and a time stamp associated with the glucose measurement; 1. A mobile computing device, comprising: a wireless receiver configured to receive the glucose measurement; a memory for storing data including the received glucose measurements; a processor for processing the data; a first software application including instructions stored in the memory that, when executed by the processor, determines when a duration between a current time and the timestamp satisfies a predetermined delay amount, and provides the glucose measurement to a second software application on the mobile computing device when the duration is determined to satisfy the predetermined delay amount; The system, wherein the second software application is operable to receive the glucose measurement as provided by the first software application after the predetermined amount of delay.

24. 24. The system of claim 23, further comprising a second computing device configured to receive the glucose measurements and display the glucose amounts in real time.

25. 24. The system of claim 23, wherein the first software application includes a medical device software application that configures the mobile computing device to receive and process the glucose measurements received from the sensor, and the second software application includes a third party software application.

26. 26. The system of claim 25, wherein the third party software application is configured to provide at least some capabilities different from those of the first software application, including processing auxiliary data and integrating the auxiliary data with the glucose measurement value.

27. 27. The system of claim 26, wherein the auxiliary data includes one or more of insulin data, diet data, or exercise data.

28. 26. The system of claim 25, wherein the third party software application is not an approved medical device software application approved by a government regulatory agency with authority to regulate medical device technology.

29. 24. The system of claim 23, wherein the mobile computing device further comprises a display screen, and the first software application includes instructions that, when executed by the processor, display the glucose reading on the display screen.

30. 24. The system of claim 23, wherein the glucose measurement is provided to the second software application after the delay in response to the second software application being executed.

31. 24. The system of claim 23, wherein the delay is between 5 minutes and 3 hours.

32. the wireless receiver of the mobile computing device is configured to receive a plurality of successively generated glucose measurements and a timestamp associated with each successively generated glucose measurement; the memory of the mobile computing device is configured to store the plurality of successively generated glucose measurements; The first software application includes instructions that, when executed by the processor, cause the mobile computing device to: delaying each of the plurality of successively generated glucose measurements by the predetermined amount of time; and The system of any one of claims 23 to 31, further comprising causing each of the plurality of successively generated glucose measurements to be provided to the second software application after the delay.

33. the processor is configured to obtain metabolic health information from a software application resident on the mobile computing device and provide access to the metabolic health information to the first software application, the metabolic health information affecting glucose levels; The system of any one of claims 23 to 31, wherein the instructions of the first software application, when executed by the processor, cause the glucose measurement to be displayed simultaneously with the metabolic health information.

34. the processor is configured to obtain metabolic health information using the first software application, the metabolic health information affecting glucose levels; The system of any one of claims 23 to 31, wherein the instructions of the first software application, when executed by the processor, cause the glucose measurement to be displayed simultaneously with the metabolic health information.

35. The first software application includes instructions that, when executed by the processor, cause the mobile computing device to: generating a data set associated with said continuously generated glucose measurements; splitting the data set by generating a first data set and a second data set according to predetermined criteria; restricting access to the second data set for the second software application; and 33. The system of claim 32, further comprising causing the first data set to be provided to the second software application.

36. 36. The system of claim 35, wherein the first data set is encrypted prior to providing the first data set to the second application.

37. 36. The system of claim 35, wherein generating the first data set comprises averaging the successively generated glucose measurements over a predetermined interval to generate an average glucose value included in the first data set.

38. 36. The system of claim 35, wherein generating the first dataset includes generating a generalized index of the continuously generated glucose measurements over a predetermined interval included in the first dataset, the generalized index representing that the continuously generated glucose measurements fall within one of a defined low range, a defined normal range, and a defined high range.

39. 32. The system of any one of claims 23 to 31, wherein the first software application includes instructions that, when executed by the processor, cause the mobile computing device to determine a subset of data associated with continuous glucose monitoring for providing to the second application.

40. The system of any one of claims 23 to 31, wherein the second software application is restricted from further distributing the measurements to additional software applications operable on the mobile computing device.

41. The first software application includes instructions that, when executed by the processor, cause the mobile computing device to: providing the time stamp to the second software application; reading the glucose measurement value and the timestamp from the second application; comparing the read glucose measurement to the glucose measurement provided to the second software application; determining whether the read glucose measurement matches the provided glucose measurement; comparing the read timestamp with the timestamp provided to the second software application; and A system according to any one of claims 23 to 31, adapted to determine whether the read timestamp matches the provided timestamp.

42. The processor, The system of any one of claims 23 to 31, further configured to receive an input that controls whether the glucose measurement is provided to the second application.

43. The first software application includes instructions that, when executed by the processor, cause the mobile computing device to: encrypting the glucose measurement before providing the glucose measurement to the second software application; sending instructions from the second software application to a third software application operable on the mobile computing device to provide the encrypted measurement value to the second software application; and The system of any one of claims 23 to 31, further comprising having the third application provide a key for decrypting the encrypted measurements.

44. The system of any one of claims 23 to 31, wherein the mobile computing device comprises a smartphone.

45. 1. A method for controlling distribution of data related to glucose levels between applications executing on a computing device, comprising: Receiving, at the mobile computing device, a plurality of data values ​​related to glucose level monitoring; segregating, in a first application operable on the mobile computing device, the plurality of data values ​​into a first data set and a second data set according to predetermined criteria, the first data set including restricted data values ​​from the second data set; providing the second data set to a second application operable on the mobile computing device.

46. 46. ​​The method of claim 45, wherein the first application comprises a medical device software application that configures the mobile computing device to receive and process glucose data including the data values ​​related to the glucose level monitoring provided by a continuous glucose monitoring sensor device, and the second application comprises a third party software application.

47. 47. The method of claim 46, wherein the third party software application is configured to provide at least some capabilities different from those of the first application, including processing auxiliary data and integrating the auxiliary data with the glucose data.

48. 48. The method of claim 47, wherein the auxiliary data includes one or more of insulin data, diet data, or exercise data.

49. 47. The method of claim 46, wherein the third party software application is not an approved medical device software application approved by a government regulatory agency with authority to regulate medical device technology.

50. 46. ​​The method of claim 45, further comprising displaying, by the first application, at least a portion of the received plurality of data values ​​on a display screen of the mobile computing device.

51. 46. ​​The method of claim 45, further comprising: displaying, by the first application, the first data set and the second data set differently on a display screen of the mobile computing device.

52. 46. ​​The method of claim 45, wherein the plurality of data values ​​are segregated into the first data set and the second data set based on predefined data permissions associated with the second application.

53. 46. ​​The method of claim 45, wherein the first data set and the second data set are controlled to be displayed differently by the first application and the second application.

54. The received plurality of data values ​​includes successively generated glucose measurements, and separating the plurality of data values ​​includes 46. ​​The method of claim 45, further comprising averaging the successively generated glucose measurements over a predetermined interval to generate an average glucose value included in the second data set.

55. The received plurality of data values ​​includes successively generated glucose measurements, and separating the plurality of data values ​​includes 46. ​​The method of claim 45, further comprising generating a generalized index of the continuously generated glucose measurements included in the second data set over a predetermined interval, the generalized index representing the continuously generated glucose measurements falling within one of a defined low range, a defined normal range, and a defined high range.

56. 46. ​​The method of claim 45, further comprising encrypting the second data set prior to providing the second data set to the second application.

57. Each of the plurality of data values ​​includes an associated timestamp, the method comprising: determining, by the first application, that a duration between a current time and the timestamp satisfies a predetermined delay amount; 46. ​​The method of claim 45, further comprising delaying providing the second data set to a second application by the predetermined delay amount.

58. 58. The method of claim 57, wherein the delay is from 5 minutes to 3 hours.

59. 60. The method of claim 57, further comprising encrypting the second data set prior to providing the second data set to the second application.

60. 60. The method of any one of claims 45 to 59, wherein the plurality of data values ​​comprises an actual glucose measurement and an estimated error range.

61. the first data set and the second data set include historical trends of glucose levels over a period of time; The method of any one of claims 45 to 59, wherein the first application and the second application display the historical trends.

62. The method of any one of claims 45 to 59, wherein the mobile computing device comprises a smartphone.

63. 1. A method for controlling access to data relating to glucose levels on a mobile computing device, comprising: receiving data relating to a glucose level using a first application operable on the smartphone; encrypting at least a subset of said data; providing the encrypted data subset to a second application operable on the smartphone; providing the encrypted data subset via the second application to a third application operable on the smartphone; providing a key to the third application for decrypting the encrypted data subset.

64. 64. The method of claim 63, wherein the first application comprises a medical device software application that configures the mobile computing device to receive and process the data related to the glucose level provided by a continuous glucose monitoring sensor device, and the second application comprises a third party software application.

65. 65. The method of claim 64, wherein the third party software application is configured to provide at least some capabilities different from those of the first application, including processing auxiliary data and integrating the auxiliary data with the glucose data.

66. 66. The method of claim 65, wherein the auxiliary data includes one or more of insulin data, diet data, or exercise data.

67. 65. The method of claim 64, wherein the third party software application is not an approved medical device software application approved by a government regulatory agency with authority to regulate medical device technology.

68. 64. The method of claim 63, further comprising displaying, by the first application, at least a portion of the received data on a display screen of the mobile computing device.

69. 64. The method of claim 63, further comprising, prior to providing the encrypted data subset to the second application, separating the data according to predetermined criteria into a first data set of the data and a second data set of the data consisting of the subset, the first data set including restricted data values ​​from the second data set.

70. The received data includes glucose values ​​and a timestamp associated with each glucose value, the method comprising: determining, by the first application, that a duration between a current time and the timestamp satisfies a predetermined delay amount; 64. The method of claim 63, further comprising delaying providing the second data set to a second application by the predetermined delay amount.

71. 71. The method of claim 70, wherein the delay is from 5 minutes to 3 hours.

72. 64. The method of claim 63, wherein the second application is provided with the key for decrypting the encrypted data subset.

73. 1. A method for synchronizing data relating to glucose levels between two applications executing on a mobile computing device, comprising: obtaining, by a first application, a first data set relating to glucose levels over a first period of time; executing a second application configured to display information related to glucose levels; providing the first data set to the second application; obtaining a second data set relating to glucose levels for a second period of time; determining that the second application has not received the second data set; and backfilling the second data set into the second application.

74. 74. The method of claim 73, further comprising backfilling the second data set to the second application after receiving the request to backfill the data.

75. 74. The method of claim 73, further comprising automatically backfilling the second data set into the second application.

76. displaying the first data set in real time by the first application; 76. The method of any one of claims 73 to 75, further comprising displaying the second data set by the second application after a predetermined amount of delay.

77. obtaining metabolic health information from the second application, the metabolic health information affecting glucose levels; and 76. The method of any one of claims 73 to 75, further comprising displaying the first data set simultaneously with the metabolic health information.

78. the metabolic health information is indicative of an amount of activity determined using motion data generated by an accelerometer of the mobile computing device; or 78. The method of claim 77, wherein the metabolic health information includes at least one of food intake, exercise, or insulin infusion.

79. 76. The method of any one of claims 73 to 75, further comprising restricting a portion of the first data set from being accessed by the second application, and wherein providing the first data set to the second application comprises providing only the portion of the first data set.

80. determining that the second application has not received the second data set; A method according to any one of claims 73 to 75, comprising determining that the second data set is older than a threshold amount.

81. 1. A method for determining a safety compliance level of two or more medical devices and modifying medical data based on the safety compliance levels, comprising: receiving continuous glucose measurements from a wireless receiver; Determining a compliance level of the medical device; providing the continuous glucose measurements to the medical device based on the determined compliance level; when the medical device meets a high compliance level, the continuous glucose measurements are provided to the medical device in real time; A method, wherein when the medical device meets a high compliance level, the continuous glucose measurements are provided to the medical device after a predetermined delay.

82. 82. The method of claim 81, wherein the medical device that meets a high compliance level comprises a Class 3 medical device.

83. 83. The method of claim 81 or 82, wherein the medical device comprises a software application running on a smartphone.

Images