System and method for characterizing user interface using traffic generator data

Abstract

In accordance with some implementations of the present disclosure, a method includes accessing flow generator data provided by a respiratory therapy system, the flow generator data including at least one of flow data, pressure data, or motor data. The method further includes generating a probability metric by processing the first flow generator data using a trained machine learning model, and generating a tag based on the probability metric that indicates whether the respiratory therapy system is operating with a user interface that includes an anti-suffocation valve when the flow generator data is generated.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 480,431, filed on January 18, 2023, which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure generally relates to systems and methods for using machine learning to characterize a user interface and / or an anti-asphyxia valve of a user interface, and more particularly to systems and methods for using machine learning to characterize a user interface and / or an AAV of a user interface based on flow generator data. Background Art

[0004] Many individuals suffer from sleep-related and / or respiratory-related disorders, such as periodic limb movement disorder (PLMD), restless legs 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.

[0005] Each respiratory therapy system typically has a respiratory therapy device connected to a user interface (e.g., a mask) via a conduit and optional connector. The user wears the user interface, and a pressurized air flow is supplied from the respiratory therapy device via the conduit. The user interface is typically a user interface of a specific class and type for the user, such as a direct or indirect connection for that class of user interface, and a full face mask, partial face mask, nasal mask, or nasal pillows for that type of user interface. In addition to the specific class and type, the user interface is typically a specific model manufactured by a specific manufacturer, such as the AirFit manufactured by ResMed. TM F20. For various reasons, such as ensuring that the user is using the correct user interface, it may be beneficial to know the specific category and type of user interface that the user is wearing, as well as the specific models available for the respiratory system.

[0006] Thus, understanding the user interface of a respiratory therapy system can be beneficial for improving control of the therapy delivered to the user. For example, understanding the user interface can be beneficial for accurately measuring or estimating therapy parameters (such as pressure and ventilation flow in the user interface). Thus, understanding what user interface is being used can enhance therapy. Although some respiratory therapy devices may include a menu system that allows the 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. Therefore, it may be advantageous to determine the user interface independently of the user input.

[0007] In addition, the user interface pad, the vent on the user interface or the connector to the user interface and other user interface components may deteriorate over time. For example, due to the accumulation of unwanted material (e.g., saliva, mucus, skin cells, bedding fibers, debris from the user interface), the vent may be blocked or occluded over time, or temporarily / instantaneously blocked or occluded (e.g., against bedding or pillow). A deteriorated and / or blocked vent may cause the ventilation flow performance of the user interface to deviate from normal performance, which may affect treatment comfort or treatment accuracy. A deteriorated and / or blocked vent may also cause the accumulation of CO2, which in turn may result in inefficient treatment, additional noise, patient discomfort or even danger to the user. Therefore, when the vent deteriorates or becomes blocked, it may have a negative impact on treatment. Therefore, some users will interrupt the use of the respiratory therapy system due to discomfort and / or inaccurate treatment caused by deteriorated user interface components. Therefore, it may be advantageous to determine the user interface that a user is using so that the age of the user interface, when the user interface was last changed, etc. can be monitored and action taken to avoid or remedy a degraded user interface or user interface component.

[0008] The present disclosure is directed to addressing these and other problems. Summary of the Invention

[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 including at least one of: (i) flow data, (ii) pressure data, or (iii) motor data; generating a first probability metric by processing the first flow generator data using a trained machine learning model; and generating a label based on the first probability metric, the label indicating whether the respiratory therapy system was operating with a user interface including an anti-asphyxia valve when the flow generator data was generated.

[0010] According to some embodiments of the present disclosure, a method includes accessing first flow generator data provided by a respiratory therapy system, the first flow generator data including at least one of: (i) flow data, (ii) pressure data, or (iii) motor data; determining whether the respiratory therapy system is operating with a user interface that includes an anti-asphyxia valve when the first flow generator data is collected; and training a machine learning model based on the first flow generator data and the determination of whether the respiratory therapy system is operating with the user interface that includes an anti-asphyxia valve to predict the presence of an anti-asphyxia valve.

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

[0012] 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 of the methods disclosed herein.

[0013] According to some implementations of the present disclosure, a computer program product includes instructions that, when executed by a computer, cause the computer to perform any of the methods disclosed herein.

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

[0015] Figure 1 is a functional block diagram of a system according to some specific implementations of the present disclosure.

[0016] Figure 2 According to some specific implementations of the present disclosure Figure 1 A perspective view of at least a portion of the system, a user, and a bed partner.

[0017] Figure 3A is a perspective diagram of a type of user interface according to some specific implementations of the present disclosure.

[0018] Figure 3B According to some specific implementations of the present disclosure Figure 3A Exploded view of the user interface.

[0019] Figure 4 According to some specific implementations of the present disclosure Figure 1A rear perspective view of a respiratory therapy device of a system.

[0020] Figure 5 is a process flow diagram of a method for training a machine learning model to characterize a user interface or an AAV of a user interface based on traffic generator data according to some specific implementations of the present disclosure.

[0021] Figure 6 is a process flow diagram of a method for characterizing a user interface or an AAV of a user interface based on traffic generator data using a machine learning model according to some specific implementations of the present disclosure.

[0022] Figure 7 is a process flow diagram of a method for characterizing a user interface or an AAV of a user interface based on traffic generator data and multiple criteria using a machine learning model according to some specific implementations of the present disclosure.

[0023] Figure 8 is a process flow diagram of a method for predicting the presence of an anti-asphyxia valve based on flow generator data using a machine learning model according to some implementations of the present disclosure.

[0024] Figure 9 is a process flow diagram of a method for training a machine learning model to predict the presence of an anti-asphyxia valve based on flow generator data according to some specific implementations of the present disclosure.

[0025] Figure 10A Shows various full-face user interfaces (including AirFit TM F10 model, AirFit TM F20 model, AirFit TM F30i model and AirFit TM Traffic generator data signature for F30 model).

[0026] Figure 10B Shows various full-face user interfaces (including AmaraView TM Model (Philips Respironics), DreamWear TM FullFace model (Philips Respironics), Simplus TM Model (Fisher & Paykel) and Vitera TM Traffic generator data signature for the model (Fisher & Paykel).

[0027] Figure 11A Various non-full-face mask user interfaces (including AirFitTM N20 model, AirFit TM N20 classic model, AirFit TM N30 Model and AirFit TM Traffic generator data signature for N30i model).

[0028] Figure 11B Various non-full-face mask user interfaces (including AirFit TM P30i model, AirFit TM P10 model, Brevida TM Model (Fisher & Paykel) and DreamWear TM Pillow model).

[0029] Figure 11C Shows various non-full-face mask user interfaces (including DreamWisp) according to some specific implementations of the present disclosure. TM Model (Philips Respironics), Wisp TM Nasal model (Philips Respironics), Eson2 TM Model (Fisher & Paykel) and DreamWear TM Flow generator data signature for the Nasal model (Philips Respironics).

[0030] Figure 12 Shows various full-face user interfaces (including DreamWear) when not powered on according to some specific implementations of the present disclosure. TM FullFace model (Philips Respironics), AirFit TM F20 Model and AirFit TM Traffic generator data signature for N20 model).

[0031] Figure 13 is a graph depicting notched box plots of experimental model accuracy for models trained on multiple features according to some implementations of the present disclosure.

[0032] 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 be described in detail herein. However, it should be understood that it is not intended to limit the disclosure to the particular forms disclosed, but on the contrary, the disclosure is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure as defined by the appended claims. DETAILED DESCRIPTION

[0033] 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 legs syndrome (RLS), sleep-disordered breathing (SDB) (such as obstructive sleep apnea (OSA), central sleep apnea (CSA), and other types of apnea (e.g., mixed apnea and hypopnea)), respiratory effort-related arousals (RERA), Cheyne-Stokes respiration (CSR), respiratory insufficiency, obesity hyperventilation syndrome (OHS), chronic obstructive pulmonary disease (COPD), neuromuscular disease (NMD), and chest wall disorders.

[0034] Obstructive sleep apnea (OSA) is a form of sleep-disordered breathing (SDB) characterized by episodes of upper airway obstruction or blockage during sleep due to a combination of an abnormally small upper airway and a normal loss of muscle tone in the tongue, soft palate, and posterior oropharyngeal region. More generally, apnea refers to either a cessation of breathing (obstructive sleep apnea) or a cessation of respiratory function (commonly referred to as central sleep apnea) caused by air obstruction. Typically, during an obstructive sleep apnea episode, an individual will stop breathing for about 15 to about 30 seconds.

[0035] Other types of apnea include hypopnea, hyperpnea, and hypercapnia. In contrast to airway obstruction, hypopnea is typically characterized by slow or shallow breathing caused by airway narrowing. Hyperpnea is typically characterized by increased depth and / or rate of breathing. Hypercapnia is typically characterized by elevated or excessive carbon dioxide in the bloodstream and is usually caused by hypopnea.

[0036] Respiratory effort-related arousals (RERA) events are typically characterized by an increase in respiratory effort lasting 10 seconds or longer, resulting in an arousal from sleep that does not meet the criteria for an apnea or hypopnea event. In 1999, the AASM task force defined RERAs as "a series of breaths characterized by increased respiratory effort that results in an arousal from sleep but does not meet the criteria for an apnea or hypopnea event." These events must meet the following two criteria: 1. A pattern of gradually increasing negative esophageal pressure that ends with an abrupt change in pressure to a lower negative pressure level and an arousal; and 2. The event must last 10 seconds or longer. In 2000, a study conducted at the New York University School of Medicine and published in Sleep, Vol. 23, No. 6, pp. 763-771, “Non-Invasive Detection of Respiratory Effort-Related Demontents (RERA) by a Nasal Cannula / Pressure Transducer System,” demonstrated that a nasal cannula / pressure transducer system is adequate and reliable in detecting RERA. A RERA detector can be based on a true flow signal derived from a respiratory therapy (e.g., PAP) device. For example, a measure of flow limitation can be determined based on the flow signal. A measure of arousal can then be derived from the measure of flow limitation and a measurement of sudden increases in ventilation. Some such methods are described in WO 2008 / 138040, assigned to ResMed Ltd., which is hereby incorporated by reference in its entirety.

[0037] Cheyne-Stokes respiration (CSR) is another form of sleep-disordered breathing. CSR is a condition in which a patient's respiratory controller experiences rhythmic, alternating periods of increased and decreased breathing, known as CSR cycles. CSR is characterized by repeated deoxygenation and reoxygenation of arterial blood.

[0038] Obesity hyperventilation syndrome (OHS) is defined as the combination of severe obesity and chronic hypercapnia during sleep, with no other known cause of hypoventilation. Symptoms include dyspnea, morning headaches, and excessive daytime sleepiness.

[0039] Chronic obstructive pulmonary disease (COPD) includes any of a group of lower airway diseases that share certain common characteristics, such as increased resistance to air movement, prolonged expiratory phase of breathing, and loss of the normal elasticity of the lungs.

[0040] Neuromuscular diseases (NMDs) encompass a wide range of diseases and disorders that impair muscle function either directly through intrinsic muscle pathology or indirectly through neuropathology.Chest wall disorders are a group of chest deformities that result in inefficient connections between the respiratory muscles and the rib cage.

[0041] These and other conditions are characterized by specific events that occur while an individual is sleeping (e.g., snoring, apnea, hypopnea, restless legs, sleep disturbances, choking, increased heart rate, difficulty breathing, asthma attacks, seizures, epilepsy, or any combination thereof).

[0042] 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 a sleep session by the total number of hours of sleep in the sleep session. For example, an event can be an apnea lasting at least 10 seconds. An AHI of less than 5 is considered normal. An AHI greater than or equal to 5 but less than 15 is considered to indicate mild sleep apnea. An AHI greater than or equal to 15 but less than 30 is considered to indicate moderate sleep apnea. An AHI greater than or equal to 30 is considered to indicate severe sleep apnea. In children, an AHI greater than 1 is considered abnormal. When the AHI is normal, or when the AHI is normal or mild, sleep apnea can be considered "controlled." The AHI can also be used in combination with the level of desaturation of the blood oxygen to indicate the severity of obstructive sleep apnea.

[0043] refer to Figure 1 , shows a system 100 according to some implementations of the present disclosure. 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 also optionally includes a respiratory therapy system 120 and an activity tracker 180.

[0044] The control system 110 includes one or more processors 112 (hereinafter referred to as processors 112). The control system 110 is generally used to control (e.g., actuate) 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. Although Figure 11 , the control system 110 may include any number of processors (e.g., one processor, two processors, five processors, ten processors, etc.), which may be in a single housing or located remotely from one another. 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 or portion of any other control system)) may be used to perform one or more steps of any method described and / or claimed herein. The control system 110 may be coupled to and / or located within, for example, a housing of the user device 170, a portion (e.g., a housing) of the respiratory therapy system 120, and / or a housing of one or more of the sensors 130. The control system 110 may be centralized (within one such housing) or decentralized (within two or more such housings that are physically distinct). In such embodiments including two or more housings containing the control system 110, such housings may be located proximate to and / or remotely from one another.

[0045] The memory device 114 stores machine-readable instructions that are executable by the processor 112 of the control system 110. The memory device 114 may be any suitable computer-readable storage device or medium, such as a random or serial access memory device, a hard drive, a solid-state drive, a flash memory device, etc. Figure 1 1 , the system 100 may 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 may be coupled to and / or located within a housing of the 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. Similar to the control system 110, the memory device 114 may be centralized (within one such housing) or distributed (within two or more such physically distinct housings).

[0046] In some implementations, the memory device 114 stores a user profile associated with the user. The user profile may 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. Demographic information may include, for example, information indicating the user's age, gender, race, geographic location, relationship status, family history of insomnia or sleep apnea, employment status, educational status, socioeconomic status, or any combination thereof. Medical information may include, for example, information indicating one or more medical conditions associated with the user, medication use, or both. Medical information data may also include Multiple Sleep Latency Test (MSLT) results or scores and / or Pittsburgh Sleep Quality Index (PSQI) scores or values. Self-reported user feedback may include information indicating a self-reported subjective sleep score (e.g., poor, fair, excellent), a self-reported user's subjective stress level, a self-reported user's subjective fatigue level, a self-reported user's subjective health status, a recent life event experienced by the user, or any combination thereof.

[0047] The electronic interface 119 is configured to receive data (e.g., physiological data and / or acoustic data) from one or more sensors 130 so 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, via a cellular network, etc.). The electronic interface 119 may 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 may also include one or more processors and / or one or more memory devices that are the same or similar to the processor 112 and memory device 114 described herein. In some implementations, the electronic interface 119 is coupled to or integrated into the user device 170. In other implementations, the electronic interface 119 is coupled to the control system 110 and / or the memory device 114 or integrated with the control system and / or the memory device (e.g., within a housing).

[0048] As described above, in some implementations, the system 100 optionally includes a respiratory therapy system 120. The respiratory therapy system 120 may include a respiratory pressure therapy (RPT) device 122 (referred to herein as the respiratory therapy device 122), a user interface 124, a conduit 126 (also referred to as a tube or air circuit), a display device 128, a humidification canister 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 canister 129 are part of the respiratory therapy device 122. Respiratory pressure therapy refers to the supply of air to the inlet of the user's airway at a controlled target pressure that is nominally positive relative to atmospheric pressure throughout the user's breathing cycle (e.g., as opposed to negative pressure therapy such as a tank ventilator or chest plate). The respiratory therapy system 120 is typically used to treat individuals suffering from one or more sleep-related breathing disorders (e.g., obstructive sleep apnea, central sleep apnea, or mixed sleep apnea).

[0049] The respiratory therapy device 122 is generally used to generate pressurized air delivered to the user (e.g., using one or more motors driving one or more compressors). In some specific implementations, the respiratory therapy device 122 generates a continuous constant air pressure delivered to the user. In other specific 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 other specific implementations, the respiratory therapy device 122 is configured to generate various different air pressures within a predetermined range. For example, the respiratory therapy device 122 can deliver at least about 6 cm of HO, at least about 10 cm of HO, at least about 20 cm of HO, about 6 cm of HO to about 10 cm of HO, about 7 cm of HO to about 12 cm of HO, etc. The respiratory therapy device 122 can also deliver pressurized air at a predetermined flow rate, for example, between about -20 L / min and about 150 L / min, while maintaining a positive pressure (relative to ambient pressure).

[0050] 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 help prevent the airway from narrowing and / or collapsing during sleep. This can also increase the user's oxygen uptake during sleep. Typically, the user interface 124 engages the user's face so that 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. The respiratory therapy device 122, the user interface 124, and the conduit 126 together form an air passageway fluidically coupled to the user's airway. Pressurized air also increases the user's oxygen uptake during sleep. Depending on the treatment to be applied, the user interface 124 may, for example, form a seal with an area or portion of the user's face to facilitate delivery of gas at a pressure sufficiently different from ambient pressure (e.g., at a positive pressure of approximately 10 cm of H2O relative to ambient pressure) to achieve treatment. For other forms of treatment, such as delivery of oxygen, the user interface may not include a seal sufficient to facilitate delivery of gas supply to the airway at a positive pressure of approximately 10 cm of H2O. In some implementations, the user interface 124 may include a connector 127 and one or more vents 125, which may be referred to as Figures 3A to 3B In some implementations, the connector 127 is distinct from but can be coupled to the user interface 124 (and / or the conduit 126 ).

[0051] like Figure 2 As shown, in some specific implementations, the user interface 124 is a mask (e.g., a full face mask) covering the nose and mouth of the user. Alternatively, the user interface 124 can be a nasal mask that provides air to the user's nose or a nasal pillow mask that delivers air directly to the user's nostrils. The user interface 124 may include a plurality of strips that form, for example, a headband for helping to position and / or stabilize the interface on a part of the user (e.g., face) and a conformal pad (e.g., silicone, plastic, foam, etc.) that helps provide an airtight seal between the user interface 124 and the user. The user interface 124 may also include one or more vents for allowing carbon dioxide and other gases exhaled by the user 210 to escape. In other specific implementations, the user interface 124 includes an oral piece (e.g., a night guard oral piece molded to conform to the user's teeth, a mandibular repositioning device, etc.).

[0052] Figure 3A and Figure 3BA perspective view and exploded view of one embodiment of a directly connected user interface ("direct-type" user interface) according to various aspects of the present disclosure are shown, respectively. The direct-type user interface 300 generally includes a cushion 330 and a frame 350 that define a volume of space around the user's mouth and / or nose. During use, this volume of space receives pressurized air to enter the user's airway. In some embodiments, the cushion 330 and frame 350 of the user interface 300 form an integral part of the user interface. The user interface 300 components can further be considered to include a headband 310, which in the case of the user interface 300 is typically a strap assembly and optionally includes a connector 370. The headband 310 is configured to be positioned generally around at least a portion of the user's head when the user wears the user interface 300. The headband 310 can be coupled to the frame 350 and positioned on the user's head so that the user's head is positioned between the headband 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 be coupled to the frame 350 and / or cushion 330 at one end and to a conduit of a respiratory therapy device (not shown). Pressurized air can flow directly from the conduit of the respiratory therapy system through the connector 370 into the volume of space defined by the cushion 330 (or cushion 330 and frame 350) of the user interface 300. The pressurized air passes from the user interface 300 through the user's mouth, nose, or both to the user's airway. Alternatively, where the user interface 300 does not include the connector 370, the conduit of the respiratory therapy system can be directly connected to the cushion 330 and / or frame 350.

[0053] In some implementations, the connector 370 can include one or more vents 372 on the body of the connector 370 itself and / or one or more vents 376 near the frame 350 ("diffuser vents") for allowing carbon dioxide (CO2) and other gases exhaled by the user to escape when the respiratory therapy device is active. In some implementations, one or more vents (such as vents 372 and / or 376) can be located in a user interface, such as in the frame 350 and / or in the conduit 126. In some implementations, the frame 350 can include at least one anti-asphyxia valve (AAV) 374 that allows CO2 and other gases exhaled by the user to escape in the event that a vent (e.g., vents 372 or 376) fails while the respiratory therapy device is active, and / or allows the user to breathe when therapy is inactive (e.g., due to a power outage, device failure, triggering of an auto-stop feature, such as due to an error or accident, etc.).

[0054] In some embodiments, an AAV (such as AAV 374) generally includes two components: a vent (also referred to as an orifice or opening in some embodiments), and a flap (also referred to as a damper, louver, or shutter in some embodiments). In the illustrated example, the opening or vent of AAV 374 is visible, but the flap is not depicted. Typically, when therapy is off (e.g., the flow generator is not generating airflow), the flap does not cover the vent. When therapy is on, pressure seals the flap against the vent.

[0055] In some embodiments, if there is no airflow from the flow generator, the diffuser vents on the mask (if present) may not be sufficient to safely expel exhaled CO2. For some interfaces, such as nasal pillow masks, the user can breathe through their mouth. However, for full-face masks, an AAV may be required to ensure adequate ventilation. Typically, an AAV (e.g., AAV 374) is always present on full-face masks (as a safety feature); however, diffuser vents and vents located on the mask or connector (typically an array of holes in the mask material itself or a mesh made of some fabric, which is replaceable in many cases) are not necessarily both present (e.g., some masks may have only diffuser vents, such as multiple vents 376, other masks may have multiple vents 372 only on the connector itself).

[0056] For an indirectly connected user interface ("indirect category" user interface), and as will be described in more detail below, the conduit of the respiratory therapy system is indirectly connected to the cushion and / or frame of the user interface. In addition to any connectors, another element of the user interface 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 the user interface conduit described below) delivers pressurized air from the conduit of the respiratory therapy system to the spatial volume formed between the cushion (or frame, or cushion and frame) of the user interface and the user's face. Thus, pressurized air is indirectly delivered from the conduit of the respiratory therapy system to the spatial volume defined by the cushion (or cushion and frame) of the user interface against the user's face. In addition, according to some specific implementations, the indirect connection category of the user interface can be described as at least two different categories: "indirect headband" and "indirect conduit". For the indirect headband category, the conduit of the respiratory therapy system is optionally connected to the headband conduit via a connector, which in turn is connected to the cushion (or frame, or cushion and frame). Therefore, the headband is constructed to deliver pressurized air from the conduit of the respiratory therapy system to the cushion (or frame, or cushion and frame) of the user interface. Therefore, the headband conduit in the headband of the user interface is constructed to deliver 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 includes a user interface conduit, which is generally located between the conduit and the frame, cushion or connector (if present), and the conduit is fluidically coupled to the frame, cushion or connector (if present). Typically, 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 can also have a length shorter than the conduit. In the described user interface, an optional connector is constructed to be coupled to the frame and / or cushion at one end according to the category of the user interface, and to the conduit or user interface conduit at the other end.

[0057] Return Reference Figure 1 The conduit 126 (also referred to as an air circuit or tube) allows air to flow between two components of the respiratory therapy system 120, such as the respiratory therapy device 122 and the user interface 124. In some implementations, there may be separate branches of the conduit for inspiration and expiration. In other implementations, a single limb conduit is used for both inspiration and expiration.

[0058] 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 may include one or more sensors (e.g., a pressure sensor, a flow rate sensor, or more generally any other sensor 130 described herein). For example, these one or more sensors may be used to measure the air pressure and / or flow rate of the pressurized air supplied by the respiratory therapy device 122.

[0059] Brief reference Figure 4 , is a perspective view of the rear side of respiratory therapy device 122, which includes housing 123, air inlet 186, and air outlet 190. Air inlet 186 includes an inlet cover 182 that is movable between a closed position and an open position. Air inlet cover 182 includes one or more air inlet apertures 184 defined therein. Respiratory therapy device 122 includes a blower motor configured to draw air through one or more air inlet apertures 184 defined in air inlet cover 182. The motor is also configured to flow pressurized air through humidification tank 129 and out of air outlet 190. Conduit 126 can be fluidly coupled to air outlet 190 so that air flows from air outlet 190 and into conduit 126. Air outlet 190 is formed in part by an internal conduit 192 that extends from the interior of respiratory therapy device 122 through housing 123. A seal 194 is positioned around the end of internal conduit 192 to ensure that substantially all air exiting through air outlet 190 flows into conduit 126.

[0060] Return Reference Figure 1 , the display device 128 is generally used to display images including still images, video images, or both, and / or information about the respiratory therapy device 122. For example, the display device 128 (and / or the display device 172 of the user device 170) may provide information about the status of the respiratory therapy device 122 (e.g., whether the respiratory therapy device 122 is on / off, the pressure of the air delivered by the respiratory therapy device 122, the temperature of the air 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 myAir TMscores, such as described in WO 2016 / 061629, which is hereby incorporated by reference in its entirety; current date / time; personal information of user 210, etc.). In some implementations, the display device 128 acts as a human-machine interface (HMI) that includes a graphical user interface (GUI) configured to display images as an input interface. The display device 128 can be an LED display, an OLED display, an LCD display, etc. The input interface can be, for example, a touch screen or touch-sensitive substrate, a mouse, a keyboard, or any sensor system configured to sense input made by a human user interacting with the respiratory therapy device 122. The display device 172 of the user device 170 can operate in the same or similar manner as the display device 128 and can be used in conjunction with or in place of the display device 128.

[0061] The humidification tank 129 is coupled to or integrated into the respiratory therapy device 122 and includes a water reservoir 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 to humidify the pressurized air provided to the user. Additionally, in some implementations, the conduit 126 can further include a heating element (e.g., coupled to and / or embedded 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 passageway and deliver water vapor into the air passageway via the water vapor inlet, or can be formed in line with the air passageway as part of the air passageway itself.

[0062] For example, the respiratory therapy system 120 can be used as a ventilator or 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 to the user (e.g., determined by a sleep physician). The APAP system automatically changes the air pressure delivered to the user based on, for example, respiratory data associated with the user. The BPAP or VPAP system is configured to deliver a first predetermined pressure (e.g., inspiratory positive airway pressure or IPAP) and a second predetermined pressure (e.g., expiratory positive airway pressure or EPAP) that is lower than the first predetermined pressure.

[0063] refer to Figure 2 , showing a system 100 ( Figure 1) is part of a respiratory therapy system 120. A user 210 and a bed partner 220 of the respiratory therapy system 120 are positioned on a bed 230 and lying on a mattress 232. A user interface 124 (also referred to herein as a mask, e.g., a full face mask) may 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 a 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, thereby helping to prevent the airway from closing and / or narrowing during sleep. The respiratory therapy device 122 may be positioned on a nightstand 240 directly adjacent to the bed 230, as shown in FIG. Figure 2 As shown, or more generally, positioned on any surface or structure generally adjacent to the bed 230 and / or user 210.

[0064] Return Reference Figure 1 In some embodiments, the one or more sensors 130 of the system 100 include a pressure sensor 132, a flow rate sensor 134, a temperature sensor 136, a motion sensor 138, a microphone 140, a speaker 142, a radio frequency (RF) receiver 146, an RF transmitter 148, a camera 150, an infrared sensor 152, a photoplethysmogram (PPG) sensor 154, an electrocardiogram (ECG) sensor 156, an electroencephalogram (EEG) sensor 158, a capacitive sensor 160, a force sensor 162, a strain gauge sensor 164, an electromyogram (EMG) sensor 166, an oxygen sensor 168, an analyte sensor 174, a humidity sensor 176, a LiDAR sensor 178, or any combination thereof. Typically, each of the one or more sensors 130 is configured to output sensor data, which is received and stored in the memory device 114 or one or more other memory devices.

[0065] Although the one or more sensors 130 are shown and described as including each of a pressure sensor 132, a flow rate sensor 134, a temperature sensor 136, a motion sensor 138, a microphone 140, a speaker 142, an RF receiver 146, an RF transmitter 148, a camera 150, an infrared sensor 152, a photoplethysmogram (PPG) sensor 154, an electrocardiogram (ECG) sensor 156, an electroencephalogram (EEG) sensor 158, a capacitive sensor 160, a force sensor 162, a strain gauge sensor 164, an electromyogram (EMG) sensor 166, an oxygen sensor 168, an analyte sensor 174, a humidity sensor 176, and a LiDAR sensor 178, more generally, the one or more sensors 130 may include any combination and any number of each of the sensors described and / or shown herein.

[0066] As described herein, the system 100 may generally be used to generate a message with a user (e.g., Figure 2 The physiological data may be analyzed to generate one or more sleep-related parameters, which may include any parameters, measurements, etc., associated with the user during a sleep session. The one or more sleep-related parameters that may be determined for user 210 during a sleep session include, for example, an apnea-hypopnea index (AHI) score, a sleep score, a flow signal, a respiration signal, a respiration rate, an inspiratory amplitude, an expiratory amplitude, an inspiratory-expiratory ratio, a number of events per hour, an event pattern, a phase, a pressure setting of the respiratory therapy device 122, a heart rate, a heart rate variability, movement of the user 210, a temperature, EEG activity, EMG activity, arousals, snoring, choking, coughing, whistling, gasping, or any combination thereof.

[0067] The one or more sensors 130 may be used to generate, for example, physiological data, acoustic data, or both. The physiological data generated by one or more of the sensors 130 may be used by the control system 110 to determine whether the user 210 ( Figure 2 ) and one or more sleep-related parameters. The sleep-wake signal may indicate one or more sleep states, including wakefulness, relaxation-wakefulness, micro-arousal, or different sleep stages, such as rapid eye movement (REM) stage, first non-REM stage (commonly referred to as "N1"), second non-REM stage (commonly referred to as "N2"), third non-REM stage (commonly referred to as "N3"), or any combination thereof. Methods for determining sleep states and / or sleep stages based on physiological data generated by one or more sensors (such as 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.

[0068] In some implementations, the sleep arousal signals described herein can be time-stamped to indicate the time the user entered the bed, the time the user left the bed, the time the user attempted to fall asleep, etc. The sleep arousal signals can be measured by one or more sensors 130 during a sleep session at a predetermined sampling rate, such as one sample per second, one sample per 30 seconds, one sample per minute, etc. In some implementations, the sleep arousal signals can also indicate a respiratory signal, respiratory rate, inspiratory amplitude, expiratory amplitude, inspiratory-expiratory ratio, number of events per hour, event pattern, pressure setting of the respiratory therapy device 122, or any combination thereof during the sleep session. Events can include snoring, apnea, central apnea, obstructive apnea, mixed apnea, hypopnea, mask leak (e.g., from the user interface 124), restless legs, sleep disturbances, apnea, increased heart rate, difficulty breathing, asthma attack, seizure, epilepsy, or any combination thereof. One or more sleep-related parameters that can be determined for a user based on the sleep-wake signal during a sleep session include, for example, total time in bed, total sleep time, sleep onset latency, wake parameters after sleep onset, sleep efficiency, fragmentation index, or any combination thereof. As described in further detail herein, physiological data and / or sleep-related parameters can be analyzed to determine one or more sleep-related scores.

[0069] Physiological data and / or acoustic data generated by one or more sensors 130 may also be used to determine a respiratory signal associated with the user during a sleep session. The respiratory signal generally indicates the user's respiration (or breathing) during a sleep session. The respiratory signal may indicate and / or be analyzed to determine (e.g., using the control system 110) one or more sleep-related parameters, such as respiratory rate, respiratory rate variability, inspiratory amplitude, expiratory amplitude, inspiration-expiratory ratio, occurrence of one or more events, number of events per hour, event pattern, sleep state, sleep stage, apnea-hypopnea index (AHI), pressure setting of the respiratory therapy device 122, or any combination thereof. The one or more events may include snoring, apnea, central apnea, obstructive apnea, mixed apnea, hypopnea, mask leak (e.g., from the user interface 124), coughing, restless legs, sleep disturbances, choking, increased heart rate, difficulty breathing, asthma attack, seizure, epilepsy, increased blood pressure, or any combination thereof. Many of the sleep-related parameters described are physiological parameters, although some of the sleep-related parameters may be considered non-physiological parameters. Other types of physiological parameters and / or non-physiological parameters may also be determined based on data from one or more sensors 130 or based on other types of data.

[0070] 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., an atmospheric pressure sensor) that generates sensor data indicative of the respiration (e.g., inhalation and / or exhalation) and / or ambient pressure of a user of the respiratory therapy system 120. In such implementations, the pressure sensor 132 can be coupled to or integrated into 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.

[0071] 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. An example of a flow rate sensor (e.g., flow rate sensor 134) is described in WO 2012 / 012835, which is hereby incorporated by reference in its entirety. In some embodiments, the flow rate sensor 134 is used to determine the air flow rate from the respiratory therapy device 122, the air flow rate through the conduit 126, the air flow rate through the user interface 124, or any combination thereof. In such embodiments, the flow rate sensor 134 can be coupled to or integrated into 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 a rotary flow meter (e.g., a Hall effect flow meter), 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 ventilation flow (e.g., intentional "leak"), unintentional leak (e.g., mouth leak and / or mask leak), patient flow (e.g., air entering and / or leaving the lungs), or any combination thereof. In some implementations, the flow rate data can be analyzed to determine the user's cardiogenic oscillations. In one example, the pressure sensor 132 can be used to determine the user's blood pressure.

[0072] 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 a signal indicating to the user 210 ( Figure 2 ), the core body temperature of user 210, the skin temperature of user 210, the temperature of air flowing from respiratory therapy device 122 and / or through conduit 126, the temperature in user interface 124, the ambient temperature, or any combination thereof. Temperature sensor 136 may be, for example, a thermocouple sensor, a thermistor sensor, a silicon bandgap temperature sensor or a semiconductor-based sensor, a resistance temperature detector, or any combination thereof.

[0073] 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 the movement of the user 210 during a sleep session and / or detect the movement of any component of the respiratory therapy system 120 (such as the respiratory therapy device 122, the user interface 124, or the catheter 126). The motion sensor 138 may include one or more inertial sensors, such as an accelerometer, a gyroscope, and a magnetometer. In some implementations, alternatively or in addition, the motion sensor 138 generates one or more signals representing the user's body movement, for example, via the user's respiratory movement, from which a signal representing the user's sleep state can be obtained. In some implementations, the motion data from the motion sensor 138 can be used in combination with additional data from another sensor 130 to determine the user's sleep state.

[0074] The microphone 140 can be located anywhere 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 can include a microphone 140 that is (i) externally coupled to the conduit 126, (ii) positioned within the respiratory therapy device 122, optionally at least partially positioned within the respiratory therapy device, (iii) externally coupled to the user interface 124, (iv) directly or indirectly coupled to a headband associated with the user interface 124, or at any other suitable location. In some implementations, the microphone 140 is coupled to a mobile device (e.g., a user device 170 or a smart speaker, such as a Google Nest Hub enabled device). TM , Google Home TM , Amazon Echo TM 、AmazonShod TM Alexa TM device, etc.), which is communicatively coupled to the respiratory therapy system 120.

[0075] In some implementations, the microphone 140 is positioned on or at least partially external to the housing of the respiratory therapy device 122. For example, the microphone 140 can be at least partially movable relative to the housing of the respiratory therapy device 122 to help direct it toward the user 210 ( Figure 2 For example, the microphone 340 may be rotated from about 5° to about 355° toward the user 210 .

[0076] 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 can be (i) at least partially positioned within the conduit 126, (ii) at least partially positioned within the respiratory therapy device 122, optionally at least partially positioned within a component of the respiratory therapy device 122 that is in fluid communication with the conduit 126, or (iii) at least partially positioned within the user interface 124, which is in fluid communication with the conduit 126. Furthermore, in some implementations, the microphone 140 is electrically connected (e.g., physically connected, such as being mounted directly or indirectly on the circuit board) to a circuit board of the respiratory therapy device 122, which can be in acoustic communication (e.g., via a small tube and / or silicone window, such as in a stethoscope) or in fluid communication with the airflow in the respiratory therapy system 120.

[0077] The microphone 140 outputs sounds 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 can be reproduced as one or more sounds (e.g., sounds from the user 210) during a sleep session. The acoustic data from the microphone 140 can also be used (e.g., using the control system 110) to identify events experienced by the user during the sleep session, as described in further detail herein. The microphone 140 can be coupled to or integrated into the respiratory therapy device 122, the user interface 124, the catheter 126, or the user device 170. In some implementations, the system 100 includes multiple microphones (e.g., two or more microphones and / or a microphone array with beamforming) such that the sound data generated by each of the multiple microphones can be used to distinguish the sound data generated by another of the multiple microphones.

[0078] Speaker 142 outputs information to the user of system 100 (e.g., Figure 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 into the respiratory therapy device 122, the user interface 124, the conduit 126, or the user device 170.

[0079] 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, for example, in 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 predetermined intervals, and the microphone 140 detects 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 inaudible to the human ear (e.g., below 20 Hz or above approximately 18 kHz) so as not to disturb the user 210 or the bed partner 220 ( Figure 2 )'s sleep. Based at least in part on data from microphone 140 and / or speaker 142, control system 110 may determine that user 210 ( Figure 2 ) and / or one or more sleep-related parameters described herein, such as, for example, a respiratory signal, a respiratory rate, an inspiratory amplitude, an expiratory amplitude, an inspiratory-expiratory ratio, a number of events per hour, a pattern of events, a sleep state, a sleep stage, a pressure setting of the respiratory therapy device 122, or any combination thereof. In this context, a SONAR sensor may be understood as involving active acoustic sensing, such as generating and / or transmitting ultrasound and / or low-frequency ultrasound sensing signals through air (e.g., in a frequency range of approximately 17kHz to 23kHz, 18kHz to 22kHz, or 17kHz to 18kHz). Such systems may be considered in connection with the aforementioned WO 2018 / 050913 and WO 2020 / 104465, each of which is hereby incorporated by reference herein in its entirety.

[0080] In some implementations, sensor 130 includes (i) a first microphone that is identical or similar to microphone 140 and integrated into acoustic sensor 141 , and (ii) a second microphone that is identical or similar to microphone 140 but separate and distinct from the first microphone integrated into acoustic sensor 141 .

[0081] The RF transmitter 148 generates and / or transmits radio waves having a predetermined frequency and / or a predetermined amplitude (e.g., within a high frequency band, within a low frequency band, a long wave signal, a short wave signal, etc.). The RF receiver 146 detects reflections of the radio waves transmitted from the RF transmitter 148, and this data may be analyzed by the control system 110 to determine whether the user 210 ( Figure 2) and / or one or more sleep-related parameters described herein. The RF receiver (RF receiver 146 and RF transmitter 148 or another RF pair) may also be used for wireless communication between the control system 110, the respiratory therapy device 122, one or more sensors 130, the user device 170, or any combination thereof. Although the RF receiver 146 and RF transmitter 148 are Figure 1 Although shown as separate and distinct elements in FIG, in some implementations, the RF receiver 146 and the RF transmitter 148 are combined as part of an RF sensor 147 (e.g., a RADAR sensor). In some such implementations, the RF sensor 147 includes control circuitry. The specific format of RF communication can be Wi-Fi, Bluetooth, etc.

[0082] In some implementations, the RF sensor 147 is part of a mesh system. An example of a mesh system is a Wi-Fi mesh system, which may include mesh nodes, mesh routers, and mesh gateways, each of which may be mobile / removable 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 includes an RF sensor that is the same or similar to the RF sensor 147. The Wi-Fi router and the satellites continuously communicate with each other using Wi-Fi signals. The Wi-Fi mesh system can be used to generate motion data based on changes in the Wi-Fi signal between the router and the satellite (e.g., differences in received signal strength) due to the movement of an object or person partially blocking the signal. The motion data may indicate movement, respiration, heart rate, gait, falls, behavior, etc., or any combination thereof.

[0083] The camera 150 outputs image data that can be reproduced 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 control system 110 can use the image data from the camera 150 to determine one or more sleep-related parameters described herein, such as one or more events (e.g., periodic limb movements or restless legs syndrome), a respiratory signal, a respiratory rate, an inspiratory amplitude, an expiratory amplitude, an inspiratory-expiratory ratio, a number of events per hour, a pattern of events, a sleep state, a sleep stage, or any combination thereof. In addition, the image data from the camera 150 can be used, for example, to identify the location of the user to determine whether the user 210 ( Figure 2 ) chest movement, determining the airflow of the mouth and / or nose of the user 210, determining that the user 210 enters the bed 230 ( Figure 2 ) and determines the time when the user 210 leaves the bed 230. In some implementations, the camera 150 includes a wide-angle lens or a fish-eye lens.

[0084] Infrared (IR) sensor 152 outputs infrared image data that can be reproduced as one or more infrared images (e.g., still images, video images, or both) that can be stored in memory device 114. Infrared data from IR sensor 152 can be used to determine one or more sleep-related parameters during a sleep session, including the temperature of user 210 and / or the movement of user 210. IR sensor 152 can also be used in conjunction with camera 150 when measuring the presence, position, and / or movement of user 210. For example, IR sensor 152 can detect infrared light having a wavelength between approximately 700 nm and approximately 1 mm, while camera 150 can detect visible light having a wavelength between approximately 380 nm and approximately 740 nm.

[0085] The PPG sensor 154 outputs the same signal as the user 210 ( Figure 2 ) that can be used to determine one or more sleep-related parameters, such as heart rate, heart rate variability, cardiac cycle, respiratory rate, inspiratory amplitude, expiratory amplitude, inspiratory-expiratory ratio, estimated blood pressure parameters, or any combination thereof. The PPG sensor 154 can be worn by the user 210, embedded in clothing and / or fabric worn by the user 210, embedded and / or coupled to the user interface 124 and / or its associated headband (e.g., a strap, etc.), etc.

[0086] In some implementations, a PAT (peripheral arterial tone) sensing device may utilize a fingertip-mounted PPG probe, such as PPG sensor 154. The PPG probe operates using optical technology that detects changes in blood volume in the microvascular bed of tissue. As described above, PPG measurements are used to derive changes in arterial oxygen saturation (SpO2), pulse rate (PR), and peripheral arterial tone, which are then used to detect respiratory events. Peripheral arterial tone refers to the tension of the smooth muscle tissue of the peripheral arteries. When the muscle tone of the peripheral arteries increases, the arterial diameter decreases, resulting in a decrease in perfusion and, therefore, a decrease in pulsatile blood volume in the peripheral tissues. This decrease in pulsatile blood volume in the peripheral tissues manifests as a decrease in the PPG signal swing between systole and diastole. A PAT signal can 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 hereby incorporated by reference in its entirety. A PPG-derived signal that can be derived by trending toward this decrease in pulsatile blood volume is referred to as a PAT signal.

[0087] The ECG sensor 156 outputs physiological data associated with the electrical activity of the heart of the user 210. In some implementations, the ECG sensor 156 includes one or more electrodes positioned on or around a portion of the user 210 during a sleep session. For example, the physiological data from the ECG sensor 156 can be used to determine one or more sleep-related parameters described herein.

[0088] The EEG sensor 158 outputs physiological data associated with the electrical activity of the brain of the user 210. In some implementations, the EEG sensor 158 includes one or more electrodes positioned on or around the scalp of the user 210 during a sleep session. For example, the physiological data from the EEG sensor 158 can be used to determine the sleep state and / or sleep stage of the user 210 at any given time during a sleep session. In some implementations, the EEG sensor 158 can be integrated into the user interface 124 and / or an associated headband (e.g., a strap, etc.).

[0089] The capacitance 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 sleep-related parameters described herein. The EMG sensor 166 outputs physiological data associated with the electrical activity generated by one or more muscles. The oxygen sensor 168 outputs oxygen data indicating the oxygen concentration of a 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., an SpO2 sensor), or any combination thereof. In some implementations, the one or more sensors 130 further include a galvanic skin response (GSR) sensor, a blood flow sensor, a respiration sensor, a pulse sensor, a blood pressure sensor, a blood oxygen sensor, or any combination thereof.

[0090] Analyte sensor 174 can be used to detect the presence of analytes in the exhaled breath of user 210. Data output by analyte sensor 174 can be stored in memory device 114 and used by control system 110 to determine the identity and concentration of any analytes in the breath of user 210. In some implementations, analyte sensor 174 is positioned near the mouth of user 210 to detect analytes in breath exhaled from the mouth of user 210. For example, when user interface 124 is a mask that covers the nose and mouth of user 210, analyte sensor 174 can be positioned within the mask to monitor mouth breathing of user 210. In other implementations, such as when user interface 124 is a nasal mask or a nasal pillow mask, analyte sensor 174 can be positioned near the nose of user 210 to detect analytes in breath exhaled through the user's nose. In other implementations, when user interface 124 is a nasal mask or a nasal pillow mask, analyte sensor 174 can be positioned near the mouth of user 210. In this implementation, the analyte sensor 174 can be used to detect whether any air is inadvertently leaking from the mouth of the user 210. 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 the analyte sensor 174 positioned near the mouth of the user 210 or within the mask (in the implementation where the user interface 124 is a 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.

[0091] The humidity sensor 176 outputs data that can be stored in the memory device 114 and used by the control system 110. The humidity sensor 176 can be used to detect the humidity of various areas around the user (e.g., inside the conduit 126 or user interface 124, near the face of the user 210, 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 humidity sensor 176 can be coupled to or integrated into the user interface 124 or conduit 126 to monitor the humidity of the pressurized air from the respiratory therapy device 122. In other implementations, the humidity sensor 176 is placed near any area where humidity levels need to be monitored. The humidity sensor 176 can also be used to monitor the humidity of the ambient environment surrounding the user 210, for example, the air in a bedroom.

[0092] Light detection and ranging (LiDAR) sensors 178 can be used for depth sensing. This type of optical sensor (e.g., a laser sensor) can be used to detect objects and build a three-dimensional (3D) map of the surrounding environment (such as a living space). LiDAR can typically use a pulsed laser to perform time-of-flight measurements. LiDAR is also known as 3D laser scanning. In an example using this sensor, a fixed or mobile device (such as a smartphone) with a LiDAR sensor 178 can measure and map an area extending 5 meters or more away from the sensor. For example, LiDAR data can be fused with point cloud data estimated by an electromagnetic RADAR sensor. The LiDAR sensor 178 can also use artificial intelligence (AI) to automatically establish a geofence for the RADAR system by detecting and classifying features in the space that may cause problems for the RADAR system, such as glass windows (which may be highly reflective to RADAR). For example, LiDAR can also be used to provide an estimate of a person's height, as well as changes in height when a person sits down or falls. LiDAR can be used to form a 3D mesh representation of the environment. In further use, for solid surfaces through which radio waves pass (e.g., radio-translucent materials), LiDAR can reflect from such surfaces, allowing classification of different types of obstacles.

[0093] 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., a pulse sensor), a blood pressure sensor (e.g., a sphygmomanometer sensor), a blood oxygen sensor, a SONAR sensor, a RADAR sensor, a blood glucose sensor, a camera (e.g., a 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 the device relative to an orthogonal coordinate system), an alcohol sensor, or any combination thereof.

[0094] Although Figure 110, any combination of the one or more sensors 130 can be integrated into and / or coupled to any one or more components of the system 100, including the respiratory therapy device 122, the user interface 124, the conduit 126, the humidification canister 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 into and / or coupled to the user device 170, and the pressure sensor 132 and / or the flow rate sensor 134 can be integrated into 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 generally positioned near the user 210 during a 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 a nightstand, coupled to a mattress, coupled to a ceiling, etc.).

[0095] Data from one or more sensors 130 may be analyzed to determine one or more sleep-related parameters, which may include a respiratory signal, respiratory rate, respiratory pattern, inspiratory amplitude, expiratory amplitude, inspiration-expiratory ratio, occurrence of one or more events, number of events per hour, event pattern, sleep state, apnea-hypopnea index (AHI), or any combination thereof. The one or more events may include snoring, apnea, central apnea, obstructive apnea, mixed apnea, hypopnea, mask leak, coughing, restless legs, sleep disorder, choking, increased heart rate, dyspnea, asthma attack, seizure, epilepsy, increased blood pressure, or any combination thereof. Many of these sleep-related parameters are physiological parameters, although some of the sleep-related parameters may be considered non-physiological parameters. Other types of physiological and non-physiological parameters may also be determined based on data from one or more sensors 130 or based on other types of data.

[0096] User equipment 170 ( Figure 1 ) includes a display device 172. For example, the user device 170 may be a mobile device such as a smartphone, a tablet, a game console, a smartwatch, a laptop, etc. Alternatively, the user device 170 may be an external sensing system, a television (e.g., a smart TV), or another smart home device (e.g., a smart speaker such as a Google Nest Hub). TM , Google Home TM , Amazon Echo TM 、Amazon Shod TM Alexa TM). In some implementations, the user device is a wearable device (e.g., a smartwatch). The display device 172 is typically used to display images including still images, video images, or both. In some implementations, the display device 172 acts as a human-machine interface (HMI) that includes a graphical user interface (GUI) configured to display images and an input interface. The display device 172 can be an LED display, an OLED display, an LCD display, etc. The input interface can be, for example, a touch screen or touch-sensitive substrate, a mouse, a keyboard, or any sensor system configured to sense input 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.

[0097] In some implementations, the system 100 also includes an activity tracker 180. The activity tracker 180 is generally used to help generate physiological data associated with the user. The activity tracker 180 may include one or more of the sensors 130 described herein, such as 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 information from the activity tracker 180 can be used to determine, for example, the number of steps, distance traveled, number of steps climbed, duration of physical activity, type of physical activity, intensity of physical activity, time spent standing, breathing rate, average breathing rate, resting breathing rate, maximum breathing rate, breathing rate variability, heart rate, average heart rate, resting heart rate, maximum heart rate, heart rate variability, 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.

[0098] In some implementations, the activity tracker 180 is a wearable device that can be worn by a user, such as a smartwatch, wristband, ring, or patch. Figure 2 , activity tracker 180 is worn on the wrist of user 210. Activity tracker 180 may also be coupled to or integrated into a garment or clothing worn by the user. Alternatively, activity tracker 180 may also be coupled to or integrated into user device 170 (e.g., within the same housing). More generally, activity tracker 180 may be communicatively coupled to or physically integrated into (e.g., within a housing) control system 110, memory device 114, respiratory therapy system 120, and / or user device 170.

[0099] Although the control system 110 and the memory device 114 are Figure 1100 as separate and distinct components of system 100, in some implementations, control system 110 and / or memory device 114 are integrated into user device 170 and / or respiratory therapy device 122. Alternatively, in some implementations, control system 110 or a portion thereof (e.g., processor 112) can be located in the cloud (e.g., integrated in a server, integrated in an Internet of Things (IoT) device, connected to the cloud, subject to edge cloud processing, etc.), located in one or more servers (e.g., a remote server, a local server, etc.), or any combination thereof.

[0100] Although system 100 is shown as including all of the components described above, more or fewer components may be included in the system depending on the specific implementation of the present disclosure. For example, a first alternative system includes control system 110, memory device 114, and at least one of one or more sensors 130, and does not include respiratory therapy system 120. For another example, a second alternative system includes control system 110, memory device 114, at least one of one or more sensors 130, and user device 170. For another example, a third alternative system includes control system 110, memory device 114, respiratory therapy system 120, at least one of one or more sensors 130, and user device 170. Therefore, any one or more portions of the components shown and described herein and / or in combination with one or more other components may be used to form various systems.

[0101] As used herein, a sleep session can be defined in a variety of 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 the duration of time a user is asleep, i.e., a sleep session has a start time and an end time, and during the sleep session, the user does not wake up until the end time. That is, any period during which the user is awake is not included in a sleep session. According to this first definition of a sleep session, if a user wakes up and falls asleep multiple times in the same night, each of the sleep intervals separated by the wake intervals is a sleep session.

[0102] Alternatively, in some implementations, a sleep session has a start time and an end time, and during a sleep session, as long as the user is awake for a continuous duration below a wakefulness duration threshold, the user can wake up without the sleep session ending. The wakefulness duration threshold can be defined as a percentage of the sleep session. The wakefulness duration threshold can be, for example, approximately 20 percent of the sleep session duration, approximately 15 percent of the sleep session duration, approximately 10 percent of the sleep session duration, approximately 5 percent of the sleep session duration, approximately 2 percent of the sleep session duration, or any other threshold percentage. In some implementations, the wakefulness duration threshold is defined as a fixed amount of time, such as approximately one hour, approximately 30 minutes, approximately 15 minutes, approximately 10 minutes, approximately 5 minutes, approximately 2 minutes, or the like, or any other amount of time.

[0103] In some implementations, a sleep session is defined as the entire time between the time the user first enters the bed in the evening and the time the user last leaves the bed in the early morning of the following day. In other words, a sleep session can be defined as a time period starting at a first time (e.g., 10:00 PM) on a first date (e.g., Monday, January 6, 2020), when the user first enters the bed with the intention of going to sleep (e.g., if the user does not plan to watch TV or use a smartphone before going to bed, this may be referred to as the current evening), and ending at a second time (e.g., 7:00 AM) on a second date (e.g., Tuesday, January 7, 2020), when the user first leaves the bed without intending to go back to sleep the next morning, which may be referred to as the next morning.

[0104] In some implementations, a user can manually define the start of a sleep session and / or manually terminate a sleep session. For example, a user can select (e.g., by clicking or tapping) a sleep session on the user device 170 ( Figure 1 ) to manually initiate or terminate a sleep session.

[0105] Generally, a sleep session includes any point in time after user 210 has been lying or sitting on bed 230 (or another area or object where they intend to sleep) and has turned on respiratory therapy device 122 and put on user interface 124. Thus, a sleep session may include the following time periods: (i) when user 210 is using the CPAP system but before user 210 attempts to fall asleep (e.g., when user 210 is lying on bed 230 reading a book); (ii) when user 210 begins to try to fall asleep but is still awake; (iii) when user 210 is in light sleep (also known as stages 1 and 2 of non-rapid eye movement (NREM) sleep); (iv) when user 210 is in deep sleep (also known as slow wave sleep (SWS) or stage 3 of NREM sleep); (v) when user 210 is in rapid eye movement (REM) sleep; (vi) when user 210 is awake periodically between light sleep, deep sleep, or REM sleep; or (vii) when user 210 wakes up and does not fall back asleep.

[0106] A sleep session is generally defined as ending once user 210 removes user interface 124, turns off respiratory therapy device 122, and leaves bed 230. In some implementations, a sleep session may include additional time periods, or may be limited to only some of the time periods disclosed above. For example, a sleep session may be defined as encompassing a period of time beginning when respiratory therapy device 122 begins supplying pressurized air to the airway or user 210 and ending when respiratory therapy device 122 stops supplying pressurized air to the airway of user 210, and including some or all points in between, i.e., points in time when user 210 falls asleep or awake.

[0107] refer to Figure 5 , shows a method 500 for training a machine learning model 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 embodiments of the present disclosure. One or more steps of the method 500 may be performed using the system 100 ( Figures 1 to 2 ) is implemented in any element or aspect of ). Although method 500 has been shown and described herein as occurring in a particular order, more generally, the steps of method 500 may be performed in any suitable order.

[0108] As discussed above, the AAV can be used to allow exhaled gases to vent from the user interface in situations where other vents fail or become blocked, and when therapy fails or stops (e.g., due to engine failure, power loss, etc.). In some embodiments, the AAV is typically open when no pressure is applied (e.g., when the respiratory therapy system is not providing airflow and / or the user is not breathing) and closed when pressure is applied (e.g., when the user is breathing, and / or when the respiratory therapy system begins to supply flow). In some embodiments, the AAV is typically at least partially open during at least some portions of the respiratory cycle to allow gas exchange with the atmosphere. In embodiments of the present disclosure, flow generator data (e.g., collected, generated, or otherwise provided by a respiratory therapy system (e.g., 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.

[0109] In some embodiments, method 500 may be performed by one or more training systems. For example, the training system may correspond to or be implemented using one or more components of system 100. In some embodiments, the training system may correspond to other systems (e.g., a remote server, a cloud system, etc.), and the resulting model may be used to perform inference using one or more components of system 100. That is, one or more components of system 100 may use method 500 to train a machine learning model locally, or one or more components of system 100 may collect relevant data (e.g., traffic 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., a cloud system), where these other systems use the collected data to train a machine learning model.

[0110] At box 505, the training system accesses flow generator data associated with the user interface. For example, flow generator data may be collected, generated, or otherwise provided by the respiratory therapy system (e.g., respiratory therapy system 120) while the respiratory therapy system is operating in conjunction with a user interface (e.g., user interface 124) in conjunction with respiratory therapy, or after such operation. As used herein, a respiratory therapy system may be referred to as "operating 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 may generally include generating, receiving, requesting, retrieving, or otherwise obtaining access to the data. For example, the training system itself may generate the flow generator data, may receive the flow generator data from another system, may retrieve the flow generator data from a repository, and so on.

[0111] 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 time period). In some embodiments, flow generator data may additionally or alternatively be collected or generated when the respiratory therapy system is not providing airflow. For example, flow generator data may be generated based on the breathing of a user wearing the user interface. In some embodiments, flow generator data may be collected / generated continuously and only selectively accessed / processed for training and / or AAV detection (e.g., when breathing is detected, when blower activation is detected, etc.).

[0112] In embodiments, depending on the specific implementation, flow generator data may include various data. In some embodiments, flow generator data includes flow data (e.g., measured in liters per second) indicating and / or related to the volume of the air flow provided. For example, a flow rate sensor 134 may be used to generate and / or collect flow data to determine the flow rate of the blower. In some embodiments, flow generator data includes pressure data (e.g., measured in cmH2O) indicating and / or related to the pressure of the air flow provided. For example, 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, flow generator data includes motor data (e.g., measured in revolutions per minute (RPM)) indicating and / or related to the movement or rotation of a motor (e.g., a blower motor) used to generate and / or provide airflow. For example, motor data may indicate whether the blower motor is on, the speed of the motor, the ramp rate, etc. In some embodiments, various motor sensors may be used to capture motor data. Such sensors are known in the art and generally detect operating parameters of the motor, such as the rotational speed (e.g., RPM) of the motor. Such sensors include motor speed transducers for determining the rotational speed of a motor and / or blower (flow generator). The motor speed signal from the motor speed transducer can be provided to the therapeutic device controller. For example, the motor speed transducer can 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, an acoustic sensor 141 can be used to generate and / or collect audio data.

[0113] In one embodiment, the flow generator data may include any combination of components. For example, in some embodiments, the flow generator data includes at least one of the following: flow data, pressure data, or motor data. In some embodiments, the flow generator data includes at least two of the following: 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 the following: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes at least two of the following: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes at least three of the following: 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.

[0114] As used herein, "flow generator data" may include raw data or values ​​(e.g., air flow rate, pressure, motor speed, audio, etc.), as well as pre-processed or transformed values ​​and / or derivatives of the raw data (e.g., for one or more of a metric, minimum value, maximum value, skewness value, kurtosis value, minimum-maximum ratio, etc.).

[0115] In some aspects, flow generator data is generated in response to determining that the respiratory therapy device has begun providing airflow. For example, in response to determining that the blower motor has begun rotating, the sensor 130 may begin collecting, generating, and / or recording or storing flow generator data. In some embodiments, flow generator data is collected / stored corresponding to a defined time period, such as during a 1-second interval after the blower motor is started, during a 1.5-second interval after the blower motor is started, during a 2-second interval after the blower motor is started, etc.

[0116] In some aspects, flow generator data is generated when the respiratory therapy device is not providing airflow. For example, in response to determining that the user (when wearing the user interface) is breathing, the sensor 130 may begin to collect, generate and / or record or store flow generator data. In some embodiments, flow generator data may be continuously generated and evaluated to detect breathing, and when breathing is detected, flow generator data corresponding to a defined window may be stored. In some embodiments, flow generator data is collected corresponding to a defined time period (e.g., to ensure that a complete breathing cycle is collected), for example, during a 3-second interval, a 4-second interval, a 5-second interval, a 6-second interval, a 7-second interval, etc.

[0117] At box 510, the training system may optionally preprocess some or all of the traffic generator data. In some embodiments, the specific preprocessing used (if any) may vary depending on the specific implementation. For example, in some embodiments, the training system may optionally scale some or all of the metrics reflected in the traffic generator data (e.g., to scale pressure data). In some embodiments, the training system may optionally downsample some or all of the metrics reflected in the traffic generator data (e.g., to downsample audio data). In some embodiments, the training system may optionally generate one or more derivative features based on one or more metrics reflected in the traffic generator data, as discussed in more detail below. In some embodiments, the training system may optionally align the traffic generator data in time (e.g., align the metrics so that the starting points of the windows are aligned).

[0118] In some embodiments, at box 510, the training system may evaluate the flow generator data collected during the window to generate additional or alternative features, such as indicating a maximum value of one or more metrics (e.g., the maximum flow rate and / or pressure during the time window), a minimum value of one or more metrics (e.g., the minimum flow rate and / or pressure during the time window), a ratio between the maximum and minimum values ​​of one or more metrics, a range of one or more metrics, a skewness of one or more metrics, a kurtosis of one or more metrics, and the like.

[0119] At box 515, the training system determines whether the user interface being used / operated includes an AAV. In one embodiment, this determination can be used as a target or label during training, allowing the model to predict whether the user interface includes an AAV based on flow generator data collected when the respiratory therapy system is operated with the user interface. Generally, the training system can use various techniques and operations to determine whether the user interface includes an AAV. For example, in some embodiments, a user of the respiratory therapy system can manually or explicitly indicate the user interface and / or whether the user interface includes an AAV. In some embodiments, the respiratory therapy system can use various techniques to identify a specific brand and / or model of the user interface in order to determine whether it includes an AAV. In some embodiments, another user or individual (e.g., a healthcare provider) can indicate the user interface and / or whether the user interface includes an AAV.

[0120] In some embodiments, the flow generator data (accessed at block 505) and the determination of whether the user interface includes an AAV (determined at block 515) can be used to form training data (referred to in some embodiments as training samples, exemplars, data points, etc.). Generally, the flow generator data (or its derivative) can be used as input, while the determination of whether the user interface includes an AAV is the target output. In this manner, the data samples can be used to train one or more machine learning models to process the flow generator data in order to predict whether a user interface associated with a respiratory therapy system includes an AAV.

[0121] 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 available in the repository of historical traffic generator data. If so, the method 500 returns to block 505 to process new examples. If not, the method 500 continues to block 525.

[0122] At block 525, the training system trains one or more machine learning models to predict the presence (or absence) of AAV based on the traffic generator data. For example, using the examples 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. In general, the training process can vary depending on the specific model architecture and the specific implementation.

[0123] 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 convolutional layers, pooling layers, etc. In one such embodiment, each metric in the flow generator data (or its derivative) is used as the corresponding channel in the input to generate a probability metric that indicates the likelihood or probability that the flow generator data was generated when the respiratory therapy system is operating with a user interface that includes AAV. In some embodiments, the AAV probability metric may correspond to or include a continuous value (e.g., between 0 and 1) and / or a categorical value (e.g., a binary value such as "AAV present" or "AAV absent," or a ternary value such as "present," "absent," or "indeterminate"). The prediction may then be compared to the label (determined at block 515) to generate a loss that may then be used to refine the parameters of the model. Although stochastic gradient descent is described for conceptual clarity (e.g., refining the model independently for each example), in some embodiments, batch gradient descent may be used to train the model.

[0124] 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 (e.g., coefficients) of the model to fit a regression curve to observed data examples, such that new flow generator data can be processed using the estimated parameters to generate a metric indicating the likelihood or probability that the flow generator data was generated when the respiratory therapy system was operating with a user interface that includes an AAV.

[0125] Once the machine learning model is trained, method 500 proceeds to block 530. In one embodiment, training may include one or more rounds or epochs and may continue until various termination criteria are met. For example, termination criteria may include determining whether there are any remaining additional examples to train the model, whether the model has sufficient predictive 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, etc.

[0126] At block 530, the training system deploys the trained machine learning model for runtime inference. In one embodiment, deploying the model may include various operations and techniques to make the model available for inference. For example, if the training system uses the model locally to classify or predict new flow generator data, the training system may simply instantiate the model or otherwise use the model to process the new data. If one or more other systems use the model, the training system may transfer or otherwise make the trained model available to these other systems, such as by directly transferring the model to these other systems or by storing the model in a designated repository or location. For example, the model may be used by one or more components of system 100, allowing system 100 to quickly determine the presence of AAV based on newly collected data. In at least one embodiment, one or more components of a treatment system (e.g., system 100) may collect flow generator data and optionally pre-process it / perform feature extraction on it. This flow generator data (or features extracted therefrom) may then be provided to a remote system (e.g., in the cloud), which hosts the machine learning model and uses it to generate AAV predictions.

[0127] As discussed in more detail below, the model can then be used to process the flow generator data to generate a probability metric that indicates whether the flow generator data was generated when the respiratory therapy system was operated in conjunction with a user interface having an AAV.

[0128] Figure 6is a process flow diagram of a method 600 for characterizing a user interface (e.g., user interface 124 of system 100) or an AAV of a user interface (e.g., AAV) based on traffic generator data using a machine learning model according to some implementations of the present disclosure. One or more steps of method 600 may be performed using system 100 ( Figures 1 to 2 ) is implemented in any element or aspect of ). Although method 600 has been shown and described herein as occurring in a particular order, more generally, the steps of method 600 may be performed in any suitable order.

[0129] In some embodiments, a trained machine learning model (e.g., Figure 5 Method 600 is performed using a training system trained using method 500. In some embodiments, method 600 may be performed by one or more inference systems, which may or may not correspond to the training system. For example, the inference system may correspond to or be implemented using one or more components of system 100. In some embodiments, the inference system may correspond to another system (e.g., a remote server, a cloud system, etc.).

[0130] At block 605, the inference system accesses flow generator data associated with the 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 operating in conjunction with respiratory therapy (e.g., being coupled to) a user interface (e.g., user interface 124).

[0131] 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., 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 time period). In some embodiments, flow generator data may additionally or alternatively be collected and / or generated when the respiratory therapy system is not providing airflow. For example, flow generator data may be generated / stored based on the breathing of a user wearing the user interface.

[0132] In embodiments, as discussed above, the flow generator data may include various data depending on the particular implementation. In some embodiments, the flow generator data includes flow data indicating and / or related to the volume of the provided air flow (e.g., generated by the flow rate sensor 134). In some embodiments, the flow generator data includes pressure data indicating and / or related to the pressure of the provided air flow (e.g., generated by the pressure sensor 132). In some embodiments, the flow generator data includes motor data indicating and / or related to the movement or rotation of a motor (e.g., a blower motor). In some embodiments, the flow generator data includes audio data (e.g., generated by the acoustic sensor 141).

[0133] In one embodiment, the flow generator data may include any combination of components. For example, in some embodiments, the flow generator data includes at least one of the following: flow data, pressure data, or motor data. In some embodiments, the flow generator data includes at least two of the following: 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 the following: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes at least two of the following: flow data, pressure data, motor data, or audio data. In some embodiments, the flow generator data includes at least three of the following: 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.

[0134] In some aspects, as discussed above, flow generator data is generated and / or maintained in response to determining that the respiratory therapy device has begun providing airflow. For example, in response to determining that the blower motor has begun rotating, the sensor 130 may begin collecting or generating flow generator data. In some embodiments, flow generator data is collected during a defined period of time or interval after the blower is started.

[0135] In some aspects, as discussed above, flow generator data is generated and / or maintained when the respiratory therapy device is not providing airflow. For example, in response to determining that the user (while wearing the user interface) is breathing, the sensor 130 may begin collecting or generating flow generator data. In some embodiments, flow generator data may be continuously generated and evaluated to detect breathing, and when breathing is detected, flow generator data for a defined window may be stored. In some embodiments, flow generator data is collected during a defined time period (e.g., to ensure that a complete breathing 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, etc.

[0136] At block 610, the inference system determines whether the flow generator data meets one or more anomaly criteria. In some embodiments, the anomaly criteria relate to confounding factors or events that may lead to inaccurate predictions. For example, the anomaly criteria may relate to whether the user is speaking (e.g., using a microphone or acoustic sensor to detect speech), whether the user is coughing or sneezing (e.g., using a microphone or acoustic sensor, a flow sensor, a pressure sensor, etc.), whether the user is moving (e.g., using an accelerometer, a gyroscope, an acoustic sensor, a flow sensor, a pressure sensor, etc.), whether there is air leakage from the user interface, etc. In some embodiments, the inference system may use various sensors (e.g., sensor 130) to determine whether the anomaly criteria are met.

[0137] If one or more anomaly criteria are met, method 600 proceeds to block 615, where the inference system refrains from generating an AAV probability metric for the traffic generator data accessed at block 605. In some embodiments, refraining from generating the probability metric includes refraining from processing the traffic generator data using a machine learning model such that no probabilities are generated. This can reduce computational overhead, thereby increasing the computational efficiency of the inference system. In some embodiments, refraining from generating the probability metric corresponds to processing the traffic 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 metric corresponds to processing the traffic generator data to generate a prediction and labeling the prediction with a label indicating that the prediction may be untrustworthy or inaccurate due to an anomaly.

[0138] Although not depicted in the illustrated example, in some embodiments, after avoiding generating the AAV probability metric, method 600 may return to block 605 to access additional and / or new traffic generator data to re-evaluate the anomaly criteria at block 610 .

[0139] Returning to block 610, if the inference system determines that the flow generator data does not meet any anomalies, method 600 proceeds to block 620, where the inference system generates an AAV probability metric by processing the flow generator data using one or more machine learning models. As discussed above, the probability metric may generally indicate a probability or likelihood that the flow generator data was generated when the respiratory therapy system was operating with a user interface that includes an AAV. That is, generating the probability metric may include processing the flow generator data using one or more learned parameters of a trained machine learning model to calculate a score indicating a probability that the respiratory therapy system is operating with a user interface that includes an AAV.

[0140] In general, the specific techniques or operations used to generate the AAV probability metric may vary depending on the specific model architecture and implementation. For example, as discussed above, the inference system may perform various pre-processing operations (e.g., downsampling, scaling, generating derivative features such as the minimum or maximum values ​​of one or more metrics, etc.). The (possibly pre-processed) traffic generator data may then be processed using the trained machine learning model to generate the AAV probability metric.

[0141] At box 625, the inference system determines whether AAV is present in the user interface based on the AAV probability and one or more confidence criteria. In some embodiments, the confidence criterion relates to whether the AAV probability is expected to be accurate. For example, the inference system may compare the probability metric with one or more thresholds to determine whether the user interface includes AAV. For example, if the AAV probability is a score between 0 and 1, a first threshold (e.g., less than 0.2) may be used to classify the user interface as lacking AAV, a second threshold (e.g., greater than 0.8) may be used to classify the user interface as including AAV, and the intermediate probability metric may be marked as uncertain or indeterminate. In some embodiments, in addition to the AAV probability metric, the machine learning model also outputs a confidence metric. In one such embodiment, the confidence criterion may correspond to the confidence metric. For example, the inference system may determine whether the model confidence meets or exceeds a certain threshold.

[0142] If, at block 625, the inference system determines or infers that AAV is present (e.g., the AAV probability or classification is above a threshold and / or is associated with a sufficiently high confidence level), method 600 continues to block 630, where the inference system generates a label indicating the presence of AAV in the user interface. Generally, generating the label can include various operations depending on the particular implementation. For example, in some embodiments, the inference system tags 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 operating with a user interface having AAV. In some aspects, the inference system can return or output the label (e.g., to the requesting entity providing the flow generator data).

[0143] If, at block 625, the inference system determines or infers that AAV is not present (e.g., the AAV probability is below a threshold, or the model output generates an "AAV not present" label or category), method 600 continues to block 635, where the inference system generates a label indicating that AAV is not present in the user interface. As discussed above, generating the label may similarly include various operations depending on the particular implementation. For example, in some embodiments, the inference system marks 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 operating with a user interface that did not include AAV. In some aspects, the inference system may return or output the label (e.g., to the requesting entity).

[0144] In some embodiments, the inference system (or another system) can use the generated tags to perform various actions. For example, in some embodiments, the inference system can control or assist in controlling one or more airflow parameters of the respiratory therapy system (or determine or assist in determining adjustments or settings for airflow parameters) based on the tags. 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). Thus, in some embodiments, these airflow parameters can be adjusted (e.g., the parameters can be updated or changed, if necessary) to better suit a full-face mask (in the case where the presence of an AAV is predicted) and to better suit a non-full-face mask (in the case where the absence of an AAV is predicted).

[0145] As another example, if the respiratory therapy system includes an auto-start functionality (e.g., where the system begins providing airflow when breathing is detected), the AAV tag can be used to set one or more thresholds (e.g., flow thresholds) for triggering auto-start (e.g., where the predicted presence of AAV may allow auto-start to be performed using a lower flow threshold).

[0146] As an additional example, AAV tags can be used to enhance other operations or predictions that depend at least in part on whether the user interface is using a full face mask, such as mouth leak detection, snoring detection, etc. By using the generated tags to infer whether the user interface is full face, these other operations can be performed more accurately and efficiently.

[0147] Figure 7 is a process flow diagram of a method 700 for characterizing a user interface (e.g., user interface 124 of system 100) or an AAV of a user interface (e.g., AAV) based on traffic generator data and various criteria using a machine learning model according to some implementations of the present disclosure. One or more steps of method 700 may be performed using system 100 ( Figures 1 to 2 ) is implemented in any element or aspect of the method 700. Although the method 700 has been shown and described herein as occurring in a particular order, more generally, the steps of the method 700 may be performed in any suitable order.

[0148] In some embodiments, a trained machine learning model (e.g., Figure 5 In some embodiments, method 700 may be performed by one or more inference systems that may or may not correspond to the training system. In some embodiments, method 700 provides additional or alternative details for generating predicted AAV metrics, as described above with reference to Figure 6 .

[0149] At block 705, the inference system determines whether one or more initiation criteria are met. Typically, the initiation criteria relate to whether traffic generator data should be collected and / or generated to generate an AAV probability metric. In some embodiments, the inference system only accesses or generates traffic generator data when the initiation criteria are met. In some embodiments, traffic generator data may be generated continuously but may only be stored or otherwise used to predict the presence of AAV when the initiation criteria are met.

[0150] 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 airflow). For example, the inference system may evaluate flow generator data or other data to detect whether the user is wearing the user interface, whether they are breathing, whether there are any anomalies (e.g., talking), etc. 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 inference system may evaluate flow generator data (such as motor speed) to determine whether the system has begun generating airflow.

[0151] If the criteria are not met at box 705, method 700 iterates until the criteria are met. If the inference system determines that the criteria are met, method 700 continues to box 710. At box 710, the inference system generates, collects, or otherwise accesses flow generator data within a duration, window, or time interval. In some embodiments, the length of the interval may vary according to a specific implementation and / or according to which initiation criteria are met. For example, in some embodiments, if the initiation criteria involves the start of the blower motor, the inference system may collect data at relatively small intervals (e.g., one or two seconds) to capture the closure of the AAV (if present) in conjunction with the start. In some embodiments, if the initiation criteria involves user breathing, the inference system may collect data at relatively large intervals (e.g., five to ten seconds) to increase the probability of capturing one or more complete breathing cycles (thereby increasing the probability of capturing at least one AAV closure (if present)).

[0152] As discussed above, flow generator data may generally be collected, generated, or otherwise provided by a respiratory therapy system (e.g., respiratory therapy system 120) when operating in conjunction with respiratory therapy and a user interface (e.g., user interface 124). In embodiments, as discussed above, flow generator data may include various data, such as flow data, pressure data, motor data, and / or audio data, depending on the particular implementation.

[0153] In some aspects, the specific content of the flow generator data generated and / or used may vary depending on the specific implementation and / or the initiation criteria used. For example, in some embodiments, 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 itself may be used as an input to the model. If the motor is off, in one embodiment, the motor data itself may not be used as an input to the model. As another example, in some embodiments, if the motor is on, audio data may be used as an input (e.g., together with flow data, pressure data, and / or motor data). If the motor is off, in one embodiment, audio data may be excluded (e.g., the system may use the model to process only flow data and pressure data). In other embodiments, audio data may also be used as an input when the motor is off.

[0154] At block 715, the inference system generates an AAV probability metric based on the traffic collected or generated at block 710. For example, as discussed above, the inference system may optionally pre-process the data (e.g., to determine maximum values, minimum values, skewness values, etc.) and then process some or all of the (optionally pre-processed) data using one or more trained machine learning models to generate a probability metric indicating whether the user interface includes an AAV.

[0155] At block 720, the inference system determines whether one or more additional iterations should be used to predict the presence of AAV. In some embodiments, whether one or more iterations of flow generator data collection are used may vary depending on the particular implementation. For example, in some embodiments, the inference system may determine whether to use at least one additional iteration based on determining that the probability and / or confidence level satisfies one or more criteria (e.g., if the probability measure is indeterminate and / or the confidence level is sufficiently low, the inference system may determine to perform another iteration). In some embodiments, the number of iterations (or whether to use iterations) may be specified (e.g., as a hyperparameter). For example, the inference system may be configured to perform N iterations, to iteratively collect and / or process flow generator data until a defined time period has elapsed, to iteratively collect and / or process flow generator data throughout a sleep interval, and so on.

[0156] In some embodiments, iterations may include passively collecting or generating flow generator data (e.g., collecting data at appropriate times, such as when a user breathes without providing airflow and / or whenever a user initiates or turns on airflow). In some embodiments, iterations may include active initiation of flow generator data collection. For example, the inference system may perform multiple initiations / flow starts (e.g., briefly starting and stopping airflow multiple times) within a relatively brief period to perform iterations.

[0157] In some embodiments, the inference system can use different airflow parameters for one or more different iterations. For example, during an iterative sequence, the inference system can use a sequence of airflow ramp rates (e.g., the rate at which airflow is increased to reach a target treatment pressure or flow rate at the start of treatment), 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 inference system can use different target pressures, different target flow rates, and so on. In this way, the inference system can generate more diverse flow generator data.

[0158] If no further iterations are used, the method 700 proceeds to block 725, where the inference system optionally aggregates the probability metrics generated from each iteration. For example, the inference system may calculate an average probability metric, a median probability metric, a sum of the probability metrics, etc. In one embodiment, the aggregated probability metric may then be used to generate an AAV signature (e.g., by comparing the aggregated probability metric to one or more thresholds).

[0159] In some embodiments, using data generated over multiple iterations (e.g., multiple times in one night, over multiple nights, using different flow parameters, etc.), the inference system may be able to generate more accurate and reliable AAV predictions compared to a single-iteration solution.

[0160] Figure 8 is a process flow diagram of a method 800 for predicting the presence of an anti-asphyxia valve based on flow generator data using a machine learning model according to some embodiments of the present disclosure. One or more steps of the method 800 may be performed using the system 100 described herein. Figures 1 to 2 ) is implemented in any element or aspect of system 100. Although method 800 has been shown and described herein as occurring in a particular order, more generally, the steps of method 800 may be performed in any suitable order. In some embodiments, method 800 is performed using a trained machine learning model. In some embodiments, method 800 may be performed by one or more inference systems, which may or may not correspond to a training system. For example, an inference system may correspond to or be implemented using one or more components of system 100. In some embodiments, an inference system may correspond to other systems (e.g., a remote server, a cloud system, etc.).

[0161] At block 805, access is made to a respiratory therapy system (e.g., Figure 1 The respiratory therapy system 120 of the present invention provides first flow generator data, the first flow generator data including at least one of the following: (i) flow data (e.g., Figure 1 (ii) pressure data (e.g., generated by the flow rate sensor 134) Figure 1 ), or (iii) motor data.

[0162] At block 810 , a first probability metric is generated by processing first traffic generator data using a trained machine learning model.

[0163] At block 815, a label is generated based on the first probability measure, the label indicating whether the respiratory therapy system is operating in conjunction with a flow generator that includes an anti-asphyxia valve (e.g., Figure 3A and Figure 3B AAV 374) of the user interface (e.g., Figure 1 The user interface 124 operates together with the user interface 124).

[0164] Figure 9 is a process flow diagram of a method 900 for training a machine learning model to predict the presence of an anti-asphyxia valve based on flow generator data, according to some implementations of the present disclosure.

[0165] At block 905, access is made to a respiratory therapy system (e.g., Figure 1 The respiratory therapy system 120 of the present invention provides first flow generator data, the first flow generator data including at least one of the following: (i) flow data (e.g., Figure 1(ii) pressure data (e.g., generated by the flow rate sensor 134) Figure 1 ), or (iii) motor data.

[0166] At block 910, it is determined whether the respiratory therapy system is being used with a device including an anti-asphyxia valve (e.g., Figure 3A and Figure 3B AAV 374) of the user interface (e.g., Figure 1 The user interface 124 operates together with the user interface 124).

[0167] At block 915 , a machine learning model is trained based on the first flow generator data and a determination of whether the respiratory therapy system is operating with a user interface that includes an anti-asphyxia valve to predict the presence of an anti-asphyxia valve.

[0168] Experimental data

[0169] One or more aspects of the above-described methods and techniques are directed to generating test or experimental traffic generator data for various user interfaces under various operating conditions.

[0170] Figure 10A and Figure 10B Traffic generator data signatures for various full-face user interfaces are shown. Specifically, Figure 10A and 10B Depicts the signature of AAV OFF at the start of a session with a full face mask. Graph 1000A depicts the AirFit TM Flow generator data for the F10 model, graph 1000B depicts the AirFit TM Flow generator data for the F20 model, graph 1000C depicts the AirFit TM Flow generator data for the F30i model, graph 1000D depicts AirFit TM Flow generator data for the F30 model, graph 1000E depicts the AmaraView TM Traffic generator data for the model, graph 1000F depicts DreamWear TM Traffic generator data for the FullFace model, graph 1000G depicts Simplus TM Flow generator data for the F10 model, and graph 1000H depicts the Vitera TM Traffic generator data for the model.

[0171] In the illustrated graphs 1000A through 1000H (collectively, graph 1000 ), the data for each traffic generator feature may have undergone one or more pre-processing operations to facilitate visualization and / or use with one or more machine learning models. In the depicted example, the data indicated by lines 1015A to 1015H (collectively, lines 1015) reflects audio data collected for each user interface, the data indicated by lines 1020A to 1020H (collectively, lines 1020) reflects blower flow data collected for each user interface (e.g., airflow volume in liters per second), the data indicated by lines 1025A to 1025H (collectively, lines 1025) reflects blower pressure data collected for each user interface (e.g., airflow pressure in centimeters of water column (cmH2O)), and the data indicated by lines 1030A to 1030H (collectively, lines 1030) reflects motor speed data collected for each user interface (e.g., in revolutions per minute (RPM)).

[0172] Additionally, in the illustrated graph 1000, lines 1005A through 1005H (collectively, lines 1005) indicate when the motor turns on / begins ramping, and boxes 1010A through 1010H (collectively, boxes 1010) indicate the AAV shutdown signature in the various flow generator data, which consists of a unique shape in the acoustic wave form and a peak in the remaining flow generator signal (e.g., within two seconds of the motor speed ramping up).

[0173] Figure 11A 、 Figure 11B and Figure 11C Traffic generator data signatures for various non-comprehensive desktop user interfaces are shown. Specifically, Figure 11A 、 Figure 11B and Figure 11C Graph 1100A depicts flow generator data for a session start for a non-full face mask (e.g., nasal mask, pillow mask, etc.). TM Flow generator data for the N20 model, graph 1100B depicts the AirFit TM Flow generator data for the N20 Classic model, graph 1100C depicts AirFit TM Flow generator data for the N30 model, graph 1100D depicts the AirFit TM Flow generator data for the N30i model, graph 1100E depicts the AirFit TM Flow generator data for the P30i model, graph 1100F depicts the AirFit TM Traffic generator data for the P10 model, graph 1100G depicts BrevidaTM Model traffic generator data, graph 1100H depicts DreamWear TM Traffic generator data for the Pillow model, graph 1100I depicts DreamWisp TM Traffic generator data for the model, graph 1100J depicts WISP TM Flow generator data for the Nasal model, graph 1100K depicts Eson2 TM Model traffic generator data, and graph 1100L depicts DreamWear TM Flow generator data for the Nasal model.

[0174] In the illustrated graphs 1100A-1100L (collectively, graphs 1100 ), the data for each traffic generator feature may have undergone one or more pre-processing operations to facilitate visualization and / or use with one or more machine learning models. In the depicted example, the data indicated by lines 1115A to 1115L (collectively, lines 1115) reflects audio data collected for each user interface, the data indicated by lines 1120A to 1120L (collectively, lines 1120) reflects blower flow data collected for each user interface (e.g., airflow volume in liters per second), the data indicated by lines 1125A to 1125L (collectively, lines 1125) reflects blower pressure data collected for each user interface (e.g., airflow pressure in centimeters of water column (cmH2O)), and the data indicated by lines 1130A to 1130L (collectively, lines 1130) reflects motor speed data collected for each user interface (e.g., in revolutions per minute (RPM)).

[0175] Additionally, in the illustrated graph 1100, lines 1105A to 1105L (collectively, line 1105) indicate when the motor is turned on / begins to ramp up. As shown, no peaks are observed in one or more flow generator signals, such as the blower flow data and / or the blower pressure data (unlike the signature of a full-face mask as discussed above), and the acoustic signature is different from the acoustic signature of a full-face mask as discussed above.

[0176] Figure 12 Flow generator data signatures for various full-face user interfaces are shown when not powered. Specifically, Figure 12 Depicted is a signature of the AAV being off when therapy is stopped (e.g., when motor speed is zero) and the user is wearing / breathing into the user interface. As discussed above, this can be utilized in an auto-start scenario (where the patient wears the user interface and motor activation is triggered when breathing is detected). Figure 12 A flow generator is depicted on graph 1200, where portion 1205A depicts DreamWear TM Traffic generator data for the FullFace model, part 1205A depicts AirFit TM Flow generator data for the F20 model, and section 1205A depicts the AirFit TM Traffic generator data for the N20 model.

[0177] In the illustrated graph 1200, the data for each flow generator feature may have undergone one or more pre-processing operations to facilitate visualization and / or use with one or more machine learning models. In the depicted example, the data indicated by line 1220 reflects blower flow data collected for each user interface (e.g., airflow volume in liters / second), the data indicated by line 1225 reflects blower pressure data collected for each user interface (e.g., airflow pressure in centimeters of water column (cmH2O)), and the data indicated by line 1230 reflects motor speed data collected for each user interface (e.g., in revolutions per minute (RPM)).

[0178] Additionally, in the illustrated graph 1200, lines 1005A through 1005H (collectively, lines 1005) indicate when the motor turns on / begins ramping, and boxes 1010A through 1010H (collectively, boxes 1010) indicate the AAV shutdown signature in the various flow generator data, which consists of a unique shape in the acoustic wave form and a peak in the remaining flow generator signal (e.g., within two seconds of the motor speed ramping up).

[0179] As depicted, with a nasal mask (e.g., the AirFit TM N20 model) compared to full-flow masks (e.g., DreamWear shown in parts 1205A and 1205B, respectively). TM FullFace Model and AirFit TM F20 model) have different signatures in terms of flow and pressure. For example, nasal masks tend to result in flow and / or pressure with large variations that are roughly symmetrical around zero, while full-face masks with AAV tend to result in flow and / or pressure data that are smaller and / or asymmetrical around zero.

[0180] Figure 131300 is a graph depicting notched box plots of experimental model accuracy for models trained on various features according to some embodiments of the present disclosure. In the illustrated example, a collection of ten machine learning models was trained on six separate configurations of feature data: each individual flow generator signal (e.g., motor speed, air flow, or air pressure), a combination of flow generator signals (e.g., motor speed, air flow, and air pressure), audio data only, and all flow generator signals (e.g., motor speed, air flow, air pressure, and audio). The models were trained on a subset of data collected on human subjects under controlled conditions and tested on an independent test set covering twenty mask types.

[0181] In the illustrated graph 1300, the resulting model accuracy is plotted on the vertical axis using corresponding notched box plots for each corresponding feature combination. Specifically, notched box plot 1305A corresponds to a model trained on motor data only (e.g., motor speed), notched box plot 1305B corresponds to a model trained on flow data only (e.g., air flow rate), notched box plot 1305C corresponds to a model trained on pressure data only (e.g., air pressure), notched box plot 1305D corresponds to a model 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 a model trained on audio data only, and notched box plot 1305F corresponds to a model trained on flow generator data including motor speed data, air pressure data, air flow data, and audio data.

[0182] Sample Clauses

[0183] 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 metric by processing the first flow generator data using a trained machine learning model; and generating a label based on the first probability metric, the label indicating whether the respiratory therapy system was operating with a user interface including an anti-asphyxia valve when the flow generator data was generated.

[0184] Clause 2: The method of clause 1, wherein the first flow generator data comprises at least two of: (i) flow data, (ii) pressure data, or (iii) motor data.

[0185] Clause 3: The method of clause 1 or 2, wherein the first flow generator data comprises (i) flow data, (ii) pressure data, and (iii) motor data.

[0186] Clause 4: The method of any one of clauses 1 to 3, wherein the first traffic generator data further comprises audio data.

[0187] Clause 5: The method of any one of clauses 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 time window beginning at the first time.

[0188] Clause 6: The method of any one of clauses 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.

[0189] Clause 7: The method of clause 6, wherein the first flow generator data comprises at least one of: (i) a maximum value of at least one of the flow rate or pressure, (ii) a minimum value of at least one of the flow rate or pressure, (iii) a skewness value of at least one of the flow rate or pressure, or (iv) a kurtosis value of at least one of the flow rate or pressure.

[0190] Clause 8: The method of any one of clauses 1 to 7, further comprising: accessing second flow generator data provided by the respiratory therapy system; generating a second probability metric by processing the second flow generator data using the trained machine learning model; and further generating the label based on the second probability metric, the label indicating whether the respiratory therapy system was operating with the user interface including the anti-asphyxia valve when the flow generator data was generated.

[0191] Clause 9: A method according to any one of clauses 1 to 8, wherein: the first flow generator data is collected when the respiratory therapy system uses a first airflow ramp rate, and the second flow generator data is collected when the respiratory therapy system uses a second airflow ramp rate.

[0192] Clause 10: The method according to any one of clauses 1 to 9 further includes preprocessing the first traffic generator data before processing the first traffic generator data using the trained machine learning model, including at least one of the following: (i) scaling the first traffic generator data, or (ii) downsampling the first traffic generator data.

[0193] Clause 11: The method of any of clauses 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 includes an anti-asphyxia valve.

[0194] Clause 12: The method according to any one of clauses 1 to 11 further includes: accessing third flow generator data provided by the respiratory therapy system; determining that the respiratory therapy system satisfies one or more anomaly criteria relative to the third flow generator data; and in response to determining that the one or more anomaly criteria are satisfied, performing at least one of the following: avoiding generating a probability measure for the third flow generator data, or generating a flag indicating that the one or more anomaly criteria are satisfied.

[0195] Clause 13: A method according to clause 12, wherein determining that the one or more abnormality criteria are satisfied includes at least one of the following: (i) detecting air leakage of the user interface based on the third flow generator data, (ii) detecting speech from the user using a microphone sensor, or (iii) detecting movement of the user using an accelerometer sensor.

[0196] Clause 14: A method according to any one of clauses 1 to 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.

[0197] Clause 15: A method according to any one of clauses 1 to 14, wherein generating the first probability metric comprises processing the first flow generator data using one or more learning parameters of the trained machine learning model to calculate a score indicating the probability that the first respiratory therapy system was operating with the user interface comprising the AAV when the flow generator data was generated.

[0198] 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 is operating with a user interface that includes an anti-asphyxia valve when the first flow generator data is collected; and training a machine learning model based on the first flow generator data and the determination of whether the respiratory therapy system is operating with a user interface that includes an anti-asphyxia valve to predict the presence of an anti-asphyxia valve.

[0199] Clause 17: The method of clause 16, wherein the first flow generator data comprises at least two of: (i) flow data, (ii) pressure data, or (iii) motor data.

[0200] Clause 18: The method of clause 16 or 17, wherein the first flow generator data comprises (i) flow data, (ii) pressure data, and (iii) motor data.

[0201] Clause 19: The method of any one of clauses 16 to 18, wherein the first traffic generator data further comprises audio data.

[0202] Clause 20: The method of any one of clauses 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 time window beginning at the first time.

[0203] Clause 21: The method of any one of clauses 16 to 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.

[0204] Clause 22: A method according to clause 21, wherein the first flow generator data includes at least one of the following: (i) a maximum value of at least one of the flow rate or pressure, (ii) a minimum value of at least one of the flow rate or pressure, (iii) a skewness value of at least one of the flow rate or pressure, or (iv) a kurtosis value of at least one of the flow rate or pressure.

[0205] Clause 23: The method according to any one of clauses 16 to 22 further includes preprocessing the first traffic generator data before processing the first traffic generator data using the trained machine learning model, including at least one of the following: (i) scaling the first traffic generator data, or (ii) downsampling the first traffic generator data.

[0206] Clause 24: A system comprising: a control system comprising one or more processors; and a memory having machine-readable instructions stored thereon; wherein the control system is coupled to the memory, and the method according to 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.

[0207] Clause 25: The system of 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.

[0208] Clause 26: The system of 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.

[0209] Clause 27: The system of any one of clauses 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.

[0210] Clause 28: The system of any one of clauses 24 to 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.

[0211] Clause 29: The system of any one of clauses 24 to 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.

[0212] Clause 30: The system of any of clauses 26 to 29, wherein at least one of the one or more microphones, the flow rate sensor, the pressure sensor, or the motor sensor is included in a respiratory therapy device.

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

[0214] Clause 29: The system of clause 28, wherein the characterization is based at least in part on whether the user interface is determined to include an anti-asphyxia valve.

[0215] Clause 30: A computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method according to any one of claims 1 to 23.

[0216] Clause 31: The computer program product of clause 30, wherein the computer program product is a non-transitory computer readable medium.

[0217] Additional considerations

[0218] One or more elements or aspects or steps or any portions thereof from one or more of any of the following claims may be combined with one or more elements or aspects or steps or any portions thereof from one or more of any other of the following claims or combinations thereof to form one or more additional implementations and / or claims of the present disclosure.

[0219] Although the present disclosure has been described with reference to one or more specific 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 considered to fall 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 implementation described herein.

[0220] The foregoing description is provided to enable any person skilled in the art to practice the various embodiments described herein. The examples discussed herein do not limit the scope, applicability, or embodiments set forth in the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments. For example, the functions and arrangements of the elements discussed may be changed without departing from the scope of this disclosure. Various examples may omit, replace, or add various processes or components as appropriate. For example, the methods described may be performed in an order different from that described, and various steps may be added, omitted, or combined. In addition, the features described with respect to some examples may be combined in some other examples. For example, any number of aspects set forth herein may be used to implement a device or practice a method. In addition, the scope of this disclosure is intended to cover such a device or method practiced using other structures, functions, or structures and functions that supplement or replace 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 the claims.

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

[0222] As used herein, a phrase referring to "at least one" of a list of items refers to any combination of those items, including individual members. For example, "at least one of a, b, or c" is intended to encompass a, b, c, ab, ac, bc, and abc, as well as any combination with multiples of the same element (e.g., aa, aaa, aab, aac, abb, ac, bb, bbb, bbc, cc, and ccc, or any other ordering of a, b, and c).

[0223] As used herein, the term "determining" encompasses a wide variety of actions. For example, "determining" may include calculating, computing, processing, deriving, investigating, searching (e.g., searching in a table, database, or another data structure), ascertaining, and the like. Furthermore, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. Furthermore, "determining" may include resolving, selecting, choosing, establishing, and the like.

[0224] The method disclosed herein includes one or more steps or actions for implementing the method. Without departing from the scope of the claims, the method steps and / or actions are interchangeable with each other. 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. In addition, the various operations of the above-mentioned method can be performed by any suitable device capable of performing the corresponding function. The device may include various hardware and / or software components and / or modules, including but not limited to circuits, application specific integrated circuits (ASICs) or processors. Typically, where there are operations shown in the accompanying drawings, those operations may have corresponding corresponding means plus function components (counterpart means-plus-function components) with similar numbers.

[0225] Embodiments of the present invention may be provided to end users via 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 can be defined as computing capabilities that provide an abstraction between computing resources and their underlying technology infrastructure (e.g., servers, storage, networks), thereby enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be quickly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows users to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in a "cloud" without regard to the underlying physical systems (or the location of those systems) used to provide the computing resources.

[0226] Typically, cloud computing resources are provided to users on a pay-per-use basis, where users pay only for the computing resources actually used (e.g., the amount of storage space consumed by the user or the number of virtualized systems instantiated by the user). Users can access any resource residing in the cloud at any time and from anywhere on the Internet. In the context of the present invention, users can access applications or systems (e.g., training systems and / or inference systems) or related data available in the cloud. For example, the training system and / or inference system can be executed on a computing system in the cloud and train and use a machine learning model to predict the presence of AAV. In this case, the training system and / or inference system can receive and process traffic generator data and store the model and AAV predictions in a storage location in the cloud. Doing so allows users to access this information from any computing system attached to a network connected to the cloud (e.g., the Internet).

[0227] The following claims are not intended to be limited to the embodiments shown herein, but should be given the full scope consistent with the language of the claims. In the claims, unless otherwise specified, elements mentioned in the singular do not mean "one and only one", but "one or more". Unless otherwise specifically stated, the term "some" refers to one or more. No claim element should be interpreted according to the provisions of 35 U.S.C. § 112 (f) unless the element is explicitly recorded using the phrase "device for..." or, in the case of a method claim, the element is recorded using the phrase "step for...". All structural and functional equivalents of the elements of the various aspects described throughout this disclosure that are known or will be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims. In addition, nothing disclosed herein is intended to be dedicated to the public, regardless of whether such disclosure is explicitly recorded in the claims.

Claims

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 metric by processing the first traffic generator data using a trained machine learning model; as well as A label is generated based on the first probability metric, the label indicating whether the respiratory therapy system was operating with a user interface including an anti-asphyxia valve 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 2, wherein the first flow generator data comprises (i) flow data, (ii) pressure data, and (iii) motor data.

4. The method according to any one of claims 1 to 3, wherein the first traffic generator data further comprises audio data.

5. The method according to any one of claims 1 to 4, further comprising: determining that the respiratory therapy system has initially begun providing airflow; as well as The first traffic generator data is collected corresponding to a predefined time window starting at the first time.

6. The method according to 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 traffic generator data comprises at least one of: (i) the maximum value of at least one of the flow rate or pressure, (ii) a minimum value of at least one of flow rate or pressure, (iii) the skewness of at least one of flow rate or pressure, or (iv) The kurtosis value of at least one of the flow rate or the pressure.

8. The method according to any one of claims 1 to 7, further comprising: accessing second flow generator data provided by the respiratory therapy system; generating a second probability metric by processing the second traffic generator data using the trained machine learning model; as well as The label is generated based further on the second probability metric, the label indicating whether the respiratory therapy system was operating with the user interface including the anti-asphyxia valve when the flow generator data was generated.

9. The method according to claim 8, wherein: The first flow generator data is collected while the respiratory therapy system is using a first airflow ramp rate, and The second flow generator data is collected while the respiratory therapy system is using a second airflow ramp rate.

10. The method according to any one of claims 1 to 9 further includes preprocessing the first traffic generator data before processing the first traffic generator data using the trained machine learning model, including at least one of the following: (i) scaling the first traffic generator data, or (ii) downsampling the first traffic 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 includes an anti-asphyxia valve.

12. The method according to any one of claims 1 to 11, further comprising: accessing third flow generator data provided by the respiratory therapy system; determining that the respiratory therapy system meets one or more anomaly criteria with respect to the third flow generator data; and In response to determining that the one or more exception criteria are met, performing at least one of the following: refrain from generating a probability metric for said third traffic generator data, or A flag is generated indicating that the one or more exception criteria are met.

13. The method of claim 12, wherein determining that the one or more exception criteria are satisfied comprises at least one of: (i) detecting an air leak of the user interface based on the third flow generator data, (ii) detecting speech from the user using a microphone sensor, or (iii) detecting the user's motion using an accelerometer sensor.

14. The method of any one of claims 1 to 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 to 14, wherein generating the first probability metric comprises processing the first flow generator data using one or more learned parameters of the trained machine learning model to calculate a score indicating a probability that a first respiratory therapy system was operating with the user interface comprising an AAV 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 is operating with a user interface including an anti-asphyxia valve when the first flow generator data is collected; as well as A machine learning model is trained based on the first flow generator data and a determination of whether the respiratory therapy system is being operated with a user interface that includes an anti-asphyxia valve to predict the presence of an anti-asphyxia valve.

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.

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 according to any one of claims 16 to 18, wherein the first traffic generator data further comprises audio data.

20. The method according to any one of claims 16 to 19, further comprising: determining that the respiratory therapy system has initially begun providing airflow; as well as The first traffic generator data is collected corresponding to a predefined time window starting at the first time.

21. The method according to any one of claims 16 to 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 traffic generator data comprises at least one of: (i) the maximum value of at least one of the flow rate or pressure, (ii) a minimum value of at least one of flow rate or pressure, (iii) the skewness of at least one of flow rate or pressure, or (iv) The kurtosis value of at least one of the flow rate or the pressure.

23. The method according to any one of claims 16 to 22 further includes preprocessing the first traffic generator data before using the trained machine learning model to process the first traffic generator data, including at least one of the following: (i) scaling the first traffic generator data, or (ii) downsampling the first traffic generator data.

24. A system comprising: a control system comprising one or more processors; as well as a memory having machine-readable instructions stored thereon; wherein the control system is coupled to the memory, and the method according to 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 to 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 to 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 to 29, wherein at least one of the one or more microphones, the flow rate sensor, the pressure sensor, or the motor sensor is included 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.

32. The system of claim 31 , wherein the characterization is based at least in part on whether the user interface is determined to include an anti-asphyxia valve.

33. A computer program product comprising instructions which, when executed by a computer, cause the computer to perform the method according to 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.

Images