EP4652611A1

EP4652611A1 - Systems and methods for characterizing a user interface using flow generator data

Info

Publication number: EP4652611A1
Application number: EP24704902.6A
Authority: EP
Inventors: Roxana TIRON; Niall Andrew FOX; Jamal MOUSSA
Original assignee: Resmed Pty Ltd; Resmed Sensor Technologies Ltd
Current assignee: Resmed Pty Ltd; Resmed Sensor Technologies Ltd
Priority date: 2023-01-18
Filing date: 2024-01-18
Publication date: 2025-11-26
Also published as: WO2024154086A1; CN120641990A

Abstract

According to some implementations of the present disclosure, a method includes accessing flow generator data provided by a respiratory therapy system, the flow generator data comprising at least one of flow data, pressure data, or motor data. A probability measure is generated by processing the first flow generator data using a trained machine learning model, and a label indicating whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve is generated based on the probability measure at a time when the flow generator data was generated.

Description

SYSTEMS AND METHODS FOR CHARACTERIZING A USER INTERFACE USING FLOW GENERATOR DATA CROSS-REFERENCE TO RELATED APPLICATIONS [0001] This application claims priority to U.S. Provisional Patent Application No. 63/480,431, filed on January 18, 2023, the entire contents of which are incorporated herein by reference. TECHNICAL FIELD [0002] The present disclosure relates generally to systems and methods for using machine learning to characterize a user interface and/or an anti-asphyxia valve of the user interface, and more particularly, to systems and methods for using machine learning to characterize a user interface and/or an AAV of the user interface using based on flow generator data. BACKGROUND [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. For various reasons, such as ensuring the user is using the correct user interface, it can be beneficial for the respiratory system to know the specific category and type, and optionally specific model, of the user interface worn by the user. P2247WO1 (RSMD/0072PC) [0005] Thus, it is advantageous to know the user interface of a respiratory therapy system for providing improved control of therapy delivered to the user. For instance, it may be advantageous to know the user interface in order to accurately measure or estimate treatment parameters, such as pressure in the user interface and vent flow. Accordingly, knowledge of what user interface is being used can enhance therapy. Although some respiratory therapy devices may include a menu system that allows a user to manually enter the type of user interface being used (e.g., by type, model, manufacturer, etc.), the user may enter incorrect or incomplete information. As such, it may be advantageous to determine the user interface independently of user input. [0006] In addition, user interface cushions, vents on the user interface or on a connector to the user interface, and other user interface components can deteriorate over time. For example, vents can become blocked or occluded over time due to a buildup of unwanted material (e.g., saliva, mucus, skin cells, bedding fibers, debris from the user interface), or become temporarily/ transiently blocked or occluded (e.g., against bedding or a pillow). A deteriorated and/or occluded vent can cause the vent-flow performance of the user interface to deviate from the normal performance, which may impact therapy comfort or therapy accuracy. The deteriorated and/or the occluded vent can also lead to a buildup of CO₂, which in turn may result in inefficient therapy, additional noise, patient discomfort, or even danger to the user. Thus, when the vent is deteriorated or occluded, it can negatively impact therapy. As a result, some users will discontinue use of the respiratory therapy system because of the discomfort and/or inaccurate therapy caused by the deteriorated user interface components. As such, it may be advantageous to determine the user interface being used by a user so that the age of the user interface, when the user interface was last changed, etc. may be monitored and actions taken to avoid or remediate deteriorated user interfaces or user interface components. [0007] The present disclosure is directed to solving these and other problems. SUMMARY [0008] According to some implementations of the present disclosure, a method includes accessing first flow generator data provided by a respiratory therapy system, the first flow generator data comprising at least one of: (i) flow data, (ii) pressure data, or (iii) motor data; generating a first probability measure by processing the first flow generator data using a trained machine learning model; and generating, based on the first probability measure, a label P2247WO1 (RSMD/0072PC) indicating whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve at a time when the flow generator data was generated. [0009] According to some implementations of the present disclosure, a method includes accessing first flow generator data provided by a respiratory therapy system, the first flow generator data comprising at least one of: (i) flow data, (ii) pressure data, or (iii) motor data; determining whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve when the first flow generator data was collected; and training a machine learning model, based on the first flow generator data and the determination whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve, to predict presence of anti-asphyxia valves. [0010] 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. [0011] According to some implementations of the present disclosure, a system for characterizing a user interface and/or an AAV of a respiratory therapy system includes a control system configured to implement any one of the methods disclosed herein. [0012] According to some implementations of the present disclosure, a computer program product includes instructions which, when executed by a computer, cause the computer to carry out any one of the methods disclosed herein. [0013] 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 [0014] FIG. 1 is a functional block diagram of a system, according to some implementations of the present disclosure; [0015] FIG.2 is a perspective view of at least a portion of the system of FIG.1, a user, and a bed partner, according to some implementations of the present disclosure; [0016] FIG.3A is a perspective view of one category of user interfaces, according to some implementations of the present disclosure. [0017] FIG. 3B is an exploded view of the user interface of FIG. 3A, according to some P2247WO1 (RSMD/0072PC) implementations of the present disclosure. [0018] FIG. 4 is a rear perspective view of a respiratory therapy device of the system of FIG. 1, according to some implementations of the present disclosure. [0019] FIG.5 is a process flow diagram for a method for training machine learning models to characterize a user interface or an AAV of the user interface based on flow generator data, according to some implementations of the present disclosure. [0020] FIG. 6 is a process flow diagram for a method for using machine learning models to characterize a user interface or an AAV of the user interface based on flow generator data, according to some implementations of the present disclosure. [0021] FIG. 7 is a process flow diagram for a method for using machine learning models to characterize a user interface or an AAV of the user interface based on flow generator data and various criteria, according to some implementations of the present disclosure. [0022] FIG. 8 is a process flow diagram for a method for using a machine learning model to predict anti-asphyxia valve presence based on flow generator data, according to some implementations of the present disclosure. [0023] FIG.9 is a process flow diagram for a method for training a machine learning model to predict anti-asphyxia valve presence based on flow generator data, according to some implementations of the present disclosure. [0024] FIG. 10A illustrates flow generator data signatures for various full face user interfaces, including an AirFit^TM F10 model, an AirFit^TM F20 model, an AirFit^TM F30i model, and an AirFit^TM F30 model, according to some implementations of the present disclosure. [0025] FIG. 10B illustrates flow generator data signatures for various full face user interfaces, including an AmaraView^TM model (Philips Respironics), a DreamWear^TM FullFace model (Philips Respironics), a Simplus^TM model (Fisher & Paykel), and a Vitera^TM model (Fisher & Paykel), according to some implementations of the present disclosure. [0026] FIG. 11A illustrates flow generator data signatures for various non-full face user interfaces, including an AirFit^TM N20 model, an AirFit^TM N20 Classic model, an AirFit^TM N30 model, and an AirFit^TM N30i model, according to some implementations of the present disclosure. [0027] FIG. 11B illustrates flow generator data signatures for various non-full face user interfaces, including an AirFit^TM P30i model, an AirFit^TM P10 model, a Brevida^TM model (Fisher & Paykel), and a DreamWear^TM Pillow model, according to some implementations of the present disclosure. [0028] FIG. 11C illustrates flow generator data signatures for various non-full face user P2247WO1 (RSMD/0072PC) interfaces, including a DreamWisp^TM model (Philips Respironics), a Wisp^TM Nasal model (Philips Respironics), an Eson2^TM model (Fisher & Paykel), and a DreamWear^TM Nasal model (Philips Respironics), according to some implementations of the present disclosure. [0029] FIG.12 illustrates flow generator data signatures for various full face user interfaces while unpowered, including a DreamWear^TM FullFace model (Philips Respironics), an AirFit^TM F20 model, and an AirFit^TM N20 model, according to some implementations of the present disclosure. [0030] FIG. 13 is a graph depicting notched box plots of experimental model accuracy for models trained on various features, according to some implementations of the present disclosure. [0031] 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 [0032] Many individuals suffer from sleep-related and/or respiratory disorders. Examples of sleep-related and/or respiratory disorders include Periodic Limb Movement Disorder (PLMD), Restless Leg Syndrome (RLS), Sleep-Disordered Breathing (SDB) such as Obstructive Sleep Apnea (OSA), Central Sleep Apnea (CSA), and other types of apneas (e.g., mixed apneas and hypopneas), Respiratory Effort Related Arousal (RERA), Cheyne-Stokes Respiration (CSR), respiratory insufficiency, Obesity Hyperventilation Syndrome (OHS), Chronic Obstructive Pulmonary Disease (COPD), Neuromuscular Disease (NMD), and chest wall disorders. [0033] Obstructive Sleep Apnea (OSA) is a form of Sleep Disordered Breathing (SDB), and is characterized by events including occlusion or obstruction of the upper air passage during sleep resulting from a combination of an abnormally small upper airway and the normal loss of muscle tone in the region of the tongue, soft palate and posterior oropharyngeal wall. More generally, an apnea generally refers to the cessation of breathing caused by blockage of the air (Obstructive Sleep Apnea) or the stopping of the breathing function (often referred to as Central Sleep Apnea). Typically, the individual will stop breathing for between about 15 seconds and about 30 seconds during an obstructive sleep apnea event. P2247WO1 (RSMD/0072PC) [0034] Other types of apneas include hypopnea, hyperpnea, and hypercapnia. Hypopnea is generally characterized by slow or shallow breathing caused by a narrowed airway, as opposed to a blocked airway. Hyperpnea is generally characterized by an increase depth and/or rate of breathing. Hypercapnia is generally characterized by elevated or excessive carbon dioxide in the bloodstream, typically caused by inadequate respiration. [0035] A Respiratory Effort Related Arousal (RERA) event is typically characterized by an increased respiratory effort for 10 seconds or longer leading to arousal from sleep and which does not fulfill the criteria for an apnea or hypopnea event. In 1999, the AASM Task Force defined RERAs as “a sequence of breaths characterized by increasing respiratory effort leading to an arousal from sleep, but which does not meet criteria for an apnea or hypopnea.” These events must fulfil both of the following criteria: 1. pattern of progressively more negative esophageal pressure, terminated by a sudden change in pressure to a less negative level and an arousal; 2. the event lasts 10 seconds or longer. In 2000, the study “Non-Invasive Detection of Respiratory Effort-Related Arousals (RERAs) by a Nasal Cannula/Pressure Transducer System” done at NYU School of Medicine and published in Sleep, vol.23, No.6, pp.763-771, demonstrated that a Nasal Cannula/Pressure Transducer System was adequate and reliable in the detection of RERAs. A RERA detector may be based on a real flow signal derived from a respiratory therapy (e.g., PAP) device. For example, a flow limitation measure may be determined based on a flow signal. A measure of arousal may then be derived as a function of the flow limitation measure and a measure of sudden increase in ventilation. Some such methods are described in WO 2008/138040, assigned to ResMed Ltd., the disclosure of which is hereby incorporated herein by reference in its entirety. [0036] Cheyne-Stokes Respiration (CSR) is another form of sleep disordered breathing. CSR is a disorder of a patient’s respiratory controller in which there are rhythmic alternating periods of waxing and waning ventilation known as CSR cycles. CSR is characterized by repetitive de-oxygenation and re-oxygenation of the arterial blood. [0037] Obesity Hyperventilation Syndrome (OHS) is defined as the combination of severe obesity and awake chronic hypercapnia, in the absence of other known causes for hypoventilation. Symptoms include dyspnea, morning headache and excessive daytime sleepiness. [0038] Chronic Obstructive Pulmonary Disease (COPD) encompasses any of a group of lower airway diseases that have certain characteristics in common, such as increased resistance to air movement, extended expiratory phase of respiration, and loss of the normal elasticity of the lung. P2247WO1 (RSMD/0072PC) [0039] Neuromuscular Disease (NMD) encompasses many diseases and ailments that impair the functioning of the muscles either directly via intrinsic muscle pathology, or indirectly via nerve pathology. Chest wall disorders are a group of thoracic deformities that result in inefficient coupling between the respiratory muscles and the thoracic cage. [0040] These and other disorders are characterized by particular events (e.g., snoring, an apnea, a hypopnea, a restless leg, a sleeping disorder, choking, an increased heart rate, labored breathing, an asthma attack, an epileptic episode, a seizure, or any combination thereof) that occur when the individual is sleeping. [0041] The Apnea-Hypopnea Index (AHI) is an index used to indicate the severity of sleep apnea during a sleep session. The AHI is calculated by dividing the number of apnea and/or hypopnea events experienced by the user during the sleep session by the total number of hours of sleep in the sleep session. The event can be, for example, a pause in breathing that lasts for at least 10 seconds. An AHI that is less than 5 is considered normal. An AHI that is greater than or equal to 5, but less than 15 is considered indicative of mild sleep apnea. An AHI that is greater than or equal to 15, but less than 30 is considered indicative of moderate sleep apnea. An AHI that is greater than or equal to 30 is considered indicative of severe sleep apnea. In children, an AHI that is greater than 1 is considered abnormal. Sleep apnea can be considered “controlled” when the AHI is normal, or when the AHI is normal or mild. The AHI can also be used in combination with oxygen desaturation levels to indicate the severity of Obstructive Sleep Apnea. [0042] Referring to FIG.1, a system 100, according to some implementations of the present disclosure, is illustrated. The system 100 includes a control system 110, a memory device 114, an electronic interface 119, one or more sensors 130, and one or more user devices 170. In some implementations, the system 100 further optionally includes a respiratory therapy system 120, and an activity tracker 180. [0043] The control system 110 includes one or more processors 112 (hereinafter, processor 112). The control system 110 is generally used to control (e.g., actuate) the various components of the system 100 and/or analyze data obtained and/or generated by the components of the system 100. The processor 112 can be a general or special purpose processor or microprocessor. While one processor 112 is illustrated in FIG. 1, the control system 110 can include any number of processors (e.g., one processor, two processors, five processors, ten processors, etc.) that can be in a single housing, or located remotely from each other. The control system 110 (or any other control system) or a portion of the control system 110 such as the processor 112 (or any other processor(s) or portion(s) of any other control system), can be P2247WO1 (RSMD/0072PC) used to carry out one or more steps of any of the methods described and/or claimed herein. The control system 110 can be coupled to and/or positioned within, for example, a housing of the user device 170, a portion (e.g., a housing) of the respiratory therapy system 120, and/or within a housing of one or more of the sensors 130. The control system 110 can be centralized (within one such housing) or decentralized (within two or more of such housings, which are physically distinct). In such implementations including two or more housings containing the control system 110, such housings can be located proximately and/or remotely from each other. [0044] The memory device 114 stores machine-readable instructions that are executable by the processor 112 of the control system 110. The memory device 114 can be any suitable computer readable storage device or media, such as, for example, a random or serial access memory device, a hard drive, a solid state drive, a flash memory device, etc. While one memory device 114 is shown in FIG. 1, the system 100 can include any suitable number of memory devices 114 (e.g., one memory device, two memory devices, five memory devices, ten memory devices, etc.). The memory device 114 can be coupled to and/or positioned within a housing of a respiratory therapy device 122 of the respiratory therapy system 120, within a housing of the user device 170, within a housing of one or more of the sensors 130, or any combination thereof. Like the control system 110, the memory device 114 can be centralized (within one such housing) or decentralized (within two or more of such housings, which are physically distinct). [0045] In some implementations, the memory device 114 stores a user profile associated with the user. The user profile can include, for example, demographic information associated with the user, biometric information associated with the user, medical information associated with the user, self-reported user feedback, sleep parameters associated with the user (e.g., sleep-related parameters recorded from one or more earlier sleep sessions), or any combination thereof. The demographic information can include, for example, information indicative of an age of the user, a gender of the user, a race of the user, a geographic location of the user, a relationship status, a family history of insomnia or sleep apnea, an employment status of the user, an educational status of the user, a socioeconomic status of the user, or any combination thereof. The medical information can include, for example, information indicative of one or more medical conditions associated with the user, medication usage by the user, or both. The medical information data can further include a multiple sleep latency test (MSLT) result or score and/or a Pittsburgh Sleep Quality Index (PSQI) score or value. The self-reported user feedback can include information indicative of a self-reported subjective sleep score (e.g., poor, average, excellent), a self-reported subjective stress level of the user, a self-reported subjective P2247WO1 (RSMD/0072PC) fatigue level of the user, a self-reported subjective health status of the user, a recent life event experienced by the user, or any combination thereof. [0046] The electronic interface 119 is configured to receive data (e.g., physiological data and/or acoustic data) from the one or more sensors 130 such that the data can be stored in the memory device 114 and/or analyzed by the processor 112 of the control system 110. The electronic interface 119 can communicate with the one or more sensors 130 using a wired connection or a wireless connection (e.g., using an RF communication protocol, a Wi-Fi communication protocol, a Bluetooth communication protocol, over a cellular network, etc.). The electronic interface 119 can include an antenna, a receiver (e.g., an RF receiver), a transmitter (e.g., an RF transmitter), a transceiver, or any combination thereof. The electronic interface 119 can also include one more processors and/or one more memory devices that are the same as, or similar to, the processor 112 and the memory device 114 described herein. In some implementations, the electronic interface 119 is coupled to or integrated in the user device 170. In other implementations, the electronic interface 119 is coupled to or integrated (e.g., in a housing) with the control system 110 and/or the memory device 114. [0047] As noted above, in some implementations, the system 100 optionally includes a respiratory therapy system 120. The respiratory therapy system 120 can include a respiratory pressure therapy (RPT) device 122 (referred to herein as respiratory therapy device 122), a user interface 124, a conduit 126 (also referred to as a tube or an air circuit), a display device 128, a humidification tank 129, or any combination thereof. In some implementations, the control system 110, the memory device 114, the display device 128, one or more of the sensors 130, and the humidification tank 129 are part of the respiratory therapy device 122. Respiratory pressure therapy refers to the application of a supply of air to an entrance to a user’s airways at a controlled target pressure that is nominally positive with respect to atmosphere throughout the user’s breathing cycle (e.g., in contrast to negative pressure therapies such as the tank ventilator or cuirass). The respiratory therapy system 120 is generally used to treat individuals suffering from one or more sleep-related respiratory disorders (e.g., obstructive sleep apnea, central sleep apnea, or mixed sleep apnea). [0048] The respiratory therapy device 122 is generally used to generate pressurized air that is delivered to a user (e.g., using one or more motors that drive one or more compressors). In some implementations, the respiratory therapy device 122 generates continuous constant air pressure that is delivered to the user. In other implementations, the respiratory therapy device 122 generates two or more predetermined pressures (e.g., a first predetermined air pressure and a second predetermined air pressure). In still other implementations, the respiratory therapy P2247WO1 (RSMD/0072PC) device 122 is configured to generate a variety of different air pressures within a predetermined range. For example, the respiratory therapy device 122 can deliver at least about 6 cmH₂O, at least about 10 cmH₂O, at least about 20 cmH₂O, between about 6 cmH₂O and about 10 cmH₂O, between about 7 cmH₂O and about 12 cmH₂O, etc. The respiratory therapy device 122 can also deliver pressurized air at a predetermined flow rate between, for example, about -20 L/min and about 150 L/min, while maintaining a positive pressure (relative to the ambient pressure). [0049] The user interface 124 engages a portion of the user’s face and delivers pressurized air from the respiratory therapy device 122 to the user’s airway to aid in preventing the airway from narrowing and/or collapsing during sleep. This may also increase the user’s oxygen intake during sleep. Generally, the user interface 124 engages the user’s face such that the pressurized air is delivered to the user’s airway via the user’s mouth, the user’s nose, or both the user’s mouth and nose. Together, the respiratory therapy device 122, the user interface 124, and the conduit 126 form an air pathway fluidly coupled with an airway of the user. The pressurized air also increases the user’s oxygen intake during sleep. Depending upon the therapy to be applied, the user interface 124 may form a seal, for example, with a region or portion of the user’s face, to facilitate the delivery of gas at a pressure at sufficient variance with ambient pressure to effect therapy, for example, at a positive pressure of about 10 cmH₂O relative to ambient pressure. For other forms of therapy, such as the delivery of oxygen, the user interface may not include a seal sufficient to facilitate delivery to the airways of a supply of gas at a positive pressure of about 10 cmH₂O. In some implementations, the user interface 124 may include a connector 127 and one or more vents 125, which are described in more detail with reference to FIGS. 3A-3B. In some implementations, the connector 127 is distinct from, but couplable to, the user interface 124 (and/or conduit 126). [0050] As shown in FIG. 2, in some implementations, the user interface 124 is a facial mask (e.g., a full face mask) that covers the nose and mouth of the user. Alternatively, the user interface 124 can be a nasal mask that provides air to the nose of the user or a nasal pillow mask that delivers air directly to the nostrils of the user. The user interface 124 can include a plurality of straps forming, for example, a headgear for aiding in positioning and/or stabilizing the interface on a portion of the user (e.g., the face) and a conformal cushion (e.g., silicone, plastic, foam, etc.) that aids in providing an air-tight seal between the user interface 124 and the user. The user interface 124 can also include one or more vents for permitting the escape of carbon dioxide and other gases exhaled by the user 210. In other implementations, the user interface 124 includes a mouthpiece (e.g., a night guard mouthpiece molded to conform to the teeth of the user, a mandibular repositioning device, etc.). P2247WO1 (RSMD/0072PC) [0051] FIGS. 3A and 3B illustrate a perspective view and an exploded view, respectively, of one implementation of a directly connected user interface (“direct category” user interfaces), according to aspects of the present disclosure. The direct category of a user interface 300 generally includes a cushion 330 and a frame 350 that define a volume of space around the mouth and/or nose of the user. When in use, the volume of space receives pressurized air for passage into the user’s airways. In some embodiments, the cushion 330 and frame 350 of the user interface 300 form a unitary component of the user interface. The user interface 300 assembly may further be considered to comprise a headgear 310, which in the case of the user interface 300 is generally a strap assembly, and optionally a connector 370. The headgear 310 is configured to be positioned generally about at least a portion of a user’s head when the user wears the user interface 300. The headgear 310 can be coupled to the frame 350 and positioned on the user’s head such that the user’s head is positioned between the headgear 310 and the frame 350. The cushion 330 is positioned between the user’s face and the frame 350 to form a seal on the user’s face. The optional connector 370 is configured to couple to the frame 350 and/or cushion 330 at one end and to a conduit of a respiratory therapy device (not shown). The pressurized air can flow directly from the conduit of the respiratory therapy system into the volume of space defined by the cushion 330 (or cushion 330 and frame 350) of the user interface 300 through the connector 370). From the user interface 300, the pressurized air reaches the user’s airway through the user’s mouth, nose, or both. Alternatively, where the user interface 300 does not include the connector 370, the conduit of the respiratory therapy system can connect directly to the cushion 330 and/or the frame 350. [0052] In some implementations, the connector 370 may include one or a plurality of vents 372 located on the main body of the connector 370 itself and/or one or a plurality of vents 376 (“diffuser vents”) in proximity to the frame 350, for permitting the escape of carbon dioxide (CO₂) and other gases exhaled by the user when the respiratory therapy device is active. In some implementations, one or a plurality of vents, such as vents 372 and/or 376 may be located in the user interface, such as in frame 350, and/or in the conduit 126. In some implementations, the frame 350 may include at least one anti-asphyxia valve (AAV) 374, which allows CO₂ and other gases exhaled by the user to escape in the event that the vents (e.g., the vents 372 or 376) fail when the respiratory therapy device is active, and/or allows the user to breathe when the therapy is not active (e.g., due to power loss, device failure, an auto-stop feature being triggered, such as by mistake or accident, and the like). [0053] In some embodiments, AAVs (such as AAV 374) generally comprise two components: a vent (also referred to in some embodiments as an orifice or opening), as well as P2247WO1 (RSMD/0072PC) a flap (also referred to in some embodiments as a damper, louver, or shutter). In the illustrated example, the opening or vent of the AAV 374 is visible, but the flap is not depicted. Generally, when the therapy is off (e.g., air flow is not being generated by the flow generator), the flap does not cover the vent. When the therapy is on, the pressure seals the flap against the vent. [0054] In some embodiments, if there is no airflow from the flow generator, the diffuser vents on the mask (if present) may be insufficient for safe evacuation of exhaled CO₂. For some interfaces, such as nasal pillow masks, the user can breathe through their mouth. However, for full face masks, the AAV may be needed to ensure adequate ventilation. In general, AAVs (e.g., the AAV 374) are always present for full face masks (as a safety feature); however, the diffuser vents and vents located on the mask or connector (usually an array of orifices in the mask material itself or a mesh made of some sort of fabric, in many cases replaceable) are not necessarily both present (e.g., some masks might have only the diffuser vents such as the plurality of vents 376, other masks might have only the plurality of vents 372 on the connector itself). [0055] For indirectly connected user interfaces (“indirect category” user interfaces), and as will be described in greater detail below, the conduit of the respiratory therapy system connects indirectly with the cushion and/or frame of the user interface. Another element of the user interface—besides any connector—is located between the conduit of the respiratory therapy system and the cushion and/or frame. This additional element (e.g., a relatively short, relatively flexible tube, such as user interface conduit described below) delivers the pressurized air to the volume of space formed between the cushion (or frame, or cushion and frame) of the user interface and the user’s face, from the conduit of the respiratory therapy system. Thus, pressurized air is delivered indirectly from the conduit of the respiratory therapy system into the volume of space defined by the cushion (or the cushion and frame) of the user interface against the user’s face. Moreover, according to some implementations, the indirectly connected category of user interfaces can be described as being at least two different categories: “indirect headgear” and “indirect conduit”. For the indirect headgear category, the conduit of the respiratory therapy system connects to a headgear conduit, optionally via a connector, which in turn connects to the cushion (or frame, or cushion and frame). The headgear is therefore configured to deliver the pressurized air from the conduit of the respiratory therapy system to the cushion (or frame, or cushion and frame) of the user interface. This headgear conduit within the headgear of the user interface is therefore configured to deliver the pressurized air from the conduit of the respiratory therapy system to the cushion of the user interface. For the indirect conduit category, the user interface comprises a user interface conduit, typically located P2247WO1 (RSMD/0072PC) between the conduit and the frame, cushion, or connector (if present) and fluidly couples the conduit to the frame, cushion, or connector (if present). Generally, the user interface conduit (i) is more flexible than the conduit of the respiratory therapy system, or (ii) has a diameter smaller than the diameter of the conduit of the respiratory therapy system, or both (i) and (ii). The user interface conduit may also have a shorter length than the conduit. In the described user interfaces, the optional connector is configured to couple to the frame and/or cushion at one end and to the conduit or user interface conduit at the other end depending on the category of user interface. [0056] Referring back to FIG. 1, the conduit 126 (also referred to as an air circuit or tube) allows the flow of air between two components of a respiratory therapy system 120, such as the respiratory therapy device 122 and the user interface 124. In some implementations, there can be separate limbs of the conduit for inhalation and exhalation. In other implementations, a single limb conduit is used for both inhalation and exhalation. [0057] One or more of the respiratory therapy device 122, the user interface 124, the conduit 126, the display device 128, and the humidification tank 129 can contain one or more sensors (e.g., a pressure sensor, a flow rate sensor, or more generally any of the other sensors 130 described herein). These one or more sensors can be used, for example, to measure the air pressure and/or flow rate of pressurized air supplied by the respiratory therapy device 122. [0058] Referring briefly to FIG. 4, a perspective view of the back side of the respiratory therapy device 122 that includes a housing 123, an air inlet 186, and an air outlet 190. The air inlet 186 includes an inlet cover 182 movable between a closed position and an open position. The air inlet cover 182 includes one or more air inlet apertures 184 defined therein. The respiratory therapy device 122 includes a blower motor configured to draw air in through the one or more air inlet apertures 184 defined in the air inlet cover 182. The motor is further configured to cause pressurized air to flow through the humidification tank 129 and out of the air outlet 190. The conduit 126 can be fluidly coupled to the air outlet 190, such that the air flows from the air outlet 190 and into the conduit 126. The air outlet 190 is partially formed by an internal conduit 192 extending through the housing 123 from the interior of the respiratory therapy device 122. A seal 194 is positioned around the end of the internal conduit 192 to ensure that substantially all of the air that exits through the air outlet 190 flows into the conduit 126. [0059] Referring back to FIG. 1, the display device 128 is generally used to display image(s) including still images, video images, or both and/or information regarding the respiratory therapy device 122. For example, the display device 128 (and/or the display device P2247WO1 (RSMD/0072PC) 172 of the user device 170) can provide information regarding the status of the respiratory therapy device 122 (e.g., whether the respiratory therapy device 122 is on/off, the pressure of the air being delivered by the respiratory therapy device 122, the temperature of the air being delivered by the respiratory therapy device 122, etc.) and/or other information (e.g., a sleep score and/or a therapy score, also referred to as a myAir™ score, such as described in WO 2016/061629, which is hereby incorporated by reference herein in its entirety; the current date/time; personal information for the user 210; etc.). In some implementations, the display device 128 acts as a human-machine interface (HMI) that includes a graphic user interface (GUI) configured to display the image(s) as an input interface. The display device 128 can be an LED display, an OLED display, an LCD display, or the like. The input interface can be, for example, a touchscreen or touch-sensitive substrate, a mouse, a keyboard, or any sensor system configured to sense inputs made by a human user interacting with the respiratory therapy device 122. Display device 172 of user device 170 may operate in the same or similar way to display device 128 and may be used with or instead of display device 128. [0060] The humidification tank 129 is coupled to or integrated in the respiratory therapy device 122 and includes a reservoir of water that can be used to humidify the pressurized air delivered from the respiratory therapy device 122. The respiratory therapy device 122 can include a heater to heat the water in the humidification tank 129 in order to humidify the pressurized air provided to the user. Additionally, in some implementations, the conduit 126 can also include a heating element (e.g., coupled to and/or imbedded in the conduit 126) that heats the pressurized air delivered to the user. The humidification tank 129 can be fluidly coupled to a water vapor inlet of the air pathway and deliver water vapor into the air pathway via the water vapor inlet, or can be formed in-line with the air pathway as part of the air pathway itself. [0061] The respiratory therapy system 120 can be used, for example, as a ventilator or as a positive airway pressure (PAP) system, such as a continuous positive airway pressure (CPAP) system, an automatic positive airway pressure system (APAP), a bi-level or variable positive airway pressure system (BPAP or VPAP), or any combination thereof. The CPAP system delivers a predetermined air pressure (e.g., determined by a sleep physician) to the user. The APAP system automatically varies the air pressure delivered to the user based on, for example, respiration data associated with the user. The BPAP or VPAP system is configured to deliver a first predetermined pressure (e.g., an inspiratory positive airway pressure or IPAP) and a second predetermined pressure (e.g., an expiratory positive airway pressure or EPAP) that is lower than the first predetermined pressure. P2247WO1 (RSMD/0072PC) [0062] Referring to FIG. 2, a portion of the system 100 (FIG. 1), according to some implementations, is illustrated. A user 210 of the respiratory therapy system 120 and a bed partner 220 are located in a bed 230 and are laying on a mattress 232. The user interface 124 (also referred to herein as a mask, e.g., a full facial mask) can be worn by the user 210 during a sleep session. The user interface 124 is fluidly coupled and/or connected to the respiratory therapy device 122 via the conduit 126. In turn, the respiratory therapy device 122 delivers pressurized air to the user 210 via the conduit 126 and the user interface 124 to increase the air pressure in the throat of the user 210 to aid in preventing the airway from closing and/or narrowing during sleep. The respiratory therapy device 122 can be positioned on a nightstand 240 that is directly adjacent to the bed 230 as shown in FIG. 2, or more generally, on any surface or structure that is generally adjacent to the bed 230 and/or the user 210. [0063] Referring to back to FIG. 1, the one or more sensors 130 of the system 100 include a pressure sensor 132, a flow rate sensor 134, temperature sensor 136, a motion sensor 138, a microphone 140, a speaker 142, a radio-frequency (RF) receiver 146, a RF transmitter 148, a camera 150, an infrared sensor 152, a photoplethysmogram (PPG) sensor 154, an electrocardiogram (ECG) sensor 156, an electroencephalography (EEG) sensor 158, a capacitive sensor 160, a force sensor 162, a strain gauge sensor 164, an electromyography (EMG) sensor 166, an oxygen sensor 168, an analyte sensor 174, a moisture sensor 176, a LiDAR sensor 178, or any combination thereof. Generally, each of the one or more sensors 130 are configured to output sensor data that is received and stored in the memory device 114 or one or more other memory devices. [0064] While the one or more sensors 130 are shown and described as including each of the pressure sensor 132, the flow rate sensor 134, the temperature sensor 136, the motion sensor 138, the microphone 140, the speaker 142, the RF receiver 146, the RF transmitter 148, the camera 150, the infrared sensor 152, the photoplethysmogram (PPG) sensor 154, the electrocardiogram (ECG) sensor 156, the electroencephalography (EEG) sensor 158, the capacitive sensor 160, the force sensor 162, the strain gauge sensor 164, the electromyography (EMG) sensor 166, the oxygen sensor 168, the analyte sensor 174, the moisture sensor 176, and the LiDAR sensor 178, more generally, the one or more sensors 130 can include any combination and any number of each of the sensors described and/or shown herein. [0065] As described herein, the system 100 generally can be used to generate physiological data associated with a user (e.g., a user of the respiratory therapy system 120 shown in FIG. 2) during a sleep session. The physiological data can be analyzed to generate one or more sleep- related parameters, which can include any parameter, measurement, etc. related to the user P2247WO1 (RSMD/0072PC) during the sleep session. The one or more sleep-related parameters that can be determined for the user 210 during the sleep session include, for example, an Apnea-Hypopnea Index (AHI) score, a sleep score, a flow signal, a respiration signal, a respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, a number of events per hour, a pattern of events, a stage, pressure settings of the respiratory therapy device 122, a heart rate, a heart rate variability, movement of the user 210, temperature, EEG activity, EMG activity, arousal, snoring, choking, coughing, whistling, wheezing, or any combination thereof. [0066] The one or more sensors 130 can be used to generate, for example, physiological data, acoustic data, or both. Physiological data generated by one or more of the sensors 130 can be used by the control system 110 to determine a sleep-wake signal associated with the user 210 (FIG.2) during the sleep session and one or more sleep-related parameters. The sleep- wake signal can be indicative of one or more sleep states, including wakefulness, relaxed wakefulness, micro-awakenings, or distinct sleep stages such as, for example, a rapid eye movement (REM) stage, a first non-REM stage (often referred to as “N1”), a second non-REM stage (often referred to as “N2”), a third non-REM stage (often referred to as “N3”), or any combination thereof. Methods for determining sleep states and/or sleep stages from physiological data generated by one or more sensors, such as the one or more sensors 130, are described in, for example, WO 2014/047310, US 2014/0088373, WO 2017/132726, WO 2019/122413, and WO 2019/122414, each of which is hereby incorporated by reference herein in its entirety. [0067] In some implementations, the sleep-wake signal described herein can be timestamped to indicate a time that the user enters the bed, a time that the user exits the bed, a time that the user attempts to fall asleep, etc. The sleep-wake signal can be measured by the one or more sensors130 during the sleep session at a predetermined sampling rate, such as, for example, one sample per second, one sample per 30 seconds, one sample per minute, etc. In some implementations, the sleep-wake signal can also be indicative of a respiration signal, a respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, a number of events per hour, a pattern of events, pressure settings of the respiratory therapy device 122, or any combination thereof during the sleep session. The event(s) can include snoring, apneas, central apneas, obstructive apneas, mixed apneas, hypopneas, a mask leak (e.g., from the user interface 124), a restless leg, a sleeping disorder, choking, an increased heart rate, labored breathing, an asthma attack, an epileptic episode, a seizure, or any combination thereof. The one or more sleep-related parameters that can be determined for the user during the sleep session based on the sleep-wake signal include, for example, a total time P2247WO1 (RSMD/0072PC) in bed, a total sleep time, a sleep onset latency, a wake-after-sleep-onset parameter, a sleep efficiency, a fragmentation index, or any combination thereof. As described in further detail herein, the physiological data and/or the sleep-related parameters can be analyzed to determine one or more sleep-related scores. [0068] Physiological data and/or acoustic data generated by the one or more sensors 130 can also be used to determine a respiration signal associated with a user during a sleep session. The respiration signal is generally indicative of respiration or breathing of the user during the sleep session. The respiration signal can be indicative of and/or analyzed to determine (e.g., using the control system 110) one or more sleep-related parameters, such as, for example, a respiration rate, a respiration rate variability, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, an occurrence of one or more events, a number of events per hour, a pattern of events, a sleep state, a sleet stage, an apnea-hypopnea index (AHI), pressure settings of the respiratory therapy device 122, or any combination thereof. The one or more events can include snoring, apneas, central apneas, obstructive apneas, mixed apneas, hypopneas, a mask leak (e.g., from the user interface 124), a cough, a restless leg, a sleeping disorder, choking, an increased heart rate, labored breathing, an asthma attack, an epileptic episode, a seizure, increased blood pressure, or any combination thereof. Many of the described sleep-related parameters are physiological parameters, although some of the sleep-related parameters can be considered to be non-physiological parameters. Other types of physiological and/or non-physiological parameters can also be determined, either from the data from the one or more sensors 130, or from other types of data. [0069] The pressure sensor 132 outputs pressure data that can be stored in the memory device 114 and/or analyzed by the processor 112 of the control system 110. In some implementations, the pressure sensor 132 is an air pressure sensor (e.g., barometric pressure sensor) that generates sensor data indicative of the respiration (e.g., inhaling and/or exhaling) of the user of the respiratory therapy system 120 and/or ambient pressure. In such implementations, the pressure sensor 132 can be coupled to or integrated in the respiratory therapy device 122. The pressure sensor 132 can be, for example, a capacitive sensor, an electromagnetic sensor, a piezoelectric sensor, a strain-gauge sensor, an optical sensor, a potentiometric sensor, or any combination thereof. [0070] The flow rate sensor 134 outputs flow rate data that can be stored in the memory device 114 and/or analyzed by the processor 112 of the control system 110. Examples of flow rate sensors (such as, for example, the flow rate sensor 134) are described in WO 2012/012835, which is hereby incorporated by reference herein in its entirety. In some implementations, the P2247WO1 (RSMD/0072PC) flow rate sensor 134 is used to determine an air flow rate from the respiratory therapy device 122, an air flow rate through the conduit 126, an air flow rate through the user interface 124, or any combination thereof. In such implementations, the flow rate sensor 134 can be coupled to or integrated in the respiratory therapy device 122, the user interface 124, or the conduit 126. The flow rate sensor 134 can be a mass flow rate sensor such as, for example, a rotary flow meter (e.g., Hall effect flow meters), a turbine flow meter, an orifice flow meter, an ultrasonic flow meter, a hot wire sensor, a vortex sensor, a membrane sensor, or any combination thereof. In some implementations, the flow rate sensor 134 is configured to measure a vent flow (e.g., intentional “leak”), an unintentional leak (e.g., mouth leak and/or mask leak), a patient flow (e.g., air into and/or out of lungs), or any combination thereof. In some implementations, the flow rate data can be analyzed to determine cardiogenic oscillations of the user. In one example, the pressure sensor 132 can be used to determine a blood pressure of a user. [0071] The temperature sensor 136 outputs temperature data that can be stored in the memory device 114 and/or analyzed by the processor 112 of the control system 110. In some implementations, the temperature sensor 136 generates temperatures data indicative of a core body temperature of the user 210 (FIG.2), a skin temperature of the user 210, a temperature of the air flowing from the respiratory therapy device 122 and/or through the conduit 126, a temperature in the user interface 124, an ambient temperature, or any combination thereof. The temperature sensor 136 can be, for example, a thermocouple sensor, a thermistor sensor, a silicon band gap temperature sensor or semiconductor-based sensor, a resistance temperature detector, or any combination thereof. [0072] The motion sensor 138 outputs motion data that can be stored in the memory device 114 and/or analyzed by the processor 112 of the control system 110. The motion sensor 138 can be used to detect movement of the user 210 during the sleep session, and/or detect movement of any of the components of the respiratory therapy system 120, such as the respiratory therapy device 122, the user interface 124, or the conduit 126. The motion sensor 138 can include one or more inertial sensors, such as accelerometers, gyroscopes, and magnetometers. In some implementations, the motion sensor 138 alternatively or additionally generates one or more signals representing bodily movement of the user, from which may be obtained a signal representing a sleep state of the user; for example, via a respiratory movement of the user. In some implementations, the motion data from the motion sensor 138 can be used in conjunction with additional data from another sensor 130 to determine the sleep state of the user. P2247WO1 (RSMD/0072PC) [0073] The microphone 140 can be located at any location relative to the respiratory therapy system 120 and in acoustic communication with the airflow in the respiratory therapy system 120. For example, the respiratory therapy system 120 may include a microphone 140 (i) coupled externally to the conduit 126, (ii) positioned within, optionally at least partially within the respiratory therapy device 122, (iii) coupled externally to the user interface 124, (iv) coupled directly or indirectly to a headgear associated with the user interface 124, or in any other suitable location. In some implementations, the microphone 140 is coupled to a mobile device (for example, the user device 170 or a smart speaker(s) such as Google Nest Hub™, Google Home™, Amazon Echo™, Amazon Show™, Alexa™-enabled devices, etc.) that is communicatively coupled to the respiratory therapy system 120. [0074] In some implementations, the microphone 140 is positioned on or at least partially outside of a housing of the respiratory therapy device 122. For example, the microphone 140 may be at least partially movable relative to the housing of the respiratory therapy device 122 to aid in being directed to the user 210 (FIG. 2). For example, the microphone 340 can be rotated between about 5° and about 355° towards the user 210. [0075] In some implementations, the microphone 140 is configured to be in direct fluid communication with the airflow in the respiratory therapy system 120. For example, the microphone 140 may be (i) positioned at least partially within the conduit 126, (ii) positioned at least partially within the respiratory therapy device 122, optionally positioned at least partially within a component of the respiratory therapy device 122, which is in fluid communication with the conduit 126, or (iii) positioned at least partially within the user interface 124, the user interface 124 being in fluid communication with the conduit 126. Further, in some implementations, the microphone 140 is electrically connected with a circuit board (for example, connected physically, such as mounted on, the circuit board directly or indirectly) of the respiratory therapy device 122, which may be in acoustic communication (for example, via a small duct and/or a silicone window as in a stethoscope) or in fluid communication with the airflow in the respiratory therapy system 120. [0076] The microphone 140 outputs sound and/or acoustic data that can be stored in the memory device 114 and/or analyzed by the processor 112 of the control system 110. The acoustic data generated by the microphone 140 is reproducible as one or more sound(s) during a sleep session (e.g., sounds from the user 210). The acoustic data form the microphone 140 can also be used to identify (e.g., using the control system 110) an event experienced by the user during the sleep session, as described in further detail herein. The microphone 140 can be coupled to or integrated in the respiratory therapy device 122, the user interface 124, the P2247WO1 (RSMD/0072PC) conduit 126, or the user device 170. In some implementations, the system 100 includes a plurality of microphones (e.g., two or more microphones and/or an array of microphones with beamforming) such that sound data generated by each of the plurality of microphones can be used to discriminate the sound data generated by another of the plurality of microphones [0077] The speaker 142 outputs sound waves that are audible to a user of the system 100 (e.g., the user 210 of FIG. 2). The speaker 142 can be used, for example, as an alarm clock or to play an alert or message to the user 210 (e.g., in response to an event). In some implementations, the speaker 142 can be used to communicate the acoustic data generated by the microphone 140 to the user. The speaker 142 can be coupled to or integrated in the respiratory therapy device 122, the user interface 124, the conduit 126, or the user device 170. [0078] The microphone 140 and the speaker 142 can be used as separate devices. In some implementations, the microphone 140 and the speaker 142 can be combined into an acoustic sensor 141 (e.g., a SONAR sensor), as described in, for example, WO 2018/050913 and WO 2020/104465, each of which is hereby incorporated by reference herein in its entirety. In such implementations, the speaker 142 generates or emits sound waves at a predetermined interval and the microphone 140 detects the reflections of the emitted sound waves from the speaker 142. The sound waves generated or emitted by the speaker 142 have a frequency that is not audible to the human ear (e.g., below 20 Hz or above around 18 kHz) so as not to disturb the sleep of the user 210 or the bed partner 220 (FIG. 2). Based at least in part on the data from the microphone 140 and/or the speaker 142, the control system 110 can determine a location of the user 210 (FIG. 2) and/or one or more of the sleep-related parameters described in herein such as, for example, a respiration signal, a respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, a number of events per hour, a pattern of events, a sleep state, a sleep stage, pressure settings of the respiratory therapy device 122, or any combination thereof. In such a context, a SONAR sensor may be understood to concern an active acoustic sensing, such as by generating and/or transmitting ultrasound and/or low frequency ultrasound sensing signals (e.g., in a frequency range of about 17-23 kHz, 18-22 kHz, or 17-18 kHz, for example), through the air. Such a system may be considered in relation to WO 2018/050913 and WO 2020/104465 mentioned above, each of which is hereby incorporated by reference herein in its entirety. [0079] In some implementations, the sensors 130 include (i) a first microphone that is the same as, or similar to, the microphone 140, and is integrated in the acoustic sensor 141 and (ii) a second microphone that is the same as, or similar to, the microphone 140, but is separate and distinct from the first microphone that is integrated in the acoustic sensor 141. P2247WO1 (RSMD/0072PC) [0080] The RF transmitter 148 generates and/or emits radio waves having a predetermined frequency and/or a predetermined amplitude (e.g., within a high frequency band, within a low frequency band, long wave signals, short wave signals, etc.). The RF receiver 146 detects the reflections of the radio waves emitted from the RF transmitter 148, and this data can be analyzed by the control system 110 to determine a location of the user 210 (FIG.2) and/or one or more of the sleep-related parameters described herein. An RF receiver (either the RF receiver 146 and the RF transmitter 148 or another RF pair) can also be used for wireless communication between the control system 110, the respiratory therapy device 122, the one or more sensors 130, the user device 170, or any combination thereof. While the RF receiver 146 and RF transmitter 148 are shown as being separate and distinct elements in FIG. 1, in some implementations, the RF receiver 146 and RF transmitter 148 are combined as a part of an RF sensor 147 (e.g., a RADAR sensor). In some such implementations, the RF sensor 147 includes a control circuit. The specific format of the RF communication can be Wi-Fi, Bluetooth, or the like. [0081] In some implementations, the RF sensor 147 is a part of a mesh system. One example of a mesh system is a Wi-Fi mesh system, which can include mesh nodes, mesh router(s), and mesh gateway(s), each of which can be mobile/movable or fixed. In such implementations, the Wi-Fi mesh system includes a Wi-Fi router and/or a Wi-Fi controller and one or more satellites (e.g., access points), each of which include an RF sensor that the is the same as, or similar to, the RF sensor 147. The Wi-Fi router and satellites continuously communicate with one another using Wi-Fi signals. The Wi-Fi mesh system can be used to generate motion data based on changes in the Wi-Fi signals (e.g., differences in received signal strength) between the router and the satellite(s) due to an object or person moving partially obstructing the signals. The motion data can be indicative of motion, breathing, heart rate, gait, falls, behavior, etc., or any combination thereof. [0082] The camera 150 outputs image data reproducible as one or more images (e.g., still images, video images, thermal images, or any combination thereof) that can be stored in the memory device 114. The image data from the camera 150 can be used by the control system 110 to determine one or more of the sleep-related parameters described herein, such as, for example, one or more events (e.g., periodic limb movement or restless leg syndrome), a respiration signal, a respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, a number of events per hour, a pattern of events, a sleep state, a sleep stage, or any combination thereof. Further, the image data from the camera 150 can be used to, for example, identify a location of the user, to determine chest movement of the user P2247WO1 (RSMD/0072PC) 210 (FIG. 2), to determine air flow of the mouth and/or nose of the user 210, to determine a time when the user 210 enters the bed 230 (FIG. 2), and to determine a time when the user 210 exits the bed 230. In some implementations, the camera 150 includes a wide-angle lens or a fish eye lens. [0083] The infrared (IR) sensor 152 outputs infrared image data reproducible as one or more infrared images (e.g., still images, video images, or both) that can be stored in the memory device 114. The infrared data from the IR sensor 152 can be used to determine one or more sleep-related parameters during a sleep session, including a temperature of the user 210 and/or movement of the user 210. The IR sensor 152 can also be used in conjunction with the camera 150 when measuring the presence, location, and/or movement of the user 210. The IR sensor 152 can detect infrared light having a wavelength between about 700 nm and about 1 mm, for example, while the camera 150 can detect visible light having a wavelength between about 380 nm and about 740 nm. [0084] The PPG sensor 154 outputs physiological data associated with the user 210 (FIG. 2) that can be used to determine one or more sleep-related parameters, such as, for example, a heart rate, a heart rate variability, a cardiac cycle, respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, estimated blood pressure parameter(s), or any combination thereof. The PPG sensor 154 can be worn by the user 210, embedded in clothing and/or fabric that is worn by the user 210, embedded in and/or coupled to the user interface 124 and/or its associated headgear (e.g., straps, etc.), etc. [0085] In some implementations, a PAT (peripheral arterial tone) sensing device may make use of a fingertip mounted PPG probe, e.g., PPG sensor 154. The PPG probe operates with an optical technology that detects blood volume changes in the tissue’s microvascular bed. As noted above, PPG measurements are used to derive the arterial blood oxygen saturation (SpO₂), pulse rate (PR), and changes in peripheral arterial tone, which are then used to detect respiratory events. Peripheral arterial tone refers to the tone of the peripheral arterial smooth muscle tissue. When the muscle tone of peripheral arteries increases, the arteries’ diameter decreases, resulting in a reduction of perfusion and thus a decrease in pulsatile blood volume in the peripheral tissue. The decrease in pulsatile blood volume in the peripheral tissue is picked up as a drop in the PPG signal swing between systole and diastole. The PAT signal may be derived from the PPG signal from the PPG sensor, such as by the method described in WO 2021/260190, the disclosure of which is incorporated by reference herein in its entirety. The PPG-derived signal, which may be derived by trending such pulsatile blood volume reductions, is referred to as the PAT signal. P2247WO1 (RSMD/0072PC) [0086] The ECG sensor 156 outputs physiological data associated with electrical activity of the heart of the user 210. In some implementations, the ECG sensor 156 includes one or more electrodes that are positioned on or around a portion of the user 210 during the sleep session. The physiological data from the ECG sensor 156 can be used, for example, to determine one or more of the sleep-related parameters described herein. [0087] The EEG sensor 158 outputs physiological data associated with electrical activity of the brain of the user 210. In some implementations, the EEG sensor 158 includes one or more electrodes that are positioned on or around the scalp of the user 210 during the sleep session. The physiological data from the EEG sensor 158 can be used, for example, to determine a sleep state and/or a sleep stage of the user 210 at any given time during the sleep session. In some implementations, the EEG sensor 158 can be integrated in the user interface 124 and/or the associated headgear (e.g., straps, etc.). [0088] The capacitive sensor 160, the force sensor 162, and the strain gauge sensor 164 output data that can be stored in the memory device 114 and used by the control system 110 to determine one or more of the sleep-related parameters described herein. The EMG sensor 166 outputs physiological data associated with electrical activity produced by one or more muscles. The oxygen sensor 168 outputs oxygen data indicative of an oxygen concentration of gas (e.g., in the conduit 126 or at the user interface 124). The oxygen sensor 168 can be, for example, an ultrasonic oxygen sensor, an electrical oxygen sensor, a chemical oxygen sensor, an optical oxygen sensor, a pulse oximeter (e.g., SpO₂ sensor), or any combination thereof. In some implementations, the one or more sensors 130 also include a galvanic skin response (GSR) sensor, a blood flow sensor, a respiration sensor, a pulse sensor, a sphygmomanometer sensor, an oximetry sensor, or any combination thereof. [0089] The analyte sensor 174 can be used to detect the presence of an analyte in the exhaled breath of the user 210. The data output by the analyte sensor 174 can be stored in the memory device 114 and used by the control system 110 to determine the identity and concentration of any analytes in the breath of the user 210. In some implementations, the analyte sensor 174 is positioned near a mouth of the user 210 to detect analytes in breath exhaled from the user 210’s mouth. For example, when the user interface 124 is a facial mask that covers the nose and mouth of the user 210, the analyte sensor 174 can be positioned within the facial mask to monitor the user 210’s mouth breathing. In other implementations, such as when the user interface 124 is a nasal mask or a nasal pillow mask, the analyte sensor 174 can be positioned near the nose of the user 210 to detect analytes in breath exhaled through the user’s nose. In still other implementations, the analyte sensor 174 can be positioned near the P2247WO1 (RSMD/0072PC) user 210’s mouth when the user interface 124 is a nasal mask or a nasal pillow mask. In this implementation, the analyte sensor 174 can be used to detect whether any air is inadvertently leaking from the user 210’s mouth. In some implementations, the analyte sensor 174 is a volatile organic compound (VOC) sensor that can be used to detect carbon-based chemicals or compounds. In some implementations, the analyte sensor 174 can also be used to detect whether the user 210 is breathing through their nose or mouth. For example, if the data output by an analyte sensor 174 positioned near the mouth of the user 210 or within the facial mask (in implementations where the user interface 124 is a facial mask) detects the presence of an analyte, the control system 110 can use this data as an indication that the user 210 is breathing through their mouth. [0090] The moisture sensor 176 outputs data that can be stored in the memory device 114 and used by the control system 110. The moisture sensor 176 can be used to detect moisture in various areas surrounding the user (e.g., inside the conduit 126 or the user interface 124, near the user 210’s face, near the connection between the conduit 126 and the user interface 124, near the connection between the conduit 126 and the respiratory therapy device 122, etc.). Thus, in some implementations, the moisture sensor 176 can be coupled to or integrated in the user interface 124 or in the conduit 126 to monitor the humidity of the pressurized air from the respiratory therapy device 122. In other implementations, the moisture sensor 176 is placed near any area where moisture levels need to be monitored. The moisture sensor 176 can also be used to monitor the humidity of the ambient environment surrounding the user 210, for example, the air inside the bedroom. [0091] The Light Detection and Ranging (LiDAR) sensor 178 can be used for depth sensing. This type of optical sensor (e.g., laser sensor) can be used to detect objects and build three dimensional (3D) maps of the surroundings, such as of a living space. LiDAR can generally utilize a pulsed laser to make time of flight measurements. LiDAR is also referred to as 3D laser scanning. In an example of use of such a sensor, a fixed or mobile device (such as a smartphone) having a LiDAR sensor 178 can measure and map an area extending 5 meters or more away from the sensor. The LiDAR data can be fused with point cloud data estimated by an electromagnetic RADAR sensor, for example. The LiDAR sensor(s) 178 can also use artificial intelligence (AI) to automatically geofence RADAR systems by detecting and classifying features in a space that might cause issues for RADAR systems, such a glass windows (which can be highly reflective to RADAR). LiDAR can also be used to provide an estimate of the height of a person, as well as changes in height when the person sits down, or falls down, for example. LiDAR may be used to form a 3D mesh representation of an P2247WO1 (RSMD/0072PC) environment. In a further use, for solid surfaces through which radio waves pass (e.g., radio- translucent materials), the LiDAR may reflect off such surfaces, thus allowing a classification of different type of obstacles. [0092] In some implementations, the one or more sensors 130 also include a galvanic skin response (GSR) sensor, a blood flow sensor, a respiration sensor, a heart rate sensor (e.g., pulse sensor), a blood pressure sensor (e.g., sphygmomanometer sensor), an oximetry sensor, a SONAR sensor, a RADAR sensor, a blood glucose sensor, a camera (e.g., color sensor), a pH sensor, a tilt sensor (which measures the tilt in multiple axes of a reference plane), an orientation sensor (which measures the orientation of a device relative to an orthogonal coordinate frame), an alcohol sensor, or any combination thereof. [0093] While shown separately in FIG.1, any combination of the one or more sensors 130 can be integrated in and/or coupled to any one or more of the components of the system 100, including the respiratory therapy device 122, the user interface 124, the conduit 126, the humidification tank 129, the control system 110, the user device 170, the activity tracker 180, or any combination thereof. For example, the microphone 140 and the speaker 142 can be integrated in and/or coupled to the user device 170 and the pressure sensor 132 and/or flow rate sensor 134 are integrated in and/or coupled to the respiratory therapy device 122. In some implementations, at least one of the one or more sensors 130 is not coupled to the respiratory therapy device 122, the control system 110, or the user device 170, and is positioned generally adjacent to the user 210 during the sleep session (e.g., positioned on or in contact with a portion of the user 210, worn by the user 210, coupled to or positioned on the nightstand, coupled to the mattress, coupled to the ceiling, etc.). [0094] The data from the one or more sensors 130 can be analyzed to determine one or more sleep-related parameters, which can include a respiration signal, a respiration rate, a respiration pattern, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, an occurrence of one or more events, a number of events per hour, a pattern of events, a sleep state, an apnea-hypopnea index (AHI), or any combination thereof. The one or more events can include snoring, apneas, central apneas, obstructive apneas, mixed apneas, hypopneas, a mask leak, a cough, a restless leg, a sleeping disorder, choking, an increased heart rate, labored breathing, an asthma attack, an epileptic episode, a seizure, increased blood pressure, or any combination thereof. Many of these sleep-related parameters are physiological parameters, although some of the sleep-related parameters can be considered to be non- physiological parameters. Other types of physiological and non-physiological parameters can P2247WO1 (RSMD/0072PC) also be determined, either from the data from the one or more sensors 130, or from other types of data. [0095] The user device 170 (FIG. 1) includes a display device 172. The user device 170 can be, for example, a mobile device such as a smart phone, a tablet, a gaming console, a smart watch, a laptop, or the like. Alternatively, the user device 170 can be an external sensing system, a television (e.g., a smart television) or another smart home device (e.g., a smart speaker(s) such as Google Nest Hub™, Google Home™, Amazon Echo™, Amazon Show™, Alexa™-enabled devices, etc.). In some implementations, the user device is a wearable device (e.g., a smart watch). The display device 172 is generally used to display image(s) including still images, video images, or both. In some implementations, the display device 172 acts as a human-machine interface (HMI) that includes a graphic user interface (GUI) configured to display the image(s) and an input interface. The display device 172 can be an LED display, an OLED display, an LCD display, or the like. The input interface can be, for example, a touchscreen or touch-sensitive substrate, a mouse, a keyboard, or any sensor system configured to sense inputs made by a human user interacting with the user device 170. In some implementations, one or more user devices can be used by and/or included in the system 100. [0096] In some implementations, the system 100 also includes an activity tracker 180. The activity tracker 180 is generally used to aid in generating physiological data associated with the user. The activity tracker 180 can include one or more of the sensors 130 described herein, such as, for example, the motion sensor 138 (e.g., one or more accelerometers and/or gyroscopes), the PPG sensor 154, and/or the ECG sensor 156. The physiological data from the activity tracker 180 can be used to determine, for example, a number of steps, a distance traveled, a number of steps climbed, a duration of physical activity, a type of physical activity, an intensity of physical activity, time spent standing, a respiration rate, an average respiration rate, a resting respiration rate, a maximum he respiration art rate, a respiration rate variability, a heart rate, an average heart rate, a resting heart rate, a maximum heart rate, a heart rate variability, a number of calories burned, blood oxygen saturation, electrodermal activity (also known as skin conductance or galvanic skin response), or any combination thereof. In some implementations, the activity tracker 180 is coupled (e.g., electronically or physically) to the user device 170. [0097] In some implementations, the activity tracker 180 is a wearable device that can be worn by the user, such as a smartwatch, a wristband, a ring, or a patch. For example, referring to FIG. 2, the activity tracker 180 is worn on a wrist of the user 210. The activity tracker 180 can also be coupled to or integrated a garment or clothing that is worn by the user. Alternatively P2247WO1 (RSMD/0072PC) still, the activity tracker 180 can also be coupled to or integrated in (e.g., within the same housing) the user device 170. More generally, the activity tracker 180 can be communicatively coupled with, or physically integrated in (e.g., within a housing), the control system 110, the memory device 114, the respiratory therapy system 120, and/or the user device 170. [0098] While the control system 110 and the memory device 114 are described and shown in FIG. 1 as being a separate and distinct component of the system 100, in some implementations, the control system 110 and/or the memory device 114 are integrated in the user device 170 and/or the respiratory therapy device 122. Alternatively, in some implementations, the control system 110 or a portion thereof (e.g., the processor 112) can be located in a cloud (e.g., integrated in a server, integrated in an Internet of Things (IoT) device, connected to the cloud, be subject to edge cloud processing, etc.), located in one or more servers (e.g., remote servers, local servers, etc., or any combination thereof. [0099] While system 100 is shown as including all of the components described above, more or fewer components can be included in a system according to implementations of the present disclosure. For example, a first alternative system includes the control system 110, the memory device 114, and at least one of the one or more sensors 130 and does not include the respiratory therapy system 120. As another example, a second alternative system includes the control system 110, the memory device 114, at least one of the one or more sensors 130, and the user device 170. As yet another example, a third alternative system includes the control system 110, the memory device 114, the respiratory therapy system 120, at least one of the one or more sensors 130, and the user device 170. Thus, various systems can be formed using any portion or portions of the components shown and described herein and/or in combination with one or more other components. [0100] As used herein, a sleep session can be defined in multiple ways. For example, a sleep session can be defined by an initial start time and an end time. In some implementations, a sleep session is a duration where the user is asleep, that is, the sleep session has a start time and an end time, and during the sleep session, the user does not wake until the end time. That is, any period of the user being awake is not included in a sleep session. From this first definition of sleep session, if the user wakes ups and falls asleep multiple times in the same night, each of the sleep intervals separated by an awake interval is a sleep session. [0101] Alternatively, in some implementations, a sleep session has a start time and an end time, and during the sleep session, the user can wake up, without the sleep session ending, so long as a continuous duration that the user is awake is below an awake duration threshold. The awake duration threshold can be defined as a percentage of a sleep session. The awake duration P2247WO1 (RSMD/0072PC) threshold can be, for example, about twenty percent of the sleep session, about fifteen percent of the sleep session duration, about ten percent of the sleep session duration, about five percent of the sleep session duration, about two percent of the sleep session duration, etc., or any other threshold percentage. In some implementations, the awake duration threshold is defined as a fixed amount of time, such as, for example, about one hour, about thirty minutes, about fifteen minutes, about ten minutes, about five minutes, about two minutes, etc., or any other amount of time. [0102] In some implementations, a sleep session is defined as the entire time between the time in the evening at which the user first entered the bed, and the time the next morning when user last left the bed. Put another way, a sleep session can be defined as a period of time that begins on a first date (e.g., Monday, January 6, 2020) at a first time (e.g., 10:00 PM), that can be referred to as the current evening, when the user first enters a bed with the intention of going to sleep (e.g., not if the user intends to first watch television or play with a smart phone before going to sleep, etc.), and ends on a second date (e.g., Tuesday, January 7, 2020) at a second time (e.g., 7:00 AM), that can be referred to as the next morning, when the user first exits the bed with the intention of not going back to sleep that next morning. [0103] In some implementations, the user can manually define the beginning of a sleep session and/or manually terminate a sleep session. For example, the user can select (e.g., by clicking or tapping) one or more user-selectable element that is displayed on the display device 172 of the user device 170 (FIG. 1) to manually initiate or terminate the sleep session. [0104] Generally, the sleep session includes any point in time after the user 210 has laid or sat down in the bed 230 (or another area or object on which they intend to sleep), and has turned on the respiratory therapy device 122 and donned the user interface 124. The sleep session can thus include time periods (i) when the user 210 is using the CPAP system but before the user 210 attempts to fall asleep (for example when the user 210 lays in the bed 230 reading a book); (ii) when the user 210 begins trying to fall asleep but is still awake; (iii) when the user 210 is in a light sleep (also referred to as stage 1 and stage 2 of non-rapid eye movement (NREM) sleep); (iv) when the user 210 is in a deep sleep (also referred to as slow-wave sleep, SWS, or stage 3 of NREM sleep); (v) when the user 210 is in rapid eye movement (REM) sleep; (vi) when the user 210 is periodically awake between light sleep, deep sleep, or REM sleep; or (vii) when the user 210 wakes up and does not fall back asleep. [0105] The sleep session is generally defined as ending once the user 210 removes the user interface 124, turns off the respiratory therapy device 122, and gets out of bed 230. In some implementations, the sleep session can include additional periods of time, or can be limited to P2247WO1 (RSMD/0072PC) only some of the above-disclosed time periods. For example, the sleep session can be defined to encompass a period of time beginning when the respiratory therapy device 122 begins supplying the pressurized air to the airway or the user 210, ending when the respiratory therapy device 122 stops supplying the pressurized air to the airway of the user 210, and including some or all of the time points in between, when the user 210 is asleep or awake. [0106] Referring to FIG. 5, a method 500 for training machine learning models to characterize a user interface (e.g., the user interface 124 of the system 100) and/or an AAV of the user interface according to some implementations of the present disclosure is illustrated. One or more steps of the method 500 can be implemented using any element or aspect of the system 100 (FIGS.1-2) described herein. While the method 500 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 500 can be performed in any suitable order. [0107] As discussed above, an AAV can be used to allow exhaled gases to be expelled from the user interface in the event that other vent(s) fail or are occluded, as well as when the therapy fails or stops (e.g., due to motor failure, power loss, and the like). In some embodiments, the AAV generally is open when pressure is not applied (e.g., when no airflow is being provided by the respiratory therapy system and/or the user is not breathing) and closes when pressure is applied (e.g., when the user breathes, and/or when the respiratory therapy system begins supplying flow). In some embodiments, the AAV may generally be at least partially open during at least some portion of the respiration cycle, in order to allow gas exchange with the atmosphere. In embodiments of the present disclosure, flow generator data (e.g., collected by, generated by, or otherwise provided by a respiratory therapy system, such as respiratory therapy system 120) can be used to train one or more machine learning models to predict or detect the presence/absence of such AAVs. [0108] In some embodiments, the method 500 can be performed by one or more training systems. For example, the training system may correspond or be implemented using one or more components of the system 100. In some embodiments, the training system(s) may correspond to other systems (e.g., remote servers, cloud systems, and the like), and the resulting model(s) can be used for inferencing using one or more components of the system 100. That is, one or more components of the system 100 may use the method 500 to train machine learning models locally, or one or more components of the system 100 may collect the relevant data (e.g., flow generator data at block 505), and the data (or features extracted therefrom) may be transmitted or otherwise provided to one or more other systems (e.g., cloud systems), where these other systems use the collected data to train the machine learning models. P2247WO1 (RSMD/0072PC) [0109] At block 505, the training system accesses flow generator data associated with a user interface. For example, the flow generator data may be collected, generated, or otherwise provided by a respiratory therapy system (e.g., respiratory therapy system 120) while the respiratory therapy system is being operated with a user interface (e.g., user interface 124) in connection with a respiratory therapy, or following said operation. As used herein, a respiratory therapy system may be referred to as “operated with” a user interface to indicate that the user interface is coupled to the respiratory therapy system, regardless of whether the respiratory therapy system is actively providing airflow. Additionally, as used herein, accessing data can generally include generating, receiving, requesting, retrieving, or otherwise gaining access to the data. For example, the training system may itself generate the flow generator data, may receive it from another system, may retrieve it from a repository, and the like. [0110] In some embodiments, the flow generator data is generated and/or collected while the respiratory therapy system is providing airflow. For example, upon determining that the respiratory therapy device 122 has begun providing airflow (e.g., determined based on blower motor movement), the respiratory therapy system may generate or collect flow generator data (e.g., continuously, or during a defined window or period of time). In some embodiments, the flow generator data can additionally or alternatively be collected or generated while the respiratory therapy system is not providing airflow. For example, the flow generator data may be generated based on breathing of a user wearing the user interface. In some embodiments, the flow generator data may be continuously collected/generated, and only selectively accessed/processed for training and/or AAV detection (e.g., when breathing is detected, when blower start is detected, and the like). [0111] In embodiments, the flow generator data can include a variety of data, depending on the particular implementation. In some embodiments, the flow generator data includes flow data indicating and/or relating to the volume of air flow being provided (e.g., measured in in liters per second). For example, the flow data may be generated and/or collected using a flow rate sensor 134 to determine the flow rate of the blower. In some embodiments, the flow generator data includes pressure data indicating and/or relating to the pressure of the provided air flow (e.g., measured in cmH₂O). For example, the pressure data may be generated and/or collected using a pressure sensor 132 to determine the blower pressure, the pressure at the mask, or both. In some embodiments, the flow generator data includes motor data indicating and/or relating to the movement or rotation of a motor (e.g., the blower motor) used to generate and/or provide the air flow (e.g., measured in in revolutions per minute (RPM)). For example, the motor data may indicate whether the blower motor is on, the speed of the motor, the ramp P2247WO1 (RSMD/0072PC) rate, and the like. In some embodiments, a variety of motor sensors may be used to capture the motor data. Such sensors are known in the art, and can generally detect the operational parameter(s) of the motor, such as rotational velocity (e.g., RPM), of the motor. Such sensors include a motor speed transducer used to determine a rotational velocity of the motor and/or the blower (flow generator). A motor speed signal from the motor speed transducer may be provided to the therapy device controller. The motor speed transducer may, for example, be a speed sensor, such as a Hall effect sensor. In some embodiments, the flow generator data includes audio data (e.g., measured in decibels). For example, the audio data may be generated and/or collected using an acoustic sensor 141. [0112] In an embodiment, the flow generator data can include any combination of components. For example, in some embodiments, the flow generator data includes at least one of: flow data, pressure data, or motor data. In some embodiments, the flow generator data includes at least two of: flow data, pressure data, or motor data. In some embodiments, the flow generator data includes: flow data, pressure data, and motor data. In some embodiments, the flow generator data includes at least one of: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes at least two of: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes at least three of: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes: flow data, pressure data, motor data, and audio data. [0113] As used herein, “flow generator data” may include raw data or values (e.g., air flow rate, pressure, motor speed, audio, and the like), as well as preprocessed or transformed values and/or derivatives of the raw data (e.g., for one or more of the metrics, minimum values, maximum values, skewness values, kurtosis values, min-max ratios, and the like). [0114] In some aspects, the flow generator data is generated in response to determining that the respiratory therapy device has begun providing air flow. For example, in response to determining that the blower motor has begun spinning, the sensors 130 may begin collecting, generating, and/or recording or storing flow generator data. In some embodiments, the flow generator data is collected/stored corresponding to a defined period of time, such as during a 1 second interval after the blower motor starts, a 1.5 second interval after the blow motor starts, a 2 second interval after the blower motor starts, and the like. [0115] In some aspects, the flow generator data is generated while the respiratory therapy device is not providing air flow. For example, in response to determining that the user (while wearing the user interface) is breathing, the sensors 130 may begin collecting, generating, and/or recording or storing flow generator data. In some embodiments, the flow generator data P2247WO1 (RSMD/0072PC) may be continuously generated and evaluated to detect breathing, and when breathing is detected, the flow generator data corresponding to a defined window can be stored. In some embodiments, the flow generator data is collected corresponding a defined period of time (e.g., to ensure a full breath cycle is collected), such as during a 3 second interval, a 4 second interval, a 5 second interval, a 6 second interval, a 7 second interval, and the like. [0116] At block 510, the training system can optionally preprocess some or all of the flow generator data. In some embodiments, the particular preprocessing used (if any) may vary depending on the particular implementation. For example, in some embodiments, the training system can optionally scale some or all of the metrics reflected in the flow generator data (e.g., to scale the pressure data). In some embodiments, the training system can optionally down- sample some or all of the metrics reflected in the flow generator data (e.g., to down-sample the audio data). In some embodiments, the training system can optionally generate one or more derivative features based on one or more metrics reflected in the flow generator data, as discussed in more detail below. In some embodiments, the training system can optionally align the flow generator data in time (e.g., aligning the metrics such that the start point of the window aligns). [0117] In some embodiments, at block 510, the training system can evaluate the flow generator data collecting during the window to generate additional or alternative features, such as to indicate the maximum value for one or more metrics (e.g., the maximum flow rate and/or pressure during the window of time), the minimum value for one or more metrics (e.g., the minimum flow rate and/or pressure during the window of time), the ratio between the maximum and minimum values for one or more metrics, the range of one or more metrics, the skewness of one or more metrics, the kurtosis of one or more metrics, and the like. [0118] At block 515, the training system determines whether the user interface being used/operated includes an AAV. In an embodiment, this determination can be used as a target or label during training, allowing the model(s) to predict, based on flow generator data collected while the respiratory therapy system is being operated with a user interface, whether the user interface includes an AAV. Generally, the training system can determine whether the user interface includes an AAV using a variety of techniques and operations. For example, in some embodiments, the user of the respiratory therapy system may manually or explicitly indicate the user interface and/or whether the user interface includes an AAV. In some embodiments, the respiratory therapy system may use various techniques to identify the specific make and/or model of the user interface in order to determine whether it includes an P2247WO1 (RSMD/0072PC) AAV. In some embodiments, another user or individual (e.g., a healthcare provider) may indicate the user interface and/or whether the user interface includes an AAV. [0119] In some embodiments, the flow generator data (accessed at block 505) and the determination as to whether the user interface includes an AAV (determined at block 515) can be used to form training data (referred to in some embodiments as a training sample, exemplar, data point, and the like). Generally, the flow generator data (or derivatives therefrom) may be used as the input, while the determination as to whether the user interface includes an AAV is the target output. In this way, one or more machine learning models can be trained, using the data sample, to process flow generator data in order to predict whether the user interface coupled with the respiratory therapy system includes an AAV. [0120] At block 520, the training system determines whether there is any additional training data remaining to be accessed/processed. For example, the training system may determine whether there are more data points in a repository of historical flow generator data that can be used. If so, the method 500 returns to block 505 to process a new exemplar. If not, the method 500 continues to block 525. [0121] At block 525, the training system trains one or more machine learning models to predict the presence (or absence) of AAVs based on flow generator data. For example, using the exemplars discussed above with reference to blocks 505, 510, and 515, the training system can refine the parameters of one or more models to generate more accurate predictions or classifications. Generally, the training process may vary depending on the particular model architecture and particular implementation. [0122] For example, in some embodiments, the machine learning model corresponds to a neural network (e.g., a 1D convolutional neural network), having a set of convolution layers, pooling layers, and the like. In one such embodiment, each metric in the flow generator data (or derivatives therefrom) is used as a corresponding channel in the input to generate a probability measure indicating the likelihood or probability that the flow generator data was generated while the respiratory therapy system was being operated with a user interface that includes an AAV. In some embodiments, the AAV probability measure may correspond to or comprise a continuous value (e.g., between zero and one) and/or a classification value (e.g., a binary value, such as “AAV present” or “AAV absent”, or a trinary value, such as “present,” “absent,” or “inconclusive”). This prediction can then be compared against the label (determined at block 515) to generate a loss, which can then be used to refine the parameter(s) of the model. Although stochastic gradient descent is described (e.g., refining the model P2247WO1 (RSMD/0072PC) independently for each exemplar) for conceptual clarity, in some embodiments, the model may be trained using batch gradient descent. [0123] As another example, in some embodiments, the machine learning model corresponds to a logistic regression model. In one such embodiment, to train the regression model, the training system can estimate parameters of the model (e.g., coefficients) to fit a regression curve to the observed data exemplars, such that new flow generator data can be processed using the estimated parameters to generate a measure indicating the likelihood or probability that the flow generator data was generated while the respiratory therapy system was being operated with a user interface that includes an AAV. [0124] Once the machine learning model is trained, the method 500 continues to block 530. In an embodiment, the training can include one or more rounds or epochs, and may continue until a variety of termination criteria are met. For example, the termination criteria may include determining whether there are any additional exemplars remaining to train the model, whether the model has sufficient prediction accuracy (e.g., determined using test data), whether a defined number of rounds, amount of computing resources, and/or amount of time has been spent training, and the like. [0125] At block 530, the training system deploys the trained machine learning model(s) for runtime inferencing. In an embodiment, deploying the model(s) can include a variety of operations and techniques to provide them for inferencing. For example, if the training system uses the models locally to classify or predict new flow generator data, the training system may simply instantiate the model or otherwise use it to process new data. If one or more other systems use the model(s), the training system may transmit or otherwise provide the trained model(s) to these other systems, such as by transmitting it directly to them or by storing the model in a designated repository or location. For example, the model may be used by one or more components of the system 100, allowing the system 100 to quickly determine whether an AAV is present based on newly-collected data. In at least one embodiment, one or more components of the therapy system (e.g., system 100) may collect flow generator data and optionally preprocess it/perform feature extraction. This flow generator data (or features extracted therefrom) may then be provided to a remote system (e.g., in the cloud) that hosts the machine learning model and uses it to generate AAV predictions. [0126] As discussed in more detail below, the model may then be used to process flow generator data in order to generate a probability measure indicating whether the flow generator data was generated while the respiratory therapy system was being operated in conjunction with a user interface having an AAV. P2247WO1 (RSMD/0072PC) [0127] FIG. 6 is a process flow diagram for a method 600 for using machine learning models to characterize a user interface (e.g., the user interface 124 of the system 100) or an AAV of the user interface (e.g., an AAV) based on flow generator data, according to some implementations of the present disclosure. One or more steps of the method 600 can be implemented using any element or aspect of the system 100 (FIGS. 1-2) described herein. While the method 600 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 600 can be performed in any suitable order. [0128] In some embodiments, the method 600 is performed using a trained machine learning model (e.g., trained using the method 500 of FIG. 5). In some embodiments, the method 600 can be performed by one or more inferencing systems, which may or may not correspond to the training system(s). For example, the inferencing system may correspond or be implemented using one or more components of the system 100. In some embodiments, the inferencing system(s) may correspond to other systems (e.g., remote servers, cloud systems, and the like). [0129] At block 605, the inferencing system accesses flow generator data associated with a user interface. For example, the flow generator data may be collected, generated, or otherwise provided by a respiratory therapy system (e.g., respiratory therapy system 120) while being operated with (e.g., coupled to) a user interface (e.g., user interface 124) in connection with a respiratory therapy. [0130] In some embodiments, as discussed above, the flow generator data is generated and/or collected while the respiratory therapy system is providing airflow. For example, upon determining that the respiratory therapy device 122 has begun providing airflow (e.g., determined based on motor movement), the respiratory therapy system may generate, collect, and/or store/record flow generator data (e.g., continuously, periodically, or during a defined window or period of time). In some embodiments, the flow generator data can additionally or alternatively be collected and/or generated while the respiratory therapy system is not providing airflow. For example, the flow generator data may be generated/stored based on breathing of a user wearing the user interface. [0131] In embodiments, as discussed above, the flow generator data can include a variety of data, depending on the particular implementation. In some embodiments, the flow generator data includes flow data indicating and/or relating to the volume of air flow being provided (e.g., generated by a flow rate sensor 134). In some embodiments, the flow generator data includes pressure data indicating and/or relating to the pressure of the provided air flow (e.g., generated by a pressure sensor 132). In some embodiments, the flow generator data includes motor data P2247WO1 (RSMD/0072PC) indicating and/or relating to the movement or rotation of a motor (e.g., the blower motor). In some embodiments, the flow generator data includes audio data (e.g., generated by an acoustic sensor 141). [0132] In an embodiment, the flow generator data can include any combination of components. For example, in some embodiments, the flow generator data includes at least one of: flow data, pressure data, or motor data. In some embodiments, the flow generator data includes at least two of: flow data, pressure data, or motor data. In some embodiments, the flow generator data includes: flow data, pressure data, and motor data. In some embodiments, the flow generator data includes at least one of: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes at least two of: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes at least three of: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes: flow data, pressure data, motor data, and audio data. [0133] In some aspects, as discussed above, the flow generator data is generated and/or maintained in response to determining that the respiratory therapy device has begun providing air flow. For example, in response to determining that the blower motor has begun spinning, the sensors 130 may begin collecting or generating flow generator data. In some embodiments, the flow generator data is collected during a defined period of time or interval after the blower starts. [0134] In some aspects, as discussed above, the flow generator data is generated and/or maintained while the respiratory therapy device is not providing air flow. For example, in response to determining that the user (while wearing the user interface) is breathing, the sensors 130 may begin collecting or generating flow generator data. In some embodiments, the flow generator data may be continuously generated and evaluated to detect breathing, and when breathing is detected, the flow generator data for a defined window can be stored. In some embodiments, the flow generator data is collected during a defined period of time (e.g., to ensure a full breath cycle is collected), such as during a 3 second interval, a 4 second interval, a 5 second interval, a 6 second interval, a 7 second interval, and the like. [0135] At block 610, the inferencing system determines whether the flow generator data satisfies one or more exception criteria. In some embodiments, the exception criteria relate to confounding factors or events that may result in an inaccurate prediction. For example, the exception criteria may relate to whether the user is talking (e.g., detecting speech using a microphone or acoustic sensor), whether the user is coughing or sneezing (e.g., determined using a microphone or acoustic sensor, flow sensor, pressure sensor, and the like), whether the P2247WO1 (RSMD/0072PC) user is moving (e.g., determined using an accelerometer, gyroscope, acoustic sensor, flow sensor, pressure sensor, and the like), whether there is air leak from the user interface, and the like. In some embodiments, the inferencing system can use various sensors (e.g., sensors 130) to determine whether the exception criteria are satisfied. [0136] If one or more exception criteria are satisfied, the method 600 continues to block 615, where the inferencing system refrains from generating an AAV probability measure for the flow generator data accessed at block 605. In some embodiments, refraining from generating the probability measure includes refraining from processing the flow generator data using the machine learning model(s), such that no probability is generated. This may reduce computational expense, improving computational efficiency of the inferencing system. In some embodiments, refraining from generating the probability measure corresponds to processing the flow generator data to generate a prediction, but refraining from outputting or returning the prediction or otherwise using it to generate a label. In some embodiments, refraining from generating the probability measure corresponds to processing the flow generator data to generate a prediction, and labeling the prediction with a label indicating that it may be untrustworthy or inaccurate due to the exception(s). [0137] Though not depicted in the illustrated example, in some embodiments, after refraining from generating the AAV probability measure, the method 600 may return to block 605 to access additional and/or new flow generator data to assess the exception criteria again at block 610. [0138] Returning to block 610, if the inferencing system determines that the flow generator data does not meet any exception, the method 600 continues to block 620, where the inferencing system generates an AAV probability measure by processing the flow generator data using one or more machine learning models. As discussed above, the probability measure may generally indicate the probability or likelihood that the flow generator data was generated while the respiratory therapy system was being operated with a user interface that comprises an AAV. That is, generating the probability measure may include processing the flow generator data, using one or more learned parameters of the trained machine learning model, to compute a score indicating a probability that the respiratory therapy system is being operated with a user interface comprising an AAV. [0139] Generally, the specific techniques or operations used to generate the AAV probability measure may vary depending on the particular model architecture and implementation. For example, as discussed above, the inferencing system may perform various preprocessing operations (e.g., downsampling, scaling, generating derivative features such as P2247WO1 (RSMD/0072PC) the minimum or maximum value of one or more metrics, and the like). The (potentially preprocessed) flow generator data can then be processed using the trained machine learning model to generate the AAV probability measure. [0140] At block 625, the inferencing system determines whether an AAV is present in the user interface based on the AAV probability and one or more confidence criteria. In some embodiments, the confidence criteria relate to whether the AAV probability is expected to be accurate. For example, the inferencing system may compare the probability measure against one or more thresholds to determine whether the user interface comprises an AAV. For example, if the AAV probability is a score between zero and one, a first threshold (e.g., below 0.2) may be used to classify the user interface as lacking an AAV, a second threshold (e.g., above 0.8) may be used to classify the user interface as including an AAV, and probability measures in the middle may be labeled as uncertain or inconclusive. In some embodiments, in addition to an AAV probability measure, the machine learning model also outputs a confidence measure. In one such embodiment, the confidence criteria may correspond to this confidence measure. For example, the inferencing system may determine whether the model confidence meets or exceeds some threshold. [0141] If, at block 625, the inferencing system determines or infers that an AAV is present (e.g., the AAV probability or classification is above a threshold and/or is associated with a sufficiently high confidence), the method 600 continues to block 630, where the inferencing system generates a label indicating the presence of an AAV in the user interface. Generally, generating the label can include a variety of operations depending on the particular implementation. For example, in some embodiments, the inferencing system labels the flow generator data (accessed at block 605) with a record or flag indicating that the data was generated while the respiratory therapy system was being operated with a user interface that has an AAV. In some aspects, the inferencing system can return or output the label (e.g., to a requesting entity that provided the flow generator data). [0142] If, at block 625, the inferencing system determines or infers that an AAV is not present (e.g., the AAV probability is below a threshold, or the model output generated an “AAV absent” label or category), the method 600 continues to block 635, where the inferencing system generates a label indicating absence of an AAV in the user interface. As discussed above, generating this label can similarly include a variety of operations depending on the particular implementation. For example, in some embodiments, the inferencing system labels the flow generator data (accessed at block 605) with a record or flag indicating that the data was generated while the respiratory therapy system was being operated with a user interface P2247WO1 (RSMD/0072PC) that does not include an AAV. In some aspects, the inferencing system can return or output the label (e.g., to a requesting entity). [0143] In some embodiments, the inferencing system (or another system) may use the generated label to perform a variety of actions. For example, in some embodiments, the inferencing system may control or contribute to the control of one or more airflow parameters (or determine or contribute to the determination of adjustments or settings for the airflow parameters) for a respiratory therapy system based on the label. For example, different airflow parameters may be appropriate depending on whether the user interface is a full face mask (e.g., as indicated by the presence of an AAV) or not. In some embodiments, therefore, adjustments to these airflow parameters may be made (e.g., the parameters may be updated or changed, if needed) to be better-suited for a full face mask (in the event that an AAV is predicted to be present) and better-suited for a non-full face mask (in the event that an AAV is not predicted to be present). [0144] As another example, if the respiratory therapy system includes auto-start functionality (e.g., where the system begins providing air flow when breathing is detected), the AAV label may be used to set one or more thresholds (e.g., flow thresholds) used to trigger the auto-start (e.g., where predicted presence of an AAV can allow a lower flow threshold to be used to perform the auto-start). [0145] As additional examples, the AAV label may be used to enhance other operations or predictions that depend at least in part on whether the user interface us a full face mask, such as mouth leak detection, snore detection, and the like. By using the generated label to infer whether the user interface is full face, these other operations can be performed more accurately and efficiently. [0146] FIG. 7 is a process flow diagram for a method 700 for using machine learning models to characterize a user interface (e.g., the user interface 124 of the system 100) or an AAV of the user interface (e.g., an AAV) based on flow generator data and various criteria, according to some implementations of the present disclosure. One or more steps of the method 700 can be implemented using any element or aspect of the system 100 (FIGS. 1-2) described herein. While the method 700 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 700 can be performed in any suitable order. [0147] In some embodiments, the method 700 is performed using a trained machine learning model (e.g., trained using the method 500 of FIG. 5). In some embodiments, the method 700 can be performed by one or more inferencing systems, which may or may not correspond to the training system(s). In some embodiments, the method 700 provides P2247WO1 (RSMD/0072PC) additional or alternative detail for generating predicted AAV measures, as discussed above with reference to FIG. 6. [0148] At block 705, the inferencing system determines whether one or more initiation criteria are satisfied. Generally, the initiation criteria relate to whether flow generator data should be collected and/or generated to generate an AAV probability measure. In some embodiments, the inferencing system only accesses or generates flow generator data when the initiation criteria are met. In some embodiments, the flow generator data may be continuously generated, but may only be stored or otherwise used to predict AAV presence when the initiation criteria are met. [0149] In some embodiments, the initiation criteria relate to whether the user is breathing while wearing the user interface (e.g., if the respiratory therapy system is not currently providing air flow). For example, the inferencing system may evaluate flow generator data or other data to detect whether the user is wearing the user interface, whether they are breathing, whether any exceptions are present (e.g., talking), and the like. As another example, the initiation criteria may relate to whether the respiratory therapy system is providing air (or has just begun providing airflow). For example, the inferencing system may evaluate flow generator data (such as motor speed) to determine whether the system has begun generating airflow. [0150] If, at block 705, the criteria are not met, the method 700 iterates until the criteria are satisfied. If the inferencing system determines that the criteria are satisfied, the method 700 continues to block 710. At block 710, the inferencing system generates, collects, or otherwise accesses flow generator data for a duration, window, or interval of time. In some embodiments, the length of the interval may vary depending on the particular implementation and/or depending on which initiation criterion was met. For example, in some embodiments, if the initiation criteria relate to starting of the blower motor, the inferencing system may collect data for a relatively small interval (e.g., one or two seconds) to capture the closing of the AAV (if present) in conjunction with this start. In some embodiments, if the initiation criteria relate to user breathing, the inferencing system may collect data for a relatively larger interval (e.g., five to ten seconds) to increase the probability that one or more full breath cycles are captured (thereby improving the probability that at least one AAV closure (if present) is captured). [0151] As discussed above, the flow generator data may generally be collected, generated, or otherwise provided by a respiratory therapy system (e.g., respiratory therapy system 120) while being operated with a user interface (e.g., user interface 124) in connection with a respiratory therapy. In embodiments, as discussed above, the flow generator data can include P2247WO1 (RSMD/0072PC) a variety of data, depending on the particular implementation, such as flow data, pressure data, motor data, and/or audio data. [0152] In some aspects, the particular contents of the flow generator data generated and/or used may vary depending on the particular implementation, and/or depending on the initiation criteria used. For example, in some embodiments, the motor data may be evaluated to determine whether the motor is on. In one such embodiment, if the motor is on, the motor speed data may itself be used as input to the model. If the motor is off, in an embodiment, the motor data may itself not be used as input to the model. As another example, in some embodiments, audio data may be used as input if the motor is on (e.g., alongside the flow data, pressure data, and/or motor data). If the motor is off, in an embodiment, the audio data may be excluded (e.g., the system may process only the flow data and pressure data using the model). In other embodiments, the audio data may be used as input when the motor is off as well. [0153] At block 715, the inferencing system generates an AAV probability measure based on the flow generated collected or generated at block 710. For example, as discussed above, the inferencing system may optionally preprocess the data (e.g., to determine the maximums, minimums, skewness values, and the like), and then process some or all of the (optionally preprocessed) data using one or more trained machine learning models to generate a probability measure indicating whether the user interface comprises an AAV. [0154] At block 720, the inferencing system determines whether one or more additional iterations should be used to predict AAV presence. In some embodiments, whether to use one or multiple iterations of flow generator data collection may vary depending on the particular implementation. For example, in some embodiments, the inferencing system may determine whether to use at least one additional iteration based on determining that the probability and/or confidence meet one or more criteria (e.g., if the probability measure is inconclusive and/or the confidence is sufficiently low, the inferencing system may determine to perform another iteration). In some embodiments, the number of iterations (or whether to use iterations at all) may be specified (e.g., as a hyperparameter). For example, the inferencing system may be configured to perform ^ iterations, to iteratively collect and/or process flow generator data until a defined period of time has elapsed, to iteratively collect and/or process flow generator data throughout the sleep interval, and the like. [0155] In some embodiments, the iterations can include passive collection or generation of flow generator data (e.g., collecting the data whenever appropriate, such as when the user is breathing without airflow provided and/or whenever the user initiates or turns on airflow). In some embodiments, the iterations can include active initiation of the flow generator data P2247WO1 (RSMD/0072PC) collection. For example, the inferencing system may perform multiple initiations/flow starts within a relatively brief period (e.g., briefly starting and stopping airflow a number of times) to perform the iterations. [0156] In some embodiments, the inferencing system can use different airflow parameters for one or more different iterations. For example, during a sequence of iterations, the inferencing system may use a sequence of airflow ramp rates (e.g., the rate at which airflow increases, at the start of therapy, to reach the target therapeutic pressure or flow rate), such as by using a first ramp rate for the first iteration, a second (relatively higher) ramp rate for the second iteration, and so on. Similarly, the inferencing system may use differing target pressures, differing target flow rates, and the like. In this way, the inferencing system can generate more varied flow generator data. [0157] If no further iterations are to be used, the method 700 continues to block 725, where the inferencing system optionally aggregates the generated probability measures from each iteration. For example, the inferencing system may compute the average probability measure, the median probability measure, the sum of the probability measures, and the like. In an embodiment, this aggregated probability measure can then be used to generate the AAV label (e.g., by comparing it against one or more thresholds). [0158] In some embodiments, using data generated over multiple iterations (e.g., multiple times in one night, over multiple nights, using differing flow parameters, and the like), the inferencing system may be able to generate more accurate and reliable AAV predictions, as compared to single-iteration solutions. [0159] FIG. 8 is a process flow diagram for a method 800 for using a machine learning model to predict anti-asphyxia valve presence based on flow generator data, according to some implementations of the present disclosure. One or more steps of the method 800 can be implemented using any element or aspect of the system 100 (FIGS. 1-2) described herein. While the method 800 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 800 can be performed in any suitable order. In some embodiments, the method 800 is performed using a trained machine learning model. In some embodiments, the method 800 can be performed by one or more inferencing systems, which may or may not correspond to training system(s). For example, the inferencing system may correspond or be implemented using one or more components of the system 100. In some embodiments, the inferencing system(s) may correspond to other systems (e.g., remote servers, cloud systems, and the like). [0160] At block 805, first flow generator data provided by a respiratory therapy system P2247WO1 (RSMD/0072PC) (e.g., respiratory therapy system 120 of FIG. 1) is accessed, the first flow generator data comprising at least one of: (i) flow data (e.g., generated by a flow rate sensor 134 of FIG. 1), (ii) pressure data (e.g., generated by a pressure sensor 132 of FIG. 1), or (iii) motor data. [0161] At block 810, a first probability measure is generated by processing the first flow generator data using a trained machine learning model. [0162] At block 815, a label indicating whether the respiratory therapy system was being operated with a user interface (e.g., user interface 124 of FIG. 1) comprising an anti-asphyxia valve (e.g., AAV 374 of FIGS. 3A and 3B) at a time when the flow generator data was generated is generated based on the first probability measure. [0163] FIG. 9 is a process flow diagram for a method 900 for training a machine learning model to predict anti-asphyxia valve presence based on flow generator data, according to some implementations of the present disclosure. [0164] At block 905, first flow generator data provided by a respiratory therapy system (e.g., respiratory therapy system 120 of FIG. 1) is accessed, the first flow generator data comprising at least one of: (i) flow data (e.g., generated by a flow rate sensor 134 of FIG. 1), (ii) pressure data (e.g., generated by a pressure sensor 132 of FIG. 1), or (iii) motor data. [0165] At block 910, it is determined whether the respiratory therapy system was being operated with a user interface (e.g., user interface 124 of FIG. 1) comprising an anti-asphyxia valve (e.g., AAV 374 of FIGS. 3A and 3B) when the first flow generator data was collected. [0166] At block 915, a machine learning model is trained, based on the first flow generator data and the determination whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve, to predict presence of anti-asphyxia valves. Experimental Data [0167] One or more aspects of the above-described methods and techniques in order to generate test or experimental flow generator data for a variety of user interfaces under various operating conditions. [0168] FIGS. 10A and 10B illustrate flow generator data signatures for various full face user interfaces. Specifically, FIGS. 10A and 10B depict signatures of AAV closure at the beginning of the session for full face masks. Graph 1000A depicts flow generator data for an AirFit^TM F10 model, graph 1000B depicts flow generator data for an AirFit^TM F20 model, graph 1000C depicts flow generator data for an AirFit^TM F30i model, graph 1000D depicts flow generator data for an AirFit^TM F30 model, graph 1000E depicts flow generator data for an AmaraView^TM model, graph 1000F depicts flow generator data for an DreamWear^TM FullFace model, graph 1000G depicts flow generator data for an Simplus^TM F10 model, and graph P2247WO1 (RSMD/0072PC) 1000H depicts flow generator data for an Vitera^TM model. [0169] In the illustrated graphs 1000A-H (collectively, graphs 1000), the data for each flow generator feature may have undergone one or more preprocessing operations to facilitate visualization and/or use with one or more machine learning models. In the depicted examples, the data indicated by lines 1015A-H (collectively, lines 1015) reflects the collected audio data for each user interface, the data indicated by lines 1020A-H (collectively, lines 1020) reflects the collected blower flow data for each user interface (e.g., the volume of air flow in liters per second), the data indicated by lines 1025A-H (collectively, lines 1025) reflects the collected blower pressure data for each user interface (e.g., the pressure of air flow in centimeters of water column (cmH2O)), and the data indicated by lines 1030A-H (collectively, lines 1030) reflects the collected motor speed data for each user interface (e.g., in revolutions per minute (RPM). [0170] Additionally, in the illustrated graphs 1000, the lines 1005A-H (collectively, lines 1005) indicate when the motor turned on/began ramping up, and the boxes 1010A-H (collectively, boxes 1010) indicate the AAV closure signature in the various flow generator data, which consists of a distinctive shape in the acoustic wave form as well as peaks in the remaining flow generator signals (e.g., within two seconds of the motor speed ramping up). [0171] FIG. 11A, 11B, and 11C illustrate flow generator data signatures for various non- full face user interfaces. Specifically, FIGS.11A, 11B, and 11C depict flow generator data for the beginning of the session for non-full face masks (such as nasal masks, pillow masks, and the like). Graph 1100A depicts flow generator data for an AirFit^TM N20 model, graph 1100B depicts flow generator data for an AirFit^TM N20 Classic model, graph 1100C depicts flow generator data for an AirFit^TM N30 model, graph 1100D depicts flow generator data for an AirFit^TM N30i model, graph 1100E depicts flow generator data for an AirFit^TM P30i model, graph 1100F depicts flow generator data for an AirFit^TM P10 model, graph 1100G depicts flow generator data for a Brevida^TM model, graph 1100H depicts flow generator data for a DreamWear^TM Pillow model, graph 1100I depicts flow generator data for a DreamWisp^TM model, graph 1100J depicts flow generator data for a Wisp^TM Nasal model, graph 1100K depicts flow generator data for an Eson2^TM model, and graph 1100L depicts flow generator data for a DreamWear^TM Nasal model. [0172] In the illustrated graphs 1100A-L (collectively, graphs 1100), the data for each flow generator feature may have undergone one or more preprocessing operations to facilitate visualization and/or use with one or more machine learning models. In the depicted examples, the data indicated by lines 1115A-L (collectively, lines 1115) reflects the collected audio data P2247WO1 (RSMD/0072PC) for each user interface, the data indicated by lines 1120A-L (collectively, lines 1120) reflects the collected blower flow data for each user interface (e.g., the volume of air flow in liters per second), the data indicated by lines 1125A-L (collectively, lines 1125) reflects the collected blower pressure data for each user interface (e.g., the pressure of air flow in centimeters of water column (cmH2O)), and the data indicated by lines 1130A-L (collectively, lines 1130) reflects the collected motor speed data for each user interface (e.g., in revolutions per minute (RPM). [0173] Additionally, in the illustrated graphs 1100, the lines 1105A-L (collectively, lines 1105) indicate when the motor turned on/began ramping up. As illustrated, no peaks can be observed in one or more of the flow generator signals, such as the blower flow data and/or the blower pressure data (unlike the signatures for full face masks, as discussed above), and the acoustic signature differs than that of full face masks, as discussed above. [0174] FIG.12 illustrates flow generator data signatures for various full face user interfaces while unpowered. Specifically, FIG. 12 depicts signatures of AAV closure while off therapy (e.g., when the motor speed is zero) and the user is wearing/breathing into the user interface. As discussed above, this may be leveraged in an auto-start scenario (where the patient puts the user interface on and the motor start is triggered when breathing is detected). FIG. 12 depicts flow generator on a graph 1200, where the portion 1205A depicts flow generator data for a DreamWear^TM FullFace model, the portion 1205A depicts flow generator data for an AirFit^TM F20 model, and the portion 1205A depicts flow generator data for an AirFit^TM N20 model. [0175] In the illustrated graph 1200, the data for each flow generator feature may have undergone one or more preprocessing operations to facilitate visualization and/or use with one or more machine learning models. In the depicted examples, the data indicated by line 1220 reflects the collected blower flow data for each user interface (e.g., the volume of air flow in liters per second), the data indicated by line 1225 reflects the collected blower pressure data for each user interface (e.g., the pressure of air flow in centimeters of water column (cmH2O)), and the data indicated by line 1230 reflects the collected motor speed data for each user interface (e.g., in revolutions per minute (RPM). [0176] Additionally, in the illustrated graph 1200, the lines 1005A-H (collectively, lines 1005) indicate when the motor turned on/began ramping up, and the boxes 1010A-H (collectively, boxes 1010) indicate the AAV closure signature in the various flow generator data, which consists of a distinctive shape in the acoustic wave form as well as peaks in the remaining flow generator signals (e.g., within two seconds of the motor speed ramping up). [0177] As depicted, full flow masks (such as the DreamWear^TM FullFace model and the P2247WO1 (RSMD/0072PC) AirFit^TM F20 model, depicted in portions 1205A and 1205B, respectively) have different signatures in terms of flow and pressure, as compared to nasal masks (such as the AirFit^TM N20 model, depicted in portion 1205C). For example, nasal masks tend to result in flow and/or pressure with large magnitude variation that is generally symmetric above and below a value of zero, while full face masks with AAVs tend to result in flow and/or pressure data that is smaller and/or asymmetric around a value of zero. [0178] FIG. 13 is a graph 1300 depicting notched box plots of experimental model accuracy for models trained on various features, according to some implementations of the present disclosure. In the illustrated example, ensembles of ten machine learning models were trained on six individual configurations of feature data: each individual flow generator signal (e.g., motor speed, air flow, or air pressure), on a combination of flow generator signals (e.g., motor speed, air flow, and air pressure), on audio data only, and on all flow generator signals (e.g., motor speed, air flow, air pressure, and audio). Models were trained on a subset of data collected on human subjects in controlled conditions, and tested on an independent test set, with coverage for twenty mask types. [0179] In the illustrated graph 1300, resulting model accuracy is plotted on the vertical axis using a respective notched box plot for each respective combination of features. Specifically, notched box plot 1305A corresponds to models trained on motor data only (e.g., motor speed), notched box plot 1305B corresponds to models trained on flow data only (e.g., the air flow rate), notched box plot 1305C corresponds to models trained on pressure data only (e.g., air pressure), notched box plot 1305D corresponds to models trained on flow generator data (including motor speed data, air pressure data, and air flow data) without audio data, notched box plot 1305E corresponds to models trained on audio data only, and notched box plot 1305F corresponds to models trained on flow generator data including motor speed data, air pressure data, air flow data, and audio data. Example Clauses [0180] Clause 1: A method, comprising: accessing first flow generator data provided by a respiratory therapy system, the first flow generator data comprising at least one of: (i) flow data, (ii) pressure data, or (iii) motor data; generating a first probability measure by processing the first flow generator data using a trained machine learning model; and generating, based on the first probability measure, a label indicating whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve at a time when the flow generator data was generated. [0181] Clause 2: A method according to Clause 1, wherein the first flow generator data P2247WO1 (RSMD/0072PC) comprises at least two of (i) flow data, (ii) pressure data, or (iii) motor data. [0182] Clause 3: A method according to Clause 1 or 2, wherein the first flow generator data comprises (i) flow data, (ii) pressure data, and (iii) motor data. [0183] Clause 4: A method according to any of Clauses 1-3, wherein the first flow generator data further comprises audio data. [0184] Clause 5: A method according to any of Clauses 1-4, further comprising: determining that the respiratory therapy system has begun providing airflow at a first time; and collecting the first flow generator data corresponding to a predefined window of time beginning at the first time. [0185] Clause 6: A method according to any of Clauses 1-5, wherein: the first flow generator data is collected when the respiratory therapy system is not providing airflow, and the first flow generator data is indicative of breathing of a user of the respiratory therapy system. [0186] Clause 7: A method according to Clause 6, wherein the first flow generator data comprises at least one of: (i) a maximum value of at least one of flow rate or pressure, (ii) a minimum value of at least one of flow rate or pressure, (iii) a skewness value of at least one of flow rate or pressure, or (iv) a kurtosis value of at least one of flow rate or pressure. [0187] Clause 8: A method according to any of Clauses 1-7, further comprising: accessing second flow generator data provided by the respiratory therapy system; generating a second probability measure by processing the second flow generator data using the trained machine learning model; and generating the label indicating whether the respiratory therapy system was being operated with the user interface comprising the anti-asphyxia valve at the time when the flow generator data was generated based further on the second probability measure. [0188] Clause 9: A method according to any of Clauses 1-8, wherein: the first flow generator data was collected while the respiratory therapy system used a first airflow ramp rate, and the second flow generator data was collected while the respiratory therapy system used a second airflow ramp rate. [0189] Clause 10: A method according to any of Clauses 1-9, further comprising preprocessing the first flow generator data prior to processing it using the trained machine learning model, comprising at least one of: (i) scaling the first flow generator data, or (ii) downsampling the first flow generator data. [0190] Clause 11: A method according to any of Clauses 1-10, further comprising determining an adjustment to at least one airflow parameter of the respiratory therapy system based on the label indicating whether the user interface comprises an anti-asphyxia valve. P2247WO1 (RSMD/0072PC) [0191] Clause 12: A method according to any of Clauses 1-11, further comprising: accessing third flow generator data provided by the respiratory therapy system; determining that one or more exception criteria are satisfied for the respiratory therapy system, with respect to the third flow generator data; and in response to determining that the one or more exception criteria are satisfied, performing at least one of: refraining from generating a probability measure for the third flow generator data, or generating a flag indicating that the one or more exception criteria are satisfied. [0192] Clause 13: A method according to Clause 12, wherein determining that the one or more exception criteria are satisfied comprises at least one of: (i) detecting air leak from the user interface based on the third flow generator data, (ii) detecting speech from the user using a microphone sensor, or (iii) detecting movement by the user using an accelerometer sensor. [0193] Clause 14: A method according to any of Clauses 1-13, wherein the motor data comprises at least one of (i) an indication of whether a motor of the respiratory therapy system is on, (ii) a speed of the motor, or (iii) a ramp rate of the motor. [0194] Clause 15: A method according to any of Clauses 1-14, wherein generating the first probability measure comprises processing the first flow generator data using one or more learned parameters of the trained machine learning model to compute a score indicating a probability that the first respiratory therapy system was being operated with the user interface comprising the AAV at the time when the flow generator data was generated. [0195] Clause 16: A method, comprising: accessing first flow generator data provided by a respiratory therapy system, the first flow generator data comprising at least one of: (i) flow data, (ii) pressure data, or (iii) motor data; determining whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve when the first flow generator data was collected; and training a machine learning model, based on the first flow generator data and the determination whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve, to predict presence of anti- asphyxia valves. [0196] Clause 17: A method according to Clause 16, wherein the first flow generator data comprises at least two of (i) flow data, (ii) pressure data, or (iii) motor data. [0197] Clause 18: A method according to Clause 16 or 17, wherein the first flow generator data comprises (i) flow data, (ii) pressure data, and (iii) motor data. [0198] Clause 19: A method according to any of Clauses 16-18, wherein the first flow generator data further comprises audio data. [0199] Clause 20: A method according to any of Clauses 16-19, further comprising: P2247WO1 (RSMD/0072PC) determining that the respiratory therapy system has begun providing airflow at a first time; and collecting the first flow generator data corresponding to a predefined window of time beginning at the first time. [0200] Clause 21: A method according to any of Clauses 16-20, wherein: the first flow generator data is collected when the respiratory therapy system is not providing airflow, and the first flow generator data is indicative of breathing of a user of the respiratory therapy system. [0201] Clause 22: A method according to Clause 21, wherein the first flow generator data comprises at least one of: (i) a maximum value of at least one of flow rate or pressure, (ii) a minimum value of at least one of flow rate or pressure, (iii) a skewness value of at least one of flow rate or pressure, or(iv) a kurtosis value of at least one of flow rate or pressure. [0202] Clause 23: A method according to any of Clauses 16-22, further comprising preprocessing the first flow generator data prior to processing it using the trained machine learning model, comprising at least one of: (i) scaling the first flow generator data, or (ii) downsampling the first flow generator data. [0203] Clause 24: A system, comprising: a control system comprising one or more processors; and a memory having stored thereon machine readable instructions; wherein the control system is coupled to the memory, and the method of any one of Clauses 1 to 23 is implemented when the machine readable instructions in the memory are executed by at least one of the one or more processors of the control system. [0204] Clause 25: A system according to Clause 24, further comprising an electronic interface configured to receive data associated with a sleep session of a user, wherein the received data includes acoustic data associated with airflow caused by operation of the respiratory therapy system. [0205] Clause 26: A system according to Clause 24 or 25, further comprising one or more microphones communicatively coupled to the respiratory therapy system, wherein the one or more microphones are configured to generate acoustic data. [0206] Clause 27: A system according to any of Clauses 24-26, further comprising a flow rate sensor communicatively coupled to the respiratory therapy system, wherein the flow rate sensor is configured to generate flow rate data associated with pressurized air supplied to the user of the respiratory therapy system. [0207] Clause 28: A system according to any of Clauses 24-27, further comprising a pressure sensor communicatively coupled to the respiratory therapy system, wherein the pressure sensor is configured to generate pressure data associated with pressurized air supplied P2247WO1 (RSMD/0072PC) to the user of the respiratory therapy system. [0208] Clause 29: A system according to any of Clauses 24-28, further comprising a motor sensor communicatively coupled to the respiratory therapy system, wherein the motor sensor is configured to generate motor data associated with pressurized air supplied to the user of the respiratory therapy system. [0209] Clause 30: A system according to any of Clauses 26-29, wherein at least one of the one or more microphones, the flow rate sensor, the pressure sensor, or the motor sensor are comprised in a respiratory therapy device. [0210] Clause 28: A system for characterizing a user interface of a respiratory therapy system, the system comprising a control system configured to implement the method of any one of claims 1 to 23. [0211] Clause 29: A system according to Clause 28, wherein the characterizing is based, at least in part, on whether the user interface is determined to comprise an anti-asphyxia valve. [0212] Clause 30: A computer program product comprising instructions which, when executed by a computer, cause the computer to carry out the method of any one of claims 1 to 23. [0213] Clause 31: A computer program product according to Clause 30, wherein the computer program product is a non-transitory computer readable medium. Additional Considerations [0214] 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. [0215] 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. [0216] 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 P2247WO1 (RSMD/0072PC) 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. [0217] 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. [0218] 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). [0219] 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. [0220] 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 P2247WO1 (RSMD/0072PC) 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. [0221] 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. [0222] 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 training system and/or inferencing system) or related data available in the cloud. For example, the training system and/or inferencing system could execute on a computing system in the cloud and train and use machine learning models to predict AAV presence. In such a case, the training system and/or inferencing system could receive and process the flow generator data, and store the models and AAV 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). [0223] 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 P2247WO1 (RSMD/0072PC) 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. P2247WO1 (RSMD/0072PC)

Claims

CLAIMS WHAT IS CLAIMED IS: 1. A method, comprising: accessing first flow generator data provided by a respiratory therapy system, the first flow generator data comprising at least one of: (i) flow data, (ii) pressure data, or (iii) motor data; generating a first probability measure by processing the first flow generator data using a trained machine learning model; and generating, based on the first probability measure, a label indicating whether the respiratory therapy system was being operated with a user interface comprising an anti- asphyxia valve at a time when the flow generator data was generated. 2. The method of claim 1, wherein the first flow generator data comprises at least two of (i) flow data, (ii) pressure data, or (iii) motor data. 3. The method of claim 1 or claim 2, wherein the first flow generator data comprises (i) flow data, (ii) pressure data, and (iii) motor data. 4. The method of any one of claims 1 to 3, wherein the first flow generator data further comprises audio data. 5. The method of any one of claims 1 to 4, further comprising: determining that the respiratory therapy system has begun providing airflow at a first time; and collecting the first flow generator data corresponding to a predefined window of time beginning at the first time. 6. The method of any one of claims 1 to 5, wherein: the first flow generator data is collected when the respiratory therapy system is not providing airflow, and the first flow generator data is indicative of breathing of a user of the respiratory therapy system. 7. The method of claim 6, wherein the first flow generator data comprises at least one of: P2247WO1 (RSMD/0072PC) (i) a maximum value of at least one of flow rate or pressure, (ii) a minimum value of at least one of flow rate or pressure, (iii) a skewness value of at least one of flow rate or pressure, or (iv) a kurtosis value of at least one of flow rate or pressure. 8. The method of any one of claims 1 to 7, further comprising: accessing second flow generator data provided by the respiratory therapy system; generating a second probability measure by processing the second flow generator data using the trained machine learning model; and generating the label indicating whether the respiratory therapy system was being operated with the user interface comprising the anti-asphyxia valve at the time when the flow generator data was generated based further on the second probability measure. 9. The method of claim 8, wherein: the first flow generator data was collected while the respiratory therapy system used a first airflow ramp rate, and the second flow generator data was collected while the respiratory therapy system used a second airflow ramp rate. 10. The method of any one of claims 1 to 9, further comprising preprocessing the first flow generator data prior to processing it using the trained machine learning model, comprising at least one of: (i) scaling the first flow generator data, or (ii) downsampling the first flow generator data. 11. The method of any one of claims 1 to 10, further comprising determining an adjustment to at least one airflow parameter of the respiratory therapy system based on the label indicating whether the user interface comprises an anti-asphyxia valve. 12. The method of any one of clauses 1 to 11, further comprising: accessing third flow generator data provided by the respiratory therapy system; determining that one or more exception criteria are satisfied for the respiratory therapy system, with respect to the third flow generator data; and in response to determining that the one or more exception criteria are satisfied, performing at least one of: P2247WO1 (RSMD/0072PC) refraining from generating a probability measure for the third flow generator data, or generating a flag indicating that the one or more exception criteria are satisfied. 13. The method of claim 12, wherein determining that the one or more exception criteria are satisfied comprises at least one of: (i) detecting air leak from the user interface based on the third flow generator data, (ii) detecting speech from the user using a microphone sensor, or (iii) detecting movement by the user using an accelerometer sensor. 14. The method of any one of claims 1-13, wherein the motor data comprises at least one of (i) an indication of whether a motor of the respiratory therapy system is on, (ii) a speed of the motor, or (iii) a ramp rate of the motor. 15. The method of any one of claims 1-14, wherein generating the first probability measure comprises processing the first flow generator data using one or more learned parameters of the trained machine learning model to compute a score indicating a probability that the first respiratory therapy system was being operated with the user interface comprising the AAV at the time when the flow generator data was generated. 16. A method, comprising: accessing first flow generator data provided by a respiratory therapy system, the first flow generator data comprising at least one of: (i) flow data, (ii) pressure data, or (iii) motor data; determining whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve when the first flow generator data was collected; and training a machine learning model, based on the first flow generator data and the determination whether the respiratory therapy system was being operated with a user interface comprising an anti-asphyxia valve, to predict presence of anti-asphyxia valves. 17. The method of claim 16, wherein the first flow generator data comprises at least two of (i) flow data, (ii) pressure data, or (iii) motor data. P2247WO1 (RSMD/0072PC) 18. The method of claim 16 or claim 17, wherein the first flow generator data comprises (i) flow data, (ii) pressure data, and (iii) motor data. 19. The method of any one of claims 16-18, wherein the first flow generator data further comprises audio data. 20. The method of any one of claims 16 to 19, further comprising: determining that the respiratory therapy system has begun providing airflow at a first time; and collecting the first flow generator data corresponding to a predefined window of time beginning at the first time. 21. The method of any one of claims 16-20, wherein: the first flow generator data is collected when the respiratory therapy system is not providing airflow, and the first flow generator data is indicative of breathing of a user of the respiratory therapy system. 22. The method of claim 21, wherein the first flow generator data comprises at least one of: (i) a maximum value of at least one of flow rate or pressure, (ii) a minimum value of at least one of flow rate or pressure, (iii) a skewness value of at least one of flow rate or pressure, or (iv) a kurtosis value of at least one of flow rate or pressure. 23. The method of any one of claims 16-22, further comprising preprocessing the first flow generator data prior to processing it using the trained machine learning model, comprising at least one of: (i) scaling the first flow generator data, or (ii) downsampling the first flow generator data. 24. A system comprising: a control system comprising one or more processors; and a memory having stored thereon machine readable instructions; P2247WO1 (RSMD/0072PC) wherein the control system is coupled to the memory, and the method of any one of claims 1 to 23 is implemented when the machine readable instructions in the memory are executed by at least one of the one or more processors of the control system. 25. The system of claim 24, further comprising an electronic interface configured to receive data associated with a sleep session of a user, wherein the received data includes acoustic data associated with airflow caused by operation of the respiratory therapy system. 26. The system of claim 24 or 25, further comprising one or more microphones communicatively coupled to the respiratory therapy system, wherein the one or more microphones are configured to generate acoustic data. 27. The system of any one of claims 24 to 26, further comprising a flow rate sensor communicatively coupled to the respiratory therapy system, wherein the flow rate sensor is configured to generate flow rate data associated with pressurized air supplied to the user of the respiratory therapy system. 28. The system of any one of claims 24-27, further comprising a pressure sensor communicatively coupled to the respiratory therapy system, wherein the pressure sensor is configured to generate pressure data associated with pressurized air supplied to the user of the respiratory therapy system. 29. The system of any one of claims 24-28, further comprising a motor sensor communicatively coupled to the respiratory therapy system, wherein the motor sensor is configured to generate motor data associated with pressurized air supplied to the user of the respiratory therapy system. 30. The system of any one of claims 26-29, wherein at least one of the one or more microphones, the flow rate sensor, the pressure sensor, or the motor sensor are comprised in a respiratory therapy device. 31. A system for characterizing a user interface of a respiratory therapy system, the system comprising a control system configured to implement the method of any one of claims 1 to 23. P2247WO1 (RSMD/0072PC) 32. The system of claim 31, wherein the characterizing is based, at least in part, on whether the user interface is determined to comprise an anti-asphyxia valve. 33. A computer program product comprising instructions which, when executed by a computer, cause the computer to carry out the method of any one of claims 1 to 23. 34. The computer program product of claim 30, wherein the computer program product is a non-transitory computer readable medium. P2247WO1 (RSMD/0072PC)