Systems and methods for distributing continuous glucose data

Abstract

The present disclosure relates to systems, devices, and methods for receiving biosensor data, e.g., related to glucose concentration values, collected by a medical device and controlling access to and distribution of the data. In some embodiments, systems and methods are disclosed for monitoring glucose levels, displaying data related to glucose values and metabolic health information, and controlling distribution of glucose data between applications executing on a computer, e.g., a smartphone. In some embodiments, systems and methods are disclosed for controlling access to medical data, e.g., continuously monitored glucose levels, synchronizing health data related to glucose levels between multiple applications executing on a computer, and / or encrypting data.

Description

[0001] This application is a divisional application of patent application filed on February 9, 2016, with application number 201680006366.7 and entitled "System and method for distributing continuous glucose data".

[0002] The relevant applications are incorporated by reference. This patent application claims the benefit of U.S. Provisional Patent Application No. 62 / 114,386, filed February 10, 2015, and U.S. Provisional Patent Application No. 62 / 269,035, filed December 17, 2015. Each of the above applications is incorporated herein by reference in its entirety, and each is hereby expressly incorporated as a part of this specification. Technical Field

[0003] This disclosure relates to a continuous glucose monitor for wirelessly transmitting data related to glucose levels and controlling the display and distribution of said data. Background Technology

[0004] Continuous glucose monitoring has become increasingly popular as a simple 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 lunchtime, and in the evening. These levels could be measured by taking a small blood sample from the patient and measuring the glucose level with a test strip or glucose meter. However, this technology has drawbacks because patients tend to prefer not having a blood sample taken, and users don't know what their blood glucose levels were throughout the day between samplings.

[0005] One potentially dangerous timeframe is at night, as a patient's glucose levels can dangerously drop low during sleep. Therefore, continuous glucose monitors have become popular, providing sensors that continuously measure a patient's glucose levels and wirelessly transmit the measured levels to a display. This allows patients or their caregivers to monitor a patient's glucose levels throughout the day and even set alarms when glucose levels reach predefined levels or undergo defined changes.

[0006] Initially, continuous glucose monitors wirelessly transmitted glucose level-related data to a dedicated display. This dedicated display was designed as a medical device to show users glucose levels, trend patterns, and other information. However, with the increasing popularity of smartphones and the applications running on them, some users prefer not to carry a dedicated display. Instead, they prefer to use applications running on their smartphones to monitor their glucose levels.

[0007] The computing device running the application can communicate with a continuous glucose monitor and display glucose levels and other information. Additionally, the computing device running the application can share glucose levels with other applications, servers, or devices within a cloud computing infrastructure. In one instance, the computing device and application can share their glucose levels with another smartphone or other computing device running an application for overall health monitoring. Sharing or retransmitting medical data, whether to another application, device, or server, carries risks because the data may be corrupted or misused. Additional applications may provide incorrect recommendations to users or retransmit sensitive medical information to additional devices or applications, thereby violating patient confidentiality.

[0008] This disclosure is intended to overcome these and other problems. Summary of the Invention

[0009] Certain embodiments of this disclosure generally relate to techniques for controlling and protecting the retransmission of patient medical data. In illustrative embodiments, medical devices, such as continuous glucose sensors, transmit medical data to computing devices executing software applications, such as smartphones, tablets, smartwatches, or other wearable and / or mobile computing devices. The computing device executing the software application, illustratively described as a smartphone, can control the redistribution and use of this medical data. Redistribution may reach one or more third-party applications running on the smartphone, or to remote computing devices such as servers, or to individual smart devices. A set of control operations restricts the ability of individual applications to access or use the medical data outside of their intended purpose. In one exemplary embodiment, medical data may be delayed before being provided to other software applications on the computing device or other computing devices executing the applications, or to means for controlling third-party recommended use in situations that may pose an immediate health risk. In other exemplary embodiments, medical data may be encrypted to control access to the medical data by other applications and devices. Devices authorized to use the medical data may receive keys for decrypting all or some of the data. In another exemplary embodiment, software executing on a continuous glucose monitor or display isolates a subset of medical data, such as data that poses a small risk to patient confidentiality, and provides the streamlined data set to additional applications and devices. These embodiments, as well as other embodiments described in more detail below, protect patient confidentiality and control the redistribution of medical data.

[0010] For example, some embodiments address several problems associated with providing glucose levels to different applications running on computing devices such as smartphones. For instance, a third party may develop an application that accesses data related to glucose levels. This third-party application can use the accessed data to warn the user, for example, when glucose levels drop too low or rise too high. However, the third-party application does not properly consider calibration levels and correct the correspondence between wirelessly transmitted data and actual glucose levels. Therefore, for example, the third-party application may incorrectly calculate glucose levels 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 acceptable limits, or even worse, the third-party application may indicate that the monitored patient's glucose level is within acceptable limits when the patient's glucose level is actually dangerously low. Furthermore, for example, the third-party application may inappropriately identify trends or miss alerts based on the monitored glucose levels because the application developer has not properly configured the application to consider important clinical risk factors for glucose. Moreover, for example, the third-party application may fail to notify the user when the patient's level has entered a dangerous range due to programmatic defects in the software or the developer's lack of knowledge of appropriate clinical risk levels for glucose. Therefore, the exemplary embodiment controls the application's display and use of medical data.

[0011] Additionally, 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 expensive process. Unapproved applications often contain unacceptable security flaws regarding sensitive medical data. For example, a user may allow a third-party application to access glucose level-related data without subsequently knowing that the allowed application is also providing the 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 knowledge. This creates a serious security risk that medical data could be compromised and sent to unauthorized parties. Therefore, some embodiments control the distribution of medical data among applications. Specifically, a continuous glucose sensor or software running on the display may encrypt the data before distributing it to other third-party applications.

[0012] While the risks associated with monitoring medical information using applications running on computing devices such as smartphones are known, using a smartphone to monitor health information provides a more complete view of a user's health. Many applications are available for smartphones to monitor health information. Some of this information can have a direct impact on a user's glucose levels. For example, a user may have an application installed on their smartphone to record exercise activity. Exercise has a direct impact on glucose levels. Therefore, an exemplary embodiment integrates health information from other applications and glucose level-related data on a single display. This allows users to easily identify activities that affect their glucose levels and the extent of that effect.

[0013] An additional problem with applications that display glucose level-related data and run on computing devices such as smartphones is how to handle lost data. The transmitter may transmit glucose level-related data continuously or periodically, but users may turn off their smartphones, run out of battery, or leave them out of range. When the user runs the application, they will lose the data that was not received because the smartphone was off or out of range. This can confuse users who see outdated data. Therefore, in some embodiments, backfilled data is provided to the application that did not receive data, for example, due to a break in communication between the transmitter and the application running on the computing device. This allows users to see historical trend data of their glucose levels even when a transmission is missed.

[0014] In one example embodiment of the disclosed technology, a method for monitoring glucose levels includes: receiving health data, including a glucose measurement and an associated timestamp, transmitted via a wireless connection at a first application operable on a mobile computing device; determining, via the first application, that the duration between the current time and the timestamp satisfies a predetermined delay; and providing the glucose measurement to a second application operable on the mobile computing device only after the predetermined delay.

[0015] In another embodiment of the disclosed technology, a system for monitoring glucose levels includes: a sensor configured to acquire a glucose measurement of glucose quantity; a wireless transmitter for transmitting the glucose measurement and a timestamp associated with the glucose measurement; and a mobile computing device including: a wireless receiver configured to receive the glucose measurement; a memory for storing data containing the received glucose measurement; a processor for processing the data; and a first software application containing instructions stored in the memory, the instructions, when executed by the processor, determining when a duration between the current time and the timestamp satisfies the predetermined delay, and, after determining that the duration satisfies the predetermined delay, providing the glucose measurement to a second software application on the mobile computing device, wherein the second software application is operable to receive the glucose measurement after the predetermined delay when provided by the first software application.

[0016] In another embodiment of the disclosed technology, a method for controlling the distribution of glucose level-related data among applications running on a computing device includes: receiving a plurality of data values ​​related to glucose level monitoring at a mobile computing device; separating the plurality of data values ​​into a first data set and a second data set according to predetermined criteria at a first application operable on the mobile computing device, the first data set including data values ​​restricted from the second data set; and providing the second data set to a second application operable on the mobile computing device.

[0017] In another embodiment of the disclosed technology, a method for controlling access to glucose level-related data on a mobile computing device includes: receiving glucose level-related data 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 via the second application to a third application operable on the smartphone; and providing a key for decrypting the encrypted data subset to the third application.

[0018] In another embodiment of the disclosed technology, a method for synchronizing glucose level-related data between two applications running on a mobile computing device includes: obtaining a first set of glucose level-related data for a first time period through a first application; executing a second application configured to display glucose level-related information; providing the first set of data to the second application; obtaining a second set of glucose level-related data for a second time period; determining that the second application has not yet received the second set of data; and backfilling the second set of data into the second application.

[0019] In another embodiment of the disclosed technology, a method for determining the safety compliance level of two or more medical devices and modifying medical data based on the safety compliance level includes: receiving continuous glucose measurements from a wireless receiver; determining the compliance level of the medical devices; and providing the continuous glucose measurements to the medical devices based on the determined compliance level, wherein when the medical devices meet a high compliance level, the continuous glucose measurements are provided to the medical devices in real time, and when the medical devices meet a high compliance level, the continuous glucose measurements are provided to the medical devices after a predetermined delay.

[0020] Other systems, methods, features, and / or advantages will become apparent to those skilled in the art upon review of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and / or advantages be included within the scope of this description and protected by the appended claims. Attached Figure Description

[0021] Figure 1 An exemplary system for monitoring glucose levels is illustrated.

[0022] Figure 2A An exemplary method for controlling the timing of providing glucose data to an application is illustrated.

[0023] Figure 2B The illustration shows an exemplary method for controlling the timing and classification of glucose data for distribution to applications.

[0024] Figure 3 An exemplary method for integrating glucose levels with health information is illustrated.

[0025] Figure 4 The illustration shows an exemplary user interface for monitoring glucose levels with integrated health information.

[0026] Figure 5 The illustration shows an exemplary method for separating glucose level-related data for different applications.

[0027] Figure 6A and 6B The illustration shows an exemplary user interface that displays separated data related to glucose levels.

[0028] Figure 7 An exemplary method for encrypting glucose level-related data is illustrated.

[0029] Figure 8 An exemplary method for providing data to an application and monitoring whether the data has been updated is illustrated.

[0030] Figure 9A and 9B The illustration shows an exemplary user interface for displaying data related to glucose levels and an indication of whether the data has been backfilled.

[0031] Figure 10 An exemplary method is illustrated for determining the compliance level of a medical device and providing glucose level-related data to the medical device based on the compliance level.

[0032] Figure 11 An exemplary system for monitoring glucose levels is illustrated.

[0033] Figure 12 An exemplary computer used to monitor glucose levels is illustrated.

[0034] Figure 13 An exemplary method for verifying the accuracy of information stored by a third-party application is illustrated.

[0035] Figure 14 An exemplary method for providing data from a third-party application to a dedicated application is illustrated.

[0036] Figure 15 The diagram illustrates an instance of a user interface presented to a user for receiving verified data on the calibration of a sensor device.

[0037] Figure 16 An illustration shows an example display of the main screen for a dedicated application associated with a continuous analysis sensor device.

[0038] Figure 17 An illustrative diagram showing the data flow between an external sensor device and a dedicated application on a user's mobile device is provided.

[0039] Figure 18 A diagram of a user employing multiple body-worn sensor and / or actuator devices provides health information related to glucose data monitored by a continuous glucose sensor unit. Detailed Implementation

[0040] The illustrative embodiments described in this disclosure relate to techniques for receiving glucose data from a continuous glucose sensor and controlling the use and redistribution of said data, thus using said data in a predetermined manner. Some embodiments control which applications will receive the data, provide security measures to maintain the privacy of medical data, and display glucose levels and other health information for applications running on smartphones, etc. The embodiments thus provide users with convenient access to medical data, such as glucose levels, on smartphones, while maintaining privacy and security when redistributing medical data to other applications and devices. While some embodiments are described as displaying medical data on smartphones, it should be understood that other display devices, including tablets, personal computers, smartwatches, cloud applications, and the like, can be used.

[0041] Example scenarios will now be discussed to illustrate some of the embodiments disclosed herein.

[0042] The example environment generally involves a networked system of one or more body-worn medical devices communicating with electronic devices that measure one or more health characteristics of a patient and / or manage one or more treatments for the patient. The monitored health characteristics may include the subject's glucose concentration in this example, but may be alternatively included as any one or more of the other health characteristics described herein. The treatments managed for the patient may include insulin management using, for example, an insulin pump, but may be any one or more of the other treatments described herein in other examples.

[0043] Beyond the instance context, the one or more body-worn medical devices may each generate data and provide that data to consumer electronic devices, such as smartphones, tablets, smartwatches, or other wearable and / or mobile computing devices. Smartphones are used in the following examples and other examples described. A smartphone may include a dedicated application that configures the smartphone to receive and process data provided (e.g., wirelessly transmitted) by a body-worn medical device. The data provided by the body-worn medical device may include, for example, glucose measurements, insulin delivery levels, diagnostic information about the medical device, and timestamps associated with each. The smartphone, using the dedicated application, can then perform various functions based on the received data, such as generating charts and user-perceptible alerts using the data. The smartphone, using the dedicated application, may also receive and generate other data, such as data from the smartphone's user (e.g., user identification information), user interactions with the dedicated application, diagnostic information from the dedicated application, and the like. In some embodiments, the dedicated application may include a set of dedicated applications that can operate on one or more computing devices of patient users and / or non-patient users to manage access to patient user data collected by the medical device. In one instance, the suite of dedicated applications may include: a first dedicated application that operates on a patient user's smartphone to process and provide biomedical data to the patient user wearing a body-worn medical device; a second dedicated application that operates on a 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 that operates on another user's device (e.g., a remote monitor's smartphone) to remotely monitor authorized data from the biomedical data.

[0044] A dedicated application can be one or more applications downloaded from a remote server using a smartphone. In one instance, the smartphone is an iPhone purchased from Apple, Inc., and the application is a so-called "App" downloaded from the App Store, which is commercially operated by Apple, Inc.

[0045] It may also be necessary for a dedicated application to provide some or all of the data generated by the medical device worn on the body and the data generated by the dedicated application to other applications (e.g., third-party applications) residing on a smartphone or other communicatively connected computing system, such as a third-party smartphone (e.g., a guardian or family member) or a corporate system (e.g., an electronic health record operated by the Mayo Clinic in Rochester, Minnesota, or Epic in Verona, Wisconsin). The third-party application may have other capabilities that provide advantages to the user compared to the dedicated application, such as the ability to process the provided data differently (e.g., having more processing power or capability to generate different useful charts or insights) and / or to integrate the provided data with other data (e.g., integrating glucose and insulin data provided by the dedicated application with meal and exercise data generated by the third-party application).

[0046] In this exemplary environment, a dedicated application provides all or selected data to a distributed application running on a smartphone. The distributed application facilitates the distribution of data collected and generated by the dedicated application to other applications running on the smartphone. The distributed application can be another so-called "App" running on the smartphone. The distributed application may include an application programming interface (API) that allows other applications, such as the dedicated application residing on the smartphone and third-party applications, to provide and access data from the distributed application. In this way, the dedicated application can provide data to the distributed application, which can then be used by third-party applications on the smartphone. These third-party applications can acquire, process, and output data in any manner that the application is capable of. As a specific example, the third-party application may include meal tracking functionality, which obtains glucose production data provided by the dedicated application via the distributed application. The third-party application can integrate glucose data with meal information to provide valuable insights to the user, correlating meal intake with fluctuations in the user's glucose levels.

[0047] However, some implementation schemes may aim to restrict the data that third-party applications can access. For example, users may not want some or all third-party applications to access confidential information, such as patient-identifiable information. Alternatively, certain types of information may be more strictly controlled by government regulations; for instance, specific government regulations may prohibit other applications from accessing certain types of medical information (if those applications have not been approved by the relevant government body). Furthermore, security considerations may also be a factor in restricting which applications can access data. For example, even if regulations do not prohibit data exchange, it may be desirable to restrict access to certain types of data so that third-party applications do not use the data in an unsafe manner, such as incorrectly prompting users to take clinically dangerous medical actions.

[0048] Therefore, exemplary embodiments in this exemplary environment can restrict the distribution of data to third-party applications. In some implementations, only certain types of data are provided to the distributed application, preventing third-party applications from having direct access to the data. In some implementations, some or all of the data is encrypted before being provided to the distributed application. In this way, only third-party applications with a key to decrypt the encrypted data can use the encrypted data accessed from the distributed application. In some implementations, this key may be provided only to approved third-party applications that meet regulatory and / or security requirements. Similarly or alternatively, other methods of restricting access to some or all of the data may be used, as described elsewhere herein.

[0049] Beyond the exemplary environment, it may be desirable to limit third-party application access to health measurement data to so-called retrospective measurement data. Retrospective measurement data is data that is no longer actionable. That is, actionable data is data that is timely enough to allow for effective action to prevent or respond to adverse changes in a patient's physiological state. Actionable data is so-called real-time continuous glucose measurement, and may also include predictive continuous glucose measurement (e.g., glucose values ​​predicted over future time periods, such as to the next 5 minutes or 1 hour). To illustrate with 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 diabetes state, such as impending or actual hypoglycemia, or impending or actual hyperglycemia. In contrast, retrospective continuous glucose data is data that would not be used to treat a user's current clinical state because the data may be too old to provide value for making decisions about how to treat the patient. While not necessarily used to treat the current clinical state, retrospective data is still highly valuable for extrapolating insights into a patient's health. Examples include comparing a patient's glucose levels over time with the carbohydrates ("carbs") and / or medications the patient ingests to gain insights into how carbohydrates and / or medications have affected the patient's glucose levels and potentially modify the treatment plan associated with the patient.

[0050] It should be understood that the content constituting actionable data can depend on a variety of factors. For example, the content constituting actionable data can depend on how quickly the clinical state of a health condition associated with one or more monitored health characteristics can change from a non-adverse physiological state to an adverse physiological state. To illustrate, while a clinical state of diabetes can change relatively quickly, for example, from a safe range of glucose concentration to an unhealthy range of glucose concentration, the time frame for this change is typically longer than about 30 minutes. In contrast, a monitored health condition associated with cardiac conditions can change much faster, approximately within minutes or even seconds. Therefore, actionable data associated with monitoring a diabetes condition (e.g., continuous glucose data) can extend over a much longer time frame than data associated with monitoring a cardiac condition (e.g., EKG and heart rate data).

[0051] Therefore, in the above exemplary environment, traceable glucose data can be accessed by a third-party application from a dedicated application via a distributed application, as discussed above, but the third-party application is blocked from accessing non-traceable glucose data, such as actionable and predictive glucose data.

[0052] In some implementations, for example, traceable data refers to data on a subject's monitored health characteristics that are older than one of the following timeframes: 1 minute, 5 minutes, 15 minutes, 30 minutes, 1 hour, 3 hours, 5 hours, 12 hours, 24 hours, or 1 day. For instance, in one embodiment monitoring a subject's glucose levels, continuous glucose data older than 3 hours is considered traceable glucose data. In contrast, continuous glucose data measured within the last three hours is considered non-traceable data, containing actionable data.

[0053] The following are some of the features that may include the instance environment described above, but do not necessarily include any of the features described above.

[0054] Figure 1 The illustration depicts an exemplary system for monitoring glucose levels and controlling access to and use of medical data. (Reference) Figure 1 The continuous glucose sensor unit 100 acquires a series of measurements related to the user's glucose level. The continuous glucose sensor unit 100 can be worn, for example, in the abdominal area of ​​a patient. A small sensor can extend into the patient's body to obtain glucose readings using, for example, subcutaneous glucose or blood glucose readings. The continuous glucose sensor unit 100 can also be a percutaneous device, an intravascular device, or a non-invasive device.

[0055] The continuous glucose sensor unit 100 may include several components for obtaining glucose measurements, storing data, calculating glucose levels, communicating with a dedicated display 104 and / or other computing device 106 (e.g., a smartphone, referred to herein as display 106 for convenience), and performing other tasks. For example, although not illustrated, the continuous glucose sensor unit 100 may include non-volatile memory for storing historical data about glucose values, a processor, a battery, and a wireless transmitter. The wireless transmitter provides any type of wireless communication 102a and 102b, including Bluetooth connectivity (e.g., Bluetooth Low Energy (BLE)), Wi-Fi connectivity, RF connectivity, and other connections. In some embodiments, wireless communication 102a and 102b occurs between paired verification devices and uses encryption and other cryptographic techniques to ensure confidentiality of the communication.

[0056] Although illustrated as a single unit, portions of sensor unit 100 can be removed from the remainder of the continuous glucose sensor unit. For example, reusable electronics of sensor unit 100 (e.g., transmitter, battery, memory) can be removed from single-use portions of the sensor unit (e.g., and reused together with new single-use portions). Furthermore, continuous glucose sensor unit 100 may include other components to facilitate data communication. For example, continuous glucose sensor unit 100 may include wired ports, such as USB ports, Ethernet ports, and other ports, for communicating with other devices and providing glucose level-related data, system data, etc.

[0057] Figure 1 The continuous glucose sensor unit 100 acquires samples at predetermined intervals, such as every few seconds, every thirty seconds, every minute, every five minutes, or as needed in response to the occurrence of an event (e.g., a command from the user, detection of user actions such as user movement, and similar events). The wireless transmitter can be disconnected or placed in a low-power state to conserve battery life while acquiring one or more measurements within a time period, and then wake up again to wirelessly transmit the one or more measurements to a dedicated display 104 and / or display 106 in a batch transmission. For example, the continuous glucose sensor unit 100 can wake up the wireless transmitter every five minutes to transmit data (and any other data) related to the glucose measurements generated in the previous five minutes, and transmit the data to the dedicated display 104 and / or display 106. The wireless transmitter can then be disconnected again to conserve battery life. While an example of transmitting data every five minutes has been provided, it will be understood that longer or shorter time periods can be used, and these time periods can be configured by the user via the dedicated display 104 and / or display 106.

[0058] The data transmitted between the continuous glucose sensor unit 100 and the dedicated display 104 and / or display 106 can be any type of data related to monitoring glucose values ​​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 display 106 periodically upon initial startup to maintain the accuracy of glucose measurements. Users sample their glucose levels using a single-point glucose meter, inputting the values ​​displayed by the test kit into one of the displays 104 and 106, and these values ​​calibrate the continuous glucose sensor unit 100. Other examples of the exchanged data include the amount of current or voltage measured by the continuous glucose sensor, converted glucose values ​​in, for example, mg / dL, and a timestamp associated with the time each measurement or value was sampled, warnings related to glucose levels exceeding predetermined thresholds, detected faults in the system, and the like. Although described as a continuous glucose sensor unit 100, other medical devices are available for use in the disclosed embodiments. For example, the continuous glucose sensor unit 100 can be an analytical sensor, and the transmitted data can reflect analytical values.

[0059] Dedicated display 104 may be a display specifically designed for use with continuous glucose sensor unit 100. The combination of continuous glucose sensor unit 100 and dedicated display 104 in one embodiment may be an approved medical device, such as a Class III medical device. Dedicated display 104 receives glucose level-related data from continuous glucose sensor unit 100 at predetermined time intervals. In some embodiments, dedicated display 104 may include dedicated application 108 to receive and display at least a portion or the entire set of data received from continuous glucose sensor unit 100. For example, dedicated display 104 displays the actual glucose level associated with the measurement performed by the sensor. In some embodiments, display 104 may be designed to receive, process, and / or store data, but with a limited user interface, such as limited user functionality or a small display configured to display limited information (e.g., recently measured analytical concentration values ​​and trend arrows). In some instances, the user interface of display 104 may include a reduced number of input buttons (e.g., physical buttons or virtual buttons on an interactive display) to allow the user to input information (e.g., calibration information, including glucose concentration values ​​from a single-point blood glucose device, and / or settings, rules, etc., for alarms). In some instances, display 104 may include audible alarms and / or vibrating motor alarms. By keeping the functionality of display 104 limited, it can be easily carried by the user and provides an interactive device for tracking and informing the user of their monitored glucose information (from sensor unit 100) and providing other important health information and alerts without requiring a large auxiliary computing device. Display 104 may be coupled to another computing or display device (e.g., display 106) to display enhanced glucose and health-related information that the user may wish to view, such as detailed reports of data-driven traceability analysis.

[0060] In some embodiments, display 106 may include a dedicated application 108 to receive and display at least a portion or the entire set of data received from the continuous glucose sensor unit 100. Display 106 may include one or more third-party applications, such as an approved third-party application 110 (approved to manage health data) and / or other third-party applications 112 (unapproved to manage health data), to be provided with or permitted access to certain data received from the continuous glucose sensor unit 100. In some embodiments, the transmitter of sensor unit 100, the operating system executing on display 106, or the dedicated application 108 operating on display 106 may restrict the third-party application from receiving and displaying actual glucose levels. The third-party application may instead receive more general indicators of glucose levels, such as whether the glucose level is low, normal, or high. Additional details regarding the types of data that may be sent to and displayed by dedicated display 104 and display 106 are provided below.

[0061] The dedicated display 104 includes a processor for calculating glucose levels based on received measurements, a memory for storing glucose levels, a port for wired communication, and wireless communication circuitry such as Bluetooth, Wi-Fi, and RF circuitry. Additionally, the dedicated display 104 can determine whether the user's glucose levels show a downward trend, remain stable, or have a historical upward trend. Figure 1 As shown in the example, a dedicated display 104 presents glucose readings over time, allowing the user to easily monitor glucose levels and display the actual value of the current glucose level. Figure 1 In this example, the dedicated display 104 shows that the current glucose level is 94 mg / dL.

[0062] The display 106 can be any type of display associated with a personal computer, tablet computer, or smartphone that runs an application for displaying data related to glucose levels. Therefore, the display 106 includes hardware components typically associated with personal computing devices, including a processor, memory, wireless connectivity, a USB port, and other components.

[0063] Display 106 executes multiple applications 108 to 116 related to glucose monitoring, health information, exercise activity, control and monitoring of insulin injections, dietary habits, and other operations. In one embodiment, display 106 receives the same data transmitted from continuous glucose sensor unit 100 to dedicated display 104. Display 106 includes a dedicated application 108 created by the manufacturer or affiliate of continuous glucose sensor unit 100. Dedicated application 108, display 106, and / or continuous glucose sensor unit 100 may be approved medical devices. For example, continuous glucose sensor unit 100, dedicated display 104, and dedicated application 108 may individually or in combination be approved Class III medical devices. Dedicated application 108 controls the distribution of medical data received from continuous glucose sensor unit 100 to other third-party applications 110 and 114 executing on display 106 to maintain confidentiality and user preferences, as described in more detail below. Although not illustrated, dedicated application 108 may also be an application that communicates directly with dedicated application 108 (e.g., ...). Figure 1 The example shown is an approved third-party application 110 that connects to other third-party applications 112 and 116 and provides them with information.

[0064] exist Figure 1 In the illustrated example embodiment, a dedicated application 108 or an operating system running on display 106 provides glucose level-related data to an approved third-party application 110. For example, dedicated application 108 receives glucose data from a continuous glucose sensor unit 100, determines which dataset should be provided to the approved third-party application 110, and provides the data to the third-party application 110. Users can configure, via dedicated application 108, what types of medical data should be provided to the approved third-party application 110. In this way, third-party application 110 receives the same dataset or a simplified dataset received by dedicated application 108, which may be provided as encrypted data. While dedicated application 108 has been described as controlling what data is provided to third-party application 110, an operating system or other software program running on display 106 may also separate data received from continuous glucose sensor unit 100 and provide it to applications 108 through 116, where appropriate and under various restrictions.

[0065] The approved third-party application 110 may also share data with other third-party applications 114 and 116. This poses a security risk because 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 the additional applications 114 and 116. Figure 1The system can restrict applications 114 and 116 from providing medical data to additional applications, network storage sites, or other entities in an unauthorized manner. Users may want third-party applications, such as approved third-party application 116, to access the medical data provided to application 110. As an example, dedicated application 108 provides glucose levels to approved third-party application 110, which controls an insulin infusion pump. In this example, the user wants third-party application 110 to share glucose levels with third-party application 116 to provide effective feedback and allow for more accurate control of insulin injections.

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

[0067] Now it will be turned into a reference. Figure 2A The illustration depicts an exemplary method for providing glucose data to applications that include dedicated and third-party applications. For example, the method can be implemented to control the accessibility of a user's sensitive health data (e.g., glucose levels) to third-party applications to protect user security and privacy. For instance, even when calibration occurs at the sensor to provide a calibration value, the third-party application may unreliably or incorrectly use data related to glucose levels. In some cases, for example, the transmitter sends raw sensor data, and the third-party application does not have the correct formula for converting the raw sensor data into glucose levels. The conversion process may involve using a specific calibration for a given individual and sensor, and without access to this information, the third-party application generates inaccurate glucose levels from the raw sensor data. This can lead to potentially dangerous situations where the user does not receive notifications through the third-party application. In some embodiments, for example, Figure 2A The method controls the timing of redistributing medical data by delaying the provision of glucose-related data to a third-party application, thus addressing, for example, the two scenarios mentioned above. This delay prevents reliance on the accuracy of the third-party application in potentially harmful health situations. In practice, the user will rely on a dedicated display 104 or a dedicated application 108 for recommendations based on real-time or non-delayed glucose levels.

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

[0069] At process 202, the transmitter sends the glucose measurement and associated timestamp to dedicated display 104 and / or display 106. The transmitter may send the measurement and timestamp continuously, at predefined intervals (e.g., every five minutes), or as needed in response to a request from a user or device. In one embodiment, the continuous glucose sensor and transmitter may wake from a low-power sleep state every five minutes, acquire a sample, transmit data, and then return to a low-power sleep state. In other embodiments, the continuous glucose sensor acquires multiple measurements, and each measurement may be transmitted every five minutes, or the processor at the continuous glucose sensor unit 100 may process the measurements to provide fewer than all of them. As an example, the data processing unit on the continuous glucose sensor unit 100 may average the measurements acquired over a time period and transmit the average value along with a timestamp associated with the time of the first sample, the last sample, or the average sample.

[0070] In one embodiment, the data transmitted from the continuous glucose sensor unit 100 also includes other data related to monitoring a patient's glucose levels. For example, the continuous glucose sensor unit 100 transmits metadata that includes sensor calibration information, patient information, the type of sensor used to generate the measurement, system diagnostic information, rate of change information, trends (e.g., glucose values ​​rising, stabilizing, or decreasing, or numerical values ​​representing the rate of change), alarm or alert information, and / or system status. Examples of system status include warm-up, which can be the interval between sensor warm-up and calibration, operation, and offline status after a new sensor is installed.

[0071] In some embodiments, the continuous glucose sensor unit 100 encrypts glucose level-related data before transmission. When using Bluetooth communication, encryption can be performed by the data processing unit on the continuous glucose sensor unit 100 in addition to standard encryption provided by the Bluetooth device. Furthermore, in some embodiments, the continuous glucose sensor unit 100 may transmit data only to paired, verified devices. One-way or two-way verification techniques can be used to ensure that the continuous glucose sensor unit 100 only transmits data to authorized devices.

[0072] As an example, a transmitter identifier can be printed on the continuous glucose sensor unit 100. A user can enter a transmitter identifier code on displays 104 and 106 as part of a pairing process that verifies displays 104 and 106 for communication with the continuous glucose sensor unit 100. The continuous glucose sensor unit 100 and displays 104 and 106 exchange private and public security keys during the pairing process or when the user enters the transmitter identifier. Through the authentication and pairing mechanism, the system can securely transmit data between the continuous glucose sensor unit 100 and the displays 104 and 106 associated with the sensor. For example, multiple users with the continuous glucose sensor 100 may be in a public area. In one embodiment, displays 104 and 106 can be paired and authenticated with their associated continuous glucose sensor unit 100, ensuring that users do not receive data from other sensors within the range of the wireless network.

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

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

[0075] The first application 108 can run in the background, so that the display of glucose values ​​does not actually occur before the user views the first application. The first application 108 receives the measurement values ​​and handles any processing required for display. In some embodiments where the continuous glucose sensor unit 100 transmits, for example, raw data values ​​and timestamps, the first application 108 can convert the raw data values ​​into measurement units familiar to the user, such as mg / dL. The process of converting raw data values ​​can also be completed by, for example, the continuous glucose sensor unit 100 before transmission to display 104 and / or display 106. The first application 108 performs these processes in the background and prepares the measurement values ​​for display, for example, when the user selects the first application to the foreground.

[0076] The first application 108 may be part of an approved medical device. Therefore, in some embodiments, the first application 108 may process certain types of glucose measurements that would otherwise be restricted from use by other applications due to regulatory and / or security concerns. These certain types of glucose measurements may be one or more of real-time, actionable, and predictive glucose measurements rather than retrospective glucose measurements. In embodiments where the sensor unit 100 transmits raw data values ​​to the display 106, the first application 108 may use calibration values ​​input by the user, along with appropriate conversion formulas for the specific user and sensor. The first application 108 thus maintains the level of accuracy required for an approved medical device.

[0077] In some embodiments, a first application 108 alerts the user when glucose levels drop below or rise above a predefined level. The first application 108 may escalate the alert based on the current time or the user's activity. For example, an alert that glucose levels have dropped to a low level overnight could indicate that the user is asleep and a louder alert should be used. In some embodiments, a data processing unit executing on a dedicated display 104 or display 106 samples data from an accelerometer. The first application 108 may determine that the user may be asleep based on accelerometer data indicating that the user is not physically active, thereby causing the first application to escalate the alert.

[0078] Additionally, users can set alerts to be triggered when their glucose levels trend in a specific direction or change by a certain amount within a given time period. The operating system or dedicated application 108 tracks glucose levels and issues alerts or warnings as appropriate. Users can thus obtain accurate recommendations on managing their glucose levels through the first application 108. For example, users can choose to eat extra food, exercise, control insulin injections, and / or perform other tasks based on the real-time display of glucose data provided by the first application.

[0079] At process 208, the first application 108 determines the amount of delay to be used before providing glucose level-related data to a third-party application. This delay amount can be set by the manufacturer or the user. In some exemplary embodiments, the delay amount may be, for example, between five minutes and three hours, but other values ​​may also be chosen. This delay, based on limiting the data, restricts the third-party applications 110 to 116 from providing real-time recommendations to the user, ensuring accurate health recommendations are made by the first application 108 based on the current glucose level.

[0080] The first application 108 may select the latency amount based on which third-party application it serves the data to. For example, an approved third-party application 116 may have a shorter latency than other third-party applications, such as third-party application 112, which... Figure 1 The instances in this example have not yet been approved by the provider of the first application 108. Additionally, the first application 108 can control the data type that will be provided to each third-party application. In one embodiment, a third-party application may receive the same data as the dedicated application 108, or limited data, such as data with fewer data points, average data points, or indications of whether glucose levels are low, normal, or high without any specific data points. Further examples of providing data to various applications will be provided below.

[0081] At process 210, the first application 108 provides the measurement value and associated timestamp to the third-party application after the delay. The third-party application is also referred to as the second application. In one embodiment, the dedicated application 108 provides an indication of the amount of delay to the third-party application, allowing the third-party application to indicate to the user the time associated with the displayed measurement value and / or the delay. The third-party application thus displays the delayed data and an indication of the amount of delay or the time when the continuous glucose sensor unit 100 acquires a measurement value.

[0082] According to some implementation schemes, process 210 may occur either by the first application 108 automatically providing data to the second application after a delay, or by the second application requesting data. As an example of requesting data, the second application may be disconnected for a time period and, upon execution, request any past data from the first application 108. In response, the first application 108 provides all data except for data falling within a predetermined delay. After startup, the second application continues to request data from the first application, or the first application periodically provides data automatically to the second application. For example, process 210 may be implemented using the application programming interface (API) of the dedicated application 108, which facilitates the transfer of data to other applications, such as third-party applications residing on a smartphone.

[0083] Figure 2A Implementations of the method allow the continuous glucose sensor unit 100 to transmit data to a display executing multiple applications. A first application 108 may use the real-time data for display, alerting the user, or other processing. The continuous glucose sensor unit 100 provides data indicating glucose levels and a timestamp indicating the sampling time of the glucose level. The first application 108 optionally displays the glucose level and timestamp, and delays the glucose level and timestamp by a predetermined amount of time before providing them to a third-party or second application. The third-party or second application receives and uses the delayed glucose level. The third-party application may use the delayed glucose level, for example, for display. In some embodiments, the third-party or second application receives a condensed set of data or averaged data, as described below. Additionally, in some embodiments, the second application may receive some data in real time and receive other data after a delay.

[0084] exist Figure 2A In some embodiments of the exemplary method shown, a dedicated application 108 receives health data including glucose measurements and associated timestamps, or glucose measurements and their corresponding associated timestamps generated consecutively at process 104. At process 208, the dedicated application 108 determines a delay amount to be used before providing any of the received health data (e.g., glucose measurements) to another third-party application, and determines that the duration between the current time and the timestamp satisfies the determined delay amount. The determined delay amount may be input into the dedicated application or a predetermined default delay amount. For example, the delay may be predetermined to 3 hours or other time periods considered to allow the data to be used as traceable data. In these embodiments, at process 210, the dedicated application 108 provides only traceable glucose measurements to the third-party application device only after the predetermined delay amount. Similarly, in some embodiments, at process 210, the dedicated application 108 provides glucose measurements and / or any other health data determined to be delayed to the third-party application only after the determined delay amount.

[0085] In these implementations, for example, the dedicated application 108 may be a medical device software application that configures the mobile computing device to receive and process medical data (e.g., glucose measurements provided by the continuous glucose sensor unit 100), and the third-party application is not an approved medical device software application, i.e., it has not been approved by a government regulatory agency authorized to regulate medical device technology. Figure 2AImplementations of the exemplary method may therefore allow these unapproved third-party applications to access valuable medical data collected, processed, and protected by medical device software applications (e.g., dedicated application 108), as well as medical data valuable to end users (e.g., patient users and their caregiver networks, remote monitors, etc.), in accordance with government regulations regarding medical devices and / or medical data, to obtain and view such data on third-party applications that can integrate and enrich medical data. Third-party applications may obtain, process, and output medical data in any manner that a third-party application is capable of. In an illustrative example, a third-party application may include meal tracking functionality, which can be integrated with... Figure 2A The exemplary method used is to integrate glucose measurement data provided by a dedicated application 108. Third-party applications can integrate glucose data with meal information to provide users with valuable insights, such as correlating meal intake with fluctuations in a user's glucose levels.

[0086] In some embodiments, for example, Figure 2A An exemplary method may include a process for generating a subset of data from received health data, wherein a first subset of data and a second subset of data are generated according to predetermined criteria (e.g., by dividing the received health data into multiple subsets, and / or by generating at least some new or modified data based on the received health data). Figure 2A An exemplary method may include a process for controlling which subsets of data are provided to a third-party application after a delay is determined in providing the determined subset.

[0087] Figure 2B The illustration shows an exemplary method for controlling the timing and classification of glucose data for distribution to applications. Figure 2B The exemplary methods are referenced for illustrative purposes. Figure 1 The system and Figure 2A and Figure 5 The method is described, and can be used in conjunction with, except for Figure 2B Other systems and / or processes besides those described in the exemplary embodiments may be used together. Figure 2B As illustrated in the figure, the exemplary method includes process 204, in which a dedicated display 104 and / or display 106 receives glucose level-related data and associated timestamps from a continuous glucose sensor unit 100. The received data may include continuously generated glucose level measurements and their associated timestamps. For example, display 106 (e.g., a mobile computing device such as a smartphone) uses a dedicated application 108 or the operating system of display 106 to receive glucose measurements and associated timestamps. Figure 2BAn exemplary method includes process 252, in which a first application 108 separates received data into a first data set and a second data set. In some embodiments of process 252, the first application divides continuously generated glucose measurements into the first and second data sets based on predetermined criteria, such as the category or type of data (e.g., identifiable by data fields or metadata), the timestamp of the data, the size of the data, the source of the data, or other factors associated with the received data. In some embodiments of the exemplary method, the received data includes additional health or medical data, and process 252 includes the first application 108 generating a data set related to the continuously generated glucose measurements, from which the first and second data sets are formed. Figure 2B An exemplary method includes process 254, wherein a first application 108 restricts access to a second data set for a second application, the second application being one or more of, for example, third-party applications 110 to 116. Figure 2B An exemplary method includes process 208, wherein a first application 108 determines the amount of latency to be employed before providing data to a third-party application, such as a delay value that may be set by the manufacturer and / or by the user, for example, five minutes, three hours, or other time delay values. Figure 2B In some exemplary embodiments of the method, process 208 may be performed before process 252; and in other exemplary embodiments, process 208 may be performed after process 252, for example, included after process 254. The delay, based on limiting data, restricts third-party applications 110 to 116 from providing real-time recommendations to the user, ensuring accurate health recommendations are made by the first application 108 based on the current glucose level. Figure 2B An exemplary method includes process 210, in which a first application 108 provides a first data set to a second application (e.g., one or more third-party applications) after a delay.

[0088] Figure 3 An exemplary method for integrating glucose levels with health information is illustrated. Figure 3 The methods described herein, as well as other methods, are referenced for illustrative purposes. Figure 1 The system described herein. The disclosed methods can be used with other systems or different components of a system other than those described in the exemplary embodiments. Figure 1As illustrated in the diagram, third-party application 110 provides a centralized way for users to access health information. Display 106 can execute multiple applications related to health information. Some examples include applications that track sleep patterns, monitor food and calorie intake, track exercise, measure calories burned, monitor blood pressure, control and record insulin injections, monitor heart rate, monitor supplement and medication consumption, and perform other operations. For example, third-party applications 114, 116, etc., provide information to the approved third-party application 110, which stores the user's health-related information. Many different types of health information can affect glucose levels and an individual's health, generally assumed to be diabetes-related or other conditions. Therefore, Figure 3 The method obtains health information from a third-party application that acts as a health information repository and distributed interface for other applications to store and access health information. The dedicated application can integrate the health information from the third-party application used for display with glucose levels, allowing users to track the correlation between health information and glucose levels.

[0089] At process 300, dedicated application 108 acquires glucose data as previously described. Then, at process 302, dedicated application 108 accesses a health application (also referred to herein as a distributed application) that acts as a repository for health information. For example, the health application may include an approved third-party application 110. In some embodiments, third-party application 110 may act as a repository for receiving and storing health information from a third-party application 114 that tracks exercise activity and from an approved third-party application 116 that controls insulin administration.

[0090] In some embodiments of process 302, dedicated application 108 may access the health application via a standardized application programming interface (API). Dedicated application 108 may inspect the health application for any new data at the occurrence of an event. The event may be, for example, a time interval, application startup or opening, detection of glucose levels exceeding a threshold, and other events. As a specific example, dedicated application accesses the health application to inspect updated data periodically (e.g., every fifteen minutes), in response to detection that glucose levels have risen or fallen to a predefined level, in response to detection of the rate of change in glucose levels, as requested by the user, when dedicated application 108 is executed, in a predetermined pattern of one or more monitored health characteristics (e.g., instructing the monitored person to eat, administer insulin, and exercise or sleep), and similarly. Additionally, third-party application 110 or the operating system running on display 106 may push information to dedicated application 108 in response to the occurrence of any of the aforementioned events.

[0091] As an example, the continuous glucose monitor 100 sends glucose measurements and associated timestamps to a dedicated application 108 in process 300. In process 302, the dedicated application 108 connects to the health application 110 after detecting a defined decrease in glucose levels, such as a decrease of 50 mg / dL over a 30-minute interval. For example, a rapid drop in glucose level signals may indicate that the user is exercising, suggesting that the health application may have received or is receiving exercise information from another application tracking exercise activity. In response to the detected change in glucose levels, the dedicated application 108 obtains health information from the health application 110 in process 304, as described below.

[0092] At process 304, dedicated application 108 obtains health information from the health application through a standardized interface. The health application automatically provides health information to dedicated application 108 in response to an event or a request from dedicated application 108, as previously described. The health application may include a standardized application interface that provides a list of acceptable commands and formats for any response. For example, dedicated application 108 may send, for instance, the following command: retrieve exercise activity, and receive a response with two variables—one indicating the type of activity (e.g., running, weightlifting, walking, swimming, etc.) and one indicating the duration of the activity. While examples have been provided, it will be understood that other application interfaces can be used to exchange information between dedicated application 108 and the health application.

[0093] This health information may include, for example: indications of the specific medications the user has taken, the dosage, and the time of administration; nutritional information such as calories and sugar consumed; physical measurements such as the user's height, weight, blood pressure, and heart rate; insulin information indicating the time and dosage of insulin injections; and other types of health information.

[0094] As another illustrative example, a dedicated application 108 detects a given rate of change in glucose levels and prompts the user with health-related information. The user inputs health-related information directly into the dedicated application 108 or into a health application such as an approved third-party application 110. For example, the dedicated application 108 can detect a sudden rise in glucose levels and prompt the user to input meal information, or detect a drop in glucose levels and prompt the user to input exercise activity. Furthermore, prompts from other distributed systems, such as a cloud that monitors the user's glucose levels, or from another application that monitors glucose levels, can trigger prompts to input or access health information.

[0095] The dedicated application 108 can control and configure the types of health information obtained from the health application. For example, a user might be comfortable with the dedicated application 108 accessing, for example, exercise and nutrition information rather than medication 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 grants permission for categories of health information or only for specific items of health information. For example, one user might want to allow access to all health information related to medications taken, while another user might want to limit medication consumption to insulin. The dedicated application 108 stores data and exercises control over the access to authorized information. Additionally, the dedicated application 108 allows the user to revoke permission at any time to prevent the dedicated application 108 from accessing some or all of the health information stored by the health application.

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

[0097] At process 306, the dedicated application can display glucose data along with health information obtained from the health application 110. Figure 4 The example shown is an example display, but other display configurations can also be used. Figure 4 The graph shows glucose levels along the y-axis and time along the x-axis. Curve 402 illustrates continuous glucose levels based on data received from a continuous glucose sensor.

[0098] like Figure 4The diagram illustrates a user's continuous glucose level 402 as a trend over a time period beginning at 9:30 AM. A first instance of health information is shown at 408, illustrating an instruction to briefly record training before 10:30 AM. A third-party application tracks exercise activity and records the start of training. In an embodiment such as process 304, the health application obtains the training record from the third-party application while training is in progress or after training has concluded. In this example, the dedicated application 108 may access health information at 10:30 AM and receive an instruction to record training at 10:25 AM. Although not illustrated, the user can select the training record icon 408 to view more information about the training, such as the duration, calories burned, and any other information provided by the third-party application to the health application that is also authorized for access by the dedicated application. As shown along the continuous glucose level 402, glucose levels trend sharply downward shortly after training. This integrated display thus provides the user with a convenient way to correlate glucose levels with specific activities and health information.

[0099] The display also shows an alert when glucose levels drop below a defined amount or trend downward at a defined rate, as illustrated at 410. Subsequently, at 412, dedicated application 108 displays integrated health information indicating that a meal has been recorded in dedicated application 108, a health application, or another application. In one embodiment, dedicated application 108 reconnects to the health application at 11:45 AM and determines that new health information, in the form of a recorded meal, has been entered into the health application. The user can select the meal record icon 412 and receive any additional information related to the meal, such as calories consumed and the amount of sugar.

[0100] In one embodiment, the dedicated application 108 in Figure 4 The example shown automatically accesses health information. As illustrated, glucose levels decrease from approximately 10:00 AM until stabilizing at 11:30 AM, and then begin to rise. A 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 has engaged in other activities that affect glucose levels. In this example, the other activity is a meal consumed by the user, but it could also be, for example, the user administering glucagon. The process of automatically accessing the health application can occur in place of or supplement to other technologies such as periodic access.

[0101] User interface 414 may also include additional information for users to track their glucose levels and health information. For example, the current glucose level may be displayed at 404, and the current trend of the glucose level may be displayed at 406. The current trend level may be within a time period, such as the most recent five, ten, or thirty minutes, or another interval. The trend may also be displayed as a downward-pointing arrow to indicate a decreasing glucose level, a horizontal arrow to indicate a stable glucose level, or an upward-pointing arrow to indicate a rising glucose level. In addition, although not illustrated, the display may present other information, such as a red light to indicate an alarm due to glucose levels being outside the acceptable range, or a green light to indicate that the glucose level is acceptable.

[0102] While the integration of health information with glucose levels has been described as importing health information into a dedicated application 108, glucose levels can also be integrated with health information within health information applications, such as any of the third-party applications 110 to 116. For example, a food application allows users to take a photo of their food and determine the food type and nutritional value from the photo. The food application obtains glucose values ​​from the dedicated application 108 and will display them similarly to… Figure 4 The chart shown is overlaid with an image of food. Therefore, users can easily correlate changes in glucose levels with specific types of food consumed based on stored food images. In other applications, the integration of glucose levels can allow applications to better identify patients requiring care, develop customized analytics for patient care, improve clinical outcomes in diabetes, and monitor patient risk between doctor's appointments.

[0103] Figure 5 An exemplary method for separating glucose level-related data for different applications is illustrated. A continuous glucose sensor unit 100 transmits sensitive medical data to displays 104 and 106. The amount and type of data provided to various applications can be limited to ensure authorized use of the medical data. In one embodiment, the determination of the amount and type of data to be distributed can be based on the security level provided by each application and / or the user's preferences. Figure 5This method allows the complete 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. This method allows for the protection of sensitive medical data after it has been received from the continuous glucose sensor unit 100 and further distributed to the display device and the application executing on the display device. Unapproved applications often contain unacceptable security flaws regarding sensitive medical data. For example, an application may redistribute sensitive medical information without any restrictions on redistribution, leading to a cascading effect that compromises patient privacy or, in extreme cases, could risk the patient's health. As another example, applications may not use encryption or other forms of security, making them vulnerable. Therefore, Figure 5 The method separates glucose level-related data to control and limit the types of data provided to various applications.

[0104] At process 500, a first application, such as dedicated application 108, receives glucose level-related data from the continuous glucose sensor unit 100. This data includes, for example, multiple glucose level measurements and associated timestamps indicating when the measurements were obtained, as well as metadata including: calibration information, patient information, the type of sensor used to generate the measurements, system diagnostic information, rate of change information, trends (e.g., glucose values ​​rising, stabilizing, or decreasing), alarm or alert information, and / or system status. The data may also include the user's personally identifiable information, calibration data for the continuous glucose sensor unit 100, system diagnostic information, and / or other private health information about the patient. The data may also be generated by the user via user input in dedicated application 108 or another application 110 to 116, or by pulling data from a server via the operating system or dedicated application 108. In some embodiments, dedicated application 108 obtains data from the continuous glucose sensor unit 100 as previously described.

[0105] At process 502, the first application 108 separates the data into a first set and a second set according to predetermined criteria (e.g., established controls). The established controls include, for example, rules for restricting third-party applications' access to the complete dataset, which may be based on user preferences or default controls. For example, a user can establish controls that cause the first application 108 to provide data to an approved third-party application 110, also referred to as the second application. The first application 108 may include controls based on user input, or default settings previously determined based on user preferences, to establish which types of data will be provided to the second dataset for use by the third-party application. Furthermore, for example, the first application 108 may include default controls independent of user preferences to establish rules for restricting third-party applications' access to specific data, such as preventing access to data that may pose a risk to a patient's health. Instances of data separated into a second dataset for third-party applications may include only average glucose values ​​over defined intervals (e.g., 15 minutes instead of all sampled glucose values), and / or generalized indications of glucose levels rather than actual measurements, where exemplary indications include low, normal, or high, and which levels constitute the boundaries of low, normal, or high is predefined by the system or the user. In some embodiments where data is determined to be suitable for both the first and second datasets based on predetermined criteria, the second dataset may contain the same data as the first dataset.

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

[0107] The first application 108 can separate data in various ways, including logically separating it in software or physically separating it in memory. For example, the first application 108 may cause a device such as sensor unit 100, display 104, display 106, or another computing device securely communicating with the device executing the first application 108 to store a copy of the data in memory for a first data set and a second data set, store records in a logical database to which the data in each set belongs, or store a single data set with limiting values ​​provided only to the first application and not to the second application. In other embodiments, the continuous glucose sensor unit 100 may separate the data into two sets before emission, or the operating system of the device executing the first application 108 (e.g., display 106) may perform the separation. Additionally, although described as separating data to provide a single or concise data set to a specific application, the first application 108 may also restrict other applications (e.g., third-party applications or additional applications as part of a suite of dedicated applications) by allowing other applications access to specific types of data based on predefined rules. In some embodiments, the predefined rules are set by the system manufacturer and / or user. In these cases, the type of access granted data can be retrieved from other applications communicating with the first application 108, and may not necessarily be provided to other applications as described later in process 506.

[0108] At process 504, the first application 108 stores a first data set. For example, the first application 108 may store the first data set on display 104, display 106, sensor unit 100, and / or another computing device that securely communicates with the device executing the first application 108. In one embodiment, the first data set includes the complete data set received from the continuous glucose sensor unit 100. The first application 108 stores the first data set in the memory of display 106 and makes it available for display, for example... Figure 4 and 6A As shown in the exemplary user interface. (Reference) Figure 6A The user interface 600 displays a first data set, which contains multiple consecutive glucose levels shown in a time period to help the user monitor glucose levels.

[0109] At process 506, the first application 108, or the operating system executing on the display 106, provides the second data set to the second application. The second data set contains a streamlined set of data suitable for use by a third-party application. For example, Figure 6BThe illustration shows a user interface 602 with a third-party application displaying a second set of data indicating a healthy state with normal glucose levels. In one embodiment, the third-party application also displays other health information obtained from a dedicated application 108 or another third-party application, such as the user's blood pressure and the time of the user's last meal.

[0110] The first application 108 may provide the second data set to the second application by: pushing data to the second application, sending a notification to the second application informing it of a data request, or making the data available for access in response to a request from the second application. The second data set may be provided periodically, on demand, or in response to specific events. For example, when a user launches the second application, the second application requests any updated data, including the second data set, since the last launch of the second application.

[0111] Although two data sets have been described, the system can also generate additional sets for each application. Users can choose to provide glucose level-related data to multiple applications, and each application can receive a data set based on permission granted to it. In this embodiment, Figure 5 The method can be executed multiple times to produce additional data sets.

[0112] Figure 7 The illustration depicts an exemplary method for controlling the redistribution of medical data by encrypting glucose level-related data. One way to control access to medical data is by encrypting the data before it is emitted from a continuous glucose sensor or before it is distributed to other applications. Third-party applications may share their data with other applications, which may also distribute the data to servers, the Internet, and other devices. Therefore, when a transmitter or a dedicated application provides glucose level-related data to other applications, it is necessary to control how other applications can access and redistribute the data. Figure 7 In this example, the dedicated application 108 or sensor unit 100 can encrypt the glucose level-related data before providing it to other applications, thereby providing enhanced security and preventing unauthorized third parties from using the data without permission. Specifically, unauthorized third parties will not have the key to decrypt the data.

[0113] Figure 7 This involves encrypting the data before providing it to third-party applications. The key used to decrypt the data can be provided to authorized third-party applications. Therefore, refer to... Figure 1Approved third-party application 116 can access glucose data through approved third-party application 110, but approved third-party application 110 or other third-party applications such as 114 may be blocked from accessing the data. In this exemplary embodiment, approved third-party application 110 can act as a pathway to provide information to other applications.

[0114] The decryption key can be provided to an approved third party in a variety of ways. For example, in some implementations, the approved 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.

[0115] At process 700, display 106 and a first application, such as dedicated application 108, receive glucose level-related data from continuous glucose sensor unit 100, as previously described. At process 702, the first application 108 stores and displays the data, as previously described. For example, the first application displays continuous glucose levels over a time period, the current glucose level, and the trending glucose level.

[0116] At process 704, the first application 108 or the operating system executing on the display 106 encrypts the glucose data. The encrypted data may include all data received from the continuous glucose sensor unit 100, or as previously referenced... Figure 5 , 6AThe data received includes a subset as described in 6B, as well as other data generated at the dedicated application 108. Encryption can be performed using various techniques, including public-key / private-key encryption, etc. The type and amount of data encrypted by the first application 108 or the operating system may vary depending on the application receiving the data. For example, one receiving application may receive all the data in real time, another receiving application may receive the data after a first delay, such as fifteen minutes, and yet another application may receive the data after a longer delay, such as three hours. Furthermore, for example, the first application 108 may encrypt all the data using an encryption technique with a first encryption key and a separated subset of the data using another encryption technique with a different encryption key, wherein the data set and the corresponding decryption key may be received only by its designated application. Additionally, encryption software on a third-party application may decrypt only certain types of data and / or only after a predetermined delay. The first application 108 or the operating system may provide the same or different data to each application, thereby restricting certain types of glucose level-related data to any given application. In some embodiments, the first application 108 or the operating system provides encrypted data in real time, but provides the key after a predetermined delay, thereby preventing the receiving application from decrypting the data before an authorized time.

[0117] At process 706, the first application 108 or the operating system may provide 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, while in some embodiments no key is provided.

[0118] In an instance where data is provided to a second application without a decryption key, the second application provides the data to another application at process 708, acting as a pathway entity by providing encrypted data without having the independent capability to decrypt it itself. (See reference) Figure 1 The illustration shows an instance in which a third-party application 110 provides encrypted data to an approved third-party application 116. Although described as a third party or a third-party application, it will be understood that applications 110 or 116 do not need to originate from a third party.

[0119] At 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 from the first application 108, from an operating system running on display 106, through the third-party application 110, from another application, or directly 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, through user configuration, to control the future use of the data.

[0120] Encryption techniques can be changed periodically or as needed, requiring new decryption keys to access data. Therefore, a user can request data encryption and provide a key for use only during a defined time period. As an example, a physician can use a third-party application to control insulin injections. A dedicated application 108 or an operating system running on display 106 encrypts glucose data from the continuous glucose sensor unit 100 and transmits the data via an approved third-party application 110 to an application used by the user's physician office. The physician's application allows healthcare professionals to monitor glucose levels and make recommendations to the user. However, if the user switches physicians, the first application can revoke permission to receive or decrypt data by disallowing the approved third-party application 110 from providing data to the physician's application and by changing the encryption key.

[0121] Figure 8 The illustration depicts an exemplary method for providing data to an application and monitoring whether the data is up-to-date. One issue that arises when providing data to multiple displays and multiple applications running on those displays is ensuring that each application or display contains the latest data. For example, a user may disconnect an application, thus not receiving data from the first application. In other embodiments, the application may be inactive, the display may be disconnected or out of wireless range, or the application may receive data in response to a user request. If an application does not receive glucose data within a time period, then the application is not up-to-date. Figure 8 This method therefore allows older data to be backfilled into the application to bring it up-to-date. Up-to-date can mean that the application makes all data available to it. For example, in a scenario where the application receives data after a predetermined delay, as previously described, up-to-date could mean that the application has all available data up to the predetermined delay.

[0122] exist Figure 8At processes 800 and 802, display 106 receives glucose data and provides the data to a first application, as previously described. At process 804, the first application 108, or an operating system executing on display 106 (or in some embodiments involving a second application), determines whether the glucose data in the second application is up-to-date. In one embodiment, the first application 108 maintains a record of the time it provides glucose data to the second application. The second application acknowledges receipt of glucose data to allow for accurate recording of the most recent data provided to and received by the second application. In other embodiments, the second application sends an indication to the first application of the time associated with its most recent glucose value, for example, it may be periodic, intermittent, or in response to an inquiry or request from the first application 108 or the operating system executing on display 106. In any exemplary embodiment, a determination is made regarding whether the second application is up-to-date and includes the most recent glucose level from the continuous glucose sensor unit 100.

[0123] The second application can be considered up-to-date as long as it has received data up to any predetermined delay, for example, as referenced. Figure 2A As described above, when the second application is up-to-date, the first application 108 provides any new glucose data at process 810. However, if the second application is not up-to-date, then the first application 108 calculates the amount of data to be backfilled at process 806.

[0124] In one embodiment, the first application 108 determines the amount of data to be backfilled based on a defined time range, for example, excluding data exceeding a given lifespan (outside the time range). For instance, the first application 108 stores continuous glucose data spanning periods of several days, weeks, or even months. If the second application has been disconnected for an extended time period, or if it is being installed and executed for the first time, the first application 108 may backfill data within the first six hours. The first application 108 may also use other durations, as six hours is only provided as an example. Furthermore, in some implementations, the user can request additional data beyond any default range to be backfilled into the second application. The user can also enter the start and end dates for backfilling data into the second application.

[0125] The process 806, which calculates the amount of data to be backfilled, can occur automatically, in response to a user request, or after the user has been prompted whether to backfill and has answered affirmatively. Following process 806, at process 808, the first application 108 provides the backfilled data to the second application, for example, it may use an application programming interface (API). Once the first application 108 has backfilled the selected range of data to the second application, the first application 108 provides any new glucose data to the second application at process 810. Alternatively, the first application 108 may first provide the current glucose data and then backfill the previous data.

[0126] Figure 9A and 9B The diagram illustrates an exemplary user interface for displaying data related to glucose levels and indications of whether the data has been backfilled. Figure 9A In this context, the user interface 900, provided by the first or second application, may include a graph illustrating glucose levels over a time period when in portrait mode, as described in the embodiments herein. However, when the user rotates the display 106 to landscape mode, the user interface 902 illustrates an indication 904 that data within a given range has been backfilled.

[0127] The display can also indicate that other techniques have been used to backfill data. For example, the line illustrating the sampled glucose level can use different colors or patterns during the intervals when backfilled data is available. A user using a second application to alert when glucose levels drop below a defined level might wonder why no alert was received from the second application at the time corresponding to a low glucose level. However, when the display uses lines of different colors or additional markings to indicate that data has been backfilled, the user can confirm that the second application did not have glucose levels when the alert would have occurred.

[0128] Although Figure 8 , 9A The embodiments in 9B have been described as backfilling a second application, but it will be understood that the continuous glucose sensor unit 100 may also provide backfill data directly to the first application, the second application, or the dedicated display 104. For example, the dedicated display 104 or display 106 may be outside the wireless range of the continuous glucose sensor unit 100. In another instance, the user may disconnect the dedicated application 108. In either case, the dedicated display 104 or the dedicated application 108 may not have the current glucose value. The continuous glucose sensor unit 100 may detect that the glucose value is stale and inconsistent with... Figure 8The same method described herein provides backfill data within a defined time period. That is, the continuous glucose sensor unit 100 can begin transmitting data from the moment it last received confirmation that glucose data was received from the dedicated display 104 or display 106. Alternatively or additionally, the dedicated display 104 or display 108 can detect that it only stores old data and request backfilling of glucose values ​​for a given time period.

[0129] Figure 10 An exemplary method is illustrated for determining the compliance level of a medical device and providing glucose level-related data to the medical device based on the compliance level. Figure 10 The example illustration demonstrates how the data types provided to other applications are controlled based on their level of compatibility. This ensures that dedicated application 108 only provides data to trusted applications, or provides a streamlined set of data to an application compared to other applications.

[0130] At process 1000, display 106 receives glucose data from continuous glucose sensor unit 100, as previously described. At process 1002, dedicated application 108 determines the compliance level of another application or third party requesting access to data related to glucose levels. Dedicated application 108 may determine the compliance level in a variety of ways. For example, dedicated application 108 accesses a list of applications stored in memory or online that indicates whether the application has been approved by the Food and Drug Administration as a medical device, and if so, indicates the corresponding classification of the medical device. In another embodiment, the application may provide its classification and safety level indication to dedicated application 108.

[0131] If the application has a high compliance level, such as a Class III medical device, then dedicated application 108 provides glucose data to the application at process 1004. For example, dedicated application 108 may provide glucose level-related data to the application in real time. However, if the compliance level is low, such as when the application is not a medical device, then dedicated application 108 provides glucose level-related data with limitations at process 1006. For example, the limitations may include encrypted data, provide a concise data set, delayed data, or previous references. Figures 1 to 10 Any combination of the described embodiments. In both cases where unlimited data is provided at process 1004 or limited data is provided at process 1006 (e.g., as described with reference to Figures 2, 5 and / or 7), the user can control their preference in deciding which application will receive the data and what set of data should be provided.

[0132] Figure 11An exemplary system for monitoring glucose levels is illustrated. Figure 11 The system can be combined Figure 1 The system and the previously described embodiments are used. Specifically, any of the disclosed methods can be used with any of the disclosed systems. However, it will be understood that the disclosed methods can be used with other system architectures, and the disclosed systems implement other methods.

[0133] like Figure 1 In the embodiments, Figure 11 The system shown includes a continuous glucose sensor unit 100, wireless connections 102a-b, a dedicated display 104, and one or more displays 106 executing an application. The dedicated display 104 can be connected to a computer 1102 using a wired or wireless connection. The computer 1102 can be, for example, a personal computer, tablet computer, laptop computer, smartphone, or server. Additionally, the dedicated display 104 can be connected to the display 106, and the display 106 can be connected to the computer 1102.

[0134] Computer 1102 and monitor 106 can be connected to cloud storage device 1104, which provides long-term storage for glucose-related data, health information, system calibrations, and other information related to continuous glucose monitoring. Cloud storage device 1104 includes multiple storage devices, a computer, and network connectivity. Communication between dedicated monitor 104, computer 1102, monitor 106, and cloud storage device 1104 can use encryption to prevent unauthorized access to medical data.

[0135] Cloud storage device 1102 is connected to backend system 1106. Backend system 1106 provides technical support 1108 for users configuring and using the continuous glucose monitor. Backend system 1106 also monitors system information, such as the versions of the software running on continuous glucose monitor 100, dedicated display 104, display 106, and computer 1102. Backend system 1106 provides updates as needed, or securely pushes updates to dedicated display 104, display 106, continuous glucose sensor unit 100, and other system components via network connection.

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

[0137] A dedicated display 104 or display 106 provides continuous glucose data to a cloud storage device 1104. The cloud storage device 1104, backend system 1106, and / or display 1102 can monitor the continuous glucose data. Display 1102 receives and displays continuous glucose values ​​as previously described, either without restriction as with a dedicated application 108 or subject to restrictions as with a third-party application. In some embodiments, the restrictions can be set by the dedicated display 104 or display 106. In other embodiments, display 1110 sets restrictions on the data it receives through an authentication process between the user of the continuous glucose monitor 100, the user of display 1100, and the backend system 1106. For example, the user can contact the backend system (e.g., via computer or telephone communication) to establish authentication, such as by calling a representative of technical support 1108 and answering security questions to establish appropriate system operation, or by performing the process online. Once completed, the user of the continuous glucose sensor unit 100 or the user of display 1110 can be restricted in terms of the data received by their device or their ability to change system operation. This prevents dedicated display 104 or display 106 from restricting monitoring through display 1110. For example, situations may arise where the user of sensor unit 100 and / or display 104 or 106 may wish to limit the monitor responsible for continuous monitoring to those using display 1110, such as when a child might consume a large amount of sweets at a birthday party (causing a spike in glucose levels). The disclosed user authentication and data access processes and controls take into account a variety of use cases, such as the previous examples.

[0138] Figure 12 The illustration depicts an exemplary computer for monitoring glucose levels. It may include a continuous glucose sensor unit 100, a dedicated display 104, a display 106, a computer 1102, a cloud storage device 1104, a back-end system 1106, and a display 1110. Figure 12 The components shown.

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

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

[0141] RAM 1222 and ROM 1223 may each include one or more means for storing information associated with the operation of CPU 1221. For example, ROM 1223 may include a memory means 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 means for storing data associated with one or more operations of CPU 1221. For example, ROM 1223 may load instructions into RAM 1222 for execution by CPU 1221.

[0142] Storage device 1224 may include any type of mass storage device configured to store information that CPU 1221 may need to perform a process consistent with the disclosed embodiment. For example, storage device 1224 may include one or more magnetic and / or optical disc devices, such as hard drives, CD-ROMs, DVD-ROMs, or any other type of mass media device.

[0143] Database 1225 may include one or more software and / or hardware components that cooperate to store, organize, select, filter, and / or arrange data used by CPU 1221. For example, database 1225 may contain data related to monitoring glucose levels, associated metadata, and health information. Database 1225 is expected to store additional information and / or information different from that listed above.

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

[0145] Interface 1227 may include one or more components configured to transmit and receive data via a communication network, such as the Internet, a local area network, a workstation peer-to-peer network, a direct-link network, a wireless network, or any other suitable communication platform. For example, interface 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 perform data communication via a communication network.

[0146] Any combination of one or more computer-readable media may be used. The computer-readable media may be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination thereof. More specific embodiments of the computer-readable storage medium (not an exhaustive list) will include the following: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compressed optical disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. Program code embodied on the computer-readable medium may be transmitted using any suitable media, including (but not limited to) wireless, wired, fiber optic cable, RF, etc., or any suitable combination thereof.

[0147] Computer program code can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, or similar languages, and conventional programming languages ​​such as C or similar languages. Program code can be executed entirely on a computing unit.

[0148] Figure 13 The illustration depicts an exemplary method for verifying the accuracy of information stored by a third-party application. When distributing sensitive medical data, issues may arise where the recipient stores data inaccurately or even fails to store data at all due to system errors. This can lead to problems including incorrect glucose level recommendations and user confusion when the recipient displays data different from that provided by the provider. In one instance, a dedicated application 108 transmits data to a health application, and verification is required that the health application accurately receives and stores the data.

[0149] At process 1300, dedicated application 108 delivers glucose data to a health application. The health application can be any type of application that receives glucose data from dedicated application 108. Dedicated application 108 can deliver actual measured values ​​or test data to the health application.

[0150] At process 1302, dedicated application 108 reads glucose data from the health application. Data can be requested to be read from the health application using an application programming interface (API). By reading back the delivered value, at process 1304, dedicated application 108 can verify 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 delivered data, dedicated application 108 notifies the user or determines that the health application should no longer receive data related to the glucose value. In one embodiment, dedicated application 108 delivers a predetermined test glucose value and time to the health application. Dedicated application 108 then reads back the glucose value associated with the predetermined time and determines whether the two match.

[0151] Figure 14An exemplary method for providing data from a third-party application to a dedicated application is illustrated. This method can be used to verify the authenticity and trustworthiness of data and / or the source of the data. Implementations of this method allow the disclosed system to receive data from external devices or systems in an automated manner with protection and without requiring manual user input. For example, a continuous glucose sensor unit 100 may require or benefit from inputting glucose values ​​from an external glucose meter device, such as a single-point blood glucose (BG) meter, for initial startup calibration and / or periodic calibration updates or verification to maintain the accuracy of glucose measurements. In these cases, the user samples their glucose levels using the blood glucose meter, which 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 initial or periodic calibration purposes 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 BG values, which may also be provided to a health application on the user's device (e.g., third-party health application 110). As discussed above, accurate glucose values ​​for the calibration of the continuous glucose sensor unit 100 are particularly important because inaccurate measurements can lead to a variety of potentially dangerous situations where the user takes action based on incorrect glucose readings and / or fails to receive notifications about their physiological condition or receives false positives, thus preventing them from taking appropriate action. Therefore, Figure 14 This method provides essential verification features during the transmission of this data from a third-party application to a user's dedicated application associated with the continuous glucose sensor unit 100, while also providing convenience and security to the user by automating the data transmission and minimizing the risk of inaccurate data from user data entry errors. For example, the method can reduce potential errors such as a user reading a BG value of "68" (mg / dL) from a single-point blood glucose meter and typing "98" (mg / dL) into the user interface of a mobile device (e.g., display 106) for calibration of the continuous glucose sensor unit 100.

[0152] At process 1400, dedicated application 108 requests data (e.g., blood glucose data) from a health application, also referred to in this instance as... Figure 1 The third-party health application 110 shown is illustrated. The health application 110 can be a data storage device from a single-point blood glucose meter, on the device, or in the cloud, or via another application (also referred to in this instance). Figure 1This refers to any type of application (such as the third-party applications 112, 114, or 116 shown) that receives blood glucose data. In some embodiments of process 1400, dedicated application 108 requests data from other third-party applications 112, 114, or 116. Dedicated application 108 may request data by accessing health application 110 (or other third-party applications in some embodiments) via a standardized application programming interface. Dedicated application 108 may request data from health application 110 based on the occurrence of an event. The event may be, for example, a specific time or the amount of time since the previous data request or event, the launch or opening of dedicated application 108 or health application 110, or other events. In a particular instance, dedicated application 108 accesses health application 110 to request glucose data for a specific time in the morning and a specific time in the evening on a daily basis.

[0153] Alternatively or concurrently, at process 1401, dedicated application 108 receives data-available communications (e.g., blood glucose data) from health application 110 for retrieval. In some embodiments of process 1401, dedicated application 108 receives data-available communications from other third-party applications 112, 114, or 116.

[0154] At process 1402, dedicated application 108 obtains blood glucose data from health application 110 or other third-party applications. In some embodiments, dedicated application 108 obtains data via a standardized application programming interface (API) that provides a list of acceptable commands and formats for any response relative to the application communicating with the dedicated application. For example, dedicated application 108 may send, for instance, the following command: retrieve blood glucose value, and receive a response with two or more variables—a numeric value indicating the blood glucose measurement and associated units, and a timestamp when the measurement was taken. While examples have been provided, it will be understood that other APIs may be used to exchange information between dedicated application 108 and third-party applications. In some embodiments, health application 110 or an operating system executing on the user's display 106 may push blood glucose data to dedicated application 108 after process 1400 or 1401 or in response to either of the previously described events.

[0155] The acquired blood glucose data includes metadata associated with each blood glucose measurement, such as the unit of the measurement (e.g., concentration unit, such as mg / dL), the timestamp when the measurement was collected, parameters associated with the measurement (e.g., information associated with chemical analysis), codes associated with an external blood glucose meter device or the test strip used by the meter, or similar.

[0156] At process 1404, dedicated application 108 verifies the blood glucose data obtained from health application 110 or other third-party applications to determine if it originates from an authorized source. In some embodiments, dedicated application 108 analyzes metadata to verify the source of the blood glucose measurement data. For example, dedicated application 108 may process metadata to identify one or more codes associated with an external blood glucose meter device or test strips used by the meter, checking against a list of authorized devices and / or test strips to confirm the authenticity of the blood glucose measurement data. If the identified code matches an authorized device or associated component, then dedicated application 108 approves the blood glucose data.

[0157] At optional process 1406, dedicated application 108 presents a notification to the user to accept verified blood glucose data for calibration of continuous glucose sensor unit 100. In some embodiments, the notification is presented as a pop-up window of dedicated application 108 on the display screen of the user device (e.g., display 106) executing dedicated application 108. In some embodiments, the notification is presented on the user device (e.g., display 106) via an operating system operating on the user device as a notification in the form of a banner, badge, sound, and / or alert. In some embodiments, the notification is made to the user via text message, email, instant messaging, automated telephone calls, or other communications. In some embodiments, the notification includes an option for the user to respond positively or negatively to accept 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, then dedicated application 108 provides an interface for receiving user data input for blood glucose data.

[0158] Figure 15 A diagram depicts an example user interface of dedicated application 108 presenting a notification that verified blood glucose data has been received for calibration of a continuous glucose sensor unit for a user. On display 1501, the user interface presents an option for the user to respond affirmatively (“Yes”) or negatively (“No”) to dedicated application 108 to use verified blood glucose data, in this example shown as a BG value of “107 mg / dl at 9:59 AM” obtained from the “Health App” of the “Verio meter”. If the user selects “Yes”, the user interface displays display 1502, which depicts a return to the main view of dedicated application 108, in this example 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 display 1503, which depicts a prompt to enter a BG value for calibration.

[0159] Figure 16Illustrations of other instance displays of the main screen or main view 1502 of the dedicated application 108 are shown. Figure 16 In the example shown, the main screen can present health information such as insulin, related to diet, exercise, and nutrition, in various formats including text and / or graphical interfaces. This health information can be presented approximating glucose data provided by the continuous glucose sensor unit 100, as previously described regarding... Figure 4 , 6A As described in 9A and 9B.

[0160] See back Figure 14 At process 1408, the dedicated application 108 sends verified data to the continuous glucose sensor unit 100.

[0161] Figure 17 An illustrative diagram shows the data flow between an external sensor device (e.g., a single-point blood glucose meter) and a dedicated application 108 on the user's device (e.g., in this example, a smartphone). As shown, the single-point blood glucose meter wirelessly transmits blood glucose data to a third-party application (e.g., a dedicated application 108 on a smartphone). Figure 1 The approved third-party application 116 shown is used 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, after receiving blood glucose data from the third-party application, the health application may store the blood glucose data in a cloud storage device and manage the storage device and accessibility using the health application's database. The health application may, according to... Figure 14 The method provides blood glucose data to a dedicated application.

[0162] Figure 18 A diagram illustrating a user employing multiple body-worn sensor and / or actuator devices that provide health information related to glucose data monitored by a 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, and similar devices. Figure 18In one example, a user wears a continuous glucose sensor unit 100, which communicates via BLE to the user's mobile device (e.g., display 106, such as a smartphone), where data received from the sensor unit 100 is managed by a dedicated application 108. The user also employs an insulin pump, which communicates with the user's smartphone using a third-party application (e.g., third-party applications 110 to 116). In a closed-loop environment, third-level sensors and devices are not considered. However, if third-party applications directly or indirectly associated with these third-level sensors and devices residing on the smartphone can connect and interact with the dedicated application, then information collected and / or processed by the third-party applications can be included in and utilized by the dedicated application for the user's health management. For example, an associated third-party application with a heart rate monitor (HRM) can aggregate information from the HRM and provide said information to a health application or dedicated application for the sensor unit 100. Using the techniques described above, heart rate data can be stored and displayed simultaneously with the sensed glucose information from the continuous glucose sensor unit 100. In this way, for example, a patient user can view this information and infer knowledge from it. Moreover, access to information can be provided to secondary viewers, such as healthcare providers, who can utilize the information as determined by the provider for a range of purposes, from information to data analysis.

[0163] Furthermore, for example, if the patient user utilizes an exercise monitor such as a BLE pedometer or other exercise-related device, then the dedicated application 108 and / or health application 110 can aggregate the pedometer data into a comprehensive dataset that includes glucose data, HRM data, and other sensor or actuator data. Illustratively, in these events, when exercise does occur and the exercise sensors provide information to the user's mobile device, the information collected from the exercise device is aggregated into the dataset and analyzed to align or correlate the information from the exercise data with, for example, the sensed glucose level. Therefore, the patient user will not need to enter any tokens or event markers in their glucose monitoring application, as this occurs automatically through the disclosed system environment.

[0164] The disclosed system environment can provide automated data input for events and activities with a high degree of detail and granularity, which may be inconvenient or impossible for patient users to operate independently and at predetermined intervals as they occur. For example, the predetermined intervals can be, for instance, predetermined intervals or timed events, such as heart rate per minute at 15-second intervals or calories burned every 30 seconds, where thresholds within these intervals can trigger automated data input of events with glucose data according to the technology described in this patent document.

[0165] Furthermore, this aggregated information from the third-level sensor and / or actuator device can provide information about potential motion artifacts in the data collected from other sensing devices including the continuous glucose sensor unit 100. These motion artifacts can be presented as true / false presence and / or data confidence levels and / or values ​​on a scale. This information can be sent or provided to the continuous glucose sensor unit 100 or to technical support services for the sensor unit 100, for example, via a dedicated application 108 or a health application 110, for further processing and decision-making and / or as input to data processing algorithms.

[0166] It will be understood that each block of the flowchart illustration and / or block diagram, and combinations of blocks in the flowchart illustration and / or block diagram, can be implemented by computer program instructions. These computer program instructions are provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of said computer or other programmable data processing apparatus, create components for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0167] Although the term "first application" has been referred to as dedicated application 108, it will be understood that the first application can be any of or another of third-party applications 110 to 116. Similarly, although the second application has been referred to as approved third-party application 110 and health application, the second application can also be dedicated application 108, any of or another of third-party applications 112 to 116. Moreover, although some applications 110 to 116 have been described as third-party applications, it will be understood that applications 110 to 116 do not need to be provided by a third party.

[0168] It should be understood that the various techniques described herein can be implemented in combination with hardware or software, or where appropriate. Therefore, the methods and apparatus of the currently disclosed subject matter, or certain aspects or portions thereof, may take the form of program code (i.e., instructions) embodied in tangible media such as floppy disks, CD-ROMs, hard drives, or any other machine-readable storage media, wherein when the program code is loaded into and executed by a machine, such as a computing device, the machine becomes an apparatus for practicing the currently disclosed subject matter. In the case of program code execution on a programmable computer, the computing device generally includes a processor, processor-readable storage media (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 conjunction with the currently disclosed subject matter, for example, through the use of an application programming interface (API), reusable control, or the like. These programs may be implemented in high-level programs or object-oriented programming languages ​​to communicate with a computer system. However, programs may be implemented in assembly or machine language when necessary. In any case, the language may be a compiled or interpreted language, and the language may be combined with hardware implementations.

[0169] Example The following examples illustrate several embodiments of the present invention. Other exemplary embodiments of the present invention may be presented before or after the examples listed below.

[0170] In some embodiments of the present invention (Example 1), a method for monitoring glucose levels includes: receiving a glucose measurement and a timestamp transmitted via a wireless connection, the measurement being related to glucose quantity; displaying the measurement via a first application after receiving it; determining when the duration between the current time and the timestamp meets a predetermined delay; and providing the measurement to a second application only after the predetermined delay.

[0171] Example 2 includes the method of Example 1, further comprising: receiving a plurality of consecutively generated glucose measurements; providing the plurality of consecutively generated glucose measurements to a first application; delaying the predetermined amount of time after receiving each of the plurality of consecutively generated glucose measurements; and providing each of the plurality of consecutively generated glucose measurements to a second application after the delay.

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

[0173] Example 4 includes the method of Example 1, wherein the delay is between five minutes and three hours.

[0174] Example 5 includes the method of any of Examples 1 to 4, further comprising: obtaining metabolic health information from the second application, the metabolic health information affecting glucose levels; and displaying the glucose measurement value simultaneously with the metabolic health information using the first application.

[0175] Example 6 includes the method of any of Examples 1 to 4, further comprising: obtaining metabolic health information using the first application, the metabolic health information affecting glucose levels; and displaying the glucose measurement value simultaneously with the metabolic health information using the first application.

[0176] Example 7 includes the method of Example 1, further comprising: generating a data set related to continuous glucose monitoring; dividing the data set into a first data set and a second data set; providing the first data set and the second data set to a first application; restricting the second application's access to the second data set; and providing the first data set to the second application.

[0177] Example 8 includes the method of Example 7, wherein restricting access includes not sending the second data set to the second application.

[0178] Example 9 includes the method of any of Examples 1 to 4, 7 or 8, further comprising encrypting the first data set before providing the first data set to the second application.

[0179] Example 10 includes the method of any one of Examples 1 to 4, 7 or 8, further comprising determining a subset of data related to continuous glucose monitoring via the first application for provision to the second application.

[0180] Example 11 includes the method of any of Examples 1 to 4, 7 or 8, which further includes limiting the measurement value to be further distributed from the second application to additional applications.

[0181] Example 12 includes the method of any one of Examples 1 to 4, 7 or 8, further comprising: providing the timestamp to the second application; reading the measurement value and the timestamp from the second application; comparing the read measurement value with the measurement value provided to the second application; determining whether the read measurement value matches the provided measurement value; comparing the read timestamp with the timestamp provided to the second application; and determining whether the read timestamp matches the provided timestamp.

[0182] Example 13 includes the method of any of Examples 1 to 4, 7 or 8, further including configuring whether to provide the measurement value to the second application.

[0183] Example 14 includes the method of any one of Examples 1 to 4, 7 or 8, further comprising: encrypting the measurement value before providing the measurement value to the second application; transmitting the encrypted measurement value from the second application to a third application; and providing a key for decrypting the encrypted measurement value to the third application.

[0184] In some embodiments of the present invention (Example 15), a system for monitoring glucose levels includes: a sensor configured to acquire a glucose measurement of glucose quantity; a wireless transmitter configured to transmit the glucose measurement and a timestamp associated with the glucose measurement; and a computing device including: a wireless receiver configured to receive the glucose measurement; and a computer-readable medium. The computer-readable medium includes: a first application that, when executed by a processor, displays the glucose measurement and determines when the duration between the current time and the timestamp meets a predetermined delay; and a second application that, when executed by the processor, receives the glucose measurement after the predetermined delay.

[0185] Example 16 includes the system of Example 15, further including a second computing device configured to receive the glucose measurement in real time and display the glucose amount.

[0186] Example 17 includes the system of Example 15, wherein the computing device includes a smartphone.

[0187] Example 18 includes the system of Example 15, wherein the wireless receiver receives a plurality of consecutively generated glucose measurements; the processor provides the plurality of consecutively generated glucose measurements to a first application; the processor delays each of the plurality of consecutively generated glucose measurements by a predetermined amount of time; and the processor provides each of the plurality of consecutively generated glucose measurements to a second application after the delay.

[0188] Example 19 includes a system of any of Examples 15 to 18, wherein the glucose measurement is provided to the second application in response to the execution of the second application after the delay.

[0189] Example 20 includes a system of any of Examples 15 to 18, wherein the latency is between five minutes and three hours.

[0190] Example 21 includes a system of any of Examples 15 to 18, wherein the processor obtains metabolic health information from the second application, the metabolic health information affecting glucose levels; and the first application displays the glucose measurement simultaneously with the metabolic health information.

[0191] Example 22 includes a system of any of Examples 15 to 18, wherein the processor uses the first application to obtain metabolic health information that affects glucose levels; and the first application displays the glucose measurement simultaneously with the metabolic health information.

[0192] Example 23 includes the system of Example 15, wherein the processor is further configured to: generate a data set related to continuous glucose monitoring; divide the data set into a first data set and a second data set; provide the first data set and the second data set to the first application; restrict the second application's access to the second data set; and provide the first data set to the second application.

[0193] Example 24 includes the system of Example 23, wherein the second application is restricted by not sending the second data set to the second application.

[0194] Example 25 includes a system of any of Examples 15 to 18, 23 or 24, wherein the first data set is encrypted before being provided to the second application.

[0195] Example 26 includes a system of any one of Examples 15 to 18, 23 or 24, wherein the first application is further configured to determine a subset of data related to continuous glucose monitoring to provide to the second application.

[0196] Example 27 includes a system of any of Examples 15 to 18, 23 or 24, further wherein the second application is restricted from further distributing the measurements to additional applications.

[0197] Example 28 includes a system of any one of Examples 15 to 18, 23, or 24, wherein the first application is further configured to: provide the timestamp to the second application; read the measurement value and the timestamp from the second application; compare the read measurement value with the measurement value provided to the second application; determine whether the read measurement value matches the provided measurement value; compare the read timestamp with the timestamp provided to the second application; and determine whether the read timestamp matches the provided timestamp.

[0198] Example 29 includes a system of any one of Examples 15 to 18, 23 or 24, wherein the processor is further configured to receive input controlling whether the measurement value is provided to the second application.

[0199] Example 30 includes a system of any one of Examples 15 to 18, 23 or 24, further comprising: encrypting the measurement value before providing it to the second application; transmitting the encrypted measurement value from the second application to a third application; and providing a key for decrypting the encrypted measurement value to the third application.

[0200] In some embodiments of the present invention (Example 31), a computer-readable medium including instructions that, when executed by a processor, perform a method for monitoring glucose levels, the method comprising: receiving a glucose measurement and a timestamp transmitted via a wireless connection, the glucose measurement indicating glucose quantity; providing the glucose measurement to a first application for display; determining when the duration between the current time and the timestamp meets a predetermined delay; and providing the glucose measurement to a second application after the predetermined delay.

[0201] Example 32 includes the computer-readable medium of Example 31, further including instructions, when executed by the processor, to: receive a plurality of consecutively generated glucose measurements; provide the plurality of consecutively generated glucose measurements to the first application; delay the predetermined amount of time after receiving each of the plurality of consecutively generated glucose measurements; and provide each of the plurality of consecutively generated glucose measurements to the second application after the delay.

[0202] Example 33 includes the computer-readable medium of Example 31, further including instructions, when executed by the processor, to provide the glucose measurement value to the second application in response to the execution of the second application after the delay.

[0203] Example 34 contains the computer-readable medium of Example 31, wherein the delay is between five minutes and three hours.

[0204] Example 35 includes a computer-readable medium of any of Examples 31 to 34, further including instructions, when executed by the processor, to: obtain metabolic health information from the second application, the metabolic health information affecting glucose levels; and to simultaneously display the glucose measurement using the first application and the metabolic health information.

[0205] Example 36 includes a computer-readable medium of any of Examples 31 to 34, further including instructions, when executed by the processor, to: obtain metabolic health information using the first application, the metabolic health information affecting glucose levels; and to simultaneously display the glucose measurement using the first application and the metabolic health information.

[0206] Example 37 includes the computer-readable medium of Example 31, further including instructions that, when executed by the processor, perform the following operations: generate a data set related to continuous glucose monitoring; divide the data set into a first data set and a second data set; provide the first data set and the second data set to the first application; restrict the second application's access to the second data set; and provide the first data set to the second application.

[0207] Example 38 includes the computer-readable media of Example 37, wherein the second application is restricted access by not sending the second data set to the second application.

[0208] Example 39 includes a computer-readable medium of any one of Examples 31 to 34, 37 or 38, further including instructions, when executed by the processor, to encrypt the first data set before providing it to the second application.

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

[0210] Example 41 includes a computer-readable medium of any one of Examples 31 to 34, 37 or 38, further including instructions that, when executed by the processor, restrict the measurement value from being further distributed by the second application to additional applications.

[0211] Example 42 includes a computer-readable medium of any one of Examples 31 to 34, 37, or 38, further including instructions that, when executed by the processor, perform the following operations: providing the timestamp to the second application; reading the measurement value and the timestamp from the second application; comparing the read measurement value with the measurement value provided to the second application; determining whether the read measurement value matches the provided measurement value; comparing the read timestamp with the timestamp provided to the second application; and determining whether the read timestamp matches the provided timestamp.

[0212] Example 43 includes a computer-readable medium of any one of Examples 31 to 34, 37 or 38, further including instructions that, when executed by the processor, configure whether to provide the measurement value to the second application.

[0213] Example 44 includes a computer-readable medium of any one of Examples 31 to 34, 37 or 38, further including instructions, when executed by the processor, to: encrypt the measurement value before providing it to the second application; transmit the encrypted measurement value from the second application to the third application; and provide a key for decrypting the encrypted measurement value to the third application.

[0214] In some embodiments of the present invention (Example 45), a method for displaying glucose-related data and metabolic health information using a continuous glucose monitor includes: obtaining glucose-related data using a first application; accessing a second application configured to store metabolic health information that affects glucose levels; obtaining the metabolic health information from the second application; and simultaneously displaying the glucose-related data with the metabolic health information.

[0215] Example 46 includes the method of Example 45, wherein the first application is used to display the data related to glucose levels and the metabolic health information.

[0216] Example 47 includes the method of Example 45, which further includes: monitoring the second application to determine when the metabolic health information has been provided to the second application; and displaying a prompt requesting approval to obtain the metabolic health information from the second application.

[0217] Example 48 includes the method of Example 45, wherein the metabolic health information includes at least one of dietary intake, exercise, or insulin injection.

[0218] Example 49 includes the method of any of Examples 45 to 48, further comprising monitoring the data related to glucose levels, wherein the second application is automatically accessed when the glucose level reaches a defined level.

[0219] Example 50 includes the method of any of Examples 45 to 48, which further includes monitoring the data related to glucose levels, wherein the second application is automatically accessed when the glucose level has changed by a defined amount.

[0220] Example 51 includes the method of any of Examples 45 to 48, further comprising: monitoring the data related to glucose levels; and requesting input of the metabolic health information when the glucose level reaches a defined level or has changed by a defined amount.

[0221] Example 52 includes the method of any of Examples 45 to 48, wherein the metabolic health information indicates activity level, which is determined by an accelerometer.

[0222] Example 53 includes the method of any of Examples 45 to 48, wherein the continuous glucose monitor includes a smartphone.

[0223] In some embodiments of the present invention (Example 54), a system for integrating glucose-related data with metabolic health information includes: a wireless receiver configured to receive glucose-related data; a memory configured to store the data and the metabolic health information; and a processor. The processor is configured to: obtain the glucose-related data from the memory; access the metabolic health information using a second application configured to control the stored metabolic health information, the metabolic health information affecting glucose levels; obtain the metabolic health information from the second application; and simultaneously display the glucose-related data on a display along with the metabolic health information.

[0224] Example 55 includes the system of Example 54, wherein the first application is used to display the data related to glucose levels and the metabolic health information.

[0225] Example 56 includes the system of Example 54, wherein the processor is further configured to: monitor the second application to determine when the metabolic health information has been provided to the second application; and display a prompt requesting approval to obtain the metabolic health information from the second application.

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

[0227] Example 58 includes a system of any of Examples 54 to 57, wherein the processor is further configured to monitor the data related to glucose levels and automatically access the second application when the glucose level reaches a defined level.

[0228] Example 59 includes a system of any of Examples 54 to 57, wherein the processor is further configured to: monitor the data related to glucose levels, and automatically access the second application when the glucose level has changed by a defined amount.

[0229] Example 60 includes a system of any of Examples 54 to 57, wherein the processor is further configured to: monitor the data related to glucose levels; and request input of the metabolic health information when the glucose level reaches a defined level or has changed by a defined amount.

[0230] Example 61 includes a system of any of Examples 54 to 57, wherein the metabolic health information indicates activity levels, which are determined by an accelerometer.

[0231] In some embodiments of the present invention (Example 62), a computer-readable medium includes instructions that, when executed by a processor, perform a method for integrating glucose-related data with metabolic health information, the method comprising: obtaining glucose-related data using a first application; accessing a second application configured to store metabolic health information affecting glucose levels; obtaining the metabolic health information from the second application; and simultaneously displaying the glucose-related data with the metabolic health information.

[0232] Example 63 includes the computer-readable media of Example 62, wherein the data related to glucose levels and the metabolic health information are displayed using the first application.

[0233] Example 64 includes the computer-readable medium of Example 62, further including instructions, when executed by the processor, to: monitor the second application to determine when the metabolic health information has been provided to the second application; and to display a prompt requesting approval to obtain the metabolic health information from the second application.

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

[0235] Example 66 includes a computer-readable medium of any of Examples 62 to 65, further including instructions, when executed by the processor, to perform the following: monitor the data related to glucose levels, wherein the second application is automatically accessed when the glucose level reaches a defined level.

[0236] Example 67 includes a computer-readable medium of any of Examples 62 to 65, further including instructions, when executed by the processor, to perform the following operations: monitor the data related to glucose levels, wherein the second application is automatically accessed when the glucose level has changed by a defined amount.

[0237] Example 68 includes a computer-readable medium of any of Examples 62 to 65, further including instructions, when executed by the processor, to: monitor the data related to glucose levels; and request input of the metabolic health information when the glucose level reaches a defined level or has changed by a defined amount.

[0238] Example 69 includes a computer-readable medium of any of Examples 62 to 65, wherein the metabolic health information indicates activity levels, which are determined by an accelerometer.

[0239] In some embodiments of the present invention (Example 70), a method for controlling the distribution of glucose level-related data among applications running on a computer includes: 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, the first data set including values ​​restricted from being accessed by 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.

[0240] Example 71 includes the method of Example 70, wherein the plurality of data values ​​are separated into a first data set and a second data set based on granting permission to the second application.

[0241] Example 72 includes the method of 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.

[0242] Example 73 includes the method of any of Examples 70 to 72, wherein the first data set includes values ​​indicating glucose levels; and the first application displays the values.

[0243] Example 74 includes the method of any of Examples 70 to 72, wherein the second dataset includes an indication of glucose levels, the indication being low, normal, or high; and the second application displays the indication.

[0244] Example 75 includes the method of any of Examples 70 to 72, wherein the data values ​​include actual measurements and estimated error ranges.

[0245] Example 76 includes the method of any of Examples 70 to 72, wherein the first data set and the second data set include a historical trend of glucose levels over a time period; and the first application and the second application display the historical trend.

[0246] In some embodiments of the present invention (Example 77), a computer having security measures for controlling the distribution of glucose level-related data among applications includes: a wireless receiver configured to receive a plurality of glucose level-related data values; and a processor configured to: separate the plurality of data values ​​into a first data set and a second data set, the first data set including values ​​restricted from access to the second data set; provide the first data set to a first application executed on the computer; and provide the second data set to a second application executed on the computer.

[0247] Example 78 includes the computer of Example 77, wherein the plurality of data values ​​are separated into the first data set and the second data set based on permission granted to the second application.

[0248] Example 79 includes the computer of Example 77, wherein the first data set and the second data set are controlled to be displayed differently by the first application and the second application.

[0249] Example 80 includes the computer of Example 77, wherein the first data set includes values ​​indicating glucose levels; and the first application displays the values.

[0250] Example 81 includes a computer of any of Examples 77 to 80, wherein the second data set includes an indication of glucose levels, the indication being low, normal, or high; and the second application displays the indication.

[0251] Example 82 includes a computer from any of Examples 77 to 80, wherein the data values ​​include actual measurements and estimated error ranges.

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

[0253] In some embodiments of the present invention (Example 84), a computer-readable medium includes instructions that, when executed by a processor, perform a method for controlling the distribution of glucose level-related data 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, the first data set including values ​​restricted from being accessed by 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.

[0254] Example 85 includes the computer-readable medium of Example 84, wherein the plurality of data values ​​are separated into the first data set and the second data set based on a license granted to the second application.

[0255] Example 86 includes the computer-readable media of Example 84, wherein the first data set and the second data set are controlled to be displayed differently by the first application and the second application.

[0256] Example 87 includes the computer-readable medium of Example 84, wherein the first data set includes values ​​indicating glucose levels; and the first application displays the values.

[0257] Example 88 contains a computer-readable medium of any of Examples 84 to 87, wherein the second data set includes an indication of glucose levels, the indication including low, normal, or high; and the second application displays the indication.

[0258] Example 89 contains a computer-readable medium of any of Examples 84 to 87, wherein the data values ​​include actual measurements and estimated error ranges.

[0259] Example 90 includes computer-readable media of any of Examples 84 to 87, wherein the first data set and the second data set include historical trends of glucose levels over a time period; and the first application and the second application display the historical trends.

[0260] In some embodiments of the present invention (Example 91), a method for controlling access to glucose level-related data includes: receiving glucose level-related data 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 for decrypting the encrypted data subset to the third application.

[0261] Example 92 includes the method of Example 91, wherein the second application is provided with the key for decrypting the encrypted subset of data.

[0262] In some embodiments of the present invention (Example 93), a system for controlling access to glucose level-related data includes: a wireless receiver configured to receive glucose level-related data; and a processor configured to: display the data using an application; 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 for decrypting the encrypted data subset to the third application.

[0263] Example 94 includes the system of Example 93, wherein the second application is provided with the key for decrypting the encrypted subset of data.

[0264] In some embodiments of the present invention (Example 95), a computer-readable medium includes instructions that, when executed by a processor, perform a method for controlling access to glucose level-related data, the method comprising: receiving the glucose level-related data 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 for decrypting the encrypted data subset to the third application.

[0265] Example 96 includes the computer-readable medium of Example 95, wherein the second application is provided with a key for decrypting the encrypted subset of data.

[0266] In some embodiments of the present invention (Example 97), a method for synchronizing glucose level-related data between two applications running on a computer includes: obtaining a first set of glucose level-related data for a first time period through a first application; executing a second application configured to display glucose level-related information; providing the first set of data to the second application; obtaining a second set of glucose level-related data for a second time period; determining that the second application has not yet received the second set of data; and backfilling the second set of data into the second application.

[0267] Example 98 includes the method of Example 97, which further includes backfilling the second data set into the second application after receiving a request to backfill the data.

[0268] Example 99 includes the method of Example 97, which further includes automatically backfilling the second data set into the second application.

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

[0270] Example 101 includes the method of any of Examples 97 to 99, further comprising: obtaining metabolic health information from the second application, the metabolic health information affecting glucose levels; and simultaneously displaying the first data set with the metabolic health information.

[0271] Example 102 includes the method of any of Examples 97 to 99, further comprising: restricting a portion of the first data set from access by the second application, wherein providing the first data set to the second application includes providing the portion of the first data set.

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

[0273] In some embodiments of the present invention (Example 104), a computer for synchronizing glucose level-related data between two applications includes: a wireless receiver configured to receive a first set of glucose level-related data in a first time period; a memory configured to store the first set of data using a first application; and a processor configured to: execute a second application configured to display glucose level-related information; provide the first set of data to the second application; obtain a second set of glucose level-related data in a second time period; determine that the second application has not yet received the second set of data; and populate the second set of data back into the second application.

[0274] Example 105 includes the computer of Example 104, which further includes a user interface for receiving a request to backfill the data, wherein the processor is further configured to backfill the second data set to the second application after receiving the request to backfill the data.

[0275] Example 106 includes the computer of Example 104, wherein the processor is further configured to automatically backfill the second data set into the second application.

[0276] Example 107 includes a computer of any of Examples 104 to 106, further including a display configured to: display the first data set in real time using the first application; and display the second data set using the second application after a predetermined delay.

[0277] Example 108 includes a computer of any of Examples 104 to 106, wherein the processor is further configured to: obtain metabolic health information from the second application, the metabolic health information affecting glucose levels; and the display is configured to simultaneously display the first data set with the metabolic health information.

[0278] Example 109 includes a computer of any of Examples 104 to 106, wherein the process is further configured to: restrict a portion of the first data set from access by the second application, wherein providing the first data set to the second application includes providing the portion of the first data set.

[0279] Example 110 includes a computer of any of Examples 104 to 106, wherein the processor is further configured to determine that the second data set is older than a threshold amount.

[0280] In some embodiments of the present invention (Example 111), a computer-readable medium includes instructions that, when executed by a processor, perform a method for synchronizing glucose level-related data between two applications running on a computer. The method includes: obtaining a first set of glucose level-related data for a first time period via a first application; executing a second application configured to display glucose level-related information; providing the first set of data to the second application; obtaining a second set of glucose level-related data for a second time period; determining that the second application has not yet received the second set of data; and backfilling the second set of data into the second application.

[0281] Example 112 includes the computer-readable medium of Example 111, further including instructions, when executed by the processor, to backfill the second data set into the second application after receiving a request to backfill the data.

[0282] Example 113 includes the computer-readable medium of Example 111, further including instructions that, when executed by the processor, automatically backfill the second data set into the second application.

[0283] Example 114 includes a computer-readable medium of any of Examples 111 to 113, further including instructions, when executed by the processor, to: display the first data set in real time via the first application; and display the second data set via the second application after a predetermined delay.

[0284] Example 115 includes a computer-readable medium of any of Examples 111 to 113, further including instructions, when executed by the processor, to: obtain metabolic health information from the second application, the metabolic health information affecting glucose levels; and simultaneously display the first data set with the metabolic health information.

[0285] Example 116 includes a computer-readable medium of any of Examples 111 to 113, further including instructions, when executed by the processor, to restrict a portion of the first data set from access by the second application, wherein providing the first data set to the second application includes providing the portion of the first data set.

[0286] Example 117 includes a computer-readable medium of any of Examples 111 to 113, wherein determining that the second application has not yet received the second data set includes determining that the second data set is older than a threshold amount.

[0287] In some embodiments of the present invention (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 includes: receiving continuous glucose measurements from a wireless receiver; determining the compliance level of the medical devices; and providing the continuous glucose measurements to the medical devices based on the determined compliance level, wherein, when the medical devices meet a high compliance level, the continuous glucose measurements are provided to the medical devices in real time, and when the medical devices meet a high compliance level, the continuous glucose measurements are provided to the medical devices after a predetermined delay.

[0288] Example 119 includes the method of Example 118, wherein the medical device satisfying a high compliance level includes a Class 3 medical device.

[0289] Example 120 includes the methods of Example 118 or 119, wherein the medical device includes a software application running on a smartphone.

[0290] In some embodiments of the present invention (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 includes: a wireless receiver configured to receive continuous glucose measurements from the wireless receiver; and a processor configured to: determine the compliance level of the medical devices; and provide the continuous glucose measurements to the medical devices based on the determined compliance level, wherein the continuous glucose measurements are provided to the medical devices in real time when the medical devices meet a high compliance level, and after a predetermined delay when the medical devices meet a high compliance level.

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

[0292] Example 123 includes the system of Example 121 or 122, wherein the medical device includes a software application running on a smartphone.

[0293] In some embodiments of the present invention (Example 124), a computer-readable medium including instructions, which, when executed by a processor, perform a method for determining a safety compliance level for 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 a compliance level for the medical devices; and providing the continuous glucose measurements to the medical devices based on the determined compliance level, wherein, when the medical devices meet a high compliance level, the continuous glucose measurements are provided to the medical devices in real time, and when the medical devices meet a high compliance level, the continuous glucose measurements are provided to the medical devices after a predetermined delay.

[0294] Example 125 includes the computer-readable medium of Example 124, wherein the medical device satisfying a high compliance level includes a Class 3 medical device.

[0295] Example 125 includes the computer-readable media of Example 124 or 125, wherein the medical device includes a software application running on a smartphone.

[0296] In some embodiments of the present invention (Example 127), a method for verifying calibration data for a sensor device includes: receiving data associated with analytical measurements from a second application on a mobile computing device at a first application executed by the mobile computing device, wherein the first application is a dedicated application for a user-worn continuous analysis sensor device communicating with the mobile computing device, and wherein the analytical measurements are collected from the user via a single-measurement medical device; determining the source of the received data by analyzing metadata corresponding to the analytical measurements in the first application; and processing the data as calibration data for the continuous analysis sensor device via the first application.

[0297] Example 128 includes the method of Example 127, wherein the metadata includes one or more of the following: units associated with the analytical measurement, timestamps at which the analytical measurement was acquired, parameters associated with the measurement or analytical technique used to analyze the measurement, or one or more codes associated with the single-use medical device or a consumable component of the single-use medical device.

[0298] Example 129 includes the method of Example 127, which further includes displaying the received data on a display screen of the mobile computing device via the first application after receiving it.

[0299] Example 130 includes the method of Example 129, wherein the displayed data includes a user interface that presents to the user a notification that the data is accepted as calibration data for calibration of the continuous analysis sensor device.

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

[0301] Example 132 includes the method of Example 130, wherein the notification includes a text message, email, or instant message.

[0302] Example 133 includes the method of Example 130, which further includes receiving an affirmative or negative response to accepting the data as calibration data.

[0303] Example 134 includes the method of Example 129 or 130, which further includes displaying a prompt on the display screen of the mobile computing device for the user to manually input the analytical measurement value collected by the single-measurement medical device.

[0304] Example 135 includes the method of Example 134, which further includes: receiving the manually input analytical measurement value; and processing the manually input analytical measurement value as calibration data for the continuous analysis sensor device via the first application.

[0305] Example 136 includes the method of Example 127, which further includes: processing the calibration data via the first application during the calibration process of continuously acquired analytical measurements of the user acquired by the continuously analyzed sensor device, wherein the continuously acquired analytical measurements are provided to the first application on the mobile computing device.

[0306] Example 137 includes the method of Example 127, which further includes: providing the processed data to the continuous analysis sensor device for calibration of continuously acquired analytical measurements by the continuous analysis sensor device.

[0307] Example 138 includes the method of Example 127, wherein the analytical measurement is provided to the second application by the single-measurement medical device via a wireless connection with the mobile computing device.

[0308] Example 139 includes the method of Example 127, wherein analyzing the metadata includes: identifying one or more codes associated with the single-measurement medical device or a consumable component of the single-measurement medical device; and determining that the one or more codes are contained in an authorized device to verify the authenticity of data derived from the authorized device.

[0309] Example 140 includes the method of Example 127, wherein the continuous analysis sensor device collects glucose measurements from the user, and the data associated with the analyzed measurements includes blood glucose levels.

[0310] In some embodiments of the present invention (Example 141), a method for obtaining calibration data for a sensor device includes: receiving data associated with analytical measurements from a second application on a mobile computing device at a first application executed by the mobile computing device, wherein the first application is a dedicated application for a user-worn continuous analysis sensor device communicating with the mobile computing device, and wherein the analytical measurements are collected from the user via a single-use medical device; displaying the received data on a display screen of the mobile computing device via the first application, wherein the displayed data includes a user interface that presents to the user a notification of accepting the data as calibration data for calibration of the continuous analysis sensor device; and receiving a positive or negative response to accepting the data as calibration data, wherein, when the received response is a negative response, the method further includes: displaying a prompt on the display screen of the mobile computing device via the first application for the user to manually input the analytical measurements collected by the single-use medical device, receiving the manually input analytical measurements; and processing the manually input analytical measurements as calibration data for the continuous analysis sensor device via the first application.

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

[0312] Example 143 includes the method of Example 141, wherein the notification includes a text message, email, or instant message.

[0313] Example 144 includes the method of Example 141, further comprising: processing the calibration data via the first application during the calibration process of continuously acquired analytical measurements of the user acquired by the continuously analyzed sensor device, wherein the continuously acquired analytical measurements are provided to the first application on the mobile computing device.

[0314] Example 145 includes the method of Example 141, further comprising: providing the calibration data to the continuous analysis sensor device for calibration of continuously acquired analytical measurements by the continuous analysis sensor device.

[0315] Example 146 includes the method of Example 141, wherein the analytical measurement is provided to the second application by the single-measurement medical device via a wireless connection with the mobile computing device.

[0316] Example 147 includes the method of Example 141, wherein the continuous analysis sensor device collects glucose measurements from the user, and the data associated with the analyzed measurements includes blood glucose levels.

[0317] In some embodiments of the present invention (Example 148), a medical device software application for managing glucose data received from a glucose sensor is disclosed. The medical device software application resides on a computer-readable medium of a mobile computing device and includes instructions, when executed by a processor of the mobile computing device, to cause the mobile computing device to: receive one or more glucose measurements generated by a glucose sensor, wherein the one or more glucose measurements include an associated timestamp; assign the received one or more glucose measurements as traceable glucose data or operable glucose data based on a predetermined time difference between the timestamp and the current time; and provide the traceable glucose data to a third-party software application operable on the mobile computing device.

[0318] Example 149 includes the medical device software application of Example 148, wherein the third-party software application is not an approved medical device software application approved by a government regulatory agency authorized to regulate medical device technology.

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

[0320] Example 151 includes the medical device software application of Example 148, wherein the medical device software application includes instructions, when executed by a processor, to cause the mobile computing device to perform the following operations: generate a data set related to the one or more glucose measurements; partition the data set by generating a first data set and a second data set according to predetermined criteria; restrict access to the first data set by the third-party software application; and provide the second data set to the third-party software application.

[0321] Example 152 includes the medical device software application of Example 148, wherein the medical device software application includes instructions, when executed by a processor, to cause the mobile computing device to: encrypt one or more received glucose measurements or assigned traceable glucose data before providing the traceable glucose data to the third-party software application; issue instructions to the third-party software application to provide the encrypted traceable glucose data to a second third-party software application operable on the mobile computing device; and provide a key for decrypting the encrypted traceable glucose data to the second third-party software application.

[0322] In some embodiments of the present invention (Example 153), a medical device software application for managing glucose data received from a glucose sensor is disclosed. The medical device software application resides on a computer-readable medium of a mobile computing device and includes instructions, when executed by the processor of the mobile computing device, to cause the mobile computing device to: receive one or more glucose measurements generated by the glucose sensor; divide the one or more glucose measurements into a first data set and a second data set according to predetermined criteria, the first data set including data values ​​restricted from access to the second data set; and provide the second data set to a third-party software application operable on the mobile computing device.

[0323] Example 154 includes the medical device software application of Example 153, wherein the third-party software application is not an approved medical device software application approved by a government regulatory agency authorized to regulate medical device technology.

[0324] Example 155 includes the medical device software application of Example 153, wherein the third-party software application is configured to provide at least some capabilities different from those of the medical device software application, including processing ancillary data and integrating the ancillary data with the traced glucose data, wherein the ancillary data includes one or more of insulin data, meal data, or exercise data.

[0325] Example 156 includes the medical device software application of Example 153, wherein the received one or more glucose measurements include an associated timestamp, and wherein the medical device software application includes instructions, when executed by a processor, to cause the mobile computing device to: assign the received one or more glucose measurements as trace glucose data or actionable glucose data based on a predetermined time difference between the timestamp and the current time; and provide the trace glucose data to a third-party software application operable on the mobile computing device.

[0326] Example 157 includes the medical device software application of Example 153, wherein the medical device software application includes instructions, when executed by a processor, to cause the mobile computing device to: encrypt the received one or more glucose measurements or the second data set before providing the second data set to the third-party software application; issue 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 provide a key for decrypting the encrypted traced glucose data to the second third-party software application.

[0327] While this specification contains details of many specific embodiments, these should not be construed as limiting the claims. Certain features described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately in multiple embodiments or in any suitable sub-combination. Furthermore, while features may be described above as functioning in certain combinations and even initially claimed, one or more features from a claimed combination may be excluded from said combination in some cases, and the claimed combination may be for sub-combinations or variations thereof.

[0328] Similarly, although operations are depicted in a specific order in the diagrams, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order, or requiring all illustrated operations to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated into a single software product or packaged into multiple software products.

[0329] It should be understood that the logical operations described herein with respect to the various figures can be implemented as: (1) a sequence of actions implemented by a computer or a program module running on a computing device (i.e., software), (2) interconnected machine logic circuits or circuit modules within a computing device (i.e., hardware), and / or (3) a combination of software and hardware of the computing device. Therefore, the logical operations discussed herein are not limited to any particular combination of hardware and software. The implementation is a matter of choice depending on the performance of the computing device and other requirements. Therefore, the logical operations described herein are referred to in various ways as operations, structural devices, actions, or modules. These operations, structural devices, actions, and modules can be implemented as software, firmware, special-purpose digital logic, and any combination thereof. It should also be understood that more or fewer operations than those shown in the figures and described herein can be performed. These operations can also be performed in a different order than those described herein.

Claims

1. A system for controlling the distribution of glucose level-related data among applications running on a computing device, comprising: Memory, the memory being used to store computer-readable instructions; as well as One or more processors, the one or more processors being configured to execute the computer-readable instructions to: A first application within an application running on the computing device receives multiple data values ​​related to glucose level monitoring, each of which has an associated timestamp. According to predetermined criteria, the plurality of data values ​​are separated into a first data set and a second data set, wherein the first data set includes data values ​​that are restricted from being included in the second data set. The process of providing the second data set to a second application running on the computing device is delayed by a predetermined delay amount; as well as Based on the determination that the duration between the current time and the timestamp associated with the second data set satisfies the predetermined delay amount, the second data set is provided to a second application running on a mobile computing device.

2. The system 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 containing data values ​​related to the glucose level monitoring provided by a continuous glucose monitoring sensor device, and wherein the second application comprises a third-party software application.

3. The system 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, wherein the auxiliary data includes one or more of insulin data, meal data, or exercise data.

4. The system of claim 2, wherein the third-party software application is not an approved medical device software application approved by a government regulatory agency authorized to regulate medical device technology.

5. The system of claim 1, wherein the plurality of data values ​​are separated into the first data set and the second data set based on a predetermined data license associated with the second application.

6. The system of claim 1, wherein the received plurality of data values ​​comprises continuously generated glucose measurements, and wherein separating the plurality of data values ​​further comprises: The continuously generated glucose measurements at predetermined intervals are averaged to produce an average glucose value that will be in the second dataset.

7. The system of claim 1, wherein the received plurality of data values ​​comprises continuously generated glucose measurements, and wherein separating the plurality of data values ​​further comprises: The continuously generated glucose measurements at predetermined intervals will be subject to a generalized indication in the second data set, wherein the generalized indication indicates that the continuously generated glucose measurements are within one of a predefined low range, a predefined normal range, and a predefined high range.

8. The system of claim 1, wherein the delay is between five minutes and three hours.

9. The system according to claim 1, further comprising: The second data set is encrypted before being provided to the second application.

10. The system of claim 1, wherein the first application is configured to process glucose data associated with the continuous glucose sensor device, and the method further comprises: At the first application, one or more single glucose measurement values ​​obtained from the single glucose sensor device are received from a third-party application; The first application analyzes the metadata corresponding to the one or more single glucose measurements. as well as The first application verifies that the one or more single glucose measurements are calibration data for the continuous glucose sensor device.

11. A system for controlling access to glucose level-related data on a mobile computing device, comprising: Memory, the memory being used to store computer-readable instructions; as well as One or more processors, configured to execute the computer-readable instructions to perform the steps, the steps including: Data related to glucose levels is received using a first application that can operate on a smartphone, wherein the received data includes glucose values ​​and an associated timestamp for each glucose value; Encrypt at least a subset of the data; It is determined that there is a request to provide a first subset of glucose values ​​with associated timestamps to a second application with a predetermined delay; and Determine whether the second application is associated with a predetermined delay amount for receiving a first subset of the glucose values; Based on the determination that the second application is associated with a predetermined delay amount, when the duration between the current time and the timestamp of the data meets the predetermined delay amount, an encrypted subset of data is provided to the second application that can operate on the smartphone; The key is provided to the second application to decrypt the encrypted subset of data.

12. The system of claim 11, 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 wherein the second application is a third-party software application.

13. The system of claim 12, 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, wherein the auxiliary data includes one or more of insulin data, meal data, or exercise data.

14. The system of claim 12, wherein the third-party software application is not an approved medical device software application approved by a government regulatory agency authorized to regulate medical device technology.

15. The system of claim 12, wherein the delay is three hours.

16. The system of claim 12, further comprising: Before providing the encrypted data subset to the second application, the data is separated into a first data set consisting of the subset and a second data set of the data according to predetermined criteria, wherein the first data set includes data values ​​that are restricted from being included in the second data set.

17. The system of claim 12, wherein the key for decrypting the encrypted subset of data is provided to the second application.

18. A method for monitoring glucose levels, comprising: Health data, including glucose measurements and associated timestamps, is received via a wireless connection at a first application that can operate on a mobile computing device. The first application determines that the duration between the current time and the timestamp meets a predetermined delay amount. as well as The glucose measurement is provided by the first application to a second application that can operate on the mobile computing device only after the predetermined delay.

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

20. A system for monitoring glucose levels, comprising: A sensor configured to obtain a glucose measurement of the amount of glucose; A wireless transmitter for transmitting the glucose measurement and a timestamp associated with the glucose measurement; as well as Mobile computing device, comprising: A wireless receiver configured to receive the glucose measurement. A memory used to store data containing the received glucose measurements. A processor, which is used to process the data, and A first software application includes instructions stored in the memory that, when executed by the processor, determine when the duration between the current time and the timestamp meets a predetermined delay, and, after determining that the duration meets the predetermined delay, provide the glucose measurement value to a second software application on the mobile computing device. The second software application is operable to receive the glucose measurement value when it is provided by the first software application after the predetermined delay.

21. The system of claim 20, further comprising a second computing device configured to receive the glucose measurement in real time and display the glucose quantity.

22. A method for synchronizing glucose level-related data between two applications running on a mobile computing device, comprising: A first set of data related to glucose levels in a first time period is obtained through a first application; Execute a second application configured to display information related to glucose levels; Provide the first data set to the second application; Obtain a second dataset relating glucose levels for the second time period; It has been determined that the second application has not yet received the second data set; as well as The second data set is then populated back into the second application.

23. The method of claim 22, further comprising: After receiving a request to backfill the data, the second data set is backfilled into the second application.

24. A method for determining safety compliance levels of two or more medical devices and modifying medical data based on said safety compliance levels, comprising: Receive continuous glucose measurements from a wireless receiver; Determine the compliance level of the medical device; as well as The continuous glucose measurement is provided to the medical device based on the determined compliance level, wherein: When the medical device meets a high compliance level, the continuous glucose measurement value is provided to the medical device in real time, and When the medical device meets a high compliance level, the continuous glucose measurement is provided to the medical device after a predetermined delay.

25. The method of claim 24, wherein the medical device satisfying a high compliance level comprises a third type of medical device.

Images