EP4721104A1 - Compliance prediction using machine learning - Google Patents

Abstract

Techniques for machine learning-based therapy prediction and allocation are provided. Sleep diagnostic data for a user is accessed, and a predicted compliance measure is generated based on processing the sleep diagnostic data using a machine learning model, where the predicted compliance measure indicates a likelihood that the user will satisfy one or more compliance criteria for a respiratory therapy. The user is allocated to an assigned setup class based on evaluating the predicted compliance measure using one or more enrollment criteria, where the assigned setup class is either a virtual setup class or an in-person setup class. Inception of the respiratory therapy for the user is facilitated based on the assigned setup class.

Description

COMPLIANCE PREDICTION USING MACHINE LEARNING

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This Application claims the benefit of and priority to U.S. Provisional Patent Application No. 63/506,282, filed on June 5, 2023, the entire contents of which are incorporated herein by reference.

INTRODUCTION

[0002] Aspects of the present disclosure relate to machine learning. More specifically, aspects of the present disclosure relate to training and using machine learning to predict therapy compliance.

[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 user interface generally is a specific category and type of user interface for the user, such as direct or indirect connections for the category of user interface, and full face mask, a partial face mask, nasal mask, or nasal pillows for the type of user interface. In addition to the specific category and type, the user interface generally is a specific model made by a specific manufacturer, e.g., AirFit™ F20 manufactured by ResMed.

[0005] There are generally a variety of techniques and workflows that can be used to onboard or enroll new users in respiratory therapy and/or to provision new equipment. In some cases, the methodology used to onboard new users can impact user compliance with the therapy. For example, users may engage in in-person setup and guidance, may use virtual guidance (live or prerecorded), and the like. For various reasons, such as ensuring that the user becomes (and remains) compliant with the respiratory therapy, it can be beneficial to know that the user has been adequately trained (or otherwise understands proper use and care of the respiratory system), as well as how they will respond to various types of onboarding.

[0006] Improved systems and techniques to predict and improve therapy compliance are needed.

SUMMARY

[0007] According to one embodiment presented in this disclosure, a method is provided. The method includes: accessing sleep diagnostic data for a user; generating a predicted compliance measure based on processing the sleep diagnostic data using a machine learning model, wherein the predicted compliance measure indicates a likelihood that the user will satisfy one or more compliance criteria for a respiratory therapy; allocating the user to an assigned setup class based on evaluating the predicted compliance measure using one or more enrollment criteria, wherein the assigned setup class is either a virtual setup class or an in-person setup class; and facilitating inception of the respiratory therapy for the user based on the assigned setup class.

[0008] According to a second embodiment of the present disclosure, a method is provided. The method includes: accessing sleep diagnostic data for a user; determining whether the user satisfied a set of compliance criteria for a respiratory therapy; training a machine learning model to predict therapy compliance based at least in part on the sleep diagnostic data for the user and the determination whether the user satisfied the set of compliance criteria; and deploying the machine learning model to generate predicted compliance measures indicating likelihoods that users will satisfy the set of compliance criteria for respiratory therapy.

[0009] The following description and the related drawings set forth in detail certain illustrative features of one or more embodiments.

DESCRIPTION OF THE DRAWINGS

[0010] The appended figures depict certain aspects of the one or more embodiments and are therefore not to be considered limiting of the scope of this disclosure. [0011] FIG. 1 depicts an example workflow to train compliance prediction machine learning models, according to one embodiment of the present disclosure.

[0012] FIG. 2 depicts an example workflow to use machine learning to predict therapy compliance and improve therapy enrollment, according to one embodiment of the present disclosure.

[0013] FIG. 3 is a flow diagram depicting an example method for training compliance prediction machine learning models, according to one embodiment of the present disclosure.

[0014] FIG. 4 is a flow diagram depicting an example method for using machine learning to predict therapy compliance and improve therapy enrollment, according to one embodiment of the present disclosure.

[0015] FIG. 5 is a flow diagram depicting an example method for refining machine learning models based on user feedback, according to one embodiment of the present disclosure.

[0016] FIG. 6 is a flow diagram depicting an example method for using machine learning to predict therapy compliance, according to one embodiment of the present disclosure.

[0017] FIG. 7 is a flow diagram depicting an example method for training machine learning models to predict therapy compliance, according to one embodiment of the present disclosure.

[0018] FIG. 8 depicts an example computing device configured to perform various aspects of the present disclosure.

[0019] To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the drawings. It is contemplated that elements and features of one embodiment may be beneficially incorporated in other embodiments without further recitation.

DETAILED DESCRIPTION

[0020] Aspects of the present disclosure provide apparatuses, methods, processing systems, and computer-readable mediums for improved compliance prediction and therapy enrollment using machine learning. [0021] In some embodiments of the present disclosure, sleep diagnostic data (e.g., from a sleep test over a single night) may be evaluated using one or more trained machine learning models to predict future therapy compliance of the user (e.g., whether they will meet one or more defined compliance criteria). In some aspects, short-term compliance is predicted (e.g., compliance during a 90 day window), rather than long-term compliance, to better provide initial enrollment and therapy inception solutions. In some embodiments, in addition to or instead of predicting shortterm compliance, user compliance can be predicted with respect to other time scales, such as a medium-term compliance, long-term compliance, and the like. In some embodiments, the predicted compliance can be evaluated to determine or select an effective approach or operation to be used for therapy enrollment of the user, as discussed in more detail below.

[0022] Respiratory therapy generally involves use of specific therapy equipment (e.g., a continuous positive airway pressure (CPAP)) by a user or patient in their own homes (e.g., while the user sleeps). Accordingly, a proper understanding of how to use the equipment may play a substantial role in how effective the therapy is and/or whether the user remains active on the therapy. Therefore, a variety of techniques and systems have been designed to facilitate the inception of therapy for new users and/or for users of new equipment (e.g., existing therapy patients using a new model or type of equipment). In some embodiments, this therapy inception process may be referred to as onboarding, enrolling or enrollment, setting up or setup, and the like.

[0023] Though the specific contents and format of each setup/enrollment approach vary, each generally tries to teach the user about the components of their new equipment and how to use it. For example, some approaches involve in-person setup, where a provider (e.g., a physician, technician, or other healthcare provider) physically meets with the user face-to-face to show and explain the functionality and respond to questions. Though such in-person approaches potentially result in improved understanding by the user (and potentially in improved adherence to the therapy, at least in the initial stages), they are costly, slow, and require that the user physically travel to the provider (or vice versa), substantially limiting their applicability in some cases (such as when the user lives in a remote location or is homebound). As another example, some approaches involve a live virtual setup, where a provider (e.g., a physician, technician, or other healthcare provider) virtually meets with the user, such as using audio and/or video chat, to show and explain the functionality and respond to questions. Though such approaches may be comparable to in-person meetings, they may reduce associated costs of the setup. However, they remain similarly slow (e.g., due to the need to schedule a future appointment with the provider).

[0024] As yet another example, some approaches involve entirely virtual setup, where the user sets up their device/equipment remotely in their own home using virtual assistance in the form of prerecorded information (e.g., text, video, and/or audio explaining the functionality of the equipment). Though such virtual setup approaches can substantially reduce costs and delay (e.g., because the user can complete setup whenever desired and need not leave home), they potentially result in reduced understanding by the user (and potentially in reduced adherence to the therapy, at least during the initial stages), as compared to more direct/in-person setup.

[0025] In some conventional systems, users are assigned to setup alternatives using a variety of techniques, including manually (e.g., letting users and/or physicians select an alternative for each patient), based on simplistic criteria such as age or severity of the underlying issue for which therapy is sought, and the like. For example, some physicians assign younger patients and/or patients with more mild apnea to virtual setup, assuming that such patients are more able to complete the virtual setup successfully and/or do not need in-person assistance due to the mild nature of their condition. However, these conventional approaches fail to provide an adequate and objective framework for effective therapy enrollment.

[0026] In some embodiments, therefore, sleep diagnostic data for the user, collected/generated during or after a sleep test (which may be a single night of sleep), can be evaluated using machine learning to predict future compliance (e.g., short-term compliance that may be most impacted by the choice of enrollment guidance) and select an appropriate therapy setup approach. For example, in some embodiments, users with higher predicted compliance may be more likely to be assigned to a virtual setup approach, as compared to users with a low predicted compliance. That is, because users with predicted high compliance may be highly motivated to begin therapy, they may be more likely to pay close attention and/or spend more time on self-guided materials, follow-up for additional help if needed, or otherwise ensure that they understand how to proceed, even if virtual setup is used. Less compliant patients, however, may benefit from more personal interaction to guide their setup (as they may lose interest or otherwise fail to engage with the material).

[0027] In some embodiments, by using such machine learning techniques, overall therapy adherence (across users or patients) can be substantially improved. For example, if virtual setup generally results in reduced (average) compliance, as compared to in-person setup, the overall or aggregate compliance rate improves by assigning more compliant patients to this virtual setup and less compliant patients to in-person setup. In this way, patient outcomes are substantially improved. Further, limited healthcare resources are allocated more effectively using the trained models.

[0028] Additionally, in some embodiments, computational resources can be used more efficiently and computational expense can be reduced, thereby improving the operations of the computers and systems themselves. In some embodiments, by using such trained machine learning models to assign users to various therapy setup approaches, the resources spent or wasted providing virtual setup can be reduced. For example, there is often substantial computational expense incurred by such virtual setups, including storage and memory footprint (e.g., on the server(s) that host the material), as well as bandwidth requirements (e.g., used to transmit or stream the data to the user(s)). As the material often includes substantial amounts of data (e.g., units of information, such as gigabytes) such as video data, substantial bandwidth is consumed streaming or providing the data. Similarly, substantial electrical power may be consumed in storing and providing such setup data. Further, if the guidance materials are provided as physical copies (e.g., pamphlets, compact discs (CDs), digital versatile discs (DVDs), flash memory devices, and the like), substantial resources are used to build and provide such resources directly to virtual/asynchronous setup users.

[0029] However, by using the machine learning models disclosed herein to enable more effective setup assignments, the amount of such computing and physical resources that are used and/or wasted can be reduced. For example, because fewer users that are assigned to the virtual setup will drop out of therapy (as compared to conventional approaches that do not use machine learning), the resource waste (e.g., resources used to provide virtual setup for users that ultimately drop out) is reduced. Similarly, because users that drop out (or otherwise switch equipment due to low compliance/adherence) often re-enroll in the future, the computational and physical resources must be spent a second time (or third time, or even more) on the same users. This duplicative resource usage is clearly wasteful and can be reduced or eliminated by using the models and techniques described herein. [0030] In these (and other) ways, using embodiments of the present disclosure, the computing systems that generate, maintain, store, host, transmit, or otherwise provide the setup resources can operate with reduced computational expense and more efficient allocation of computing resources, as compared to other approaches.

Example Workflow to Train Compliance Prediction Machine Learning Models

[0031] FIG. 1 depicts an example workflow 100 to train compliance prediction machine learning models, according to one embodiment of the present disclosure.

[0032] In the illustrated workflow 100, one or more sleep test components 105 are used to collect, generate, or otherwise provide sleep diagnostic data 110, which are stored or maintained in a repository of sleep diagnostic records 115. The sleep diagnostic records 115 are accessed by a training system 125, along with a set of compliance records 120, to train or generate a compliance prediction model 130. Although the illustrated example depicts a repository of sleep diagnostic records 115, in some aspects, the sleep diagnostic data 110 can be provided directly to the training system 125.

[0033] Generally, the sleep test components 105 correspond to equipment or devices used to perform sleep tests, such as to detect sleep apnea. For example, each sleep test component 105 may include or use a variety of sensors to detect, collect, or generate the sleep diagnostic data 110 for a user while they sleep. The specific data collected may vary depending on the particular implementation, and may include information such as respiratory effort, pulse, oxygen saturation, nasal flow, snoring, and the like. In some embodiments, the sleep diagnostic data 110 includes information such as the apnea-hypopnea index (AHI) of the user (determined/generated based on the sleep test), the percentage of the night (during the sleep test) that the user spent partially or entirely in an upright position (e.g., standing, sitting, propped up, or otherwise not laying supine or on their side) during the test, the obstructive apnea index (OAI) generated based on the test, the central apnea index (CAI) generated based on the test, blood oxygen saturation information (e.g., the maximum, average, or minimum saturation) collected during the test, pulse information (e.g., the maximum, average, or minimum pulse) collected during the test, breath rate information (e.g., the maximum, average, or minimum breaths per unit of time) collected during the test, and the like. [0034] In some embodiments, users may request or be provided with the sleep test component 105 (e.g., at the request of a physician or sleep consultant) to perform a sleep test, which may allow the user and/or care provider to determine whether the user has apnea and/or could benefit from respiratory therapy. In some embodiments, the sleep tests may be performed in the user’s home, at a sleep lab, and the like. In some embodiments, the sleep test of a given user may occur over a single night. That is, each record of sleep diagnostic data 110 (for a specific user) may include data from a single test/single night of sleep.

[0035] In the illustrated example, the sleep diagnostic records 115 correspond to a repository to store the sleep diagnostic data 110 for future use (e.g., to train one or more machine learning models). In an embodiment, the sleep diagnostic records 115 can generally comprise records, where each record includes sleep diagnostic data 110 from a given sleep test/user. In some embodiments, the sleep diagnostic records 115 may include other information, such as the age of the corresponding user (when the sleep test was conducted) or other demographics of the user (e.g., their height, weight, sex, and the like).

[0036] Although depicted as residing separately from the training system 125 (e.g., in a separate repository), in some embodiments, some or all of the sleep diagnostic records 115 may be stored locally by the training system 125. The training system 125 may generally be implemented using hardware, software, or a combination of hardware and software. Additionally, though depicted as a discrete system for conceptual clarity, in some embodiments, the training system 125 may be implemented as a component of a larger system.

[0037] In the illustrated example, the training system 125 accesses the sleep diagnostic records 115 and a set of compliance records 120 to train the compliance prediction model 130. As used herein, “accessing” data may generally include receiving, retrieving, requesting, obtaining, or otherwise gaining access to the data. Although the compliance records 120 are depicted as residing separately from the training system 125 and the sleep diagnostic records 115, in some embodiments, some or all of the compliance records 120 may be stored locally by the training system 125 and/or within the same repository as the sleep diagnostic records 115. The training system 125 may generally access the sleep diagnostic records 115 and/or compliance records 120 using a variety of communication links, including wired links, wireless links, or a combination of wired and wireless links. In some embodiments, the sleep diagnostic records 115 and compliance records 120 may collectively be referred to as training data, training exemplars, training samples, training records, and the like.

[0038] In an embodiment, the compliance records 120 generally include information relating to whether one or more users became compliant patients on respiratory therapy. In some embodiments, patient compliance may be defined using a variety of rules or criteria (which may vary depending on the particular locale, country, region, or institution that assists the user in the therapy). For example, some locales may define compliance based on longer time scales (e.g. using a continually running rule), resulting in machine learning models (e.g., compliance prediction model 130) that learn to predict more long-term compliance, as compared to other locales that rely on more short-term definitions. Generally, the patient’s compliance may be determined based at least in part on whether they use the respiratory therapy equipment some threshold amount during one or more defined windows. For example, a patient may be deemed compliant if they use the equipment on at least a threshold number of nights, for at least a threshold average duration per day, and the like. In some embodiments, the compliance records 120 include, for each user having data reflected in the sleep diagnostic records 115 (e.g., each user that used a sleep test component 105 to take a sleep test, generating corresponding sleep diagnostic data 110), a binary indication as to whether the user was deemed compliant after respiratory therapy began. In at least some embodiments, the compliance records 120 indicate short-term compliance (e.g., whether the patient became compliant during an initial stage or phase of therapy, such as the first 90 days of therapy), as compared to long-term compliance (e.g., the records may indicate that a patient was compliant, even if they later became non-compliant).

[0039] Generally, the sleep diagnostic records 115 and compliance records 120 may be collected over any period of time for any number and variety of users in order to provide sufficient training data for the training system 125. As illustrated, the training system 125 accesses the sleep diagnostic records 115 and compliance records 120 to train the compliance prediction model 130.

[0040] In some embodiments, some or all of the features reflected in the sleep diagnostic records 115 are used as model input, while the compliance information contained in the compliance records 120 is used as target output (also referred to as a label, a ground truth value, and the like). The training system 125 can then update or refine one or more parameters of the compliance prediction model 130 based on the difference between the generated (predicted) compliance, which is output by the compliance prediction model 130 based on processing some or all of a sleep diagnostic record 115 for a user, and the known compliance state for the user, as reflected in the compliance records 120.

[0041] In an embodiment, a variety of suitable machine learning architectures may be used, such as neural networks, support vector machines (SVMs), random forests, light gradient boosted models (LGBMs), and the like. Generally, the particular techniques used to train the compliance prediction model 130 may vary depending on the particular implementation. For example, in the case of a neural network architecture, the training system 125 may provide one or more features from the sleep diagnostic records 115 (e.g., age, AHI, and the percentage of time spent upright during the sleep test) as input to the input layer (e.g., one or more neurons) of the neural network, resulting in an output prediction (e.g., a binary classification of predicted compliance and/or a probability of compliance). The training system 125 may then generate a loss based on the predicted compliance and the ground truth, and refine the model using backpropagation.

[0042] In embodiments, the compliance prediction model 130 is trained to output a predicted compliance measure. The measure may generally include or correspond to a variety of data, depending on the particular implementation. For example, in some embodiments, the predicted compliance measure indicates a probability or likelihood that the user will satisfy the one or more compliance criteria/become compliant once they begin respiratory therapy (during the initial stage). In some embodiments, the measure may additionally or alternatively indicate a binary prediction (e.g., compliant or non-compliant) or other categorical prediction.

[0043] In some embodiments, the training system 125 may train multiple compliance prediction models 130 based on multiple sets of compliance criteria, such as if each locale, region, country, or other logical partition of users rely on different compliance criteria. That is, the training system 125 may label the sleep diagnostic records 115 using different labels based on the different compliance criteria for each locale, training a respective compliance prediction model 130 using the labels generated for a respective locale.

[0044] In some embodiments, the training system 125 may use a variety of data augmentation techniques to enhance the training data prior to training the compliance prediction model 130. For example, if there is a class imbalance in the data (e.g., more training records for compliant patients, as compared to records for non-compliant patients), the training system 125 may improve model accuracy by balancing the classes. For example, in some embodiments, the training system 125 may identify the subset of the sleep diagnostic records 115 that correspond to non-compliant users (e.g., users that did not satisfy the compliance criteria), and generate a plurality of synthetic sleep diagnostic records/data based on these.

[0045] For example, the training system 125 may apply one or more upsampling techniques to the subset of non-compliant records to generate additional exemplars. In at least one embodiment, the training system 125 can use a synthetic minority oversampling technique (SMOTE) approach to generate new instances of non-compliant training records. The training system 125 may then train the compliance prediction model 130 using the real data as well as the generated/synthetic data.

[0046] As another example, the training system 125 may identify the subset of the sleep diagnostic records 115 that correspond to compliant users (e.g., users that did satisfy the compliance criteria), and ignore one or more of these sleep diagnostic records when training. For example, the training system 125 may apply one or more downsampling techniques to the subset of compliant records, such as trimming, pruning, deleting, or otherwise removing a portion of the subset of the compliant records. The training system 125 may then refrain from training the compliance prediction model 130 using this pruned subset of data.

[0047] In an embodiment, after the model is trained, it may be deployed for inferencing by one or more systems. In some embodiments, the training system 125 may itself deploy the model for inferencing locally. That is, the training system 125 may instantiate an instance of the compliance prediction model 130 locally, and use it to predict compliance based on new sleep diagnostic data 110. In some embodiments, the model may be deployed to one or more inferencing systems (separate from the training system 125), as discussed in more detail below.

Example Workflow to use Machine Learning to Predict Therapy Compliance and Improve Therapy Enrollment

[0048] FIG. 2 depicts an example workflow 200 to use machine learning to predict therapy compliance and improve therapy enrollment, according to one embodiment of the present disclosure. [0049] In the illustrated workflow 200, a prediction system 215 accesses a compliance prediction model 220 and uses it to process sleep diagnostic data 210 (provided by sleep test components 205) to generate predicted compliance 225. In some embodiments, the prediction system 215 corresponds to or is the same as the training system (e.g., the training system 125 of FIG. 1) that trains the compliance prediction model 220. In some embodiments, the compliance prediction model 220 corresponds to the compliance prediction model 130 of FIG. 1.

[0050] Generally, the sleep test components 205 correspond to equipment or devices used to perform sleep tests, such as to detect sleep apnea. For example, the sleep test component 205 may include or use a variety of sensors to detect, collect, or generate the sleep diagnostic data 210 for a user while they sleep. In some embodiments, the sleep test components 205 may be the same type and/or model of the sleep test components 105 of FIG. 1, and generally serve the same or a similar purpose. In some embodiments, the sleep diagnostic data 210 may include the same or similar data to the sleep diagnostic data 110 of FIG. 1.

[0051] The specific data collected may vary depending on the particular implementation, and may include information such as respiratory effort, pulse, oxygen saturation, nasal flow, snoring, and the like. In some embodiments, the sleep diagnostic data 210 includes information such as the apnea-hypopnea index (AHI) of the user (determined/generated based on the sleep test), the percentage of the night (during the sleep test) that the user spent partially or entirely upright (e.g., standing, sitting, propped up, or otherwise not laying supine or on their side) during the test, the obstructive apnea index (OAI) generated based on the test, the central apnea index (CAI) generated based on the test, blood oxygen saturation information (e.g., the maximum, average, or minimum saturation) collected during the test, pulse information (e.g., the maximum, average, or minimum pulse) collected during the test, breath rate information (e.g., the maximum, average, or minimum breaths per unit of time) collected during the test, and the like.

[0052] In some embodiments, a user may request or be provided with the sleep test component 205 (e.g., at the request of a physician or sleep consultant) to perform a sleep test, which may allow the user and/or care provider to determine whether the user has apnea and/or could benefit from respiratory therapy. In some embodiments, the sleep tests may be performed in the user’s home, at a sleep lab, and the like. In some embodiments, the sleep test of a given user may occur over a single night. That is, the sleep diagnostic data 210 may include data from a single test/single night of sleep.

[0053] In the illustrated example, the prediction system 215 also accesses the compliance prediction model 220. As discussed above, the compliance prediction model 220 may generally correspond to a machine learning model that has been trained to predict patient compliance with respiratory therapy based at least in part on sleep diagnostic data. For example, in some aspects, the compliance prediction model 220 may additionally use, as input, data such as the age of the user.

[0054] Although the illustrated example depicts the prediction system 215 accessing sleep diagnostic data 210 and compliance prediction model 220 from one or more remote sources), in some embodiments, some or all of the data may be stored locally by the prediction system 215. The prediction system 215 may generally be implemented using hardware, software, or a combination of hardware and software. Additionally, though depicted as a discrete system for conceptual clarity, in some embodiments, the prediction system 215 may be implemented as a component of a larger system.

[0055] In the illustrated example, the prediction system 215 can process the sleep diagnostic data 210 using the compliance prediction model to generate predicted compliance 225 of the user. In some embodiments, as discussed above, various models may be trained for various locales or regions (e.g., based on local definitions of respiratory therapy compliance). In some such embodiments, the prediction system 215 may select and use an appropriate compliance prediction model 220 based on the locale, region, or set of compliance rules that are applicable to the specific user.

[0056] Generally, the predicted compliance 225 is a measure indicating whether the user will satisfy defined compliance criteria. For example, the predicted compliance 225 may comprise a categorical classification (e.g., a binary classification of “predicted to be compliant” or “predicted to be noncompliant”). In some embodiments, the predicted compliance 225 additionally or alternatively includes one or more continuous values (e.g., between zero and one) indicating the probability that the user will be compliant (e.g., the likelihood they will satisfy the criteria), the confidence of the model, and the like. [0057] In some aspects, the compliance prediction model 220 itself outputs a binary or categorical prediction. In some aspects, the compliance prediction model 220 generates a compliance probability, which the prediction system 215 evaluate to generate a binary or categorical classification. For example, the prediction system 215 may classify or predict that the user will be compliant if the predicted probability meets or exceeds a threshold.

[0058] In the illustrated example, the prediction system 215 provides the predicted compliance 225 to a competency system 230. Although the illustrated example depicts the prediction system 215 as a discrete entity separate from the competency system 230, in some embodiments, some or all of the operations of the competency system 230 may be implemented or performed by the prediction system 215 (and vice versa). The competency system 230 may generally be implemented using hardware, software, or a combination of hardware and software. Additionally, though depicted as a discrete system for conceptual clarity, in some embodiments, the competency system 230 may be implemented as a component of a larger system.

[0059] In some aspects, the competency system 230 evaluates the predicted compliance 225 to generate a suggested or recommended setup class 235 for the user. For example, as discussed above, the setup class 235 may include one or more classes for in-person or face-to-face setup/instruction, one or more classes for remote or distance setup/instruction (e.g., using video chat), one or more classes for virtual or asynchronous setup/instruction (e.g., using prerecorded material), and the like. Generally, the selected or suggested setup class 235 may be used to facilitate the beginning of respiratory therapy for the user (referred to in some aspects as therapy inception, initiation, enrollment, and the like).

[0060] In some embodiments, the setup class 235 may be used to automatically initiate the therapy based on the class (without user intervention). In some aspects, the setup class 235 may output to a user (e.g., a healthcare provider), and upon receiving approval or acceptance, the therapy may be initiated based on the setup class. Generally, the setup class 235 can trigger or indicate a wide variety of operations to begin therapy. That is, facilitating the initiation may include a number of operations depending on the class. For example, in the case of a virtual or asynchronous class, facilitating inception of the therapy may include initiating shipment of a respiratory therapy device directly to the user associated with the sleep diagnostic data 210 (e.g., to the home of the user), such that they can begin enrollment on their own. As another example, in the case of an in-person setup class, facilitating inception of the therapy may include initiating shipment of a respiratory therapy device to a healthcare provider associated with the user (e.g., to the offices of the user’s doctor), such that the user can schedule or attend in-person training and receive their therapy device in the provider’s office. In some aspects, facilitating inception of the therapy may include facilitating (in-person) setup of the therapy device by the user’s healthcare provider. For example, if the healthcare provider (e.g., doctor) maintains an inventory of therapy devices (e.g., one need not be shipped to the provider), then facilitating therapy inception may include instructing or suggesting that the healthcare provider initiate or schedule in-person setup, such that the healthcare provider can setup, configure, or otherwise prepare the therapy device (in conjunction with the user) for use.

[0061] In some aspects, as discussed in more detail below, the competency system 230 may evaluate the predicted compliance 225 using one or more dynamic or configurable thresholds or parameters (referred to in some aspects as enrollment parameters) to determine the setup class 235. For example, each specific healthcare provider may indicate a desired threshold and/or a preferred percentage or proportion of users to be assigned to each class (e.g., indicating that the provider prefers half of the users be assigned to a virtual setup class and half to an in-person class, indicating preference that 10% of users be assigned to a virtual setup class and the remaining 90% to in- person classes, and the like).

[0062] In some such aspects, to determine or generate the setup class 235 for a given user, the competency system 230 may determine whether the predicted compliance 225 (e.g., the probability of compliance) meets the corresponding threshold. For example, if the enrollment criteria specifies that half of users should be assigned to virtual setup, the competency system 230 may determine the corresponding probability threshold (e.g., 0.5), and compare the predicted compliance 225 with this threshold. In some aspects, the specific probability thresholds may be determined or specified by the training system or another system.

[0063] That is, after the compliance prediction model 220 is trained, test or validation data may be processed to generate predicted compliance measures, and the training system (or another system) may determine or generate a distribution of probability scores. This allows the competency system 230 to readily determine which score threshold to use for a given preferred proportion of users. For example, if the mean score is 0.5, the threshold should be set to 0.5 if the preferred proportion is 50%. If a score of 0.7 is the 90^th percentile, the competency system 230 may determine that a threshold of 0.7 should be used if the healthcare provider indicates that only 10% of users should be assigned to the virtual setup class. That is, only users with a probability of compliance that meets or exceeds the relevant threshold (e.g., with the top 10% of compliance likelihood) will be considered sufficiently likely to be compliant such that they should be assigned to the virtual setup class.

[0064] By adjusting this preferred proportion, healthcare providers can dynamically tune their allocations and ensure desired results are met. For example, more digitized or online-based providers may prefer larger proportions to be assigned to virtual setup, while providers that are more focused on in-person care may prefer smaller proportions to be assigned to virtual setup. In some aspects, as discussed above, if actual compliance is more likely when in-person setup is used, the preferred proportion may have an impact on the actual compliance ratios achieved. For example, using a lower proportion may result in fewer patients receiving virtual setup (and therefore resulting in improved overall compliance).

[0065] In some embodiments, in addition to or instead of evaluating the predicted compliance 225 itself, the competency system 230 may implement or facilitate a technical competency screening for users to determine or predict whether the user is capable of self-setup (e.g., asynchronous or virtual setup without assistance from a healthcare provider). For example, if a user is assigned (or will likely be assigned) to the virtual class, the competency system 230 may first determine whether the user is sufficiently likely to be able to successfully complete virtual enrollment using one or more technology screening operations. Generally, the competency screening can include a variety of operations, including evaluating the sleep diagnostic data 210, predicted compliance 225, and/or other data (such as the user’s age, locale, ability to access the Internet, and the like) using one or more static rules and/or trained machine learning models. For example, if the competency system 230 determines that the user owns one or more Internet- connected devices and has access to high speed Internet (e.g., sufficiently fast for video streaming), the competency system 230 may determine the user is likely competent. In some aspects, the competency system 230 may additionally consider data such as whether the user has a physical mailing address and/or is capable of receiving mail (to ship the therapy equipment and/or enrollment materials, such as pamphlets, videos and/or audio (e.g., recorded to CDs, DVDs, flash drives, or other memory devices), and the like).

[0066] In some aspects, the competency screening may additionally or alternatively include one or more tests or screeners provided to the user directly. For example, the user may be asked to read a brief textual excerpt, watch a brief video, and/or listen to a brief audio recording. The user can then be asked to respond to one or more questions in order to evaluate the user’s ability to learn from asynchronous content.

[0067] In some aspects, if a user that would otherwise be assigned to virtual setup class does not satisfy the technical competency criteria, the competency system 230 may instead assign the user to an in-person class (despite their high probability of compliance).

[0068] Although not included in the illustrated example, in some embodiments, the prediction system 215, competency system 230, and or training system that trained the compliance prediction model 220 may optionally be configured to receive and evaluate feedback to improve model performance. In some embodiments, subsequent to therapy enrollment for a given user, the training system may determine (or be informed) whether the user became compliant (e.g., satisfied the one or more compliance criteria within a defined window of therapy start), whether the user requested or required additional assistance during enrollment or inception of the therapy, and the like. For example, the training system may generate a new training record including the sleep diagnostic data 210 of the user, and an accompanying label generated based on whether the user became compliant.

[0069] In some embodiments, regardless of whether the user became compliant, the competency system 230 may evaluate whether the user requested or needed additional assistance during enrollment (or in the early stages of the therapy). For example, if regardless of whether the user was assigned to an in-person class or a virtual class, if the user requested assistance (e.g., additional phone calls, emails, or in-person visits to the healthcare provider or another assistanceproviding entity) or otherwise had additional questions about how to operate the equipment, the competency system 230 may determine that the user may have been a poor fit for virtual enrollment. Based on this determination, the competency system 230 may refine its thresholds, rules, or other criteria to increase the probability that similar users are assigned to the in-person class in the future. Similarly, if the user participated in virtual enrollment and did not require any additional assistance, the competency system 230 may refine its thresholds, rules, or other criteria to increase the probability that similar users are assigned to the virtual class in the future.

Example Method for Training Compliance Prediction Machine Learning Models

[0070] FIG. 3 is a flow diagram depicting an example method 300 for training compliance prediction machine learning models, according to one embodiment of the present disclosure. In some embodiments, the method 300 is performed by a training system, such as the training system 125 of FIG. 1. In some aspects, the method 300 provides additional detail for the workflow 100 of FIG. 1

[0071] At block 305, the training system accesses a set of sleep diagnostic records for training a machine learning model (e.g., a compliance prediction model). For example, the training system may access data such as sleep diagnostic records 115 of FIG. 1. As discussed above, the sleep diagnostic records may generally include, for each user of a set of users that participated in a sleep test and/or began respiratory therapy, an AHI of the user, the percentage of the night (during the sleep test) that the user spent partially or entirely upright, the OAI and/or CAI of the user, blood oxygen saturation information of the user collected during the sleep test, pulse information collected during the test, breath rate information collected during the test, and the like. In some embodiments, the sleep diagnostic records may include other information, such as the age of the corresponding user (when the sleep test was conducted) or other demographics of the user (e.g., their height, weight, sex, and the like).

[0072] At block 310, the training system optionally preprocesses the diagnostic records to prepare them for input to a machine learning model. For example, depending on the particular implementation, the training system may generate or extract feature information. As one example, if the sleep diagnostic records include raw data such as the blood oxygen saturation at multiple points during the test, the training system may determine the average blood oxygen saturation (or some other quantity).

[0073] In some embodiments, at block 310, the training system may use a variety of data augmentation techniques to enhance the training data prior to training the compliance prediction model. For example, if there is a class imbalance in the data (e.g., more training records for compliant patients, as compared to records for non-compliant patients), the training system may use upsampling and/downsampling to balance the classes. As an example, the training system may generate additional synthetic non-compliant exemplars based on the existing exemplars (to train the models based on real and synthetic data), and/or may remove or cull one or more compliant exemplars (to refrain from training the model based on the pruned exemplars).

[0074] At block 315, the training system selects one of the diagnostic records to train the model. Generally, the training system may select the diagnostic record using a variety of criteria and techniques, including randomly or pseudo-randomly, as all of the diagnostic records will be evaluated during the method 300.

[0075] At block 320, the training system determines user compliance with respect to the selected diagnostic record. That is, the training system can identify the user associated with the selected record (e.g., the user that participated in the sleep test from which the sleep diagnostic record was generated), and determine whether the user became compliant in a respiratory therapy. In some embodiments, the training system can determine the user’s therapy usage information (e.g., the number of hours that the user used the therapy equipment per day, the number of days per week that the user used the therapy equipment, and the like). The training system can then compare this usage information against one or more criteria (e.g., minimum usage criteria) to determine compliance. In some aspects, rather than evaluating usage data directly, the training system can determine whether one or more other systems have already classified the user as compliant or non-compliant.

[0076] In some aspects, determining whether the user was compliant includes determining whether the user was deemed compliant within a defined time of when they began therapy (e.g., within 90 days), rather than whether they are currently compliant or remained compliant longterm. That is, because which setup class the user is assigned to may affect short-term compliance (e.g., during inception of the therapy) but may be irrelevant to long-term compliance, the training system may only consider such short-term compliance when generating the label for the sleep diagnostic record.

[0077] At block 325, the training system trains one or more machine learning models based on the selected diagnostic record. Generally, the particular techniques used to train the model(s) may vary depending on the particular architecture and implementation. For example, in some aspects, the training system may process the diagnostic data using a machine learning model to generate an output prediction (e.g., a binary classification of predicted compliance and/or a probability of compliance). The training system may then generate a loss based on the predicted compliance and the ground truth compliance (determined at block 320), and refine the model parameters (e.g., weights and/or biases) based on the loss using gradient descent.

[0078] In some embodiments, as discussed above, the training system may train multiple machine learning models (e.g., one for each locale, and/or one for each of a variety of compliance criteria). In some such embodiments, at block 320, the training system may determine multiple compliance labels based on the variety of locales or compliance rules, as discussed above.

[0079] At block 330, the training system determines whether one or more termination criteria are met. Generally, evaluating the termination criteria can include a wide variety of operations, such as determining whether additional training data remains, determining whether additional epochs or rounds of training remain, determining whether the model has reached a desired accuracy, determining whether a defined amount of time or computational resources have been spent training the model, and the like.

[0080] If, at block 330, the training system determines that the criteria are not met, the method 300 returns to block 315 to select another record. If the training system determines that the criteria are met, the method 300 continues to block 335. Although the illustrated example depicts the training system refining the model based on each diagnostic record individually (e.g., using stochastic gradient descent) for conceptual clarity, in some aspects, the training system may additionally or alternatively refine the model using a set of diagnostic records (e.g., using batch gradient descent).

[0081] At block 335, the training system deploys the machine learning model to one or more inferencing systems. As discussed above, deploying the model may include a variety of operations depending on the particular implementation, including initiating the trained model locally for inferencing, transmitting the model artefacts to one or more dedicated inferencing systems (separate from the training system), and the like.

Example Method for Using Machine Learning to Predict Therapy Compliance and Improve Therapy Enrollment [0082] FIG. 4 is a flow diagram depicting an example method 400 for using machine learning to predict therapy compliance and improve therapy enrollment, according to one embodiment of the present disclosure. In some embodiments, the method 400 is performed by a prediction system and/or a competency system (which may be collectively referred to as an inferencing system), such as the prediction system 215 and/or competency system 230, each of FIG. 2. In some aspects, the method 400 provides additional detail for the workflow 200 of FIG. 2.

[0083] At block 405, the inferencing system accesses sleep diagnostic data for processing using a machine learning model (e.g., a compliance prediction model). For example, the inferencing system may access data such as sleep diagnostic data 210 of FIG. 2. As discussed above, the sleep diagnostic data may generally include, for a user that participated in a sleep test and/or that desires to begin respiratory therapy, an AHI of the user, the percentage of the night (during the sleep test) that the user spent partially or entirely upright, the OAI and/or CAI of the user, blood oxygen saturation information of the user collected during the sleep test, pulse information collected during the test, breath rate information collected during the test, and the like. In some embodiments, the sleep diagnostic data may include other information, such as the age of the user (when the sleep test was conducted) or other demographics of the user (e.g., their height, weight, sex, and the like).

[0084] In some aspects, the inferencing system accesses the sleep diagnostic data in response to determining that the user is beginning respiratory therapy (e.g., in response to determining that a healthcare provider as prescribed or recommended respiratory therapy based on the sleep diagnostic data, and/or in response to determining that the user has accepted or expressed intent to begin such therapy).

[0085] At block 410, the inferencing system generates a predicted compliance measure (e.g., predicted compliance 225 of FIG. 2) by processing the sleep diagnostic data of the user using a trained machine learning model. As discussed above, the predicted compliance measure may generally include a categorical prediction, a probability or likelihood prediction, and the like. In some embodiments, the predicted compliance measure generally indicates the predicted probability or likelihood that the user will become compliant with a respiratory therapy. In some embodiments, as discussed above, the compliance measure may specifically indicate whether the user is predicted to be compliant in the short-term (e.g., during a 90 day window after therapy inception).

[0086] At block 415, the inferencing system determines one or more enrollment criteria for the user. In some aspects, as discussed above, healthcare providers may specify or configure provider-specific enrollment criteria, such as a preferred proportion of users to be assigned to a specific setup class (e.g., to the virtual setup class). In one such embodiment, at block 415, the inferencing system determines the enrollment criteria that are applicable to the specific user (associated with the sleep diagnostic data) based on the healthcare provider with which they are associated.

[0087] At block 420, the inferencing system determines whether the predicted compliance measure satisfies the enrollment criteria. For example, as discussed above, the inferencing system may determine the percentile of the predicted compliance measure (e.g., whether it is in the tenth percentile, the fiftieth percentile, the ninetieth percentile, and the like). As discussed above, in some aspects, the mapping between percentiles and specific probability scores may be determined by processing test data using the model. The inferencing system can then determine whether the predicted compliance measure of the user satisfies the enrollment criteria.

[0088] If, at block 420, the inferencing system determines that the enrollment criteria are not specified, the method 400 continues to block 425, where the inferencing system assigns the user to an in-person setup class (e.g., allocates the user to the assigned in-person setup class). That is, if the inferencing system determines that the user is not sufficiently likely to meet short-term compliance, the inferencing system may determine that the user would be better served by in- person instruction. The method 400 then continues to block 440.

[0089] If, at block 420, the inferencing system determines that the enrollment criteria are specified, the method 400 continues to block 430, where the inferencing system determines whether one or more competency criteria are met. That is, if the inferencing system determines that the user is sufficiently likely to meet short-term compliance, the inferencing system may determine to further evaluate the user’s competency.

[0090] At block 430, the inferencing system determines whether one or more competency criteria are satisfied. As discussed above, evaluating the competency criteria can generally include 1 a variety of operations, such as determining whether the user has indicated a preference or openness to virtual setup, whether the user has computing resources to accomplish virtual setup (e.g., a sufficiently fast network connection, or a device capable of playing or displaying the enrollment materials if they are sent via physical mail), whether the user is capable of learning and engaging with asynchronous instruction, and the like.

[0091] If, at block 430, the inferencing system determines that the competency criteria are not met, the method 400 continues to block 425, where the inferencing system assigns the user to the in-person setup class. If, at block 430, the inferencing system determines that the competency criteria are satisfied, the method 400 continues to block 435.

[0092] At block 435, the inferencing system assigns the user to the virtual setup class (e.g., allocates the user to the assigned virtual setup class). That is, if the inferencing system determines that the user is sufficiently likely to meet short-term compliance, the inferencing system may determine that the user would be well served by virtual or asynchronous instruction. The method 400 then continues to block 440.

[0093] At block 440, the inferencing system facilitates user enrollment in a respiratory therapy (e.g., prescribed by a healthcare provider) based on the assigned setup class. As discussed above, facilitating enrollment can include a wide variety of operations (which may include automated operations performed without user intervention and/or operations performed in response to receiving user approval) depending on the particular implementation.

[0094] For example, for an in-person setup class, the inferencing system may initiate shipment of the prescribed or recommended respiratory therapy equipment to the healthcare provider of the user (e.g., to their offices). As another example, for in-person setup, the inferencing system may evaluate various data such as the estimated delivery date of the equipment, the user’s schedule (if accessible) and/or the healthcare provider’s schedule to propose or schedule a date and time for the in-person instruction to occur. As another example, for a virtual setup class, the inferencing system may initiate shipment of various items to the home or physical address of the user. For example, the inferencing system may initiate shipment of the prescribed or recommended equipment, shipment of instructional material (such as pamphlets, CDs, DVDs, flash drives, and the like), and the like. Example Method for Refining Machine Learning Models based on User Feedback

[0095] FIG. 5 is a flow diagram depicting an example method 500 for refining machine learning models based on user feedback, according to one embodiment of the present disclosure. In some embodiments, the method 500 is performed by a training system, such as the training system 125 of FIG. 1, and/or by a prediction system and/or a competency system, such as the prediction system 215 and/or competency system 230, each of FIG. 2.

[0096] At block 505, the system receives enrollment feedback relating to a user that enrolled in respiratory therapy. In some embodiments, the feedback may be generated automatically or manually after a defined event or window has passed, such as a defined period of time (e.g., 90 days from when respiratory therapy began and/or when the user completed setup). In some embodiments, the feedback can include information such as whether the user met the compliance criteria with the window, whether the user requested additional assistance or input during the window, and the like.

[0097] At block 510, the system determines the setup class of the user. That is, the system can determine which setup class the user associated with the feedback was assigned to (e.g., whether they engaged in virtual/asynchronous setup or in-person setup).

[0098] At block 515, the system determines the assistance requests of the user (as indicated in the feedback), such as the number of such requests (e.g., the number of phone calls or messages asking for assistance or information), the timing of such requests (e.g., whether they occurred shortly after the setup completed, or in the middle of the window of time), and the like.

[0099] At block 520, the system determines the compliance of the user (as indicated in the feedback), such as by evaluating usage information of the user based on one or more compliance criteria and/or determining whether the user has been marked or indicated as compliant.

[0100] At block 525, the system can then refine one or more models or rules based on the feedback. For example, as discussed above, the training system may refine the compliance prediction model(s) based on the determination as to whether the user has been deemed compliant. As another example, as discussed above, the competency system may refine its rules or thresholds based on the evaluation of the assistance requests of the user. [0101] In this way, the model(s) and rule(s) used to assign users to setup classes can be dynamically refined and improved over time (e.g., periodically, such as monthly). This can further improve the accuracy and reliability of the predictions, and the performance of the computing systems.

Example Method for Using Machine Learning Models to Predict Therapy Compliance

[0102] FIG. 6 is a flow diagram depicting an example method 600 for using machine learning to predict therapy compliance, according to one embodiment of the present disclosure. In some embodiments, the method 600 is performed by a prediction system and/or a competency system (which may be collectively referred to as an inferencing system), such as the prediction system 215 and/or competency system 230, each of FIG. 2.

[0103] At block 605, sleep diagnostic data (e.g. , sleep diagnostic data 210 of FIG. 2) for a user is accessed.

[0104] At block 610, a predicted compliance measure (e.g., predicted compliance 225 of FIG. 2) is generated based on processing the sleep diagnostic data using a machine learning model (e.g., compliance prediction model 220 of FIG. 2), wherein the predicted compliance measure indicates a likelihood that the user will satisfy one or more compliance criteria for a respiratory therapy.

[0105] At block 615, the user is allocated to an assigned setup class (e.g., setup class 235 of FIG. 2) based on evaluating the predicted compliance measure using one or more enrollment criteria, wherein the assigned setup class is either a virtual setup class or an in-person setup class.

[0106] At block 620, inception of the respiratory therapy for the user is facilitated based on the assigned setup class.

Example Method for Training Machine Learning Models to Predict Therapy Compliance

[0107] FIG. 7 is a flow diagram depicting an example method 700 for training machine learning models to predict therapy compliance, according to one embodiment of the present disclosure. In some embodiments, the method 700 is performed by a training system, such as the training system 125 of FIG. 1.

[0108] At block 705, sleep diagnostic data (e.g. , sleep diagnostic data 110 of FIG. 1) for a user is accessed. [0109] At block 710, it is determined whether the user satisfied a set of compliance criteria for a respiratory therapy (e.g., based on compliance records 120 of FIG. 1).

[0110] At block 715, a machine learning model (e.g., compliance prediction model 130 of FIG. 1) is trained to predict therapy compliance based at least in part on the sleep diagnostic data for the user and the determination whether the user satisfied the set of compliance criteria.

[0111] At block 720, the machine learning model is deployed to generate predicted compliance measures indicating likelihoods that users will satisfy the set of compliance criteria for respiratory therapy.

Example Computing Device for Compliance Prediction using Machine Learning

[0112] FIG. 8 depicts an example computing device 800 configured to perform various aspects of the present disclosure. Although depicted as a physical device, in embodiments, the computing device 800 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 800 corresponds to or implements the training system 125 of FIG. 1, the prediction system 215 of FIG. 2, and/or the competency system 230 of FIG. 2.

[0113] As illustrated, the computing device 800 includes a CPU 805, memory 810, a network interface 825, and one or more I/O interfaces 820. Though not included in the depicted example, in some embodiments, the computing device 800 also includes one or more storages. In the illustrated embodiment, the CPU 805 retrieves and executes programming instructions stored in memory 810, as well as stores and retrieves application data residing in memory 810 and/or storage (not depicted). The CPU 805 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 810 is generally included to be representative of a random access memory. In an embodiment, if storage is present, it may include 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).

[0114] In some embodiments, I/O devices 835 (such as keyboards, monitors, etc.) are connected via the I/O interface(s) 820. Further, via the network interface 825, the computing device 800 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 805, memory 810, network interface(s) 825, and I/O interface(s) 820 are communicatively coupled by one or more buses 830.

[0115] In the illustrated embodiment, the memory 810 includes a preprocessing component 850, a training component 855, a prediction component 860, a competency component 865, and an enrollment component 870, 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 810, in embodiments, the operations of the depicted components (and others not illustrated) may be implemented using hardware, software, or a combination of hardware and software.

[0116] For example, the preprocessing component 850 may be used to perform a variety of preprocessing operations on data used as input to machine learning models, such a feature extraction, upsampling and/or downsampling to balance class imbalances, and the like. The training component 855 may generally be used to train machine learning models (such as the compliance model 890) to predict short-term user compliance with respiratory therapy, as discussed above. The prediction component 860 may generally be used to use trained models (such as the compliance model 890) to predict patient compliance based on diagnostic data, as discussed above. The competency component 865 may generally be used to evaluate predictions and other data to assign users to setup classes (e.g., based on enrollment thresholds 885, user technical competency, and the like), as discussed above. The enrollment component 870 may generally be used to facilitate enrollment, initiation, or inception of users in respiratory therapy based on assigned setup classes (e.g., by initiating shipment of therapy equipment and materials to the user’s home or to a doctor’s office, or otherwise facilitating device setup), as discussed above.

[0117] In the illustrated example, the storage 815 includes sleep diagnostic records 875, compliance data 880, enrollment thresholds 885, and compliance model 890. Although depicted as residing in storage 815, the depicted components may be stored in any suitable location. The sleep diagnostic records 875 (which may correspond to the sleep diagnostic records 115 of FIG. 1 and/or the sleep diagnostic data 210 of FIG. 1) generally include data relating sleep diagnostic tests performed by users, such as AHI, breathing rates, and the like. The sleep diagnostic records 875 may be used (e.g., by training component 855) to train models (e.g., compliance model 890) and/or by other components (e.g., by prediction component 860) to predict compliance.

[0118] The compliance data 880 (which may correspond to compliance records 120 of FIG. 1) may generally include therapy usage information indicating whether each user reflected in the sleep diagnostic records 875 was compliant with therapy. The compliance data 880 may be used (e.g., by training component 855) as a label or target output to train the models. The enrollment thresholds 885 may generally include information such as healthcare provider-specific preferred proportions of users to assign to each setup class, as discussed above. The compliance model 890 (which may correspond to the compliance prediction model 130 of FIG. 1 and/or the compliance prediction model 220 of FIG. 2) may be trained and used to generate predicted therapy compliance measures, as discussed above.

Example Clauses

[0119] Clause 1 : A method, comprising: accessing sleep diagnostic data for a user; generating a predicted compliance measure based on processing the sleep diagnostic data using a machine learning model, wherein the predicted compliance measure indicates a likelihood that the user will satisfy one or more compliance criteria for a respiratory therapy; allocating the user to an assigned setup class based on evaluating the predicted compliance measure using one or more enrollment criteria, wherein the assigned setup class is either a virtual setup class or an in-person setup class; and facilitating inception of the respiratory therapy for the user based on the assigned setup class.

[0120] Clause 2: The method of Clause 1, wherein the sleep diagnostic data was collected based on a sleep test performed by the user, and comprises at least one of: (i) an age of the user, (ii) an apnea-hypopnea index (AHI) generated based on the sleep test, or (iii) a percentage of time the user spent in an upright position during the sleep test.

[0121] Clause 3: The method of any one of Clauses 1-2, wherein the sleep diagnostic data further comprises at least one of: (i) an obstructive apnea index (OAI) generated based on the sleep test, (ii) a central apnea index (CAI) generated based on the sleep test, (iii) blood oxygen saturation information collected during the sleep test, (iv) pulse information collected during the sleep test, or (v) breath rate information collected during the sleep test. [0122] Clause 4: The method of any one of Clauses 1-3, wherein the one or more compliance criteria comprise a minimum usage of a respiratory therapy device during a window of time after inception of respiratory therapy.

[0123] Clause 5: The method of any one of Clauses 1-4, wherein the one or more enrollment criteria comprise a preferred proportion of users to be assigned to the virtual setup class.

[0124] Clause 6: The method of any one of Clauses 1-5, wherein the one or more enrollment criteria comprise one or more technical competency criteria used to predict whether the user is capable of self-setup of the respiratory therapy.

[0125] Clause 7: The method of any one of Clauses 1-6, wherein facilitating the inception of the respiratory therapy comprises initiating shipment of a respiratory therapy device to the user based at least in part on determining that the assigned setup class is the virtual setup class.

[0126] Clause 8: The method of any one of Clauses 1-6, wherein facilitating the inception of the respiratory therapy comprises facilitating setup of a respiratory therapy device by a healthcare provider of the user based at least in part on determining that the assigned setup class is the in- person setup class.

[0127] Clause 9: The method of any one of Clauses 1-8, further comprising: receiving feedback relating to the respiratory therapy for the user, wherein the feedback comprises at least one of: an indication of whether the user satisfied the one or more compliance criteria, or an indication of whether the user requested assistance during inception of the respiratory therapy; and refining the machine learning model based on the feedback.

[0128] Clause 10: A method, comprising: accessing sleep diagnostic data for a user; determining whether the user satisfied a set of compliance criteria for a respiratory therapy; training a machine learning model to predict therapy compliance based at least in part on the sleep diagnostic data for the user and the determination whether the user satisfied the set of compliance criteria; and deploying the machine learning model to generate predicted compliance measures indicating likelihoods that users will satisfy the set of compliance criteria for respiratory therapy.

[0129] Clause 11 : The method of Clause 10, wherein the sleep diagnostic data was collected based on a sleep test performed by the user, and comprises at least one of: (i) an age of the user, (ii) an apnea-hypopnea index (AHI) generated based on the sleep test, or (iii) a percentage of time the user spent in an upright position during the sleep test.

[0130] Clause 12: The method of any one of Clauses 10-11, wherein the sleep diagnostic data further comprises at least one of: (i) an obstructive apnea index (OAI) generated based on the sleep test, (ii) a central apnea index (CAI) generated based on the sleep test, (iii) blood oxygen saturation information collected during the sleep test, (iv) pulse information collected during the sleep test, or (v) breath rate information collected during the sleep test.

[0131] Clause 13: The method of any one of Clauses 10-12, wherein: the machine learning model is a first machine learning model of a plurality of machine learning models, and the set of compliance criteria is a first set of compliance criteria of a plurality of sets of compliance criteria corresponding to a plurality of locales, the method further comprises training each respective machine learning model of the plurality of machine learning models based on a respective set of compliance criteria of the plurality of sets of compliance criteria corresponding to a respective locale of the plurality of locales.

[0132] Clause 14: The method of any one of Clauses 10-13, further comprising: accessing a plurality of sleep diagnostic records for a plurality of users; and training the machine learning model based further on at least a portion of the plurality of sleep diagnostic records.

[0133] Clause 15: The method of any one of Clauses 10-14, further comprising: identifying a subset of the plurality of sleep diagnostic records corresponding to users that did not satisfy the one or more compliance criteria; generating a plurality of synthetic sleep diagnostic records based on applying one or more upsampling techniques to the subset of the plurality of sleep diagnostic records; and training the machine learning model based further on the plurality of synthetic sleep diagnostic records.

[0134] Clause 16: The method of any one of Clauses 10-15, further comprising: identifying a subset of the plurality of sleep diagnostic records corresponding to users that satisfied the one or more compliance criteria; selecting a portion of the subset of the plurality of sleep diagnostic records based on applying one or more downsampling techniques; and refraining from training the machine learning model based on the subset of the plurality of sleep diagnostic records. [0135] Clause 17: 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 an operation in accordance with any one of Clauses 1-16.

[0136] Clause 18: A system, comprising means for performing a method in accordance with any one of Clauses 1-16.

[0137] Clause 19: 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-16.

[0138] Clause 20: 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-16.

Additional Considerations

[0139] 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 be embodied by one or more elements of a claim. [0140] 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.

[0141] 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).

[0142] As used herein, the term “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.

[0143] 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.

[0144] 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., storage, 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.

[0145] 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 (e.g., the computing device 800) or related data available in the cloud. For example, the computing device 800 could execute on a computing system in the cloud and train and/or use machine learning models to predict short-term compliance with respiratory therapy and/or assign users to setup classes. In such a case, the computing device 800 could train machine learning models, and store the trained models 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).

[0146] 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.

Claims

WHAT IS CLAIMED IS:

1. A method, comprising: accessing sleep diagnostic data for a user; generating a predicted compliance measure based on processing the sleep diagnostic data using a machine learning model, wherein the predicted compliance measure indicates a likelihood that the user will satisfy one or more compliance criteria for a respiratory therapy; allocating the user to an assigned setup class based on evaluating the predicted compliance measure using one or more enrollment criteria, wherein the assigned setup class is either a virtual setup class or an in-person setup class; and facilitating inception of the respiratory therapy for the user based on the assigned setup class.

2. The method of claim 1, wherein the sleep diagnostic data was collected based on a sleep test performed by the user, and comprises at least one of:

(i) an age of the user,

(ii) an apnea-hypopnea index (AHI) generated based on the sleep test, or

(iii) a percentage of time the user spent in an upright position during the sleep test.

3. The method of claim 2, wherein the sleep diagnostic data further comprises at least one of:

(i) an obstructive apnea index (OAI) generated based on the sleep test,

(ii) a central apnea index (CAI) generated based on the sleep test,

(iii) blood oxygen saturation information collected during the sleep test,

(iv) pulse information collected during the sleep test, or

(v) breath rate information collected during the sleep test.

4. The method of claim 1 , wherein the one or more compliance criteria comprise a minimum usage of a respiratory therapy device during a window of time after inception of respiratory therapy.

5. The method of claim 1, wherein the one or more enrollment criteria comprise a preferred proportion of users to be assigned to the virtual setup class.

6. The method of claim 1 , wherein the one or more enrollment criteria comprise one or more technical competency criteria used to predict whether the user is capable of self-setup of the respiratory therapy.

7. The method of claim 1, wherein facilitating the inception of the respiratory therapy comprises initiating shipment of a respiratory therapy device to the user based at least in part on determining that the assigned setup class is the virtual setup class.

8. The method of claim 1, wherein facilitating the inception of the respiratory therapy comprises facilitating setup of a respiratory therapy device by a healthcare provider of the user based at least in part on determining that the assigned setup class is the in-person setup class.

9. The method of claim 1, further comprising: receiving feedback relating to the respiratory therapy for the user, wherein the feedback comprises at least one of: an indication of whether the user satisfied the one or more compliance criteria, or an indication of whether the user requested assistance during inception of the respiratory therapy; and refining the machine learning model based on the feedback.

10. A method, comprising: accessing sleep diagnostic data for a user; determining whether the user satisfied a set of compliance criteria for a respiratory therapy; training a machine learning model to predict therapy compliance based at least in part on the sleep diagnostic data for the user and the determination whether the user satisfied the set of compliance criteria; and deploying the machine learning model to generate predicted compliance measures indicating likelihoods that users will satisfy the set of compliance criteria for respiratory therapy.

11. The method of claim 10, wherein the sleep diagnostic data was collected based on a sleep test performed by the user, and comprises at least one of:

(i) an age of the user,

(ii) an apnea-hypopnea index (AHI) generated based on the sleep test, or

(iii) a percentage of time the user spent in an upright position during the sleep test.

12. The method of claim 11, wherein the sleep diagnostic data further comprises at least one of:

(i) an obstructive apnea index (OAI) generated based on the sleep test,

(ii) a central apnea index (CAI) generated based on the sleep test,

(iii) blood oxygen saturation information collected during the sleep test,

(iv) pulse information collected during the sleep test, or

(v) breath rate information collected during the sleep test.

13. The method of claim 10, wherein: the machine learning model is a first machine learning model of a plurality of machine learning models, and the set of compliance criteria is a first set of compliance criteria of a plurality of sets of compliance criteria corresponding to a plurality of locales, the method further comprises training each respective machine learning model of the plurality of machine learning models based on a respective set of compliance criteria of the plurality of sets of compliance criteria corresponding to a respective locale of the plurality of locales.

14. The method of claim 10, further comprising: accessing a plurality of sleep diagnostic records for a plurality of users; and training the machine learning model based further on at least a portion of the plurality of sleep diagnostic records.

15. The method of claim 14, further comprising: identifying a subset of the plurality of sleep diagnostic records corresponding to users that did not satisfy the one or more compliance criteria; generating a plurality of synthetic sleep diagnostic records based on applying one or more upsampling techniques to the subset of the plurality of sleep diagnostic records; and training the machine learning model based further on the plurality of synthetic sleep diagnostic records.

16. The method of claim 14, further comprising: identifying a subset of the plurality of sleep diagnostic records corresponding to users that satisfied the one or more compliance criteria; selecting a portion of the subset of the plurality of sleep diagnostic records based on applying one or more downsampling techniques; and refraining from training the machine learning model based on the subset of the plurality of sleep diagnostic records.

17. A non-transitory computer-readable medium comprising computer-executable instructions that, when executed by one or more processors of a processing system, cause the processing system to perform an operation comprising: accessing sleep diagnostic data for a user; generating a predicted compliance measure based on processing the sleep diagnostic data using a machine learning model, wherein the predicted compliance measure indicates a likelihood that the user will satisfy one or more compliance criteria for a respiratory therapy; allocating the user to an assigned setup class based on evaluating the predicted compliance measure using one or more enrollment criteria, wherein the assigned setup class is either a virtual setup class or an in-person setup class; and facilitating inception of the respiratory therapy for the user based on the assigned setup class.

18. The non-transitory computer-readable medium of claim 17, wherein the one or more enrollment criteria comprise a preferred proportion of users to be assigned to the virtual setup class.

19. The non-transitory computer-readable medium of claim 17, wherein the one or more enrollment criteria comprise one or more technical competency criteria used to predict whether the user is capable of self-setup of the respiratory therapy.

20. The non-transitory computer-readable medium of claim 17, further comprising: receiving feedback relating to the respiratory therapy for the user, wherein the feedback comprises at least one of: an indication of whether the user satisfied the one or more compliance criteria, or an indication of whether the user requested assistance during inception of the respiratory therapy; and refining the machine learning model based on the feedback.