Respiratory therapy configuration based on glucose monitoring and metabolic health

Abstract

Techniques for improved respiratory therapy are provided. Glucose data of a user collected during a sleep session is accessed. Based at least in part on the glucose data, a plurality of transitions between sleep stages experienced by the user during the sleep session is determined. A sleep quality measure for the sleep session is generated based at least in part on the plurality of transitions. An apnea risk score for the user is generated based at least in part on the sleep quality measure, and one or more medical interventions for the user are provided based on the apnea risk score.

Description

RESPIRATORY THERAPY CONFIGURATION BASED ON GLUCOSE MONITORING AND METABOLIC HEALTHCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims benefit to United States provisional patent application Serial No. 63 / 740,675 filed December 31, 2024. The aforementioned related patent applications are herein incorporated by reference in their entirety.TECHNICAL FIELD

[0002] The present disclosure relates generally to respiratory therapy, and more particularly, to use of machine learning and computer modeling to configure and use respiratory therapy devices.

[0003] Many individuals suffer from sleep-related and / or respiratory-related disorders such as, for example, Periodic Limb Movement Disorder (PLMD), Restless Leg Syndrome (RLS), Sleep-Disordered Breathing (SDB) such as Obstructive Sleep Apnea (OSA) and Central Sleep Apnea (CSA), Cheyne-Stokes Respiration (CSR), respiratory insufficiency, Obesity Hyperventilation Syndrome (OHS), Chronic Obstructive Pulmonary Disease (COPD), Neuromuscular Disease (NMD), and chest wall disorders. These disorders are often treated using respiratory therapy systems.

[0004] Each respiratory therapy system generally has a respiratory therapy device connected to a user interface (e.g., a mask) via a conduit and optionally a connector. The user wears the user interface and is supplied a flow of pressurized air from the respiratory therapy device via the conduit. The proper therapy configurations (e.g., airflow rate, pressure, and the like) can be difficult to determine without substantial experimentation and expertise (e.g., by a clinician). Further, the need for respiratory therapy itself is often difficult to determine without monitoring a user sleeping (e.g., by a clinician) in a dedicated medical setting (e.g. a sleep study). Further, even if sleep is monitored by a technician, these technicians cannot thoroughly track or understand the user’s ongoing daily lifestyle habits that can have a significant impact on sleep. As a result, many users who would substantially benefit from therapy itself and / or from different therapy configurations fail to receive optimal results.SUMMARY

[0005] According to some implementations of the present disclosure, a method includes: accessing first glucose data of a first user collected while the first user was awake, wherein the first user is a participant in a respiratory therapy: determining a first metabolic health (MH) state of the first user based at least in part on the first glucose data; generating a first respiratoryRSMD / 0134PC-160899therapy configuration for a subsequent usage session of the first user based on evaluating the first MH state using one or more MH models; and instructing a respiratory therapy flow generator of the first user to implement the first respiratory therapy configuration during a first usage session.

[0006] According to some implementations of the present disclosure, a method includes: accessing first glucose data of a first user collected during a first sleep session; determining, based at least in part on the first glucose data, a plurality of transitions between sleep stages experienced by the first user during the first sleep session; generating a first sleep quality measure for the first sleep session based at least in part on the plurality of transitions; generating a first apnea risk score for the first user based at least in part on the first sleep quality measure; and providing one or more medical interventions for the first user based on the first apnea risk score.

[0007] According to some implementations of the present disclosure, a system includes a control system and a memory. The control system includes one or more processors. The memory has stored thereon machine readable instructions. The control system is coupled to the memory, and any one of the methods disclosed herein is implemented when the machine executable instructions in the memory are executed by at least one of the one or more processors of the control system.

[0008] Other aspects provide processing systems configured to perform the aforementioned method as well as those described herein; non-transitory, computer-readable media comprising instructions that, when executed by one or more processors of a processing system, cause the processing system to perform the aforementioned methods as well as those described herein; a computer program product embodied on a computer-readable storage medium comprising code for performing the aforementioned methods as well as those further described herein; and a processing system comprising means for performing the aforementioned methods as well as those further described herein.

[0009] The above summary is not intended to represent each implementation or every aspect of the present disclosure. Additional features and benefits of the present disclosure are apparent from the detailed description and figures set forth below.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] FIG. 1 depicts an example environment for improved respiratory therapy, according to some embodiments of the present disclosure.

[0011] FIG. 2 depicts an example workflow for generating therapy configurations based on sensor data, according to some embodiments of the present disclosure.RSMD / 0134PC-160899

[0012] FIG. 3 depicts an example workflow for evaluating user’s metabolic health state for respiratory therapy, according to some embodiments of the present disclosure.

[0013] FIG. 4 depicts an example workflow for configuration of respiratory therapy systems based on metabolic health, according to some embodiments of the present disclosure.

[0014] FIG. 5 depicts an example workflow for refining therapy configuration models, according to some embodiments of the present disclosure.

[0015] FIG.6 depicts an example workflow for generating medical interventions based on sensor data, according to some embodiments of the present disclosure.

[0016] FIG. 7 depicts an example workflow for generating sleep quality measures for respiratory therapy, according to some embodiments of the present disclosure.

[0017] FIG. 8 depicts an example workflow for interventions based on sleep quality measures, according to some embodiments of the present disclosure.

[0018] FIG. 9 depicts an example workflow for refining sleep risk models, according to some embodiments of the present disclosure.

[0019] FIG. 10 depicts an example workflow for generating health recommendations and coaching based on metabolic health and / or sleep, according to some embodiments of the present disclosure.

[0020] FIG. 11 is a flow diagram depicting an example method for generating and implementing interventions based on sensor data, according to some embodiments of the present disclosure.

[0021] FIG. 12 is a flow diagram depicting an example method for configuring respiratory therapy systems based on metabolic health, according to some embodiments of the present disclosure.

[0022] FIG. 13 is a flow diagram depicting an example method for refining configuration models, according to some embodiments of the present disclosure.

[0023] FIG. 14 is a flow diagram depicting an example method for providing medical interventions based on apnea risk, according to some embodiments of the present disclosure.

[0024] FIG. 15 is a flow diagram depicting an example method for refining apnea risk models, according to some embodiments of the present disclosure.

[0025] FIG. 16 is a flow diagram depicting an example method for generating coaching outputs based on metabolic health and / or sleep quality measures, according to some embodiments of the present disclosure.

[0026] FIG. 17 is a flow diagram depicting an example method for configuring respiratory therapy systems, according to some embodiments of the present disclosure.RSMD / 0134PC-160899

[0027] FIG. 18 is a flow diagram depicting an example method for evaluating apnea risk, according to some embodiments of the present disclosure.

[0028] FIG. 19 depicts an example computing device configured to perform various aspects of the present disclosure, according to some embodiments disclosed herein.

[0029] While the present disclosure is susceptible to various modifications and alternative forms, specific implementations and embodiments thereof have been shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that it is not intended to limit the present disclosure to the particular forms disclosed, but on the contrary, the present disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims.DETAILED DESCRIPTION

[0030] Embodiments of the present disclosure generally provide techniques for using machine learning to predict therapy device usage.

[0031] Generally, respiratory therapy refers to the use of a flow generator and user interface to deliver air and / or oxygen to a user, such as during sleep. For example, respiratory therapy may include use of continuous positive airway pressure (CPAP) devices, bi-level positive airway pressure (BiPAP) devices, automatic positive airway pressure (APAP) devices, adaptive servo-ventilation (ASV) devices, and the like. Respiratory therapy can significantly improve the lives of users who engage in it. However, many users who would benefit from respiratory therapy did not participate in it. For example, proper recognition of respiratory concerns (such as apnea) often relies on relatively invasive and intensive monitoring by subject matter experts (e.g., participating in a sleep study, where prospective patients spend one or more nights sleeping in a controlled and heavily monitored environment). Such monitoring is computationally intensive (e.g., relying on detailed measurements and evaluations), expensive, and time consuming.

[0032] Further, in order to achieve the full benefits of respiratory therapy, it is important that the therapy configurations are appropriate for the particular user at the particular time. For example, poorly configured pressures, rates, ramps, and the like can significantly reduce the benefits achieved. However, in a similar manner to initial diagnosis of these concerns, proper configuration of the therapy is often achieved using complex sleep studies or other approaches (referred to in some aspects as titration) where subject matter experts tune and tweak the various settings manually. This approach is error-prone, expensive, and difficult.

[0033] Aspects of the present disclosure provide techniques and architectures to predict benefits that can be achieved by engaging in respiratory therapy and / or to predict improvedRSMD / 0134PC-160899therapy configurations. In some embodiments, a wide variety of sensor data may be collected and evaluated to generate such predictions. For example, the sensor data may include data collected via wearables of the user (e.g., glucose monitors, activity or motion sensors, temperature sensors, oxygen sensors, diet sensors, heart rate, blood pressure, and the like). Advantageously, such sensor data may be collected via wearables without relying on affirmative effort or action by any individual (e.g., the user need not sign up for and participate in a study, and a clinician or other expert need not actively collect or monitor the data).

[0034] In some aspects, if the user is already participating in respiratory therapy, the sensor data may further include therapy data, such as the patient’s apnea-hypopnea index (AHI) (e.g., the number of breathing interruptions per hour during the usage session), the rate(s) of air leak (e.g., mouth leak, mask leak, and the like) during the session, the patient’s tidal volume (the volume of air that moves in and / or out of the user’s mouth with each breath), the patient’s minute ventilation (e.g., the volume of air that moves in and / or out of the patient’s lungs per minute), the respiratory rate and / or flow rate of the therapy, and the like.

[0035] In some embodiments of the present disclosure, the various data may be evaluated to determine or estimate the metabolic health (MH) of the user. As used herein, MH is generally indicative of the user’s diet, exercise, sleep, and / or stress levels. Generally, improved MH can result in improved biomarkers and reduced risk of (or improved management of) chronic diseases, as well as improved quality of life (e.g., energy levels, fatigue, fertility, etc.). In some embodiments, various respiratory therapy settings and usage can be optimized (or at least improved), resulting in better comfort and outcomes for an individual, based at least in part on tracking and analyzing an individual’s glucose levels and / or other supplementary MH data (and, in some aspects, combined with data tracked in the therapy itself). This additional data provides a bigger picture view of the user’s metabolic health that can enable improved recommendations or settings for the user’s therapy system on a regular (e.g., daily) basis. In some embodiments, artificial intelligence (Al) and / or machine learning (ML) predictive models can be trained and used (along with rules-based guidelines in some embodiments) to evaluate the user’s MH and / or generate dynamic therapy settings, as discussed in more detail below.

[0036] In some embodiments of the present disclosure, one or more models may be trained and / or used to analyze the various metrics and sensor data (e.g., related to variability in an individual’s glucose data and potentially other data) to infer or determine sleep quality (e.g., sleep fragmentation, OSA, and the like). In some embodiments, this evaluation may be performed for each night of sleep and / or over longer time ranges, potentially enabling accurateRSMD / 0134PC-160899diagnosis and evaluation of respiratory disorders without relying on in-lab sleep studies for all users, as discussed in more detail below. In some aspects, these evaluations may be used as a pre-screening to help determine whether the user is at risk of sleep apnea (and should consider following up with further diagnosis, such as a sleep study) or is not at such risk (and therefore may be excluded from further evaluation or in-lab study).Example Environment for Improved Respiratory Therapy

[0037] FIG. 1 depicts an example environment 100 for improved respiratory therapy (e.g., improved configuration of ongoing therapy and / or improved access to therapy), according to some embodiments of the present disclosure.

[0038] In the illustrated environment 100, a user 105 is associated with a set of sensor(s) 110 and a user device 120. In some aspects, the user 105 may also be associated with a respiratory therapy system 115 (e.g., if the user is already a patient engaged in respiratory therapy). For example, in the illustrated environment 100, the sensors 110 may generally correspond to or include any number and variety of sensor devices, such as wearable devices, ingestible devices, implantable devices, and the like (e.g., smart watches, smart rings, continuous glucose monitors, and the like). The sensors 110 may generally be configured to collect sensor data relating to a wide variety of health-related data for the user 105, such as the user’s temperature, glucose levels, heart rate, blood pressure, oxygen levels, and the like. In the illustrated example, the sensor data collected via the sensors 110 is provided to the user device 120 (e.g., using one or more wired or wireless communication links, such as via Bluetooth, via a wireless local area network (WLAN), and the like). In some embodiments, the sensor data may additionally or alternatively be provided to other systems, such as cloudbased servers.

[0039] In the illustrated example, the user device 120 is generally representative of a computing system used by the user 105 to collect, review, and / or evaluate various data and perform other tasks. For example, the user device 120 may correspond to the user’s smartphone, laptop, desktop computer, tablet, smart watch, and the like. Although a single user device 120 is depicted for conceptual clarity, in some aspects, multiple user devices 120 may be used in the environment 100.

[0040] In the illustrated environment 100, the user device 120 is also communicatively coupled with the respiratory therapy system 115 (if present). The respiratory therapy system 115 is generally representative of a system used to provide and / or manage respiratory therapy. For example, the respiratory therapy system 115 may comprise a flow generator (e.g., a device that uses one or more motors or blowers to generate and drive airflow), a user interface (e.g., aRSMD / 0134PC-160899CPAP mask), conduit to connect the flow generator and the interface in order to deliver airflow to the user 105 via the interface, and the like. In some aspects, the respiratory therapy system 115 may include one or more sensors (which may be reflected as the sensors 110), such as pressure sensors (e.g., detecting the pressure of airflow as the user 105 breathes), pulse sensors, and the like. In some embodiments, the user 105 may use the user device 120 to configure the respiratory therapy system 115, to review data collected by the respiratory therapy system 115 (e.g., to review statistics about the previous night’s sleep), and the like. As discussed above, in cases where the user 105 is not yet a participant in respiratory therapy, the respiratory therapy system 115 may be absent or omitted.

[0041] In the illustrated environment, the user device 120 may transmit the sensor data (e.g., from the sensors 110 and / or the respiratory therapy system 115) to an evaluation system 125 via one or more communication links (which may include wired, wireless, or a combination of wired and wireless links). Although the illustrated example depicts the user device providing the sensor data to the evaluation system 125, in some aspects, some or all of the sensors 110 and / or respiratory therapy system 115 may additionally or alternatively transmit the data directly to the evaluation system 125.

[0042] The evaluation system 125 is generally representative of a computing system configured to evaluate the various sensor data in order to predict, quantify, or otherwise determine various aspects of the state of the user 105, such as the user’s MH state, sleep quality, disorders (e.g., whether the user has apnea, or the probability that the user will develop apnea), and the like. The evaluation system 125 may generally be implemented using hardware, software, or a combination of hardware and software. Although described as a discrete computing system for conceptual clarity, in some aspects, the operations of the evaluation system 125 may be combined or distributed across any number and variety of systems and components. For example, the operations of the evaluation system 125 may be implemented entirely or partially in the same computing environment (e.g., device) as the intervention system 130, the user device 120, the respiratory therapy system 115, and the like.

[0043] In some embodiments, the evaluation system 125 uses various models and / or rules to evaluate the sensor data, as discussed in more detail below. For example, in some embodiments, if the user 105 is already engaged in respiratory therapy, the evaluation system 125 may evaluate the sensor data to determine the MH state of the user at any given time, which can then be used (e.g., by the intervention system 130) to generate modifications to the configuration of the respiratory therapy system 115 (e.g., adjusting the pressure, flow rate, ramp speeds, and the like), as discussed in more detail below.RSMD / 0134PC-160899

[0044] As another example, in some embodiments, if the user 105 is not currently engaged in respiratory therapy, the evaluation system 125 may evaluate the sensor data to determine the sleep quality of the user and / or risk of having (or developing) various disorders, such as apnea, at any given time. These predictions can then be used (e.g., by the intervention system 130) to generate or suggest various medical interventions, as discussed in more detail below.

[0045] In some embodiments, the evaluation system 125 can use rules-based evaluations, machine learning-based evaluations, or a combination of rules-based and machine learningbased evaluations to generate the various predictions, as discussed in more detail below. For example, in some aspects, some of the input sensor data may be first preprocessed or classified using various rules-based approaches, and the resulting features may be processed using machine learning to generate output predictions. As another example in some embodiments, the sensor data may be processed using machine learning models to generate output predictions, and these predictions may be processed using rules-based models to generate final determinations.

[0046] In the illustrated example, the evaluation system 125 can provide the various predictions or determinations to an intervention system 130. In some embodiments, the evaluation system 125 and intervention system 130 may collectively be referred to as a healthcare system. The intervention system 130 is generally representative of a computing system configured to select, generate, facilitate, implement, or otherwise determine various actions (e.g., interventions) to be taken based on the output of the evaluation system (e.g., based on the user’s MH state, sleep quality, disorders, and the like). The intervention system 130 may generally be implemented using hardware, software, or a combination of hardware and software. Although described as a discrete computing system for conceptual clarity, in some aspects, the operations of the intervention system 130 may be combined or distributed across any number and variety of systems and components. For example, the operations of the intervention system 130 may be implemented entirely or partially in the same computing environment (e.g., device) as the evaluation system 125, the user device 120, the respiratory therapy system 115, and the like.

[0047] For example, in some embodiments, if the user 105 is already engaged in respiratory therapy, the intervention system 130 may evaluate the predicted information (e.g., the MH state of the user at any given time) to generate modifications to the configuration of the respiratory therapy system 115 (e.g., adjusting the pressure, flow rate, ramp speeds, and the like), as discussed in more detail below.

[0048] As another example, in some embodiments, if the user 105 is not currently engagedRSMD / 0134PC-160899in respiratory therapy, the intervention system 130 may evaluate the predictions related to sleep quality of the user and / or risk of having (or developing) various disorders, such as apnea, at any given time. Based on the predictions, the intervention system 130 may generate or suggest various medical interventions, as discussed in more detail below.

[0049] In some embodiments, the intervention system 130 can use rules-based evaluations, machine learning-based evaluations, or a combination of rules-based and machine learningbased evaluations to generate the various predictions, as discussed in more detail below. For example, in some aspects, the predictions or determinations provided by the evaluation system 125 may be preprocessed or classified using various rules-based approaches, and the resulting features may be processed using machine learning to generate output interventions or configurations (e.g., therapy configurations). As another example in some embodiments, the predictions may be processed using machine learning models to generate output interventions or suggestions, and these outputs may be processed using rules-based models to generate final interventions.

[0050] In the illustrated environment 100, the interventions or actions generated by the intervention system 130 can be provided to the respirator}' therapy system 115 (e.g., to control the configuration of the therapy system) and / or to the user device 120 (e.g., to provide suggestions relating to sleep quality, apnea risk, and the like). In some aspects, the intervention system 130 may additionally or alternatively provide the output to various other systems, such as to a computing system used by clinicians (e.g., the doctor of the user 105).

[0051] Advantageously, by using machine learning in some embodiments to evaluate the sensor data and / or generate interventions or configurations, some embodiments of the present disclosure are able to significantly improve medical outcomes with reduced manual effort and computational expense, as compared to many conventional approaches.

[0052] For example, using sensor data (such as glucose levels) to augment and / or confirm sleep quality evaluations can enable accurate identification of concerns such as sleep apnea without relying on the time and resource usage involved in a conventional lab-based sleep study in some embodiments. This may allow at least some users to be diagnosed with reduced resource usage and expense, allowing such facilities to focus their (limited) resources on harder-to-diagnose or treat individuals. In some embodiments, as discussed above, using these sensor-augmented evaluations can enable more effective pre-screening of users for such studies, which may preserve limited resources and ensure that users who are most at risk are able to participate, while users who are least at risk may not need to participate at all.

[0053] As another example, using sensor data (such as glucose levels) to augment otherRSMD / 0134PC-160899sensor information can enable more useful and improved therapy configuration generation, allowing the respiratory therapy to be dynamically reconfigured over relatively short and / or long timeframes without manual intervention. This can improve the efficacy of the therapy itself.Example Workflow for Generating Therapy Configurations based on Sensor Data

[0054] FIG. 2 depicts an example workflow 200 for generating therapy configurations based on sensor data, according to some embodiments of the present disclosure. In some embodiments some or all of the workflow 200 is performed within the environment 100 of FIG. 1

[0055] In the illustrated example, sensor data 205 is collected by sensors 110 and provided to an evaluation system 125. In the depicted workflow 200, the evaluation system 125 includes a metabolic health component 210. The metabolic heath component 210 may be implemented using hardware, software, or a combination of hardware and software. As illustrated, the metabolic health component 210 generates or determines the metabolic health state 215 of the user based on the sensor data 205. In some aspects, the metabolic health component 210 evaluates data collected while the user is awake (e.g., glucose levels throughout the day) and / or asleep (e.g., glucose levels overnight) to predict the user’s metabolic health state 215 at one or more points in time (e.g., for one or more moments in the day and / or as a trend across time).

[0056] For example, evaluations of the variability of the user’s glucose levels throughout the day, overnight, and / or across multiple days can be highly indicative of the overall metabolic health of the user. Further, as illustrated, this metabolic health state 215 can be used by an intervention system 130 to generate therapy configurations 225. In some embodiments, the metabolic health component 210 may use machine learning to generate the metabolic heath state 215. For example, the metabolic health component 210 may process some or all of the sensor data 205 (e.g., the glucose data, motion or activity data, information about food the user has consumed, and the like) as input to one or more machine learning models to predict the user’s metabolic health state. In some embodiments, the metabolic health component 210 may use guidelines or rules-based approaches to generate the metabolic heath state 215. For example, the metabolic health component 210 may quantify the user’s metabolic heath based on the stability and / or variation of the glucose levels over time.

[0057] In the illustrated example, the intervention system 130 includes a configuration component 220. The configuration component 220 may be implemented using hardware, software, or a combination of hardware and software. As illustrated, the configuration component 220 generates a therapy configuration 225 based on the metabolic health state 215.RSMD / 0134PC-160899In some aspects, the configuration component 220 may generate the therapy configuration 225 based at least in part on real-time (or near-real-time) metabolic health states 215 of the user. That is, in some embodiments, the configuration component 220 generates a therapy configuration 225 for immediate implementation based on the current (or most recently available) metabolic health state 215 of the user. This may allow the respiratory therapy system 115 to respond in real-time (or near real-time) to the user’s state.

[0058] In some embodiments, the configuration component 220 may generate the therapy configuration 225 based on previous or historical metabolic heath states 215 of the user. That is, in some embodiments, the configuration component 220 may generate the therapy configuration 225 for use during one window in time (e.g., during the next overnight sleep session) based on the user’s metabolic health state 215 during a prior window of time (e.g., during the prior day). This may allow the respiratory therapy system 115 to respond to broader trends in the user’s state.

[0059] In the illustrated example, the therapy configuration 225 is provided to the respiratory therapy system 115 of the user. In some aspects, the respiratory therapy system 115 automatically implements the therapy configuration 225. For example, during the next usage session (e.g., when the user dons the mask and activates the respiratory therapy system 115 for that night’s sleep session), the respiratory therapy system 115 may determine to implement the therapy configuration 225 that was previously provided by the intervention system 130 (or may request an updated therapy configuration 225 for the usage session, where the updated configuration is generated based on the user’s metabolic health state 215 for the day). In some embodiments, rather than automatically implementing the configuration changes, the respiratory therapy system 115 (or another system, such as the user device 120 of FIG. 1) may request approval from the user prior to implementing the modifications.

[0060] As discussed above, this dynamic control of the respiratory therapy system 115 can significantly improve the outcomes and results achieved by the user, which may help to improve the user’s sleep quality and quantity (and, in turn, to improve the user’s future metabolic health states 215). Although not depicted in the illustrated example, in some embodiments, the respiratory therapy system 115 and / or other systems (e.g., the sensors 110) may be provide feedback (e.g., indicating how the user reacted to the updated configuration) to the evaluation system 125 and / or intervention system 130, allowing the evaluation system 125 and / or intervention system 130 to refine the machine learning model(s) and / or guidelines in order to generate improved configurations in the future.

[0061] Generally, the particular configuration changes and reasoning may vary dependingRSMD / 0134PC-160899on the particular implementation. As one example, suppose the user had a relatively late meal (e.g., close to the beginning of the night’s sleep / therapy usage) and begins initiating sleep. Due to the late meal (e.g., due to the effect of the meal on the user’s glucose levels shortly before the usage session begins), the user may experience restless sleep onset. In some embodiments, therefore, the metabolic health state 215 may indicate the late meal, causing the configuration component 220 to generate a therapy configuration 225 to address or mitigate the restless sleep onset. For example, the therapy configuration 225 may cause the respiratory therapy system 115 to automatically extend the CPAP ramp up time (the time during which the respiratory therapy system 115 slowly increases the air pressure and / or flow to the target therapeutic level(s)), such as extending the ramp up time from a normal period (e.g., over a thirty minute window) to a longer period (e.g., an hour and a half window) due to the metabolic health state 215 of the user. This can help mitigate the current state, improving the user’s experience and outcomes.

[0062] As another example, the metabolic health state 215 of the user may be generated based on (or may reflect) various metrics related to glucose, such as the variability in fasting glucose levels throughout the day. In some embodiments, this glucose variability can be used to impact next session’s therapy settings. For example, fasting glucose trending high (e.g., above a target threshold), may be an indication of greater likelihood of inflammation in the airway, which might cause the configuration component 220 to generate a therapy configuration 225 having higher target pressure (as compared to a normal target for the user) for the next usage session.

[0063] As an example of a more short term (e.g., real-time) configuration, the intervention system 130 may use aspects of the metabolic health state of the user such as the current glucose levels and body temperature of the user to detect wake events during a usage session (e.g., detecting that the user has woken up during the therapy session), and may respond by generating a therapy configuration with reduced air pressure (at least for as long as the user is awake).

[0064] As another example, if the metabolic health state 215 of the user indicates that the user has consumed alcohol prior to the sleep session (e.g., through glucose levels, or from user-recorded diet logs entered in an app), the configuration component 220 may generate a therapy configuration 225 with increased maximum pressure setting, or may have an APAP pressure decay time constant adjusted (e.g., increasing the time taken to reduce the therapy pressure), in response.

[0065] As yet another example, if the metabolic health state 215 generally indicates goodRSMD / 0134PC-160899MH for the user (e.g., good MH habits that day) and / or is consistently positive and stable in a recent period (e.g., good MH for the last week), the configuration component 220 may relax various attributes of the therapy configuration 225, such as by reducing the therapy pressure, throughout the usage session or at certain moments during sleep.

[0066] As still another example, during the titration process (sometimes used to confirm the proper therapy settings for a new user of a respiratory therapy system 115), metabolic health state 215 information such as the glucose levels of the user can be incorporated in the titration process to confirm the optimal and normal settings for the user. For example, if glucose is high (e.g., indicating potential diabetes) and the data shows significant sleep fragmentation, a BiPAP device or configuration may be more appropriate than continuous pressure.

[0067] In some embodiments, in addition to or instead of dynamic therapy configurations 225, the intervention system 130 may take other actions to mitigate the concerns, such as transmitting a suggestion to the user to wait a period of time after eating to digest before initiating sleep and CPAP therapy, as discussed in more detail below.Example Workflow for Evaluating User’s Metabolic Health State for Respiratory Therapy

[0068] FIG. 3 depicts an example workflow 300 for evaluating user’s metabolic health state for respiratory therapy, according to some embodiments of the present disclosure. In some embodiments some or all of the workflow 300 is performed within the environment 100 of FIG. 1. In some embodiments, the workflow 300 gives additional detail for the sensor inputs of the workflow 200 of FIG. 2.

[0069] In the workflow 300, a set of discrete sensors (e.g., the sensors 110 of FIGS. 1-2) are used to provide sensor data 205 to the metabolic health component 210 in order to generate the metabolic health state 215 of the user. Although six discrete sensors are depicted for conceptual clarity, the workflow 300 may generally use more (or fewer) sensors than the depicted example, and may collect various other sensor data depending on the particular implementation. For example, in some embodiments, additional sensors such as melatonin sensors, cortisol sensors, ketone sensors, and the like may be used. Further, in some embodiments, some or all of the sensors may be implemented as one (or a few) components (e.g., wearable devices, skin patches, and the like).

[0070] In the illustrated example, the sensors include a glucose sensor 305, an activity sensor 310, a temperature sensor 315, an oxygen sensor 320, a diet sensor 325, and therapy sensor(s) 330.

[0071] The glucose sensor 305 is generally representative of any sensor capable of collecting real-time and / or near real-time (e.g., continuous or near-continuous) measurementsRSMD / 0134PC-160899of the amount or levels of glucose in the user’ s bloodstream. For example, the glucose sensor 305 may include one or more wearable, ingestible, and / or implantable continuous glucose monitors (CGMs) that report glucose information relatively frequently (e.g., every five minutes).

[0072] The activity sensor 310 is generally representative of any sensor(s) configured to detect or quantify activity or motion of the user. For example, the activity sensor 310 may include one or more accelerometers, gyroscopes, orientation detectors, and the like used to indicate the motion of the user. In some aspects, the activity sensor 310 may generate (or the data collected by the activity sensor 310 may be processed to generate) more detailed information about activities performed by the user. For example, in addition to detecting movement, the movement may be analyzed to identify what activity is being performed (e.g., riding a bike, jogging, and the like). In this way, data generated using the activity sensor 310 may include information relating to what physical activities (e.g., exercises) the user engaged in and when.

[0073] The temperature sensor 315 is generally representative of a thermometer capable of recording the internal and / or external temperature of the user. The temperature sensor 315 may generally be used to collect absolute temperature readings that reflect the actual temperature of the user (e.g., whether they have a fever) and / or relative temperature readings that reflect how the temperature of the user has changed over time (e.g., whether they are warmer now than they were five minutes ago).

[0074] The oxygen sensor 320 is generally representative of any sensor capable of collecting real-time and / or near real-time information about the oxygen saturation of the user (e.g., the percentage of oxygen being carried by red blood cells in the blood of the user). As discussed above, the oxygen sensor 320 may be implemented as a wearable, ingestible, implantable, or other such sensor.

[0075] The diet sensor 325 is generally representative of any sensor or source of information relating to the diet of the user, such as what they eat and / or drink during the day, when they eat and / or drink, and the like. For example, the diet sensor 325 may automatically generate diet information (e.g., indicating when and what the user eats) based on data such as images of the user’s meals, and / or may retrieve diet information from other sources (e.g., from a manual food diary kept by the user).

[0076] The therapy sensor(s) 330 is generally representative of any sensor(s) integrated with respiratory therapy systems (e.g., the respiratory therapy system 115 of FIGS. 1-2) to collect information about the usage session. For example, the therapy sensor(s) 330 may recordRSMD / 0134PC-160899information such as the pressures, flow rates, mask leak, and the like.

[0077] Generally, the depicted sensors (and others not illustrated) may be used to collect the sensor data 205 used to determine the metabolic health state 215 of the user (at discrete points in time and / or as trends over a window of time), as discussed above.Example Workflow for Configuration of Respiratory Therapy Systems based on Metabolic Health

[0078] FIG. 4 depicts an example workflow 400 for configuration of respiratory therapy systems based on metabolic health, according to some embodiments of the present disclosure. In some embodiments some or all of the workflow 400 is performed within the environment 100 of FIG. 1. In some embodiments, the workflow 400 gives additional detail for the therapy configuration 225 of FIG. 2.

[0079] In the illustrated workflow 400, the metabolic health state 215 of a user is processed by a configuration component 220 (e.g., using machine learning) to generate therapy configurations including one or more pressure settings 405, ramp settings 410, and / or curve settings 415. As discussed above, the metabolic health state 215 of the user may generally indicate the overall metabolic health of the user at one or more points in time (or during one or more windows in time). For example, the metabolic health state 215 may include one or more aggregate measures indicating the overall state of the user, and / or may include submeasures or scores, such as a “sleep measure,” a “diet measure,” a “physical activity measure,” and the like.

[0080] In some aspects, the configuration component 220 may use one or more machine learning models trained for each aspect or setting available to be adjusted for the respiratory therapy. For example, in some aspects, the configuration component 220 may use a first model trained to predict optimal pressure settings 405 (e.g., a maximum pressure, a minimum pressure, an average pressure, and the like), a second model trained to predict ramp settings 410 (e.g., the ramp up time at the start of therapy and / or ramp down duration at the end of therapy), a third model trained to predict curve settings 415 (e.g., how rapidly the pressure should be increased and / or decreased in sync with the users breathing), and the like.

[0081] Although three discrete settings are illustrated for conceptual clarity, in some embodiments, the configuration component 220 may generally generate therapy configurations with any number and variety of settings. In some embodiments, in addition to the metabolic health state 215 of the user (which, as discussed above, may include the state at a given time or set of times, and / or across one or more windows), the configuration component 220 may use other information such as the current or default therapy configuration as input to the model(s). This may allow a trained machine learning model to indicate whether (and if so, how much)RSMD / 0134PC-160899each setting should be modified. For example, based on the current configuration and user' s metabolic health state 215 for the day, the configuration component 220 may predict whether the pressure should be increased or decreased (or left unchanged), whether the ramp should be extended or reduced (or left unchanged), and the like.

[0082] In some embodiments, the configuration component 220 uses user-agnostic model(s) and / or rules to generate the various therapy configurations. That is, the configuration component 220 may generate therapy settings for any number and variety of users using the same model(s). In some embodiments, the configuration component 220 may use personalized models for some or all of the settings. For example, after implementing a given configuration, the configuration component 220 (or another system) may monitor the user’s ongoing progress (e.g., their sleep quality from the session with the new configuration and / or their metabolic health the next day(s)). This feedback may be used to further refine and / or personalize the models, as discussed in more detail below.Example Workflow for Refining Therapy Configuration Models

[0083] FIG.5 depicts an example workflow 500 for refining therapy configuration models, according to some embodiments of the present disclosure. In some embodiments some or all of the workflow 500 is performed within the environment 100 of FIG. 1.

[0084] In the illustrated example, as discussed above, a configuration component 220 of an intervention system 130 may generate therapy configurations 225 for respiratory therapy systems 115 (e.g., based on the metabolic health of the user). For example, as discussed above with reference to FIG. 3, the metabolic health may be determined based on data from sensors such as glucose monitors, sleep trackers, activity monitors, and the like. As discussed above with reference to FIG. 4, the therapy configuration 225 may generally include modifications to any number and variety of therapy settings, such as pressures, ramp rates, flow rates, and the like. As discussed above, the therapy configurations 225 may be short-term (e.g., adjusting the settings within a given usage session based on the real-time metabolic health state of the user) and / or long-term (e.g., adjusting the settings for a given usage session based on the metabolic health state of the user from one or more prior days).

[0085] As illustrated, the respiratory therapy system 115 implements the therapy configuration 225 (e.g., controlling or adjusting the pressure appropriately) during one or more usage sessions of the user. In the illustrated workflow 500, the respiratory therapy system 115 may also provide feedback 505 to an update component 510 of the intervention system 130. Although the illustrated example depicts the respiratory therapy system 115 itself providing feedback 505, in some aspects, feedback may additionally or alternatively be provided by oneRSMD / 0134PC-160899or more other systems.

[0086] The feedback 505 may generally include any information indicating how the user responded (explicitly or implicitly) to the therapy configuration 225. For example, the feedback 505 provided by the respiratory therapy system 115 may include information about the sleep session itself and / or one or more subsequent sessions (e.g., the patient’s AHI during the session, number of wakes, restlessness events, and the like). As another example, feedback provided by sensors (such as the sensors 110 of FIGS. 1-2) may provide data such as updated glucose readings during the session and / or the next day, oxygen levels, and the like.

[0087] In some embodiments, the feedback 505 can include user-provided feedback, such as an explicit indication of whether the user liked the settings, whether the user slept well, and the like. In some embodiments, some or all of the feedback 505 may be automatically generated during the ordinary runtime operations of the systems. For example, when sensor data is collected during the next day to generate an updated configuration for the next evening, the intervention system 130 may also use this updated sensor data as implicit feedback for the prior session’s configuration.

[0088] In the illustrated example, the update component 510 may use the feedback 505 to update, refine, train, or otherwise modify one or more model(s) and / or rule(s) used, by the configuration component 220, to generate therapy configurations 225. For example, the update component 510 may use the prior metabolic health information (used to generate the prior therapy configuration 225) as input to the model to generate an output, and may use the feedback 505 as positive or negative reinforcement (e.g., indicating that the resulting output configuration was positive, negative, or had no affect). If the feedback 505 was positive (indicating that the modifications helped), the update component 510 may refine the model(s) such that they are more likely to generate the same (or similar) configurations given the same (or similar) inputs. Conversely, if the feedback 505 was negative (indicating that the modifications harmed the user), the update component 510 may refine the model(s) such that they are less likely to generate the same (or similar) configurations given the same (or similar) inputs.

[0089] In some embodiments, in addition to ensuring continuous learning of the model(s), this further allows the update component 510 to personalize the model(s) to the particular user. This can significantly improve the user results, as the operations of the respiratory therapy system 115 for the user may be modified and tailored using models trained specifically for the given user.RSMD / 0134PC-160899Example Workflow for Generating Medical Interventions based on Sensor Data

[0090] FIG. 6 depicts an example workflow 600 for generating medical interventions based on sensor data, according to some embodiments of the present disclosure. In some embodiments some or all of the workflow 600 is performed within the environment 100 of FIG. 1

[0091] In the illustrated example, sensor data 605 is collected by the set of sensors 110 and provided to the evaluation system 125. In the depicted workflow 600, the evaluation system 125 includes a sleep component 610. The sleep component 610 may be implemented using hardware, software, or a combination of hardware and software. As illustrated, the sleep component 610 generates or determines a sleep quality measure 615 of the user based on the sensor data 605. In some aspects, the sleep component 610 evaluates data collected while the user is asleep (e.g., glucose levels throughout the night) to predict or generate the user’s sleep quality measure 615 at one or more points in time (e.g., for the evening’s sleep session).

[0092] Further, as illustrated, this sleep quality measure 615 can be used by an intervention system 130 to generate medical intervention(s) 625. In some embodiments, the sleep component 610 may use machine learning to generate the sleep quality measure 615. For example, the sleep component 610 may process some or all of the sensor data 605 (e.g., the glucose data, motion or activity data, temperature data, and the like) as input to one or more machine learning models to predict the user’s sleep state and / or restlessness during sleep. In some embodiments, the sleep component 610 may use guidelines or rules-based approaches to generate the sleep quality measure 615. For example, the sleep component 610 may quantify the user’s sleep quality measure 615 based on the duration of sleep in the session, the number of wakes, and the like.

[0093] In some embodiments, the sleep component 610 may process the sensor data 605 using machine learning model(s) to predict sleep and / or wake states or transitions for the user (e.g., predicting whether they were awake, asleep, and / or what phase of sleep they were in when the data was collected). For example, based on the sensor data 605, the sleep component 610 may use machine learning to predict that the user transitioned from awake to light sleep at one time, from light sleep to deep sleep at another, from deep sleep to rapid eye movement (REM) sleep at another, and so on. In some embodiments, the sleep component 610 may then process these determined transitions and / or states (e.g., using rules-based models) to generate the sleep quality measure 615 (e.g., based on factors such as the sleep latency, wakefulness after sleep onset, the number or frequency of transitions or arousals during the sleep session, and the like). The sleep quality measure 615 may generally be a single measure or value (e.g.,RSMD / 0134PC-160899an aggregate score) and / or may include a set of relevant values (e.g., indicating the average or representative value for each of a set of sleep features, such as average sleep latency).

[0094] In the illustrated example, the intervention system 130 includes a risk component 620. The risk component 620 may be implemented using hardware, software, or a combination of hardware and software. As illustrated, the risk component 620 generates the medical interventions 625 based on the sleep quality measure 615. In some aspects, the risk component 620 may generate the medical interventions 625 based at least in part on multiple sleep quality measures 615 generated over multiple nights or sleep sessions (e.g., based on trends over time).

[0095] In some embodiments, the risk component 620 can evaluate the sleep quality measure(s) 615 for a user to determine the risk or probability that the user has sleep apnea (e.g., OSA) or some other sleep-related disorder or concern (e.g., an “apnea risk score”). For example, the risk component 620 may compare the sleep quality measure(s) 615 against one or more thresholds (or other rules-based models) to determine whether the user is likely suffering from apnea or some other disorder. In some embodiments, the risk component 620 may evaluate the sleep quality measure(s) 615 using one or more machine learning models to generate the apnea risk score (or other risk score). The medical interventions 625 may be generated or selected based on the determined risk(s).

[0096] In the illustrated example, the medical interventions 625 are provided to the user device 120 of the user. In some aspects, the user device 120 automatically implements or facilitates the medical interventions 625. For example, for interventions involving coaching or providing of literature, the user device 120 may simply output this information to the user. In some embodiments, rather than automatically implementing the interventions, the user device 120 (or another system, such as the user device of a doctor or physician) may request approval from the user prior to implementing the interventions. For example, the user device 120 ay indicate the risk of sleep apnea, and prompt the user to schedule an appointment with their healthcare provider to investigate and / or discuss options.

[0097] As discussed above, this dynamic generation and use of medical interventions 625 can significantly improve the outcomes and results achieved by the user, which may help to improve the user’s sleep quality and quantity (and, in turn, to improve the user’s future metabolic health). For example, by identifying sleep problems in the user’s own home (rather than during a sleep study), the system can improve the probability that users will receive the help they need with reduced expense and time. Generally, the particular medical interventions and reasoning may vary depending on the particular implementation.RSMD / 0134PC-160899Example Workflow for Generating Sleep Quality Measures for Respiratory Therapy

[0098] FIG. 7 depicts an example workflow 700 for generating sleep quality measures for respiratory therapy, according to some embodiments of the present disclosure. In some embodiments some or all of the workflow 700 is performed within the environment 100 of FIG. 1. In some embodiments, the workflow 700 gives additional detail for the sensor inputs of the workflow 600 of FIG. 6.

[0099] In the workflow 700, a set of discrete sensors (e.g., the sensors 110 of FIGS. 1-2) are used to provide sensor data 205 to a state component 735 an a quality component 745 (which may themselves be software and / or hardware components of the sleep component 610 of FIG.6) in order to generate the sleep quality measure 615 of the user. Although six discrete sensors are depicted for conceptual clarity, the workflow 700 may generally use more (or fewer) sensors than the depicted example, and may collect various other sensor data depending on the particular implementation. For example, in some embodiments, additional sensors such as melatonin sensors, cortisol sensors, ketone sensors, and the like may be used. Further, in some embodiments, some or all of the sensors may be implemented as one (or a few) components (e.g., wearable devices, skin patches, and the like).

[0100] In the illustrated example, the sensors include a glucose sensor 705 (which may correspond to the glucose sensor 305 of FIG. 3), a motion sensor 710 (which may correspond to the activity sensor 310 of FIG. 3), a temperature sensor 715 (which may correspond to the temperature sensor 315 of FIG.3), an oxygen sensor 720 (which may correspond to the oxygen sensor 320 of FIG. 3), a pulse sensor 725, and blood pressure sensor(s) 730.

[0101] The glucose sensor 705 is generally representative of any sensor capable of collecting real-time and / or near real-time (e.g., continuous or near-continuous) measurements of the amount or levels of glucose in the user’s bloodstream. For example, the glucose sensor 705 may include one or more wearable, ingestible, and / or implantable continuous glucose monitors (CGMs) that report glucose information relatively frequently (e.g., every five minutes).

[0102] The motion sensor 710 is generally representative of any sensor(s) configured to detect or quantify activity or motion of the user. For example, the motion sensor 710 may include one or more accelerometers, gyroscopes, orientation detectors, and the like used to indicate the motion of the user.

[0103] The temperature sensor 715 is generally representative of a thermometer capable of recording the internal and / or external temperature of the user. The temperature sensor 715 may generally be used to collect absolute temperature readings that reflect the actual temperature ofRSMD / 0134PC-160899the user (e.g., whether they have a fever) and / or relative temperature readings that reflect how the temperature of the user has changed over time (e.g., whether they are warmer now than they were five minutes ago).

[0104] The oxygen sensor 720 is generally representative of any sensor capable of collecting real-time and / or near real-time information about the oxygen saturation of the user (e.g., the percentage of oxygen being carried by red blood cells in the blood of the user). As discussed above, the oxygen sensor 720 may be implemented as a wearable, ingestible, implantable, or other such sensor.

[0105] The pulse sensor 725 is generally representative of any sensor capable of collecting heart rate or pulse information for the user (e.g., via a wearable smart watch or ring). The blood pressure sensor 730 is similarly representative of any sensor(s) used to detect or measure the blood pressure of the user. Although not included in the illustrated example, in some embodiments, the sensors may also include respiratory therapy sensors (e.g., if the user is already engaged in respiratory therapy) /

[0106] Generally, the depicted sensors (and others not illustrated) may be used to collect the sensor data 205 used to determine the sleep quality measure 615 of the user (at discrete points in time and / or as trends over a window of time), as discussed in more detail below.

[0107] In the illustrated example, the sensor data 205 is accessed by a state component 735. The state component 735 may evaluate the sensor data 205 to generate or identify a set of sleep stages or transitions 740, where each transition 740 indicates the user moving from a first sleep stage to a second sleep stage (e.g., from awake to light sleep, from deep sleep to REM, and the like), as well as the time (e.g., timestamp) of the transition. That is, the transitions 740 may be generated based on sensor data 205 such as glucose levels, pulse, temperature, motion, etc. which may be correlated with sleep stage may be evaluated (e.g., using trained machine learning models) to predict what stage the user is in at any given time (based on data collected at the time) and / or to predict what stage the user is transferring from and / or to during any transition. In this way, the state component 735 (or another component) can estimate or determine the durations of each stage of sleep.

[0108] As illustrated, the transitions 740 are accessed by a quality component 745, which generates the sleep quality measure 615. Further, in the illustrated example, the quality component 745 may evaluate some or all of the sensor data 205 itself to generate the sleep quality measure 615. In some embodiments, the quality component 745 uses one or more machine learning models to generate the sleep quality measure 615 based on the input transitions 740 and / or sensor data 205. In some embodiments, the quality component 745 usesRSMD / 0134PC-160899one or more rules-based models (e.g., thresholds) to generate the sleep quality measure 615.

[0109] For example, based on the transitions 740, the quality component 745 may detect markers or indicia of sleep quality related to sleep fragmentation (e.g., frequent arousals or state transitions). For example, frequent arousal (e.g., transitioning to an awake state frequently during the sleep session) may indicate poor sleep quality. Similarly, prolonged sleep latency (e.g., the delay from when the user lay down to begin a sleep session to when the user actually transitions from awake to asleep), high levels of wakefulness after sleep onset (e.g., the total number of minutes for which the user was awake after the initial transition to sleep and before the user ended the sleep session in the morning), a high number of state transitions, and the like may all indicate relatively poor quality sleep.

[0110] In some embodiments, as discussed above, the quality component 745 may further evaluate sensor data 205 itself. In some embodiments, in addition to data collected while the user slept, the quality component 745 may evaluate sensor data 205 collected while the user is awake. For example, glucose variability and changes throughout the day may be correlated with frequent arousal while sleeping, and glucose data may indicate the sleep latency of the user (e.g., reflecting difficulties with long sleep onset).

[0111] As another example, some glucose metrics may be correlated with low mean oxygen saturation, high oxygen desaturation index, and / or high AHI, each of which may be linked to apnea risk. Further, information such as the user’s glucose variability throughout the day, the average glucose value at various points in the day (and how the values change over time), the mean or average difference between the user’s glucose levels at the same time but on different days, and the like may be evaluated to generate the sleep quality measure 615.

[0112] In some embodiments, the quality component 745 may similarly evaluate the glucose data to determine information such as the user’s high blood glucose index (HBGI) and / or low blood glucose index (LBGI) (e.g., measures of the number, frequency, and / or extent of such high and low glucose levels) may be used by the quality component 745 to generate the sleep quality measure 615.Example Workflow for Interventions based on Sleep Quality Measures

[0113] FIG. 8 depicts an example workflow 800 for interventions based on sleep quality measures, according to some embodiments of the present disclosure. In some embodiments some or all of the workflow 800 is performed within the environment 100 of FIG. 1. In some embodiments, the workflow 800 gives additional detail for the medical interventions 625 of FIG. 6

[0114] In the illustrated workflow 800, the sleep quality measure 615 of a user is processedRSMD / 0134PC-160899by a risk component 620 (e.g., using machine learning) to generate medical interventions including one or diagnosis recommendations 805, therapy recommendations 810, and / or sleep recommendations 815. As discussed above, the sleep quality measure 615 of the user may generally indicate the overall quality of sleep of the user at one or more points in time (or during one or more windows in time). For example, the sleep quality measure 615 may include one or more aggregate scores indicating the overall quality of the sleep (e.g., across multiple nights), and / or may include subscores or measures, such as a “sleep latency,” a “wakefulness after sleep score,” a “number of arousals,” and the like.

[0115] In some aspects, the risk component 620 may use one or more machine learning models trained for each risk or intervention available. For example, in some aspects, the risk component 620 may use a first model trained to predict diagnosis recommendations 805 (e.g., an apnea risk score indicating the probability that the user has sleep apnea), a second model trained to predict therapy recommendations 810 (e.g., whether the user should consider enrolling in respiratory therapy), a third model trained to predict sleep recommendations 815 (e.g., suggestions relating to how and when to sleep), and the like.

[0116] Although three discrete recommendations are illustrated for conceptual clarity, in some embodiments, the risk component 620 may generally generate any number of risk scores associated with any number and variety of recommendations or interventions. In some embodiments, as discussed above, some or all of the interventions may be implemented automatically. For example, the user may be automatically enrolled in a sleep study and / or an appointment may be scheduled to investigate potential sleep issues. In some embodiments, some or all of the interventions may be implemented as suggestions or recommendations (e.g., indicating, to the user, the magnitude of the risk and suggesting next steps, such as prompting the user to follow a link to schedule an appointment).

[0117] In some embodiments, the risk component 620 and / or the sleep component 610 of FIG. 6 use user-agnostic model(s) and / or rules to generate the sleep quality measure(s) and / or interventions(s). In some embodiments, the sleep component 610 and / or the risk component 620 may use personalized models for some or all of the predictions, as discussed in more detail below.Example Workflow for Refining Sleep Risk Models

[0118] FIG. 9 depicts an example workflow 900 for refining sleep risk models, according to some embodiments of the present disclosure. In some embodiments some or all of the workflow 900 is performed within the environment 100 of FIG. 1.

[0119] In the illustrated example, as discussed above, a risk component 620 of anRSMD / 0134PC-160899intervention system 130 may generate medical interventions 625 for users (e.g., based on sleep quality measures of the user). For example, as discussed above with reference to FIG. 7, the sleep quality measures may be determined based on data from sensors such as glucose monitors, sleep trackers, activity monitors, and the like. As discussed above with reference to FIG. 8, the medical interventions 625 may generally include recommendations or suggestions with respect to any action or diagnosis relating to the identified concerns.

[0120] As illustrated, the user device 120 implements the medical interventions 625 (e.g., outputting the interventions for a user to review). In the illustrated workflow 900, the user device 120 may also provide feedback 905 to an update component 910 of the intervention system 130. Although the illustrated example depicts the user device 120 itself providing feedback 905, in some aspects, feedback may additionally or alternatively be provided by one or more other systems.

[0121] The feedback 905 may generally include any information indicating how the user responded (explicitly or implicitly) to the medical interventions 625, how accurate or useful the interventions were, and / or how accurate the sleep predictions were. For example, the feedback 905 and / or feedback provided by other devices or sensors (such as the sensors 110 of FIGS. 1-2) may provide data about the sleep session itself, such as to correct a misclassified sleep transition. For example, if the medical interventions 625 note that the user slept until a given time in the morning, but feedback 905 may correct this to note that the user actually arose for the morning at an earlier time.

[0122] In some embodiments, the feedback 905 can include user-provided feedback, such as an explicit indication of whether the predicted sleep timeline is accurate, whether the user subjectively slept well, and the like. In some embodiments, some or all of the feedback 905 may be provided by others, such as from a clinician indicating that the user does not actually have sleep apnea.

[0123] In the illustrated example, the update component 910 may use the feedback 905 to update, refine, train, or otherwise modify one or more model(s) and / or rule(s) used by the risk component 620 and / or the sleep component 610. For example, the update component 910 may use the prior sleep (used to generate the prior medical interventions 625) as input to the model to generate an output, and may use the feedback 905 as positive or negative reinforcement (e.g., indicating that the resulting output suggestions were accurate or inaccurate). If the feedback 905 was positive (indicating that the suggestions helped), the update component 910 may refine the model(s) such that they are more likely to generate the same (or similar) interventions given the same (or similar) inputs. Conversely, if the feedback 905 was negative (indicating that theRSMD / 0134PC-160899interventions are inaccurate or inappropriate for the user), the update component 910 may refine the model(s) such that they are less likely to generate the same (or similar) interventions given the same (or similar) inputs.

[0124] As another example, if the sleep component 610 predicts a particular sleep timeline (e.g., laying down at a given time, actually falling asleep at a given time, waking up at one or more times, and ending the sleep session at a given time), the feedback 905 may confirm or correct any aspect of the timeline (e.g., any of the predicted transitions). Based on the particular feedback 905, the update component 910 may update, refine, train, or otherwise modify one or more model(s) and / or mle(s) used by the sleep component 610. For example, the update component 910 may use the prior sensor data (used to generate or determine the sleep transitions) as input to the model to generate an output, and may use the feedback 905 as positive or negative reinforcement (e.g., indicating that the resulting predicted transitions were accurate or inaccurate). If the feedback 905 was positive (indicating that the transition was accurate, such as that the user did in fact awaken at the indicated time), the update component 910 may refine the model(s) such that they are more likely to generate the same (or similar) transition (e.g., from light sleep to awake) given the same (or similar) inputs. Conversely, if the feedback 905 was negative (indicating that the user does not believe they awoke at the indicated time), the update component 910 may refine the model(s) such that they are less likely to generate the same (or similar) predictions given the same (or similar) inputs.

[0125] In some embodiments, in addition to ensuring continuous learning of the model(s), this further allows the update component 910 to personalize the model(s) to the particular user. This can significantly improve the user results, as the sleep predictions and risk evaluations for the user may be modified and tailored using models trained specifically for the given user.Example Workflow for Generating Health Recommendations and Coaching based on Metabolic Health and / or Sleep

[0126] FIG. 10 depicts an example workflow 1000 for generating health recommendations and coaching based on metabolic health and / or sleep, according to some embodiments of the present disclosure. In some embodiments some or all of the workflow 1000 is performed within the environment 100 of FIG. 1.

[0127] In the illustrated example, the intervention system 130 can access metabolic health states 215 and sleep quality measures 615 across one or more periods or windows of time. For example, the intervention system 130 may access the metabolic health states 215 and / or sleep quality measures 615 as they are generated (e.g., daily) to enable long-term evaluation of trends in the data. In the illustrated example, the intervention system 130 includes a scoringRSMD / 0134PC-160899component 1005, a trends component 1010, and a coaching component 1015. Each of the depicted components may be implemented using hardware, software, or a combination of hardware and software.

[0128] In some embodiments, the scoring component 1005, trends component 1010, and coaching component 1015 may be used to provide interactive feedback and suggestions based On the metabolic health state(s) 215 and sleep quality measures 615. For example, in some embodiments, the scoring component 1005 can aggregate the metabolic health states 215 and / or sleep quality measures 615 over time to generate overall scores for the user, such as dietary scores indicating the user’ s average diet quality over time, activity scores indicating the user’s average physical activity, aggregated sleep measures indicating the user’s aggregate sleep characteristics, and the like. For example, the scoring component 1005 may generate output such as the average sleep duration per night, the average number of arousals per night, the average duration of physical activity per day, and the like.

[0129] In some embodiments, the trends component 1010 may similarly be used to generate and / or evaluate trends in the metabolic health states 215 and / or sleep quality measures 615 over time. For example, the trends component 1010 may generate visualizations showing how the scores have changed over time. In some embodiments, the trends component 1010 may similarly forecast or predict how the scores will continue to evolve based on the existing trends.

[0130] In some embodiments, the coaching component 1015 may use one or more machine learning models to enable interactive feedback and discussions regarding the scores and / or trends. For example, in some embodiments, the coaching component 1015 may use one or more language models (e.g., large language models (LLMs)) to generate natural language output based on natural language inputs. As one example, the coaching component 1015 may provide a chat window allowing users to request information or guidance regarding the various scores or trends (e.g., asking if there is a recommended average value for any of the scores, asking how the user’ s scores or trends compare to the average or recommended scores or trends, asking about how to improve any scores or trends, and the like). In some embodiments, the coaching component 1015 may optionally use techniques such as retrieval augmented generation (RAG) to retrieve and provide relevant proprietary and / or public data and content that may help the user.

[0131] In the illustrated example, the outputs of each of the depicted components may be collectively referred to as health recommendations 1020. The health recommendations 1020 can generally include any insight or information that may be helpful to the user, such as contextRSMD / 0134PC-160899related to the scores and trends, articles provided by the coaching component 1015, and the like, as discussed above.Example Method for Generating and Implementing Interventions based on Sensor Data

[0132] FIG. 11 is a flow diagram depicting an example method 1100 for generating and implementing interventions based on sensor data, according to some embodiments of the present disclosure. In some embodiments, the method 1100 may be performed by a healthcare system, such as the evaluation system 125 and / or intervention system 130 of FIG. 1.

[0133] At block 1105, the healthcare system accesses sensor data (e.g., the sensor data 205 of FIGS. 2 and / or 6) including glucose data (e.g., glucose levels collected via a continuous glucose monitor of the user). As used herein, “accessing” data may generally include receiving, requesting, retrieving, collecting, measuring, obtaining, or otherwise gaining access to the data. For example, the healthcare system may access the data directly from the sensor(s), or may receive the data from one or more intermediary devices. As discussed above, the sensor data may generally include data from a wide variety of sensor devices, such as oxygen data, glucose levels, heart rate and pressure, and the like.

[0134] At block 1110, the healthcare system evaluates the sensor data using one or more models and / or rules to quantify the health of the user. For example, as discussed above with reference to FIG. 2 and / or below with reference to FIG. 12, the healthcare system may determine or infer the metabolic health state (e.g., the metabolic health state 215 of FIGS. 2-3) of the user based on the sensor data. As another example, as discussed above with reference to FIG. 6 and / or below with reference to FIG. 14, the healthcare system may determine or predict the sleep quality (e.g., the sleep quality measure 615 of FIGS. 6-7) of the user based on the sensor data.

[0135] At block 1115, the healthcare system generates one or more interventions for the user based on the quantified user health. For example, as discussed above with reference to FIG. 2 and / or below with reference to FIG. 12, the healthcare system may generate respiratory therapy configurations (e.g., the therapy configuration 225 of FIG.2) of the user based on the sensor data. As another example, as discussed above with reference to FIG. 6 and / or below with reference to FIG. 14, the healthcare system may generate medical interventions (e.g., the medical interventions 625 of FIG.6) of the user based on the sensor data.

[0136] At block 1120, the healthcare system implements the generated interventions. For example, in some embodiments, the healthcare system may automatically implement one or more of the interventions, such as by configuring a respiratory therapy system of the user based on the generated intervention. In some embodiments, the healthcare system may facilitateRSMD / 0134PC-160899implementation of the interv ention by outputting a prompt or recommendation to the user, such as warning them of the risk of sleep apnea and beginning the process of scheduling an in-person assessment.

[0137] At block 1125, the healthcare system determines whether there is any feedback (e.g., the feedback 505 of FIG. 5 and / or the feedback 905 of FIG. 9) available with respect to the quantified user health (determined at block 1110) or the generated interventions (generated at block 1115). For example, as discussed above, the healthcare system may determine whether the user or another individual provided explicit input correcting or approving the health and / or intervention predictions, whether the interventions were actually implemented, whether the user responded positively to the interventions (e.g., the metabolic health improved), and the like.

[0138] If, at block 1125, the healthcare system determines that no feedback is available, the method 1100 returns to block 1105. If feedback is available, the method 1100 continues to block 1130, where the healthcare system refines or updates the model(s) and / or threshold(s) used to generate the quantified user health information and / or interventions, as discussed above and in more detail below. The method 1100 then returns to block 1105.Example Method for Configuring Respiratory Therapy Systems based on Metabolic Health

[0139] FIG. 12 is a flow diagram depicting an example method 1200 for configuring respiratory therapy systems based on metabolic health, according to some embodiments of the present disclosure. In some embodiments, the method 1200 may be performed by a healthcare system, such as the evaluation system 125 and / or intervention system 130 of FIG. 1. In some embodiments, the method 1200 provides additional detail for the workflow 200 of FIG. 2 and / or the method 1100 of FIG. 11.

[0140] At block 1205, the healthcare system accesses glucose data (e.g., via a glucose monitor, such as the glucose sensor 305 of FIG.3 and / or the glucose sensor 705 of FIG.7) for a user. In some embodiments, as discussed above, the glucose data accessed at block 1205 was collected while the user is awake (e.g., not during a sleep session or respiratory therapy session). In some embodiments, as discussed above, the glucose data is collected at one or more points through the day (e.g., every five minutes). In some embodiments, the glucose data may comprise individual glucose readings and / or aggregate information such as the glucose changes or variations throughout the day. In some aspects, the glucose data may be collected both while the use is awake (e.g., for long-term configuration planning) and while the user is asleep (e.g., for short-term or immediately modifications).

[0141] At block 1210, the healthcare system accesses respiratory therapy data for the userRSMD / 0134PC-160899(e.g., via the therapy sensors 330 of FIG. 3). For example, as discussed above, the respiratory therapy data may include information collected during one or more respiratory therapy usage sessions, such as AHI, mask leak, and the like. In some aspects, the respiratory therapy data may correspond to the immediately prior therapy usage session. For example, if the glucose data is collected on a given day, the respiratory therapy data may be collected for the prior night. That is, if the respiratory therapy data corresponds to a given usage session, the glucose data may correspond to the user’s glucose levels during the window beginning with the end of the usage session.

[0142] At block 1215, the healthcare system optionally accesses additional sensor data (e.g., via the temperature sensor 315, activity sensor 310, and the like, each of FIG. 3), if available, to improve the metabolic health evaluations. For example, as discussed above, the healthcare system may access data such as oxygen saturation (e.g., via the oxygen sensor 320 of FIG. 3), temperature (e.g., via the temperature sensor 315 of FIG. 3), activity (e.g., via the diet sensor 325 of FIG. 3), and the like.

[0143] At block 1220, the healthcare system determines the metabolic health state of the user (e.g., the metabolic health state 215 of FIGS.2-4) based on the collected sensor data. For example, as discussed above, the healthcare system may process some or all of the sensor data using one or more trained models and / or using one or more defined rules or thresholds to quantify the metabolic health of the user as of the time(s) when the sensor data was collected. In some aspects, as discussed above, the metabolic health state comprises a single score or measure indicating the overall health of the user. In some embodiments, the metabolic health state indicates one or more scores or measures for each of one or more features or subscores, such as a sleep score, a glucose stability score, and the like.

[0144] At block 1225, the healthcare system generates a respiratory therapy configuration (e.g., the therapy configuration 225 of FIG. 2 and / or the pressure settings 405, ramp settings 410 and / or curve settings 415, each of FIG. 4) based on the metabolic health state. For example, as discussed above, the healthcare system may process the metabolic health information using one or more machine learning models and / or rules-based models to predict or select a configuration. In some embodiments, the healthcare system may also provide the current or default configuration as input to generate modifications to the current configuration (e.g., increases in pressure).

[0145] At block 1230, the healthcare system implements the generated respiratory therapy configuration (e.g., using the respiratory therapy system 115 of FIGS. 1-2 and / or 5). In some embodiments, as discussed above, this includes suggesting or recommending theRSMD / 0134PC-160899modification(s) to the user (or a clinician) for approval. In some embodiments, this includes automatically implementing the configuration without requesting approval. In some embodiments, as discussed above, implementing the configuration includes using the generated configuration during the subsequent or next therapy usage session (e.g., the next time the user begins therapy). In some embodiments, implementing the configuration includes immediately activating the configuration (e.g., if a usage session is already active).

[0146] The method 1200 then returns to block 1205 to begin anew (e.g., during the same usage session, or to collect data for the subsequent usage session, such as the next night). As discussed above, this dynamic generation and implementation of therapy configurations can significantly improve user outcomes with reduced effort and expense.Example Method for Refining Configuration Models

[0147] FIG. 13 is a flow diagram depicting an example method 1300 for refining configuration models, according to some embodiments of the present disclosure. In some embodiments, the method 1300 may be performed by a healthcare system, such as the evaluation system 125 and / or intervention system 130 of FIG. 1. In some embodiments, the method 1300 provides additional detail for workflow 500 of FIG.5 and / or the method 1200 of FIG. 12

[0148] At block 1305, the healthcare system implements a respiratory therapy configuration (e.g., the therapy configuration 225 of FIG. 5) for a user. For example, as discussed above, the healthcare system may transmit the respiratory therapy configuration to one or more respiratory therapy systems (e.g., a flow generator such as the respiratory therapy system 115 of FIG. 5), instructing the therapy system to operate (during the current usage session or during the next usage session) in accordance with the configuration. In some embodiments, as discussed above, the healthcare system may transmit the configuration to other systems (e.g., user devices), and / or may request user approval prior to actually implementing the therapy.

[0149] At block 1310, the healthcare system collects updated respiratory therapy data (e.g., from the usage session when the therapy configuration was used). For example, as discussed above, the healthcare system may collect information such as the user’s AHI per hour, minute ventilation, amount of leak, and the like. In some embodiments, this respiratory data can be used to determine whether the updated configuration affected the respiratory therapy itself (e.g., increased or decreased apnea events, mask leak, and the like).

[0150] At block 1315, the healthcare system collects updated sensor data from one or more sensors of the user, where the updated sensor data was collected during and / or after the usageRSMD / 0134PC-160899session when the updated configuration was used. For example, as discussed above, if the updated therapy configuration was used during a given usage session (e.g., a first night), the updated sensor data may correspond to data (e.g., oxygen saturation, temperature, activity, diet, and the like) collected subsequent to the given usage session (e.g., on the next day) and before the next usage session. In some embodiments, this sensor data can be used to determine whether the updated configuration affected the metabolic health of the user after the usage session.

[0151] At block 1 20, the healthcare system collects updated glucose data for user, where the updated glucose data was also collected during and / or after the usage session when the updated configuration was used. For example, as discussed above, if the updated therapy configuration was used during a given usage session (e.g., a first night), the new glucose data may be collected subsequent to the given usage session (e.g., on the next day) and before the next usage session. In some embodiments, this updated glucose data can similarly be used to determine whether the updated configuration affected the metabolic health of the user after the usage session. In some aspects, as discussed above, each of these portions of updated data (collected at block 1310, 1315, and 1320) may be referred to as feedback (e.g., the feedback 505 of FIG. 5).

[0152] At block 1325, the healthcare system updates one or more configuration models (e.g., machine learning models trained to generate respiratory therapy configurations) based on the updated respiratory therapy data, updated sensor data, and / or updated glucose data. For example, as discussed above, the healthcare system may determine an updated metabolic health state of the user (e.g., for the day after the usage session) and may compare this updated state to the user’s metabolic health state from the day prior to the usage session (e.g., the data that was used to generate the updated configuration). This may allow the healthcare system to determine or infer whether the updated configuration improved the user’s overall metabolic health (e.g., a positive exemplar), reduced the user’s metabolic health (e.g., a negative exemplar), or had no effect.

[0153] Generally, the healthcare system may use a variety of techniques to update the configuration model(s) depending on the particular architecture and implementation. For example, in some embodiments, if the updated data reflects improved metabolic health, the healthcare system may update the model parameters such that the model is more likely to generate a similar configuration when similar input data is used. Conversely, if the updated data reflects worsened metabolic health, the healthcare system may update the model parameters such that the model is less likely to generate a similar configuration when similarRSMD / 0134PC-160899input data is used (e.g., forcing the model to attempt a different therapy configuration).

[0154] In some aspects, as discussed above, updating the model(s) at block 1325 includes updating a personalized model for the particular user. That is, the healthcare system may train the model to generate improved configurations based on the metabolic health and responses of the particular user, allowing the model to specialize for the user’s own personal experience. In some aspects, in addition to or instead of updating a personalized model, the healthcare system may use the updated data as one of many exemplars to update a global or shared model (e.g., weekly). This shared model may then be used by multiple users (and, in some cases, the shared model may then be personalized to individual users, such as using the method 1300).

[0155] At block 1330, the healthcare system deploys the updated configuration model(s) for use in generating respiratory therapy configurations for one or more users. For example, as discussed above, the healthcare system may use the updated model to process updated sensor data (e.g., the data collected at blocks 1310, 1315, and 1320) in order to generate another updated respiratory therapy configuration. This updated configuration may then be used (e.g., during the subsequent usage session) in order to continuously improve the user’s metabolic health and respiratory therapy experience. The method 1300 then returns to block 1305, to implement the newly generated configuration(s) (e.g., generated using the new model(s)).Example Method for Providing Medical Interventions based on Apnea Risk

[0156] FIG. 14 is a flow diagram depicting an example method 1400 for providing medical interventions based on apnea risk, according to some embodiments of the present disclosure. In some embodiments, the method 1400 may be performed by a healthcare system, such as the evaluation system 125 and / or intervention system 130 of FIG. 1. In some embodiments, the method 1400 provides additional detail for the workflow 600 of FIG.6 and / or the method 1100 of FIG. 11.

[0157] At block 1405, the healthcare system accesses glucose data (e.g., via a glucose monitor, such as the glucose sensor 705 of FIG. 7) for a user. In some embodiments, as discussed above, the glucose data accessed at block 1405 was collected while the user is asleep (e.g., during a sleep session, such as overnight). In some embodiments, as discussed above, the glucose data is collected at one or more points through the sleep (e.g., every five minutes). In some embodiments, the glucose data may comprise individual glucose readings and / or aggregate information such as the glucose changes or variations throughout the sleep session. In some aspects, the glucose data may be collected both while the use is awake and while the user is asleep.

[0158] At block 1410, the healthcare system optionally accesses additional sensor data, ifRSMD / 0134PC-160899available, to improve the apnea risk evaluations. For example, as discussed above, the healthcare system may access data such as oxygen saturation (e.g., via the oxygen sensor 720 of FIG. 7), temperature (e.g., via the temperature sensor 715 of FIG. 7), activity or motion data (e.g., via the motion sensor 710 of FIG. 7), and the like during the sleep session. In some aspects, if the user is already engaged in respiratory therapy, the healthcare system may collect respiratory therapy data too. However, as the method 1400 may be used to determine whether respiratory therapy would be useful for the user, such data may be unavailable.

[0159] At block 1415, the healthcare system determines or identifies a set of sleep transitions (e.g., the transitions 740 of FIG. 7) based on the glucose data and / or additional sensor data. As discussed above, each transition may generally correspond to a point in time when the user transitioned from a first sleep state (which may include stages such as awake, light sleep, deep sleep, REM sleep, and the like) to a second sleep state. In some embodiments, as discussed above, each of these stages may have a corresponding effect on the sensor data (e.g., the glucose levels, motion, and temperature of the user may change depending on the particular sleep state). In some embodiments, to identify the transitions, the healthcare system may process the sensor data collected at various points using one or more machine learning models trained to predict what stage the user was currently in when the data was collected. The healthcare system may then identify the transitions as corresponding to points in time when adjacent predictions indicate different sleep states.

[0160] In some embodiments, to identify the transitions, the healthcare system may process some or all of the sensor data as a time sequence, allowing the machine learning model to (attempt to) pinpoint the particular times in the sequence when the user moved from one state to another.

[0161] At block 1420, the healthcare system generates a sleep quality measure (e.g., the sleep quality measure 615 of FIGS. 6-8) for the user (or for the particular sleep session) based on the sleep transitions. For example, in some embodiments, the healthcare system may use one or more rules-based or threshold-based approaches to quantify the quality of the user’s sleep based on information such as the number of arousals indicated in the determined transitions (e.g., the number of times the user transitioned to an awake phase during the session, where higher numbers of arousals indicate poorer sleep quality), the total wakefulness after sleep onset (e.g., the duration of time that the user was awake after initially falling asleep and prior to ending the sleep session, where higher durations correlate to poorer sleep), the number and / or frequency of transitions between stages (e.g., where more frequent or numerous transitions may indicate poorer sleep quality), the sleep latency (e.g., the length of the firstRSMD / 0134PC-160899awake stage, from the start of the session until the user actually first entered sleep), and the like.

[0162] Although the illustrated method 1400 depicts analysis of sleep transitions to determine the sleep quality measure(s), as discussed above, other features may additionally or alternatively used to define the sleep quality measure(s). For example, as discussed above with reference to FIG. 7, the sensor data itself (from glucose sensors and / or other sensors) may be used directly to evaluate the user’s sleep and / or to asses apnea risk.

[0163] In some embodiments, as discussed above, the sleep quality measure(s) may include one or more aggregate scores (e.g., a value indicating the aggregate sleep quality) and / or one or more subscores (e.g., indicating scores for various metrics of sleep, such as a transition frequency score, a wakefulness after sleep onset score, and the like).

[0164] At block 1425, the healthcare system generates an apnea risk score based on the sleep quality measure(s). In some aspects, as discussed above, the apnea risk score may generally indicate the risk or probability that the user has (or will develop) sleep apnea. In some embodiments, the risk score may more generally indicate the risk or probability of any sleep or respiratory disorder. In some embodiments, the risk score indicates the probability that the user would benefit from respiratory therapy (e.g., CPAP, BiPAP, and the like).

[0165] In some embodiments, the healthcare system generates the apnea risk score using one or more threshold-based and / or rules-based models (e.g., generating a score using a formula or algorithm based on the sleep quality measure(s)). In some embodiments, the healthcare system generates the apnea risk score by processing the sleep quality measure(s) using one or more trained machine learning models (e.g., models trained to identify and quantify correlations between various values of sleep quality measures with corresponding probability of apnea).

[0166] At block 1430, the healthcare system can then select and provide various interventions (e.g., the medical interventions 625 of FIG. 6 and / or the diagnosis recommendations 8095, therapy recommendations 810, and / or sleep recommendations 815, each of FIG. 8) based on the apnea risk score. For example, as discussed above, if the apnea risk score exceeds a threshold, the healthcare system may determine to transmit a suggestion or recommendation to the user to seek further assistance (e.g., schedule a sleep study, begin respiratory therapy, and the like).

[0167] The method 1400 then returns to block 1405 to begin anew (e.g., collecting data during a subsequent sleep session). As discussed above, this process of automatic and continuous sleep evaluation can significantly improve user outcomes with reduced effort andRSMD / 0134PC-160899expense.Example Method for Refining Apnea Risk Models

[0168] FIG. 15 is a flow diagram depicting an example method 1500 for refining apnea risk models, according to some embodiments of the present disclosure. In some embodiments, the method 1500 may be performed by a healthcare system, such as the evaluation system 125 and / or intervention system 130 of FIG. 1. In some embodiments, the method 1500 provides additional detail for the workflow 900 of FIG. 9 and / or the method 1400 of FIG. 14.

[0169] At block 1505, the healthcare system predicts (e.g., infers the occurrence of) one or more sleep transitions (e.g., the transitions 740 of FIG. 7) for a user based on various sensor data. For example, as discussed above, the healthcare system may evaluate sensor data collected while a user sleeps, such as glucose measurements, temperature, motion, and the like. The healthcare system may then predict or identify sleep transitions, as discussed above. For example, the healthcare system may process the sensor data as a sequence of discrete records (e.g., where each record includes data collected at a given time or within a given window) to predict, for each record (e.g., for each timestamp or window), what sleep stage the user was in. As another example, the healthcare system may process the data as a time series (e.g., where the entire sequence of data is used as input) to predict or identify timestamps in the time series that correspond to sleep transitions. In some embodiments, as discussed above, predicting each transition may generally include predicting the user’s sleep state prior to and subsequent to the transition, as well as the time of the transition.

[0170] At block 1510, the healthcare system determines the actual sleep transitions of the user during the sleep session. That is, the healthcare system may use various techniques and equipment to determine the actual sleep state of the user at each point. For example, during the sleep session, in addition to collecting the various glucose and other sensor data (which is used as input to the transition-identifying machine learning models), the healthcare system may collect measurements of the user’s brain activity (e.g., using an electroencephalogram (EEG)). These indications of brain activity can be highly accurate in identifying sleep stages. However, EEG measurements are generally only possible in a clinical setting (e.g., a sleep study) due to the expense and complexity of the equipment used. Further, EEG equipment is fairly invasive and can be significantly uncomfortable during sleep, as compared to activity and glucose monitors. Additionally, collecting EEG data generally involves collecting a vast volume of data, requiring substantial computational resources (e.g., memory, storage, and processing power) to collect and evaluate. In contrast, glucose data, temperature data, and the other sensor information collected to predict the transitions at block 1505 use substantially fewer resourcesRSMD / 0134PC-160899(e.g., less memory, less storage, and less processing power). Therefore, in some embodiments, this more computationally expensive and difficult to procure EEG (or other brain activity) data can be collected to assist in training models to predict sleep transitions with far less computational expense.

[0171] At block 1515, the healthcare system updates the sleep model(s) used to predict the sleep transitions based on the actual transition data (determined at block 1510). The particular techniques used to update the sleep model(s) may vary depending on the particular architecture and implementation. For example, in some embodiments, the healthcare system may use the determined sleep transitions (determined at block 1510) as ground truth values for the predicted transitions. In some embodiments, for each transition predicted by the model(s), the healthcare system may determine whether a sleep transition was actually recorded (e.g., in the EEG data). If so, the healthcare system may update the model to encourage or reinforce such predictions. If not, the healthcare system may update the model to discourage such predictions. Similarly, in some embodiments, for each transition reflected in the EEG data, the healthcare system may determine whether the model predicted such a transition, and may update the model accordingly. As another example, in some embodiments, at one or more points in time, the healthcare system may determine whether the sleep stage predicted by the model aligns with the actual sleep stage reflected in the EEG data, and may refine the model parameters accordingly.

[0172] Advantageously, as discussed above, this training process allows the machine learning model(s) to learn to use computationally inexpensive data (e.g., glucose readings) to predict sleep stages and / or transitions. This allows for accurate sleep quality quantification without relying on computationally (and procedurally) expensive equipment such as EEGs. In this way, the healthcare system can enable improved functionality and applicability of sleep analysis systems (e.g., resulting in more accurate and reliable predictions with reduced expense).

[0173] At block 1520, the healthcare system predicts the apnea risk of the user based on the sleep data. For example, as discussed above, the healthcare system may generate one or more sleep quality measures based on the transition predictions, and may then predict the user’ s apnea risk based on the sleep quality measures and / or based directly on the transition information. In some embodiments, as discussed above, the healthcare system may process the sleep quality measure(s) using one or more trained models to predict the user’ s apnea risk (e.g., probability of developing apnea).

[0174] At block 1525, the healthcare system determines the actual apnea state of the user.RSMD / 0134PC-160899For example, if the user has undergone formal diagnosis or engaged in a sleep study, the healthcare system may determine whether the user was actually diagnosed with having (or being at risk of developing) apnea (or any other respiratory or sleep disorder, as discussed above).

[0175] At block 1530, the healthcare system updates one or more apnea risk prediction models based on the apnea state. The particular techniques used to update the apnea model(s) may vary depending on the particular architecture and implementation. For example, in some embodiments, the healthcare system may use the determined apnea state or risk (determined at block 1525) as ground truth for the predicted risk. Advantageously, as discussed above, this training process allows the machine learning model(s) to learn to predict the risk of apnea (or other disorders) with reduced manual effort and reduced computational expense, as compared to existing approaches. This allows for accurate sleep risk quantification without relying on computationally (and procedurally) expensive equipment or extensive subject matter expertise. In this way, the healthcare system can enable improved functionality and applicability of sleep analysis systems (e.g., resulting in more accurate and reliable predictions with reduced expense).

[0176] In some aspects, as discussed above, updating the model(s) at blocks 1515 and 1530 includes updating a personalized model for the particular user. That is, the healthcare system may train the models to generate improved transition predictions and / or risk scores based on the data of the particular user, allowing the model to specialize for the user’s own personal experience. In some aspects, in addition to or instead of updating a personalized model, the healthcare system may use the updated data as one of many exemplars to update global or shared models (e.g., weekly). These shared models may then be used by multiple users (and, in some cases, the shared models may then be personalized to individual users, such as using the method 1500).

[0177] The method 1500 then returns to block 1505, to continue training or refining the models using newly collected data.Example Method for Generating Coaching Outputs based on Metabolic Health and / or Sleep Quality Measures

[0178] FIG. 16 is a flow diagram depicting an example method 1600 for generating coaching outputs based on metabolic health and / or sleep quality measures, according to some embodiments of the present disclosure. In some embodiments, the method 1600 may be performed by a healthcare system, such as the evaluation system 125 and / or intervention system 130 of FIG. 1. In some embodiments, the method 1600 provides additional detail forRSMD / 0134PC-160899the workflow 1000 of FIG. 10.

[0179] At block 1605. the healthcare system generates one or more health scores (e.g., metabolic health states 215 of FIG. 10) and / or sleep quality measures (e.g., the sleep quality measures 615 of FIG. 10) for the user. For example, as discussed above, the healthcare system may generate a new set of sleep quality measure(s) after each sleep session, and / or may generate one or more new metabolic health scores periodically (e.g., daily) for the user based on updated sensor data.

[0180] At block 1610, the healthcare system identifies or evaluates any trend(s) in the scores. For example, the healthcare system may determine whether either score is trending upwards, trending downwards, steady, tends to oscillate, and the like. In some embodiments, as part of identifying trends, the healthcare system may attempt to identify potential triggers or causes for changes in the trend. For example, the healthcare system may determine that metabolic health of the user tends to be higher some specific days of the week, that the user’s sleep quality measures tend to be lower on specific days of the week, and the like. Generally, the healthcare system may use a variety of techniques to identify trends in the data.

[0181] At block 1615, the healthcare system generates one or more coaching outputs (e.g., the health recommendations 1020 of FIG. 10) based on the score(s) and / or trend(s), as discussed above. For example, in some embodiments, the healthcare system may generate visualizations showing how the scores have changed over time and / or how the scores are predicted to evolve over time based on the existing trends.

[0182] In some embodiments, as discussed above, the coaching may be provided using one or more machine learning models to enable interactive feedback and discussions regarding the scores and / or trends. For example, in some embodiments, the healthcare system may use an LLM to generate natural language outputs based on natural language inputs from the user. In some embodiments, the healthcare system may provide a chat window allowing users to request information or guidance regarding the various scores or trends and may use techniques such as RAG in combination with the LLM to retrieve and provide relevant documentation or literature for the request, such as to suggest relevant articles or other resources that may help the user.

[0183] In the illustrated example, the method 1600 then returns to block 1605. In this way, the healthcare system can provide dynamic coaching and assistance to the user based on their personal trends and scores.Example Method for Configuring Respiratory Therapy Systems

[0184] FIG. 17 is a flow diagram depicting an example method 1700 for configuringRSMD / 0134PC-160899respiratory therapy systems, according to some embodiments of the present disclosure. In some embodiments, the method 1700 may be performed by a healthcare system, such as the evaluation system 125 and / or intervention system 130 of FIG. 1, the healthcare system discussed above with reference to FIGS. 2-16, and / or the computing device 1900 of FIG. 19.

[0185] At block 1705, first glucose data (e.g., the sensor data 205 of FIG. 2 from the glucose sensor 305 of FIG. 3) of a first user (e.g., the user 105 of FIG. 1) collected while the first user was awake is accessed, wherein the first user is a participant in a respiratory therapy (e.g., using the respiratory therapy system 115 of FIG. 1).

[0186] At block 1710, a first metabolic health (MH) state (e.g., the metabolic health state 215 of FIGS. 2-4) of the first user is determined based at least in part on the first glucose data.

[0187] At block 1715, a first respiratory therapy configuration (e.g., the therapy configuration 225 of FIG.2, the pressure settings 405 of FIG.4, the ramp settings 410 of FIG.4, and / or the curve settings 415 of FIG. 4) for a subsequent usage session of the first user is generated based on evaluating the first MH state using one or more MH models.

[0188] At block 1720, a respiratory therapy flow generator of the first user (e.g., the respiratory therapy system 115 of FIG. 2) is instructed to implement the first respiratory therapy configuration during a first usage session.Example Method for Evaluating Apnea Risk

[0189] FIG. 18 is a flow diagram depicting an example method 1800 for evaluating apnea risk, according to some embodiments of the present disclosure. In some embodiments, the method 1800 may be performed by a healthcare system, such as the evaluation system 125 and / or intervention system 130 of FIG.1, the healthcare system discussed above with reference to FIGS. 2-17, and / or the computing device 1900 of FIG. 19.

[0190] At block 1805, first glucose data (e.g., the sensor data 205 of FIG. 7 from the glucose sensor 705 of FIG. 7) of a first user (e.g., the user 105 of FIG. 1) collected during a first sleep session is accessed.

[0191] At block 1810, a plurality of transitions (e.g., the transitions 740 of FIG.7) between sleep stages experienced by the first user during the first sleep session is determined based at least in part on the first glucose data.

[0192] At block 1815, a first sleep quality measure (e.g., the sleep quality measure 615 of FIGS. 6-8) for the first sleep session is generated based at least in part on the plurality of transitions.

[0193] At block 1820, a first apnea risk score for the first user is generated based at least in part on the first sleep quality measure.RSMD / 0134PC-160899

[0194] At block 1825, one or more medical interventions (e.g., the medical interventions 625 of FIG. 6, the diagnosis recommendations 805 of FIG. 8, the therapy recommendations 810 of FIG. 8, and / or the sleep recommendations 815 of FIG. 8) for the first user are provided based on the first apnea risk score.Example Processing System for Respiratory Therapy Configuration

[0195] FIG. 19 depicts an example computing device 1900 configured to perform various aspects of the present disclosure, according to some embodiments disclosed herein. Although depicted as a physical device, in embodiments, the computing device 1900 may be implemented using virtual device(s), and / or across a number of devices (e.g., in a cloud environment). In one embodiment, the computing device 1900 corresponds to any element or aspect of a healthcare system, such as the healthcare systems discussed above with reference to FIGS. 1-18.

[0196] As illustrated, the computing device 1900 includes a CPU 1905, memory 1910, storage 1915, a network interface 1925, and one or more input / output (I / O) interfaces 1920. In the illustrated embodiment, the CPU 1905 retrieves and executes programming instructions stored in memory 1910, as well as stores and retrieves application data residing in storage 1915. The CPU 1905 is generally representative of a single CPU and / or GPU, multiple CPUs and / or GPUs, a single CPU and / or GPU having multiple processing cores, and the like. The memory 1910 is generally included to be representative of a random access memory. Storage 1915 may be any combination of disk drives, flash-based storage devices, and the like, and may include fixed and / or removable storage devices, such as fixed disk drives, removable memory cards, caches, optical storage, network attached storage (NAS), or storage area networks (SAN).

[0197] In some embodiments, I / O devices 1935 (such as keyboards, monitors, etc.) are connected via the I / O interface(s) 1920. Further, via the network interface 1925, the computing device 1900 can be communicatively coupled with one or more other devices and components (e.g., via a network, which may include the Internet, local network(s), and the like). As illustrated, the CPU 1905, memory 1910, storage 1915, network interface(s) 1925, and I / O interface(s) 1920 are communicatively coupled by one or more buses 1930.

[0198] In the illustrated embodiment, the memory 1910 includes an evaluation component 1950 and an intervention component 1955, which may perform one or more embodiments discussed above. Although depicted as discrete components for conceptual clarity, in embodiments, the operations of the depicted components (and others not illustrated) may be combined or distributed across any number of components. Further, although depicted as software residing in memory 1910, in embodiments, the operations of the depicted componentsRSMD / 0134PC-160899(and others not illustrated) may be implemented using hardware, software, or a combination of hardware and software. Additionally, in some embodiments, additional components may be present, such as training components for training or refining the machine learning model(s).

[0199] In some embodiments, the evaluation component 1950 (which may correspond to the evaluation system 125 of FIGS. 1-2, 6-, the metabolic health component 210 of FIGS. 2-3, the sleep component 610 of FIGS.6 and / or 9, the state component 735 of FIG.7, the quality component 745 of FIG. 7.) can be used to evaluate various sensor data to quantify the health and sleep of users, as discussed above. For example, the evaluation component 1950 may generate metabolic health states for the users, quantify sleep quality for the users, and the like.

[0200] In some embodiments, the intervention component 1955 (which may correspond to the intervention system 130 of FIGS. 1-2, 5-6, 9, and / or 10, the configuration component 220 of FIGS.2, 4, and / or 5, the update component 510 of FIG. 5, the risk component 620 of FIG.6 and / or 8-9, the update component 910 of FIG. 9, the scoring component 1005 of FIG. 10, the trends component 1010 of FIG. 10, and / or the coaching component 1015 of FIG. 10) can be used to generate and / or implement interventions based on user health information, as discussed above. For example, the evaluation component 1950 may generate respiratory therapy configurations, evaluate sleep apnea risks, and the like.

[0201] In the illustrated example, the storage 1915 includes one or more machine learning models, including configuration models 1960, sleep models 1965, and risk models 1970. The configuration models 1960 may generally correspond to machine learning models trained to predict or generate therapy configurations based on the user’s metabolic health, as discussed above. The sleep models 1965 may generally correspond to machine learning models trained to predict or generate sleep transitions based on sensor data while the user sleeps, as discussed above. The risk models 1970 may generally correspond to machine learning models trained to predict the risk (e.g., probability) of a user having (or eventually developing) one or more sleep and / or respiratory disorders, as discussed above. Although depicted as residing in storage 1915, the depicted models may be stored in any suitable location, including memory 1910.

[0202] Generally, the depicted components (and others not depicted) in memory 1910 may be used to implement one or more embodiments discussed above.Example Clauses

[0203] Clause 1 : A method, comprising: accessing first glucose data of a first user collected while the first user was awake, wherein the first user is a participant in a respiratory therapy; determining a first metabolic health (MH) state of the first user based at least in part on the first glucose data; generating a first respiratory therapy configuration for a subsequent usage sessionRSMD / 0134PC-160899of the first user based on evaluating the first MH state using one or more MH models; and instructing a respiratory therapy flow generator of the first user to implement the first respiratory therapy configuration during a first usage session.

[0204] Clause 2: A method according to Clause 1, further comprising: accessing respiratory therapy data of the first user collected during a prior usage session; and determining the first MH state of the first user based further on the respiratory therapy data.

[0205] Clause 3: A method according to any of Clauses 1-2, further comprising: accessing sensor data collected using one or more wearable sensors of the first user, the sensor data comprising one or more of (i) activity data, (ii) temperature data, (iii) oxygen saturation data, (iv) diet data, (v) melatonin data, (vi) cortisol data, or (vii) ketone data of the first user while the first user was awake: and determining the first MH state of the first user based further on the sensor data.

[0206] Clause 4: A method according to any of Clauses 1-3, further comprising: accessing respiratory therapy data of the first user collected during the first usage session; and determining a second MH state of the first user based at least in part on the respiratory therapy data.

[0207] Clause 5: A method according to Clause 4, further comprising: generating a second respiratory therapy configuration based on evaluating the second MH state using the one or more MH models; and instructing the respiratory therapy flow generator to implement the second respiratory therapy configuration during a second usage session.

[0208] Clause 6: A method according to any of Clauses 1-5, wherein the first glucose data comprises at least one of: (i) a glucose level or a trend in glucose level during a window immediately prior to the first usage session, or (ii) a fasting glucose level of the user during a day preceding the first usage session.

[0209] Clause 7: A method according to any of Clauses 1-6, wherein the first respiratory therapy configuration comprises at least one of: (i) an air pressure of the respiratory therapy flow generator, (ii) a ramp up time of the respiratory therapy flow generator, or (iii) a pressure curve of the respiratory therapy flow generator.

[0210] Clause 8: A method, comprising: accessing first glucose data of a first user collected during a first sleep session; determining, based at least in part on the first glucose data, a plurality of transitions between sleep stages experienced by the first user during the first sleep session; generating a first sleep quality measure for the first sleep session based at least in part on the plurality of transitions; generating a first apnea risk score for the first user based at least in part on the first sleep quality measure; and providing one or more medical interventions forRSMD / 0134PC-160899the first user based on the first apnea risk score.

[0211] Clause 9: A method according to Clause 8, further comprising accessing sensor data collected using one or more wearable sensors of the first user during the first sleep session, the sensor data comprising one or more of (i) motion data, (ii) temperature data, (iii) oxygen saturation data, (iv) pulse data, or (v) blood pressure data; and determining the plurality of transitions based further on the sensor data.

[0212] Clause 10: A method according to any of Clauses 8-9, wherein determining the plurality of transitions comprises determining, for each respective transition of the plurality of transitions and based on the first glucose data: a first sleep stage the first user was in prior to the respective transition, a second sleep stage the first user was in subsequent to the respective transition, and a timing of the respective transition.

[0213] Clause 11: A method according to any of Clauses 8-10, wherein determining the plurality of transitions comprises processing the first glucose data using one or more trained machine learning models.

[0214] Clause 12: A method according to any of Clauses 8-11, wherein generating the first sleep quality measure comprises at least one of: determining, based on the plurality of transitions, a sleep latency of the first sleep session, determining, based on the plurality of transitions, a wakefulness after sleep onset value of the first sleep session, determining, based on the plurality of transitions, a number or a frequency of arousals of the first sleep session, or determining a number of the plurality of transitions.

[0215] Clause 13: A method according to any of Clauses 8-12, further comprising: accessing second glucose data of the first user collected while the first user was awake; and generating the first apnea risk score based further on the second glucose data.

[0216] Clause 14: A method according to Clause 13, wherein the second glucose data comprises at least one of: glucose variability throughout a day, one or more average glucose values throughout the day, a mean difference between glucose values collected at a same time on two different days, a high blood glucose index during the day, or a low blood glucose index during the day.

[0217] Clause 15: A system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the processing system to perform a method in accordance with any one of Clauses 1-14.

[0218] Clause 16: A system, comprising means for performing a method in accordance with any one of Clauses 1-14.RSMD / 0134PC-160899

[0219] Clause 17: A non-transitory computer-readable medium comprising computerexecutable instructions that, when executed by one or more processors of a processing system, cause the processing system to perform a method in accordance with any one of Clauses 1-14.

[0220] Clause 18: A computer program product embodied on a computer-readable storage medium comprising code for performing a method in accordance with any one of Clauses 1 -14.Additional Considerations

[0221] One or more elements or aspects or steps, or any portion(s) thereof, from one or more of any of claims below can be combined with one or more elements or aspects or steps, or any portion(s) thereof, from one or more of any of the other claims below or combinations thereof, to form one or more additional implementations and / or claims of the present disclosure.

[0222] While the present disclosure has been described with reference to one or more particular embodiments or implementations, those skilled in the art will recognize that many changes may be made thereto without departing from the spirit and scope of the present disclosure. Each of these implementations and obvious variations thereof is contemplated as falling within the spirit and scope of the present disclosure. It is also contemplated that additional implementations according to aspects of the present disclosure may combine any number of features from any of the implementations described herein.

[0223] The preceding description is provided to enable any person skilled in the art to practice the various embodiments described herein. The examples discussed herein are not limiting of the scope, applicability, or embodiments set forth in the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments. For example, changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. Various examples may omit, substitute, or add various procedures or components as appropriate. For instance, the methods described may be performed in an order different from that described, and various steps may be added, omitted, or combined. Also, features described with respect to some examples may be combined in some other examples. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. In addition, the scope of the disclosure is intended to cover such an apparatus or method that is practiced using other structure, functionality, or structure and functionality in addition to, or other than, the various aspects of the disclosure set forth herein. It should be understood that any aspect of the disclosure disclosed herein may beRSMD / 0134PC-160899embodied by one or more elements of a claim.

[0224] As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects.

[0225] As used herein, a phrase referring to “at least one of a list of items refers to any combination of those items, including single members. As an example, “at least one of: a, b, or c” is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiples of the same element (e.g., a-a, a-a-a, a-a-b, a-a-c, a-b-b, a c c, b-b, b-b-b, b-b-c, c-c, and c-c-c or any other ordering of a, b, and c).

[0226] As used herein, the tern “determining” encompasses a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, investigating, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like. Also, “determining” may include resolving, selecting, choosing, establishing and the like.

[0227] The methods disclosed herein comprise one or more steps or actions for achieving the methods. The method steps and / or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and / or use of specific steps and / or actions may be modified without departing from the scope of the claims. Further, the various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions. The means may include various hardware and / or software component(s) and / or module(s), including, but not limited to a circuit, an application specific integrated circuit (ASIC), or processor. Generally, where there are operations illustrated in figures, those operations may have corresponding counterpart means-plus-function components with similar numbering.

[0228] Embodiments of the invention may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g.,RSMD / 0134PC-160899storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.

[0229] Typically, cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g., an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In context of the present invention, a user may access applications or systems (e.g., the evaluation system and / or intervention system) or related data available in the cloud. For example, the evaluation system could execute on a computing system in the cloud and train and use machine learning models to predict various user health information, as discussed above. In such a case, the evaluation system could receive and process sensor data, and store the models and predictions at a storage location in the cloud. Doing so allows a user to access this information from any computing system attached to a network connected to the cloud (e.g., the Internet).

[0230] The following claims are not intended to be limited to the embodiments shown herein, but are to be accorded the full scope consistent with the language of the claims. Within a claim, reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. No claim element is to be construed under the provisions of 35 U.S.C. § 112(f) unless the element is expressly recited using the phrase “means for” or, in the case of a method claim, the element is recited using the phrase “step for.” All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims.RSMD / 0134PC-160899

Claims

CLAIMSWHAT IS CLAIMED IS:

1. A method, comprising:accessing first glucose data of a first user collected during a first sleep session; determining, based at least in part on the first glucose data, a plurality of transitions between sleep stages experienced by the first user during the first sleep session;generating a first sleep quality measure for the first sleep session based at least in part on the plurality of transitions;generating a first apnea risk score for the first user based at least in part on the first sleep quality measure; andproviding one or more medical interventions for the first user based on the first apnea risk score.

2. The method of claim 1, further comprisingaccessing sensor data collected using one or more wearable sensors of the first user during the first sleep session, the sensor data comprising one or more of (i) motion data, (ii) temperature data, (iii) oxygen saturation data, (iv) pulse data, or (v) blood pressure data; and determining the plurality of transitions based further on the sensor data.

3. The method of claim 1, wherein determining the plurality of transitions comprises determining, for each respective transition of the plurality of transitions and based on the first glucose data:a first sleep stage the first user was in prior to the respective transition,a second sleep stage the first user was in subsequent to the respective transition, and a timing of the respective transition.

4. The method of claim 1, wherein determining the plurality of transitions comprises processing the first glucose data using one or more trained machine learning models.

5. The method of claim 1, wherein generating the first sleep quality measure comprises at least one of:determining, based on the plurality of transitions, a sleep latency of the first sleep session,determining, based on the plurality of transitions, a wakefulness after sleep onset value of the first sleep session,determining, based on the plurality of transitions, a number or a frequency of arousals of the first sleep session, ordetermining a number of the plurality of transitions.RSMD / 0134PC-1608996. The method of claim 1. further comprising:accessing second glucose data of the first user collected while the first user was awake; andgenerating the first apnea risk score based further on the second glucose data.

7. The method of claim 6, wherein the second glucose data comprises at least one of:glucose variability throughout a day,one or more average glucose values throughout the day,a mean difference between glucose values collected at a same time on two different days,a high blood glucose index during the day, ora low blood glucose index during the day.

8. One or more non-transitory computer-readable media collectively or individually comprising computer-executable instructions that, when executed by one or more processors of one or more processing systems, cause the one or more processing systems to collectively or individually perform an operation comprising:accessing first glucose data of a first user collected during a first sleep session; determining, based at least in part on the first glucose data, a plurality of transitions between sleep stages experienced by the first user during the first sleep session;generating a first sleep quality measure for the first sleep session based at least in part on the plurality of transitions;generating a first apnea risk score for the first user based at least in part on the first sleep quality measure; andproviding one or more medical interventions for the first user based on the first apnea risk score.

9. The one or more non-transitory computer-readable media of claim 8, the operation further comprisingaccessing sensor data collected using one or more wearable sensors of the first user during the first sleep session, the sensor data comprising one or more of (i) motion data, (ii) temperature data, (iii) oxygen saturation data, (iv) pulse data, or (v) blood pressure data; and determining the plurality of transitions based further on the sensor data.

10. The one or more non-transitory computer-readable media of claim 8, wherein determining the plurality of transitions comprises determining, for each respective transition of the plurality of transitions and based on the first glucose data:a first sleep stage the first user was in prior to the respective transition,RSMD / 0134PC-160899a second sleep stage the first user was in subsequent to the respective transition, and a timing of the respective transition.

11. The one or more non-transitory computer-readable media of claim 8, wherein determining the plurality of transitions comprises processing the first glucose data using one or more trained machine learning models.

12. The one or more non-transitory computer-readable media of claim 8, wherein generating the first sleep quality measure comprises at least one of:determining, based on the plurality of transitions, a sleep latency of the first sleep session,determining, based on the plurality of transitions, a wakefulness after sleep onset value of the first sleep session,determining, based on the plurality of transitions, a number or a frequency of arousals of the first sleep session, ordetermining a number of the plurality of transitions.

13. The one or more non-transitory computer-readable media of claim 8, the operation further comprising:accessing second glucose data of the first user collected while the first user was awake; andgenerating the first apnea risk score based further on the second glucose data.

14. The one or more non-transitory computer-readable media of claim 13, wherein the second glucose data comprises at least one of:glucose variability throughout a day,one or more average glucose values throughout the day,a mean difference between glucose values collected at a same time on two different days,a high blood glucose index during the day, ora low blood glucose index during the day.

15. A system, comprising:one or more memories collectively or individually comprising computer-executable instructions; andone or more processors configured to, individually or collectively, execute the computer-executable instructions and cause the system to perform an operation comprising:accessing first glucose data of a first user collected during a first sleep session;RSMD / 0134PC-160899determining, based at least in part on the first glucose data, a plurality of transitions between sleep stages experienced by the first user during the first sleep session;generating a first sleep quality measure for the first sleep session based at least in part on the plurality of transitions;generating a first apnea risk score for the first user based at least in part on the first sleep quality measure; andproviding one or more medical interventions for the first user based on the first apnea risk score.

16. The system of claim 15, the operation further comprisingaccessing sensor data collected using one or more wearable sensors of the first user during the first sleep session, the sensor data comprising one or more of (i) motion data, (ii) temperature data, (iii) oxygen saturation data, (iv) pulse data, or (v) blood pressure data; and determining the plurality of transitions based further on the sensor data.

17. The system of claim 15, wherein determining the plurality of transitions comprises determining, for each respective transition of the plurality of transitions and based on the first glucose data:a first sleep stage the first user was in prior to the respective transition,a second sleep stage the first user was in subsequent to the respective transition, and a timing of the respective transition.

18. The system of claim 15, wherein determining the plurality of transitions comprises processing the first glucose data using one or more trained machine learning models.

19. The system of claim 15, wherein generating the first sleep quality measure comprises at least one of:determining, based on the plurality of transitions, a sleep latency of the first sleep session,determining, based on the plurality of transitions, a wakefulness after sleep onset value of the first sleep session,determining, based on the plurality of transitions, a number or a frequency of arousals of the first sleep session, ordetermining a number of the plurality of transitions.

20. The system of claim 15, the operation further comprising:accessing second glucose data of the first user collected while the first user was awake, wherein the second glucose data comprises at least one of:RSMD / 0134PC-160899glucose variability throughout a day,one or more average glucose values throughout the day, a mean difference between glucose values collected at a same time on two different days,a high blood glucose index during the day, ora low blood glucose index during the day; andgenerating the first apnea risk score based further on the second glucose data.RSMD / 0134PC-160899

Images