Detecting user interface changes using respiratory therapy data

Abstract

Techniques for improved machine learning to predict interface switches are provided. Respiratory therapy data of a user of a flow generator is accessed, the respiratory therapy data comprising a time series of record. A change point is identified by processing the respiratory therapy data using a machine learning model. A confidence measure indicating a probability that the user switched from a first user interface for the flow generator to a second user interface for the flow generator at the change point is generated, and a label indicating that the user switched to the second user interface at the change point is generated based on the confidence measure.

Description

DETECTING USER INTERFACE CHANGES USING RESPIRATORY THERAPY DATACROSS-REFERENCE TO REEATED APPLICATIONS

[0001] This application claims priority to Greek Patent Application No. 20230100594, filed July 19, 2023, the entire contents of which are incorporated herein by reference in their entirety.TECHNICAL FIELD

[0002] The present disclosure relates generally to use of machine learning to identify user interface switches, and more particularly, to use of machine learning to identify interface switches based on respiratory therapy data.BACKGROUND

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

[0004] Each respiratory therapy system generally has a respiratory therapy device connected to a user interface (e.g., a mask) via a conduit and optionally a connector. The user wears the user interface and is supplied a flow of pressurized air from the respiratory therapy device via the conduit. The user interface generally is a specific category and type of user interface for the user, such as direct or indirect connections for the category of user interface, and full face mask, a partial face mask, nasal mask, or nasal pillows for the type of user interface. In addition to the specific category and type, the user interface generally is a specific model made by a specific manufacturer, e.g., AirFit™ F20 manufactured by ResMed. For various reasons, such as ensuring the user is using the correct user interface, it can be beneficial for the respiratory system to know the specific category, type, and / or model of the user interface worn by the user.

[0005] Thus, it is advantageous to know the user interface of a respiratory therapy system for providing improved control of therapy delivered to the user. For instance, it may be advantageous to know the user interface in order to accurately measure or estimate treatment parameters, such as pressure in the user interface and vent flow. Accordingly, knowledge of what user interface is being used can enhance therapy. Although some respiratory therapy devices may include a menu system that allows a user to manually enter the type of user interface being used (e.g., by type, model, manufacturer, etc.), the user may enter incorrect or incomplete information. As such, it may be advantageous to determine the user interface independently of user input.

[0006] In addition, user interface cushions, vents on the user interface or on a connector to the user interface, and other user interface components can deteriorate over time. For example, vents can become blocked or occluded over time due to a buildup of unwanted material (e.g., saliva, mucus, skin cells, bedding fibers, debris from the user interface), or become temporarily / transiently blocked or occluded (e.g., against bedding or a pillow). A deteriorated and / or occluded vent can cause the vent- flow performance of the user interface to deviate from the normal performance, which may impact therapy comfort or therapy accuracy. The deteriorated and / or the occluded vent can also lead to a buildup of CO2, which in turn may result in inefficient therapy, additional noise, patient discomfort, or even danger to the user. Thus, when the vent is deteriorated or occluded, it can negatively impact therapy. As a result, some users will discontinue use of the respiratory therapy system because of the discomfort and / or inaccurate therapy caused by the deteriorated user interface components. As such, it may be advantageous to determine the user interface being used by a user so that the age of the user interface, when the user interface was last changed, etc. may be monitored and actions taken to avoid or remediate deteriorated user interfaces or user interface components.

[0007] The present disclosure is directed to solving these and other problems.SUMMARY

[0008] According to some implementations of the present disclosure, a method includes accessing respiratory therapy data of a user of a flow generator, the respiratory therapy data comprising a time series of records; identifying a change point by processing the respiratory therapy data using a machine learning model; generating a confidence measure indicating a probability that the user switched from a first user interface for the flow generator to a second user interface for the flow generator at the change point; and generating, based on theconfidence measure, a label indicating that the user switched to the second user interface at the change point.

[0009] According to some implementations of the present disclosure, a method includes accessing an image captured, by a user of a flow generator, to identify a user interface of the flow generator; generating a first classification of the user interface of the flow generator by processing the image using a first machine learning model, the first classification indicating a model of the user interface; determining a first confidence measure of the first classification; and generating a label indicating the first classification of the user interface based at least in part on the first confidence measure.

[0010] According to some implementations of the present disclosure, a method includes accessing a first plurality of training images depicting user interfaces for flow generators; determining a plurality of classifications for the first plurality of training images, each respective classification of the plurality of classifications indicating a respective model of a user interface depicted in a respective image; and training a first machine learning model, based on the first plurality of training images and the plurality of classifications, to predict user interface models in captured images.

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

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

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

[0014] FIG. 1 depicts a functional block diagram of a system, according to some implementations of the present disclosure;

[0015] FIG. 2 depicts a perspective view of at least a portion of the system of FIG. 1, a user, and a bed partner, according to some implementations of the present disclosure;

[0016] FIG. 3A depicts a perspective view of one category of user interfaces, according to some implementations of the present disclosure.

[0017] FIG. 3B depicts an exploded view of the user interface of FIG. 3A, according to some implementations of the present disclosure.

[0018] FIG. 4A is a perspective view of another category of user interfaces, according to some implementations of the present disclosure.

[0019] FIG. 4B is an exploded view of the user interface of FIG. 4A, according to some implementations of the present disclosure.

[0020] FIG. 5A is a perspective view of another category of user interfaces, according to some implementations of the present disclosure.

[0021] FIG. 5B is an exploded view of the user interface of FIG. 5A, according to some implementations of the present disclosure.

[0022] FIG. 6 depicts a rear perspective view of a respiratory therapy device of the system of FIG. 1, according to some implementations of the present disclosure.

[0023] FIG. 7 depicts an example workflow for detecting interface changes and classifying user interfaces, according to some implementations of the present disclosure.

[0024] FIG. 8 depicts an example workflow for detecting interface changes using machine learning, according to some implementations of the present disclosure.

[0025] FIG. 9 depicts an example workflow for classifying user interfaces using machine learning, according to some implementations of the present disclosure.

[0026] FIG. 10 depicts an example workflow for training machine learning models to classify user interfaces, according to some implementations of the present disclosure.

[0027] FIG. 11 is a flow diagram depicting an example method for detecting interface changes using machine learning, according to some embodiments of the present disclosure.

[0028] FIG. 12 is a flow diagram depicting an example method for classifying user interfaces using machine learning, according to some embodiments of the present disclosure.

[0029] FIG. 13 is a flow diagram depicting an example method for training machine learning models to classify user interfaces, according to some embodiments of the present disclosure.

[0030] FIG. 14 is a flow diagram depicting an example method for method for identifying user interface switches, according to some embodiments of the present disclosure.

[0031] FIG. 15 is a flow diagram depicting an example method for classifying user interfaces, according to some embodiments of the present disclosure.

[0032] FIG. 16 is a flow diagram depicting an example method for training machine learning models to classify user interfaces, according to some embodiments of the present disclosure.

[0033] FIG. 17 depicts an example inferencing device configured to perform various aspects of the present disclosure, according to some embodiments disclosed herein.

[0034] FIG. 18 depicts an example training device configured to perform various aspects of the present disclosure, according to some embodiments disclosed herein.

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

[0036] Embodiments of the present disclosure generally provide techniques for detection of user interface switches (e.g., when a user switches from a first interface to a second) based on therapy data, and / or for classification / identification of user interfaces based on images of user interfaces. In some embodiments, one or more machine learning models can be trained and / or used to evaluate multivariate time series therapy data in order to identify change points where the user switched to a new user interface. In some embodiments, this change identification serves as a trigger to image-based interface classification. In some embodiments, one or more machine learning models can be trained and / or used to identify or classify user interfaces depicted in captured images. This automated machine learning-based process of detecting interface changes and identifying the new interface can substantially improve the respiratory therapy itself (e.g., resulting in improved treatment of respiratory concerns), as well as improving a variety of other systems and operations (e.g., facilitating improved provisioning of therapy components when needed).

[0037] Many individuals suffer from sleep-related and / or respiratory disorders. Examples of sleep-related and / or respiratory disorders include Periodic Limb Movement Disorder(PLMD), Restless Leg Syndrome (RLS), Sleep-Disordered Breathing (SDB) such as Obstructive Sleep Apnea (OSA), Central Sleep Apnea (CSA), and other types of apneas (e.g., mixed apneas and hypopneas), Respiratory Effort Related Arousal (RERA), Cheyne-Stokes Respiration (CSR), respiratory insufficiency, Obesity Hyperventilation Syndrome (OHS), Chronic Obstructive Pulmonary Disease (COPD), Neuromuscular Disease (NMD), and chest wall disorders.

[0038] Obstructive Sleep Apnea (OSA) is a form of Sleep Disordered Breathing (SDB), and is characterized by events including occlusion or obstruction of the upper air passage during sleep resulting from a combination of an abnormally small upper airway and the normal loss of muscle tone in the region of the tongue, soft palate and posterior oropharyngeal wall. More generally, an apnea generally refers to the cessation of breathing caused by blockage of the air (Obstructive Sleep Apnea) or the stopping of the breathing function (often referred to as Central Sleep Apnea). Typically, the individual will stop breathing for between about 15 seconds and about 30 seconds during an obstructive sleep apnea event.

[0039] Other types of apneas include hypopnea, hyperpnea, and hypercapnia. Hypopnea is generally characterized by slow or shallow breathing caused by a narrowed airway, as opposed to a blocked airway. Hyperpnea is generally characterized by an increase depth and / or rate of breathing. Hypercapnia is generally characterized by elevated or excessive carbon dioxide in the bloodstream, typically caused by inadequate respiration.

[0040] A Respiratory Effort Related Arousal (RERA) event is typically characterized by an increased respiratory effort for 10 seconds or longer leading to arousal from sleep and which does not fulfill the criteria for an apnea or hypopnea event. In 1999, the AASM Task Force defined RERAs as “a sequence of breaths characterized by increasing respiratory effort leading to an arousal from sleep, but which does not meet criteria for an apnea or hypopnea.” These events must fulfil both of the following criteria: 1. pattern of progressively more negative esophageal pressure, terminated by a sudden change in pressure to a less negative level and an arousal; 2. the event lasts 10 seconds or longer. In 2000, the study “Non-Invasive Detection of Respiratory Effort-Related Arousals (RERAs) by a Nasal Cannula / Pressure Transducer System” done at NYU School of Medicine and published in Sleep, vol. 23, No. 6, pp. 763-771, demonstrated that a Nasal Cannula / Pressure Transducer System was adequate and reliable in the detection of RERAs. A RERA detector may be based on a real flow signal derived from a respiratory therapy (e.g., PAP) device. For example, a flow limitation measure may be determined based on a flow signal. A measure of arousal may then be derived as a function of the flow limitation measure and a measure of sudden increase in ventilation. Some suchmethods are described in WO 2008 / 138040, assigned to ResMed Ltd., the disclosure of which is hereby incorporated herein by reference in its entirety.

[0041] Cheyne-Stokes Respiration (CSR) is another form of sleep disordered breathing. CSR is a disorder of a patient’s respiratory controller in which there are rhythmic alternating periods of waxing and waning ventilation known as CSR cycles. CSR is characterized by repetitive de-oxygenation and re-oxygenation of the arterial blood.

[0042] Obesity Hyperventilation Syndrome (OHS) is defined as the combination of severe obesity and awake chronic hypercapnia, in the absence of other known causes for hypoventilation. Symptoms include dyspnea, morning headache and excessive daytime sleepiness.

[0043] Chronic Obstructive Pulmonary Disease (COPD) encompasses any of a group of lower airway diseases that have certain characteristics in common, such as increased resistance to air movement, extended expiratory phase of respiration, and loss of the normal elasticity of the lung.

[0044] Neuromuscular Disease (NMD) encompasses many diseases and ailments that impair the functioning of the muscles either directly via intrinsic muscle pathology, or indirectly via nerve pathology. Chest wall disorders are a group of thoracic deformities that result in inefficient coupling between the respiratory muscles and the thoracic cage.

[0045] These and other disorders are characterized by particular events (e.g., snoring, an apnea, a hypopnea, a restless leg, a sleeping disorder, choking, an increased heart rate, labored breathing, an asthma attack, an epileptic episode, a seizure, or any combination thereof) that occur when the individual is sleeping.

[0046] The Apnea-Hypopnea Index (AHI) is an index used to indicate the severity of sleep apnea during a sleep session. The AHI is calculated by dividing the number of apnea and / or hypopnea events experienced by the user during the sleep session by the total number of hours of sleep in the sleep session. The event can be, for example, a pause in breathing that lasts for at least 10 seconds. An AHI that is less than 5 is considered normal. An AHI that is greater than or equal to 5, but less than 15 is considered indicative of mild sleep apnea. An AHI that is greater than or equal to 15, but less than 30 is considered indicative of moderate sleep apnea. An AHI that is greater than or equal to 30 is considered indicative of severe sleep apnea. In children, an AHI that is greater than 1 is considered abnormal. Sleep apnea can be considered “controlled” when the AHI is normal, or when the AHI is normal or mild. The AHI can also be used in combination with oxygen desaturation levels to indicate the severity of Obstructive Sleep Apnea.

[0047] Referring to FIG. 1, a system 100, according to some implementations of the present disclosure, is illustrated. The system 100 includes a control system 110, a memory device 114, an electronic interface 119, one or more sensors 130, and one or more user devices 170. In some implementations, the system 100 further optionally includes a respiratory therapy system 120, and an activity tracker 180.

[0048] The control system 110 includes one or more processors 112 (hereinafter, processor 112). The control system 110 is generally used to control (e.g., actuate) the various components of the system 100 and / or analyze data obtained and / or generated by the components of the system 100. The processor 112 can be a general or special purpose processor or microprocessor. While one processor 112 is illustrated in FIG. 1, the control system 110 can include any number of processors (e.g., one processor, two processors, five processors, ten processors, etc.) that can be in a single housing, or located remotely from each other. The control system 110 (or any other control system) or a portion of the control system 110 such as the processor 112 (or any other processor(s) or portion(s) of any other control system), can be used to carry out one or more steps of any of the methods described and / or claimed herein. The control system 110 can be coupled to and / or positioned within, for example, a housing of the user device 170, a portion (e.g., a housing) of the respiratory therapy system 120, and / or within a housing of one or more of the sensors 130. The control system 110 can be centralized (within one such housing) or decentralized (within two or more of such housings, which are physically distinct). In such implementations including two or more housings containing the control system 110, such housings can be located proximately and / or remotely from each other.

[0049] The memory device 114 stores machine-readable instructions that are executable by the processor 112 of the control system 110. The memory device 114 can be any suitable computer readable storage device or media, such as, for example, a random or serial access memory device, a hard drive, a solid state drive, a flash memory device, etc. While one memory device 114 is shown in FIG. 1, the system 100 can include any suitable number of memory devices 114 (e.g., one memory device, two memory devices, five memory devices, ten memory devices, etc.). The memory device 114 can be coupled to and / or positioned within a housing of a respiratory therapy device 122 of the respiratory therapy system 120, within a housing of the user device 170, within a housing of one or more of the sensors 130, or any combination thereof. Like the control system 110, the memory device 114 can be centralized (within one such housing) or decentralized (within two or more of such housings, which are physically distinct).

[0050] In some implementations, the memory device 114 stores a user profile associated with the user. The user profile can include, for example, demographic information associated with the user, biometric information associated with the user, medical information associated with the user, self-reported user feedback, sleep parameters associated with the user (e.g., sleep-related parameters recorded from one or more earlier sleep sessions), or any combination thereof. The demographic information can include, for example, information indicative of an age of the user, a gender of the user, a race of the user, a geographic location of the user, a relationship and / or bed sharing status, a family history of insomnia or sleep apnea, an employment status of the user, an educational status of the user, a socioeconomic status of the user, or any combination thereof. The medical information can include, for example, information indicative of one or more medical conditions associated with the user, medication usage by the user, or both. The medical information data can further include a multiple sleep latency test (MSLT) result or score and / or a Pittsburgh Sleep Quality Index (PSQI) score or value. The self-reported user feedback can include information indicative of a self-reported subjective sleep score (e.g., poor, average, excellent), a self-reported subjective stress level of the user, a self-reported subjective fatigue level of the user, a self-reported subjective health status of the user, a recent life event experienced by the user, or any combination thereof.

[0051] The electronic interface 119 is configured to receive data (e.g., physiological data and / or acoustic data) from the one or more sensors 130 such that the data can be stored in the memory device 114 and / or analyzed by the processor 112 of the control system 110. The electronic interface 119 can communicate with the one or more sensors 130 using a wired connection or a wireless connection (e.g., using an RF communication protocol, a Wi-Fi communication protocol, a Bluetooth communication protocol, over a cellular network, etc.). The electronic interface 119 can include an antenna, a receiver (e.g., an RF receiver), a transmitter (e.g., an RF transmitter), a transceiver, or any combination thereof. The electronic interface 119 can also include one more processors and / or one more memory devices that are the same as, or similar to, the processor 112 and the memory device 114 described herein. In some implementations, the electronic interface 119 is coupled to or integrated in the user device 170. In other implementations, the electronic interface 119 is coupled to or integrated (e.g., in a housing) with the control system 110 and / or the memory device 114.

[0052] As noted above, in some implementations, the system 100 optionally includes a respiratory therapy system 120. The respiratory therapy system 120 can include a respiratory pressure therapy (RPT) device 122 (referred to herein as respiratory therapy device 122, and also referred to as a flow generator in some embodiments), a user interface 124, a conduit 126(also referred to as a tube or an air circuit), a display device 128, a humidification tank 129, or any combination thereof. In some implementations, the control system 110, the memory device 114, the display device 128, one or more of the sensors 130, and the humidification tank 129 are part of the respiratory therapy device 122. Respiratory pressure therapy refers to the application of a supply of air to an entrance to a user’s airways at a controlled target pressure that is nominally positive with respect to atmosphere throughout the user’s breathing cycle (e.g., in contrast to negative pressure therapies such as the tank ventilator or cuirass). The respiratory therapy system 120 is generally used to treat individuals suffering from one or more sleep-related respiratory disorders (e.g., obstructive sleep apnea, central sleep apnea, or mixed sleep apnea).

[0053] The respiratory therapy device 122 is generally used to generate pressurized air that is delivered to a user (e.g., using one or more motors that drive one or more compressors). In some implementations, the respiratory therapy device 122 generates continuous constant air pressure that is delivered to the user. In other implementations, the respiratory therapy device 122 generates two or more predetermined pressures (e.g., a first predetermined air pressure and a second predetermined air pressure). In still other implementations, the respiratory therapy device 122 is configured to generate a variety of different air pressures within a predetermined range. For example, the respiratory therapy device 122 can deliver at least about 6 cmFhO, at least about 10 cmFhO, at least about 20 cmFhO, between about 6 cmlTO and about 10 cmFLO, between about 7 cmkhO and about 12 cmlTO, etc. The respiratory therapy device 122 can also deliver pressurized air at a predetermined flow rate between, for example, about -20 L / min and about 150 L / min, while maintaining a positive pressure (relative to the ambient pressure).

[0054] The user interface 124 engages a portion of the user’s face and delivers pressurized air from the respiratory therapy device 122 to the user’s airway to aid in preventing the airway from narrowing and / or collapsing during sleep. This may also increase the user’s oxygen intake during sleep. Generally, the user interface 124 engages the user’s face such that the pressurized air is delivered to the user’s airway via the user’s mouth, the user’s nose, or both the user’s mouth and nose. Together, the respiratory therapy device 122, the user interface 124, and the conduit 126 form an air pathway fluidly coupled with an airway of the user. The pressurized air also increases the user’s oxygen intake during sleep. Depending upon the therapy to be applied, the user interface 124 may form a seal, for example, with a region or portion of the user’s face, to facilitate the delivery of gas at a pressure at sufficient variance with ambient pressure to effect therapy, for example, at a positive pressure of about 10 cmlTO relative to ambient pressure. For other forms of therapy, such as the delivery of oxygen, theuser interface may not include a seal sufficient to facilitate delivery to the airways of a supply of gas at a positive pressure of about 10 cmH O. In some implementations, the user interface 124 may include a connector 127 and one or more vents 125, which are described in more detail with reference to FIGS. 3A-3B, 4A-4B, and 5A-5B. In some implementations, the connector 127 is distinct from, but couplable to, the user interface 124 (and / or conduit 126).

[0055] As shown in FIG. 2, in some implementations, the user interface 124 is a facial mask (e.g., a full face mask) that covers the nose and mouth of the user. Alternatively, the user interface 124 can be a nasal mask that provides air to the nose of the user or a nasal pillow mask that delivers air directly to the nostrils of the user. The user interface 124 can include a plurality of straps forming, for example, a headgear for aiding in positioning and / or stabilizing the interface on a portion of the user (e.g., the face) and a conformal cushion (e.g., silicone, plastic, foam, etc.) that aids in providing an air-tight seal between the user interface 124 and the user. The user interface 124 can also include one or more vents for permitting the escape of carbon dioxide and other gases exhaled by the user 210. In other implementations, the user interface 124 includes a mouthpiece (e.g., a night guard mouthpiece molded to conform to the teeth of the user, a mandibular repositioning device, etc.).

[0056] FIGS. 3A and 3B illustrate a perspective view and an exploded view, respectively, of one implementation of a directly connected user interface (“direct category” user interfaces), according to aspects of the present disclosure. The direct category of a user interface 300 generally includes a cushion 330 and a frame 350 that define a volume of space around the mouth and / or nose of the user. When in use, the volume of space receives pressurized air for passage into the user’s airways. In some embodiments, the cushion 330 and frame 350 of the user interface 300 form a unitary component of the user interface. The user interface 300 assembly may further be considered to comprise a headgear 310, which in the case of the user interface 300 is generally a strap assembly, and optionally a connector 370. The headgear 310 is configured to be positioned generally about at least a portion of a user’s head when the user wears the user interface 300. The headgear 310 can be coupled to the frame 350 and positioned on the user’s head such that the user’s head is positioned between the headgear 310 and the frame 350. The cushion 330 is positioned between the user’s face and the frame 350 to form a seal on the user’s face. The optional connector 370 is configured to couple to the frame 350 and / or cushion 330 at one end and to a conduit of a respiratory therapy device (not shown). The pressurized air can flow directly from the conduit of the respiratory therapy system into the volume of space defined by the cushion 330 (or cushion 330 and frame 350) of the user interface 300 through the connector 370). From the user interface 300, the pressurized airreaches the user’s airway through the user’s mouth, nose, or both. Alternatively, where the user interface 300 does not include the connector 370, the conduit of the respiratory therapy system can connect directly to the cushion 330 and / or the frame 350.

[0057] In some implementations, the connector 370 may include one or a plurality of vents 372 located on the main body of the connector 370 itself and / or one or a plurality of vents 376 (“diffuser vents”) in proximity to the frame 350, for permitting the escape of carbon dioxide (CO2) and other gases exhaled by the user when the respiratory therapy device is active. In some implementations, one or a plurality of vents, such as vents 372 and / or 376 may be located in the user interface, such as in frame 350, and / or in the conduit 126. In some implementations, the frame 350 may include at least one anti-asphyxia valve (AAV) 374, which allows CO2 and other gases exhaled by the user to escape in the event that the vents (e.g., the vents 372 or 376) fail when the respiratory therapy device is active, and / or allows the user to breathe when the therapy is not active (e.g., due to power loss, device failure, an auto-stop feature being triggered, such as by mistake or accident, and the like).

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

[0059] In some embodiments, if there is no airflow from the flow generator, the diffuser vents on the mask (if present) may be insufficient for safe evacuation of exhaled CO2. For some interfaces, such as nasal pillow masks, the user can breathe through their mouth. However, for full face masks, the AAV may be needed to ensure adequate ventilation. In general, AAVs (e.g., the AAV 374) are always present for full face masks (as a safety feature); however, the diffuser vents and vents located on the mask or connector (usually an array of orifices in the mask material itself or a mesh made of some sort of fabric, in many cases replaceable) are not necessarily both present (e.g., some masks might have only the diffuser vents such as the plurality of vents 376, other masks might have only the plurality of vents 372 on the connector itself).

[0060] For indirectly connected user interfaces (“indirect category” user interfaces), and as will be described in greater detail below, the conduit of the respiratory therapy system connects indirectly with the cushion and / or frame of the user interface. Another element of the user interface — besides any connector — is located between the conduit of the respiratory therapysystem and the cushion and / or frame. This additional element (e.g., a relatively short, relatively flexible tube, such as user interface conduit described below) delivers the pressurized air to the volume of space formed between the cushion (or frame, or cushion and frame) of the user interface and the user’s face, from the conduit of the respiratory therapy system. Thus, pressurized air is delivered indirectly from the conduit of the respiratory therapy system into the volume of space defined by the cushion (or the cushion and frame) of the user interface against the user’s face. Moreover, according to some implementations, the indirectly connected category of user interfaces can be described as being at least two different categories: “indirect headgear” and “indirect conduit”. For the indirect headgear category, the conduit of the respiratory therapy system connects to a headgear conduit, optionally via a connector, which in turn connects to the cushion (or frame, or cushion and frame). The headgear is therefore configured to deliver the pressurized air from the conduit of the respiratory therapy system to the cushion (or frame, or cushion and frame) of the user interface. This headgear conduit within the headgear of the user interface is therefore configured to deliver the pressurized air from the conduit of the respiratory therapy system to the cushion of the user interface. For the indirect conduit category, the user interface comprises a user interface conduit, typically located between the conduit and the frame, cushion, or connector (if present) and fluidly couples the conduit to the frame, cushion, or connector (if present). Generally, the user interface conduit (i) is more flexible than the conduit of the respiratory therapy system, or (ii) has a diameter smaller than the diameter of the conduit of the respiratory therapy system, or both (i) and (ii). The user interface conduit may also have a shorter length than the conduit. In the described user interfaces, the optional connector is configured to couple to the frame and / or cushion at one end and to the conduit or user interface conduit at the other end depending on the category of user interface.

[0061] FIGS. 4A and 4B illustrate a perspective view and an exploded view, respectively, of one implementation of an indirect conduit user interface 400, according to aspects of the present disclosure. The indirect conduit user interface 400 includes a cushion 430 and a frame 450. In some embodiments, the cushion 430 and frame 450 form a unitary component of the user interface 400. The indirect conduit user interface 400 may further be considered to include a headgear 410, such as a strap assembly, a connector 470, and a user interface conduit 490 (often referred to in the art as a “minitube” or a “flexitube”).

[0062] Generally, the user interface conduit (i) is more flexible than the conduit 126 of the respiratory therapy system, (ii) has a diameter smaller than the diameter of the conduit 126 of the respiratory therapy system, or is both (i) and (ii). The user interface conduit is typically shorterthat conduit 126. Similar to the headgear 310 of user interface 300, the headgear 410 of user interface 400 is configured to be positioned generally about at least a portion of a user’s head when the user wears the user interface 400. The headgear 410 can be coupled to the frame 450 and positioned on the user’s head such that the user’s head is positioned between the headgear 410 and the frame 450. The cushion 430 is positioned between the user’s face and the frame 450 to form a seal on the user’s face. The connector 470 is configured to couple to the frame 450 and / or cushion 430 at one end and to the conduit 490 of the user interface 400 at the other end. In other implementations, the conduit 490 may connect directly to frame 450 and / or cushion 430. The conduit 490, at the opposite end relative to the frame 450 and cushion 430, is configured to connect to the conduit 126 (FIG. 4A) of the respiratory therapy system (not shown). The pressurized air can flow from the conduit 126 (FIG. 4A) of the respiratory therapy system, through the user interface conduit 490, and the connector 470, and into a volume of space define by the cushion 430 (or cushion 430 and frame 450) of the user interface 400 against a user’s face. From the volume of space, the pressurized air reaches the user’s airway through the user’s mouth, nose, or both.

[0063] In view of the above configuration, the user interface 400 is an indirectly connected user interface because pressurized air is delivered from the conduit 126 (FIG. 4A) of the respiratory therapy system (not shown) to the cushion 430 (or frame 450, or cushion 430 and frame 450) through the user interface conduit 490, rather than directly from the conduit 126 (FIG. 4A) of the respiratory therapy system.

[0064] As shown, in some implementations, the connector 470 includes a plurality of vents 472 for permitting the escape of carbon dioxide (CO2) and other gases exhaled by the user when the respiratory therapy device is active. In some such implementations, each of the plurality of vents 472 is an opening that may be angled relative to the thickness of the connector wall through which the opening is formed. The angled openings can reduce noise of the CO2 and other gases escaping to the atmosphere. Because of the reduced noise, acoustic signal associated with the plurality of vents 472 may be more apparent to an internal microphone, as opposed to an external microphone. As discussed further herein, an internal microphone may be located within, or otherwise physically integrated with, the respiratory therapy system and in acoustic communication with the flow of air which, in operation, is generated by the flow generator of the respiratory therapy device, and passes through the conduit and ultimately to the user interface.

[0065] In some implementations, the connector 470 optionally includes at least one valve 474 for permitting the escape of CO2 and other gases exhaled by the user when the respiratorytherapy device is inactive. In some implementations, the valve 474 (an example of an antiasphyxia valve) includes a silicone (or other suitable material) flap that is a failsafe component, which allows CO2 and other gases exhaled by the user to escape in the event that the vents 472 fail when the respiratory therapy device is active. In some such implementations, when the silicone flap is open, the valve opening is much greater than each vent opening, and therefore less likely to be blocked by occlusion materials.

[0066] FIGS. 5A and 5B illustrate a perspective view and an exploded view, respectively, of one implementation of an indirect headgear user interface 500, according to aspects of the present disclosure. The indirect headgear user interface 500 includes a cushion 530. The indirect headgear user interface 500 may further be considered to comprise headgear 510 (which can comprise strap 510a and a headgear conduit 510b), and a connector 570. Similar to the user interfaces 300 and 400, the headgear 510 is configured to be positioned generally about at least a portion of a user’s head when the user wears the user interface 500. The headgear 510 includes a strap 510a that can be coupled to the headgear conduit 510b and positioned on the user’s head such that the user’s head is positioned between the strap 510a and the headgear conduit 510b. The cushion 530 is positioned between the user’s face and the headgear conduit 510b to form a seal on the user’s face. The connector 570 is configured to couple to the headgear 510 at one end and a conduit of the respiratory therapy system at the other end. In other implementations, the connector 570 can be optional and the headgear 510 can alternatively connect directly to conduit of the respiratory therapy system. The headgear conduit 510b may be configured to deliver pressurized air from the conduit of the respiratory therapy system to the cushion 530, or more specifically, to the volume of space around the mouth and / or nose of the user and enclosed by the user cushion. Thus, the headgear conduit 510b is hollow to provide a passageway for the pressurized air. Both sides of the headgear conduit 510b can be hollow to provide two passageways for the pressurized air. Alternatively, only one side of the headgear conduit 510b can be hollow to provide a single passageway. In the implementation illustrated in FIGS. 5A and 5B, headgear conduit 510b comprises two passageways which, in use, are positioned at either side of a user’s head / face. Alternatively, only one passageway of the headgear conduit 510b can be hollow to provide a single passageway. The pressurized air can flow from the conduit of the respiratory therapy system, through the connector 570 and the headgear conduit 510b, and into the volume of space between the cushion 530 and the user’s face. From the volume of space between the cushion 530 and the user’s face, the pressurized air reaches the user’s airway through the user’s mouth, nose, or both.

[0067] In some implementations, the cushion 530 may include a plurality of vents 572 on the cushion 530 itself. Additionally or alternatively, in some implementations, the connector 570 may include a plurality of vents 576 (“diffuser vents”) in proximity to the headgear 510, for permitting the escape of carbon dioxide (CO2) and other gases exhaled by the user when the respiratory therapy device is active. In some implementations, the headgear 510 may include at least one plus anti-asphyxia valve (AAV) 574 in proximity to the cushion 530, which allows CO2 and other gases exhaled by the user to escape in the event that the vents (e.g., the vents 572 or 576) fail when the respiratory therapy device is active.

[0068] In view of the above configuration, the user interface 500 is an indirect headgear user interface because pressurized air is delivered from the conduit of the respiratory therapy system to the volume of space between the cushion 530 and the user’s face through the headgear conduit 510b, rather than directly from the conduit of the respiratory therapy system to the volume of space between the cushion 530 and the user’s face.

[0069] In one or more implementations, the distinction between the direct category and the indirect category can be defined in terms of a distance the pressurized air travels after leaving the conduit of the respiratory therapy device and before reaching the volume of space defined by the cushion of the user interface forming a seal with the user’s face, exclusive of a connector of the user interface that connects to the conduit. This distance is shorter, such as less than 1 centimeter (cm), less than 2 cm, less than 3 cm, less than 4 cm, or less than 5 cm, for direct category user interfaces than for indirect category user interfaces. This is because the pressurized air travels through the additional element of, for example, the user interface conduit 490 or the headgear conduit 510b between the conduit of the respiratory therapy system before reaching the volume of space defined by the cushion (or cushion and frame) of the user interface forming a seal with the user’s face for indirect category user interfaces.

[0070] Referring back to FIG. 1, the conduit 126 (also referred to as an air circuit or tube) allows the flow of air between two components of a respiratory therapy system 120, such as the respiratory therapy device 122 and the user interface 124. In some implementations, there can be separate limbs of the conduit for inhalation and exhalation. In other implementations, a single limb conduit is used for both inhalation and exhalation.

[0071] One or more of the respiratory therapy device 122, the user interface 124, the conduit 126, the display device 128, and the humidification tank 129 can contain one or more sensors (e.g., a pressure sensor, a flow rate sensor, or more generally any of the other sensors 130 described herein). These one or more sensors can be used, for example, to measure the air pressure and / or flow rate of pressurized air supplied by the respiratory therapy device 122.

[0072] Referring briefly to FIG. 6, a perspective view of the back side of the respiratory therapy device 122 that includes a housing 123, an air inlet 186, and an air outlet 190. The air inlet 186 includes an inlet cover 182 movable between a closed position and an open position. The air inlet cover 182 includes one or more air inlet apertures 184 defined therein. The respiratory therapy device 122 includes a blower motor configured to draw air in through the one or more air inlet apertures 184 defined in the air inlet cover 182. The motor is further configured to cause pressurized air to flow through the humidification tank 129 and out of the air outlet 190. The conduit 126 can be fluidly coupled to the air outlet 190, such that the air flows from the air outlet 190 and into the conduit 126. The air outlet 190 is partially formed by an internal conduit 192 extending through the housing 123 from the interior of the respiratory therapy device 122. A seal 194 is positioned around the end of the internal conduit 192 to ensure that substantially all of the air that exits through the air outlet 190 flows into the conduit 126.

[0073] Referring back to FIG. 1, the display device 128 is generally used to display image(s) including still images, video images, or both and / or information regarding the respiratory therapy device 122. For example, the display device 128 (and / or the display device 172 of the user device 170) can provide information regarding the status of the respiratory therapy device 122 (e.g., whether the respiratory therapy device 122 is on / off, the pressure of the air being delivered by the respiratory therapy device 122, the temperature of the air being delivered by the respiratory therapy device 122, etc.) and / or other information (e.g., a sleep score and / or a therapy score, also referred to as a my Air™ score, such as described in WO 2016 / 061629, which is hereby incorporated by reference herein in its entirety; the current date / time; personal information for the user 210; etc.). In some implementations, the display device 128 acts as a human-machine interface (HMI) that includes a graphic user interface (GUI) configured to display the image(s) as an input interface. The display device 128 can be an LED display, an OLED display, an LCD display, or the like. The input interface can be, for example, a touchscreen or touch- sensitive substrate, a mouse, a keyboard, or any sensor system configured to sense inputs made by a human user interacting with the respiratory therapy device 122. Display device 172 of user device 170 may operate in the same or similar way to display device 128 and may be used with or instead of display device 128.

[0074] The humidification tank 129 is coupled to or integrated in the respiratory therapy device 122 and includes a reservoir of water that can be used to humidify the pressurized air delivered from the respiratory therapy device 122. The respiratory therapy device 122 can include a heater to heat the water in the humidification tank 129 in order to humidify thepressurized air provided to the user. Additionally, in some implementations, the conduit 126 can also include a heating element (e.g., coupled to and / or imbedded in the conduit 126) that heats the pressurized air delivered to the user. The humidification tank 129 can be fluidly coupled to a water vapor inlet of the air pathway and deliver water vapor into the air pathway via the water vapor inlet, or can be formed in-line with the air pathway as part of the air pathway itself.

[0075] The respiratory therapy system 120 can be used, for example, as a ventilator or as a positive airway pressure (PAP) system, such as a continuous positive airway pressure (CPAP) system, an automatic positive airway pressure system (APAP), a bi-level or variable positive airway pressure system (BPAP or VPAP), or any combination thereof. The CPAP system delivers a predetermined air pressure (e.g., determined by a sleep physician) to the user. The APAP system automatically varies the air pressure delivered to the user based on, for example, respiration data associated with the user. The BPAP or VPAP system is configured to deliver a first predetermined pressure (e.g., an inspiratory positive airway pressure or IPAP) and a second predetermined pressure (e.g., an expiratory positive airway pressure or EPAP) that is lower than the first predetermined pressure.

[0076] Referring to FIG. 2, a portion of the system 100 (FIG. 1), according to some implementations, is illustrated. A user 210 of the respiratory therapy system 120 and a bed partner 220 are located in a bed 230 and are laying on a mattress 232. The user interface 124 (also referred to herein as a mask, e.g., a full facial mask) can be worn by the user 210 during a sleep session. The user interface 124 is fluidly coupled and / or connected to the respiratory therapy device 122 via the conduit 126. In turn, the respiratory therapy device 122 delivers pressurized air to the user 210 via the conduit 126 and the user interface 124 to increase the air pressure in the throat of the user 210 to aid in preventing the airway from closing and / or narrowing during sleep. The respiratory therapy device 122 can be positioned on a nightstand 240 that is directly adjacent to the bed 230 as shown in FIG. 2, or more generally, on any surface or structure that is generally adjacent to the bed 230 and / or the user 210.

[0077] Referring to back to FIG. 1, the one or more sensors 130 of the system 100 include a pressure sensor 132, a flow rate sensor 134, temperature sensor 136, a motion sensor 138, a microphone 140, a speaker 142, a radio-frequency (RF) receiver 146, a RF transmitter 148, a camera 150, an infrared sensor 152, a photoplethysmogram (PPG) sensor 154, an electrocardiogram (ECG) sensor 156, an electroencephalography (EEG) sensor 158, a capacitive sensor 160, a force sensor 162, a strain gauge sensor 164, an electromyography (EMG) sensor 166, an oxygen sensor 168, an analyte sensor 174, a moisture sensor 176, aLiDAR sensor 178, or any combination thereof. Generally, each of the one or more sensors 130 are configured to output sensor data that is received and stored in the memory device 114 or one or more other memory devices.

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

[0079] As described herein, the system 100 generally can be used to generate physiological data associated with a user (e.g., a user of the respiratory therapy system 120 shown in FIG. 2) during a sleep session. The physiological data can be analyzed to generate one or more sleep- related parameters, which can include any parameter, measurement, etc. related to the user during the sleep session. The one or more sleep-related parameters that can be determined for the user 210 during the sleep session include, for example, an Apnea-Hypopnea Index (AHI) score, a sleep score, a flow signal, a respiration signal, a respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, a number of events per hour, a pattern of events, a stage, pressure settings of the respiratory therapy device 122, a heart rate, a heart rate variability, movement of the user 210, temperature, EEG activity, EMG activity, arousal, snoring, choking, coughing, whistling, wheezing, or any combination thereof.

[0080] The one or more sensors 130 can be used to generate, for example, physiological data, acoustic data, or both. Physiological data generated by one or more of the sensors 130 can be used by the control system 110 to determine a sleep-wake signal associated with the user 210 (FIG. 2) during the sleep session and one or more sleep-related parameters. The sleep-wake signal can be indicative of one or more sleep states, including wakefulness, relaxed wakefulness, micro-awakenings, or distinct sleep stages such as, for example, a rapid eye movement (REM) stage, a first non-REM stage (often referred to as “Nl”), a second non-REM stage (often referred to as “N2”), a third non-REM stage (often referred to as “N3”), or any combination thereof. Methods for determining sleep states and / or sleep stages from physiological data generated by one or more sensors, such as the one or more sensors 130, are described in, for example, WO 2014 / 047310, US 2014 / 0088373, WO 2017 / 132726, WO2019 / 122413, and WO 2019 / 122414, each of which is hereby incorporated by reference herein in its entirety.

[0081] In some implementations, the sleep-wake signal described herein can be timestamped to indicate a time that the user enters the bed, a time that the user exits the bed, a time that the user attempts to fall asleep, etc. The sleep-wake signal can be measured by the one or more sensorsl30 during the sleep session at a predetermined sampling rate, such as, for example, one sample per second, one sample per 30 seconds, one sample per minute, etc. In some implementations, the sleep-wake signal can also be indicative of a respiration signal, a respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, a number of events per hour, a pattern of events, pressure settings of the respiratory therapy device 122, or any combination thereof during the sleep session. The event(s) can include snoring, apneas, central apneas, obstructive apneas, mixed apneas, hypopneas, a mask leak (e.g., from the user interface 124), a restless leg, a sleeping disorder, choking, an increased heart rate, labored breathing, an asthma attack, an epileptic episode, a seizure, or any combination thereof. The one or more sleep-related parameters that can be determined for the user during the sleep session based on the sleep-wake signal include, for example, a total time in bed, a total sleep time, a sleep onset latency, a wake-after-sleep-onset parameter, a sleep efficiency, a fragmentation index, or any combination thereof. As described in further detail herein, the physiological data and / or the sleep-related parameters can be analyzed to determine one or more sleep-related scores.

[0082] Physiological data and / or acoustic data generated by the one or more sensors 130 can also be used to determine a respiration signal associated with a user during a sleep session. The respiration signal is generally indicative of respiration or breathing of the user during the sleep session. The respiration signal can be indicative of and / or analyzed to determine (e.g., using the control system 110) one or more sleep-related parameters, such as, for example, a respiration rate, a respiration rate variability, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, an occurrence of one or more events, a number of events per hour, a pattern of events, a sleep state, a sleet stage, an apnea-hypopnea index (AHI), pressure settings of the respiratory therapy device 122, or any combination thereof. The one or more events can include snoring, apneas, central apneas, obstructive apneas, mixed apneas, hypopneas, a mask leak (e.g., from the user interface 124), a cough, a restless leg, a sleeping disorder, choking, an increased heart rate, labored breathing, an asthma attack, an epileptic episode, a seizure, increased blood pressure, or any combination thereof. Many of the described sleep-related parameters are physiological parameters, although some of the sleep-related parameters can be considered to be non-physiological parameters. Other types of physiological and / or non-physiological parameters can also be determined, either from the data from the one or more sensors 130, or from other types of data.

[0083] The pressure sensor 132 outputs pressure data that can be stored in the memory device 114 and / or analyzed by the processor 112 of the control system 110. In some implementations, the pressure sensor 132 is an air pressure sensor (e.g., barometric pressure sensor) that generates sensor data indicative of the respiration (e.g., inhaling and / or exhaling) of the user of the respiratory therapy system 120 and / or ambient pressure. In such implementations, the pressure sensor 132 can be coupled to or integrated in the respiratory therapy device 122. The pressure sensor 132 can be, for example, a capacitive sensor, an electromagnetic sensor, a piezoelectric sensor, a strain-gauge sensor, an optical sensor, a potentiometric sensor, or any combination thereof.

[0084] The flow rate sensor 134 outputs flow rate data that can be stored in the memory device 114 and / or analyzed by the processor 112 of the control system 110. Examples of flow rate sensors (such as, for example, the flow rate sensor 134) are described in WO 2012 / 012835, which is hereby incorporated by reference herein in its entirety. In some implementations, the flow rate sensor 134 is used to determine an air flow rate from the respiratory therapy device 122, an air flow rate through the conduit 126, an air flow rate through the user interface 124, or any combination thereof. In such implementations, the flow rate sensor 134 can be coupled to or integrated in the respiratory therapy device 122, the user interface 124, or the conduit 126. The flow rate sensor 134 can be a mass flow rate sensor such as, for example, a rotary flow meter (e.g., Hall effect flow meters), a turbine flow meter, an orifice flow meter, an ultrasonic flow meter, a hot wire sensor, a vortex sensor, a membrane sensor, or any combination thereof. In some implementations, the flow rate sensor 134 is configured to measure a vent flow (e.g., intentional “leak”), an unintentional leak (e.g., mouth leak and / or mask leak), a patient flow (e.g., air into and / or out of lungs), or any combination thereof. In some implementations, the flow rate data can be analyzed to determine cardiogenic oscillations of the user. In one example, the pressure sensor 132 can be used to determine a blood pressure of a user.

[0085] The temperature sensor 136 outputs temperature data that can be stored in the memory device 114 and / or analyzed by the processor 112 of the control system 110. In some implementations, the temperature sensor 136 generates temperatures data indicative of a core body temperature of the user 210 (FIG. 2), a skin temperature of the user 210, a temperature of the air flowing from the respiratory therapy device 122 and / or through the conduit 126, a temperature in the user interface 124, an ambient temperature, or any combination thereof. Thetemperature sensor 136 can be, for example, a thermocouple sensor, a thermistor sensor, a silicon band gap temperature sensor or semiconductor-based sensor, a resistance temperature detector, or any combination thereof.

[0086] The motion sensor 138 outputs motion data that can be stored in the memory device 114 and / or analyzed by the processor 112 of the control system 110. The motion sensor 138 can be used to detect movement of the user 210 during the sleep session, and / or detect movement of any of the components of the respiratory therapy system 120, such as the respiratory therapy device 122, the user interface 124, or the conduit 126. The motion sensor 138 can include one or more inertial sensors, such as accelerometers, gyroscopes, and magnetometers. In some implementations, the motion sensor 138 alternatively or additionally generates one or more signals representing bodily movement of the user, from which may be obtained a signal representing a sleep state of the user; for example, via a respiratory movement of the user. In some implementations, the motion data from the motion sensor 138 can be used in conjunction with additional data from another sensor 130 to determine the sleep state of the user.

[0087] The microphone 140 can be located at any location relative to the respiratory therapy system 120 and in acoustic communication with the airflow in the respiratory therapy system 120. For example, the respiratory therapy system 120 may include a microphone 140 (i) coupled externally to the conduit 126, (ii) positioned within, optionally at least partially within the respiratory therapy device 122, (iii) coupled externally to the user interface 124, (iv) coupled directly or indirectly to a headgear associated with the user interface 124, or in any other suitable location. In some implementations, the microphone 140 is coupled to a mobile device (for example, the user device 170 or a smart speaker(s) such as Google Nest Hub™, Google Home™, Amazon Echo™, Amazon Show™, Alexa™-enabled devices, etc.) that is communicatively coupled to the respiratory therapy system 120.

[0088] In some implementations, the microphone 140 is positioned on or at least partially outside of a housing of the respiratory therapy device 122. For example, the microphone 140 may be at least partially movable relative to the housing of the respiratory therapy device 122 to aid in being directed to the user 210 (FIG. 2). For example, the microphone 340 can be rotated between about 5° and about 355° towards the user 210.

[0089] In some implementations, the microphone 140 is configured to be in direct fluid communication with the airflow in the respiratory therapy system 120. For example, the microphone 140 may be (i) positioned at least partially within the conduit 126, (ii) positioned at least partially within the respiratory therapy device 122, optionally positioned at leastpartially within a component of the respiratory therapy device 122, which is in fluid communication with the conduit 126, or (iii) positioned at least partially within the user interface 124, the user interface 124 being in fluid communication with the conduit 126. Further, in some implementations, the microphone 140 is electrically connected with a circuit board (for example, connected physically, such as mounted on, the circuit board directly or indirectly) of the respiratory therapy device 122, which may be in acoustic communication (for example, via a small duct and / or a silicone window as in a stethoscope) or in fluid communication with the airflow in the respiratory therapy system 120.

[0090] The microphone 140 outputs sound and / or acoustic data that can be stored in the memory device 114 and / or analyzed by the processor 112 of the control system 110. The acoustic data generated by the microphone 140 is reproducible as one or more sound(s) during a sleep session (e.g., sounds from the user 210). The acoustic data form the microphone 140 can also be used to identify (e.g., using the control system 110) an event experienced by the user during the sleep session, as described in further detail herein. The microphone 140 can be coupled to or integrated in the respiratory therapy device 122, the user interface 124, the conduit 126, or the user device 170. In some implementations, the system 100 includes a plurality of microphones (e.g., two or more microphones and / or an array of microphones with beamforming) such that sound data generated by each of the plurality of microphones can be used to discriminate the sound data generated by another of the plurality of microphones

[0091] The speaker 142 outputs sound waves that are audible to a user of the system 100 (e.g., the user 210 of FIG. 2). The speaker 142 can be used, for example, as an alarm clock or to play an alert or message to the user 210 (e.g., in response to an event). In some implementations, the speaker 142 can be used to communicate the acoustic data generated by the microphone 140 to the user. The speaker 142 can be coupled to or integrated in the respiratory therapy device 122, the user interface 124, the conduit 126, or the user device 170.

[0092] The microphone 140 and the speaker 142 can be used as separate devices. In some implementations, the microphone 140 and the speaker 142 can be combined into an acoustic sensor 141 (e.g., a SONAR sensor), as described in, for example, WO 2018 / 050913 and WO 2020 / 104465, each of which is hereby incorporated by reference herein in its entirety. In such implementations, the speaker 142 generates or emits sound waves at a predetermined interval and the microphone 140 detects the reflections of the emitted sound waves from the speaker 142. The sound waves generated or emitted by the speaker 142 have a frequency that is not audible to the human ear (e.g., below 20 Hz or above around 18 kHz) so as not to disturb the sleep of the user 210 or the bed partner 220 (FIG. 2). Based at least in part on the data fromthe microphone 140 and / or the speaker 142, the control system 110 can determine a location of the user 210 (FIG. 2) and / or one or more of the sleep-related parameters described in herein such as, for example, a respiration signal, a respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, a number of events per hour, a pattern of events, a sleep state, a sleep stage, pressure settings of the respiratory therapy device 122, or any combination thereof. In such a context, a SONAR sensor may be understood to concern an active acoustic sensing, such as by generating and / or transmitting ultrasound and / or low frequency ultrasound sensing signals (e.g., in a frequency range of about 17-23 kHz, 18-22 kHz, or 17-18 kHz, for example), through the air. Such a system may be considered in relation to WO 2018 / 050913 and WO 2020 / 104465 mentioned above, each of which is hereby incorporated by reference herein in its entirety.

[0093] In some implementations, the sensors 130 include (i) a first microphone that is the same as, or similar to, the microphone 140, and is integrated in the acoustic sensor 141 and (ii) a second microphone that is the same as, or similar to, the microphone 140, but is separate and distinct from the first microphone that is integrated in the acoustic sensor 141.

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

[0095] In some implementations, the RF sensor 147 is a part of a mesh system. One example of a mesh system is a Wi-Fi mesh system, which can include mesh nodes, mesh router(s), and mesh gateway(s), each of which can be mobile / movable or fixed. In such implementations, the Wi-Fi mesh system includes a Wi-Fi router and / or a Wi-Fi controller and one or more satellites (e.g., access points), each of which include an RF sensor that is the sameas, or similar to, the RF sensor 147. The Wi-Fi router and satellites continuously communicate with one another using Wi-Fi signals. The Wi-Fi mesh system can be used to generate motion data based on changes in the Wi-Fi signals (e.g., differences in received signal strength) between the router and the satellite(s) due to an object or person moving partially obstructing the signals. The motion data can be indicative of motion, breathing, heart rate, gait, falls, behavior, etc., or any combination thereof.

[0096] The camera 150 outputs image data reproducible as one or more images (e.g., still images, video images, thermal images, or any combination thereof) that can be stored in the memory device 114. The image data from the camera 150 can be used by the control system 110 to determine one or more of the sleep-related parameters described herein, such as, for example, one or more events (e.g., periodic limb movement or restless leg syndrome), a respiration signal, a respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, a number of events per hour, a pattern of events, a sleep state, a sleep stage, or any combination thereof. Further, the image data from the camera 150 can be used to, for example, identify a location of the user, to determine chest movement of the user 210 (FIG. 2), to determine air flow of the mouth and / or nose of the user 210, to determine a time when the user 210 enters the bed 230 (FIG. 2), and to determine a time when the user 210 exits the bed 230. In some implementations, the camera 150 includes a wide-angle lens or a fish eye lens.

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

[0098] The PPG sensor 154 outputs physiological data associated with the user 210 (FIG. 2) that can be used to determine one or more sleep-related parameters, such as, for example, a heart rate, a heart rate variability, a cardiac cycle, respiration rate, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, estimated blood pressure parameter(s), or any combination thereof. The PPG sensor 154 can be worn by the user 210, embedded inclothing and / or fabric that is worn by the user 210, embedded in and / or coupled to the user interface 124 and / or its associated headgear (e.g., straps, etc.), etc.

[0099] In some implementations, a PAT (peripheral arterial tone) sensing device may make use of a fingertip mounted PPG probe, e.g., PPG sensor 154. The PPG probe operates with an optical technology that detects blood volume changes in the tissue’s microvascular bed. As noted above, PPG measurements are used to derive the arterial blood oxygen saturation (SpO2), pulse rate (PR), and changes in peripheral arterial tone, which are then used to detect respiratory events. Peripheral arterial tone refers to the tone of the peripheral arterial smooth muscle tissue. When the muscle tone of peripheral arteries increases, the arteries’ diameter decreases, resulting in a reduction of perfusion and thus a decrease in pulsatile blood volume in the peripheral tissue. The decrease in pulsatile blood volume in the peripheral tissue is picked up as a drop in the PPG signal swing between systole and diastole. The PAT signal may be derived from the PPG signal from the PPG sensor, such as by the method described in WO 2021 / 260190, the disclosure of which is incorporated by reference herein in its entirety. The PPG-derived signal, which may be derived by trending such pulsatile blood volume reductions, is referred to as the PAT signal.

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

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

[0102] The capacitive sensor 160, the force sensor 162, and the strain gauge sensor 164 output data that can be stored in the memory device 114 and used by the control system 110 to determine one or more of the sleep-related parameters described herein. The EMG sensor 166 outputs physiological data associated with electrical activity produced by one or more muscles. The oxygen sensor 168 outputs oxygen data indicative of an oxygen concentration of gas (e.g., in the conduit 126 or at the user interface 124). The oxygen sensor 168 can be, for example,an ultrasonic oxygen sensor, an electrical oxygen sensor, a chemical oxygen sensor, an optical oxygen sensor, a pulse oximeter (e.g., SpC sensor), or any combination thereof. In some implementations, the one or more sensors 130 also include a galvanic skin response (GSR) sensor, a blood flow sensor, a respiration sensor, a pulse sensor, a sphygmomanometer sensor, an oximetry sensor, or any combination thereof.

[0103] The analyte sensor 174 can be used to detect the presence of an analyte in the exhaled breath of the user 210. The data output by the analyte sensor 174 can be stored in the memory device 114 and used by the control system 110 to determine the identity and concentration of any analytes in the breath of the user 210. In some implementations, the analyte sensor 174 is positioned near a mouth of the user 210 to detect analytes in breath exhaled from the user 210’ s mouth. For example, when the user interface 124 is a facial mask that covers the nose and mouth of the user 210, the analyte sensor 174 can be positioned within the facial mask to monitor the user 210’s mouth breathing. In other implementations, such as when the user interface 124 is a nasal mask or a nasal pillow mask, the analyte sensor 174 can be positioned near the nose of the user 210 to detect analytes in breath exhaled through the user’s nose. In still other implementations, the analyte sensor 174 can be positioned near the user 210’s mouth when the user interface 124 is a nasal mask or a nasal pillow mask. In this implementation, the analyte sensor 174 can be used to detect whether any air is inadvertently leaking from the user 210’ s mouth. In some implementations, the analyte sensor 174 is a volatile organic compound (VOC) sensor that can be used to detect carbon-based chemicals or compounds. In some implementations, the analyte sensor 174 can also be used to detect whether the user 210 is breathing through their nose or mouth. For example, if the data output by an analyte sensor 174 positioned near the mouth of the user 210 or within the facial mask (in implementations where the user interface 124 is a facial mask) detects the presence of an analyte, the control system 110 can use this data as an indication that the user 210 is breathing through their mouth.

[0104] The moisture sensor 176 outputs data that can be stored in the memory device 114 and used by the control system 110. The moisture sensor 176 can be used to detect moisture in various areas surrounding the user (e.g., inside the conduit 126 or the user interface 124, near the user 210’ s face, near the connection between the conduit 126 and the user interface 124, near the connection between the conduit 126 and the respiratory therapy device 122, etc.). Thus, in some implementations, the moisture sensor 176 can be coupled to or integrated in the user interface 124 or in the conduit 126 to monitor the humidity of the pressurized air from the respiratory therapy device 122. In other implementations, the moisture sensor 176 is placed 1near any area where moisture levels need to be monitored. The moisture sensor 176 can also be used to monitor the humidity of the ambient environment surrounding the user 210, for example, the air inside the bedroom.

[0105] The Light Detection and Ranging (LiDAR) sensor 178 can be used for depth sensing. This type of optical sensor (e.g., laser sensor) can be used to detect objects and build three dimensional (3D) maps of the surroundings, such as of a living space. LiDAR can generally utilize a pulsed laser to make time of flight measurements. LiDAR is also referred to as 3D laser scanning. In an example of use of such a sensor, a fixed or mobile device (such as a smartphone) having a LiDAR sensor 178 can measure and map an area extending 5 meters or more away from the sensor. The LiDAR data can be fused with point cloud data estimated by an electromagnetic RADAR sensor, for example. The LiDAR sensor(s) 178 can also use artificial intelligence (Al) to automatically geofence RADAR systems by detecting and classifying features in a space that might cause issues for RADAR systems, such a glass windows (which can be highly reflective to RADAR). LiDAR can also be used to provide an estimate of the height of a person, as well as changes in height when the person sits down, or falls down, for example. LiDAR may be used to form a 3D mesh representation of an environment. In a further use, for solid surfaces through which radio waves pass (e.g., radio- translucent materials), the LiDAR may reflect off such surfaces, thus allowing a classification of different type of obstacles.

[0106] In some implementations, the one or more sensors 130 also include a galvanic skin response (GSR) sensor, a blood flow sensor, a respiration sensor, a heart rate sensor (e.g., pulse sensor), a blood pressure sensor (e.g., sphygmomanometer sensor), an oximetry sensor, a SONAR sensor, a RADAR sensor, a blood glucose sensor, a camera (e.g., color sensor), a pH sensor, a tilt sensor (which measures the tilt in multiple axes of a reference plane), an orientation sensor (which measures the orientation of a device relative to an orthogonal coordinate frame), an alcohol sensor, or any combination thereof.

[0107] While shown separately in FIG. 1, any combination of the one or more sensors 130 can be integrated in and / or coupled to any one or more of the components of the system 100, including the respiratory therapy device 122, the user interface 124, the conduit 126, the humidification tank 129, the control system 110, the user device 170, the activity tracker 180, or any combination thereof. For example, the microphone 140 and the speaker 142 can be integrated in and / or coupled to the user device 170 and the pressure sensor 132 and / or flow rate sensor 134 are integrated in and / or coupled to the respiratory therapy device 122. In some implementations, at least one of the one or more sensors 130 is not coupled to the respiratorytherapy device 122, the control system 110, or the user device 170, and is positioned generally adjacent to the user 210 during the sleep session (e.g., positioned on or in contact with a portion of the user 210, worn by the user 210, coupled to or positioned on the nightstand, coupled to the mattress, coupled to the ceiling, etc.).

[0108] The data from the one or more sensors 130 can be analyzed to determine one or more sleep-related parameters, which can include a respiration signal, a respiration rate, a respiration pattern, an inspiration amplitude, an expiration amplitude, an inspiration-expiration ratio, an occurrence of one or more events, a number of events per hour, a pattern of events, a sleep state, an apnea-hypopnea index (AHI), or any combination thereof. The one or more events can include snoring, apneas, central apneas, obstructive apneas, mixed apneas, hypopneas, a mask leak, a cough, a restless leg, a sleeping disorder, choking, an increased heart rate, labored breathing, an asthma attack, an epileptic episode, a seizure, increased blood pressure, or any combination thereof. Many of these sleep-related parameters are physiological parameters, although some of the sleep-related parameters can be considered to be non- physiological parameters. Other types of physiological and non-physiological parameters can also be determined, either from the data from the one or more sensors 130, or from other types of data.

[0109] The user device 170 (FIG. 1) includes a display device 172. The user device 170 can be, for example, a mobile device such as a smart phone, a tablet, a gaming console, a smart watch, a laptop, or the like. Alternatively, the user device 170 can be an external sensing system, a television (e.g., a smart television) or another smart home device (e.g., a smart speaker(s) such as Google Nest Hub™, Google Home™, Amazon Echo™, Amazon Show™, Alexa™-enabled devices, etc.). In some implementations, the user device is a wearable device (e.g., a smart watch). The display device 172 is generally used to display image(s) including still images, video images, or both. In some implementations, the display device 172 acts as a human-machine interface (HMI) that includes a graphic user interface (GUI) configured to display the image(s) and an input interface. The display device 172 can be an LED display, an OLED display, an LCD display, or the like. The input interface can be, for example, a touchscreen or touch-sensitive substrate, a mouse, a keyboard, or any sensor system configured to sense inputs made by a human user interacting with the user device 170. In some implementations, one or more user devices can be used by and / or included in the system 100.

[0110] In some implementations, the system 100 also includes an activity tracker 180. The activity tracker 180 is generally used to aid in generating physiological data associated with the user. The activity tracker 180 can include one or more of the sensors 130 described herein,such as, for example, the motion sensor 138 (e.g., one or more accelerometers and / or gyroscopes), the PPG sensor 154, and / or the ECG sensor 156. The physiological data from the activity tracker 180 can be used to determine, for example, a number of steps, a distance traveled, a number of steps climbed, a duration of physical activity, a type of physical activity, an intensity of physical activity, time spent standing, a respiration rate, an average respiration rate, a resting respiration rate, a maximum he respiration art rate, a respiration rate variability, a heart rate, an average heart rate, a resting heart rate, a maximum heart rate, a heart rate variability, a number of calories burned, blood oxygen saturation, electrodermal activity (also known as skin conductance or galvanic skin response), or any combination thereof. In some implementations, the activity tracker 180 is coupled (e.g., electronically or physically) to the user device 170.

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

[0112] While the control system 110 and the memory device 114 are described and shown in FIG. 1 as being a separate and distinct component of the system 100, in some implementations, the control system 110 and / or the memory device 114 are integrated in the user device 170 and / or the respiratory therapy device 122. Alternatively, in some implementations, the control system 110 or a portion thereof (e.g., the processor 112) can be located in a cloud (e.g., integrated in a server, integrated in an Internet of Things (loT) device, connected to the cloud, be subject to edge cloud processing, etc.), located in one or more servers (e.g., remote servers, local servers, etc., or any combination thereof.

[0113] While system 100 is shown as including all of the components described above, more or fewer components can be included in a system according to implementations of the present disclosure. For example, a first alternative system includes the control system 110, the memory device 114, and at least one of the one or more sensors 130 and does not include the respiratory therapy system 120. As another example, a second alternative system includes the control system 110, the memory device 114, at least one of the one or more sensors 130, and the user device 170. As yet another example, a third alternative system includes the controlsystem 110, the memory device 114, the respiratory therapy system 120, at least one of the one or more sensors 130, and the user device 170. Thus, various systems can be formed using any portion or portions of the components shown and described herein and / or in combination with one or more other components.

[0114] As used herein, a sleep session can be defined in multiple ways. For example, a sleep session can be defined by an initial start time and an end time. In some implementations, a sleep session is a duration where the user is asleep, that is, the sleep session has a start time and an end time, and during the sleep session, the user does not wake until the end time. That is, any period of the user being awake is not included in a sleep session. From this first definition of sleep session, if the user wakes ups and falls asleep multiple times in the same night, each of the sleep intervals separated by an awake interval is a sleep session.

[0115] Alternatively, in some implementations, a sleep session has a start time and an end time, and during the sleep session, the user can wake up, without the sleep session ending, so long as a continuous duration that the user is awake is below an awake duration threshold. The awake duration threshold can be defined as a percentage of a sleep session. The awake duration threshold can be, for example, about twenty percent of the sleep session, about fifteen percent of the sleep session duration, about ten percent of the sleep session duration, about five percent of the sleep session duration, about two percent of the sleep session duration, etc., or any other threshold percentage. In some implementations, the awake duration threshold is defined as a fixed amount of time, such as, for example, about one hour, about thirty minutes, about fifteen minutes, about ten minutes, about five minutes, about two minutes, etc., or any other amount of time.

[0116] In some implementations, a sleep session is defined as the entire time between the time in the evening at which the user first entered the bed, and the time the next morning when user last left the bed. Put another way, a sleep session can be defined as a period of time that begins on a first date (e.g., Monday, January 6, 2020) at a first time (e.g., 10:00 PM), that can be referred to as the current evening, when the user first enters a bed with the intention of going to sleep (e.g., not if the user intends to first watch television or play with a smart phone before going to sleep, etc.), and ends on a second date (e.g., Tuesday, January 7, 2020) at a second time (e.g., 7:00 AM), that can be referred to as the next morning, when the user first exits the bed with the intention of not going back to sleep that next morning.

[0117] In some implementations, the user can manually define the beginning of a sleep session and / or manually terminate a sleep session. For example, the user can select (e.g., byclicking or tapping) one or more user-selectable element that is displayed on the display device 172 of the user device 170 (FIG. 1) to manually initiate or terminate the sleep session.

[0118] Generally, the sleep session includes any point in time after the user 210 has laid or sat down in the bed 230 (or another area or object on which they intend to sleep), and has turned on the respiratory therapy device 122 and donned the user interface 124. The sleep session can thus include time periods (i) when the user 210 is using the CPAP system but before the user 210 attempts to fall asleep (for example when the user 210 lays in the bed 230 reading a book); (ii) when the user 210 begins trying to fall asleep but is still awake; (iii) when the user 210 is in a light sleep (also referred to as stage 1 and stage 2 of non-rapid eye movement (NREM) sleep); (iv) when the user 210 is in a deep sleep (also referred to as slow-wave sleep, SWS, or stage 3 of NREM sleep); (v) when the user 210 is in rapid eye movement (REM) sleep; (vi) when the user 210 is periodically awake between light sleep, deep sleep, or REM sleep; or (vii) when the user 210 wakes up and does not fall back asleep.

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

[0120] FIG. 7 depicts an example workflow 700 for detecting interface changes and classifying user interfaces, according to some implementations of the present disclosure.

[0121] In the illustrated example, a user 705 (also referred to in some embodiments as a patient) engaged in a respiratory therapy can use / interact with a flow generator 710 and a user device 730. The flow generator 710 generally corresponds to a respiratory therapy device or system, such as the respiratory therapy device 122 of FIGS. 1, 2, and 6. That is, the flow generator 710 may correspond to a device that generates and provides air flow to the user 705 as part of a respiratory therapy, such as via a user interface or respiratory mask (e.g., user interface 124 of FIGS. 1-2, user interface 300 of FIGS. 3A-3B, user interface 400 of FIGS. 4A-4B, and / or user interface 500 of FIGS. 5A-5B) connected to the flow generator 710 via a conduit (e.g., conduit 126 if FIGS. 1-2).

[0122] In some embodiments, the user device 730 can generally correspond to a computing device associated with and / or controlled / used by the user 705 in connection with the respiratorytherapy. For example, the user device 730 may correspond to a smartphone, tablet, laptop computer, smart device (e.g., an loT device), and the like. In at least one embodiment, the user device 730 corresponds to the user device 170 of FIGS. 1-2.

[0123] In the illustrated workflow 700, the flow generator 710 can collect, generate, or otherwise provide data relevant to the respiratory therapy, which can be stored or maintained in a database of therapy data 715. For example, the flow generator 710 may collect or generate data for one or more usage / sleep sessions for a variety of variables or features, such as the usage duration (e.g., the length of time the user 705 used the flow generator 710 during the session and / or the total or average duration across multiple sessions), the number of times the user put on (donned) and removed (doffed) the user interface during a period of time and / or during a sleep session (e.g., during the sleep session and / or the total or average number of times across multiple sessions), the amount of air leak of the flow generator (e.g., the total or average volume of air, such as in liters per second, that leak from the flow generator 710, user interface, the user’s mouth, and the like during the session or across multiple sessions), the minimum, maximum, and / or average air pressure used during the session and / or across multiple sessions (e.g., measured in cmFFO), the AHI of the user during the session (or the average AHI across multiple sessions), and the like.

[0124] In some embodiments, the flow generator 710 can provide this therapy data 715 continuously (e.g., throughout use), periodically (e.g., transmitting a daily report), upon the end of a usage session (e.g., when the user 705 turns off the flow generator 710), and the like. Additionally, though the illustrated example depicts the flow generator 710 directly providing the therapy data 715, in some embodiments some or all of the data may be transmitted using one or more intermediary devices. For example, in at least one embodiment, the flow generator 710 can transmit the data to the user device 730 (e.g., using a short-range wireless communication technology such as WiFi or Bluetooth), and the user device 730 can forward or provide the data to the store of therapy data 715.

[0125] In some embodiments, the therapy data 715 generally corresponds to a data store that can reside in any suitable location, such as in the cloud. The therapy data 715 may include data for any number of users 705 of any number of flow generators 710. Although a single store of therapy data 715 is depicted for conceptual clarity, in embodiments, there may be any number of discrete data stores that store the therapy data 715. In some embodiments, the therapy data 715 may be stored as part of a clinician-accessible system to review and interact with the data to assist in the respiratory therapy. Generally, the granularity of the therapy data 715 may differ depending on the particular implementation. For example, the therapy data 715may store, for each user 705, aggregated daily / session data (e.g., the average or total flow pressure used during a given day or session), minute-by-minute data (e.g., a representative value for each minute of use), second-by- second data (e.g., a representative value for each second of use), and so on.

[0126] As illustrated, a change detection system 720 can generally access the therapy data 715 to detect or identify changes in user interfaces, as discussed in more detail below (e.g., with reference to FIG. 8). As used herein, accessing data may generally refer to receiving, retrieving, requesting, acquiring, obtaining, or otherwise gaining access to the data. The change detection system 720 may generally be implemented using hardware, software, or a combination of hardware and software, and may execute in any suitable location, including the cloud. In some embodiments, the change detection system 720 uses machine learning to evaluate multivariate time series data (e.g., one or more features or variables across time in the therapy data 715) to predict or identify points in time when the user 705 switched from a first user interface to a second user interface.

[0127] In some embodiments, the change detection system 720 may process multivariate time series data (e.g., time series for multiple features, such as usage duration, mask on / off information, air leak information, air pressure information, and / or AHI data) across multiple use sessions and / or days to identify the switch. For example, using one or more supervised and / or unsupervised change point detection models, the change detection system 720 may indicate probable change points where data collected / generated prior to the point corresponds to the user 705 using a first user interface with the flow generator 710, and data collected generated subsequent to the point corresponds to the user 705 using a second user interface with the flow generator 710.

[0128] In the illustrated workflow 700, if the change detection system 720 detects or predicts that a user 705 changed to a new user interface, it may trigger the interface classifier system 725 to classify / identify the new user interface. The interface classifier system 725 may generally be implemented using hardware, software, or a combination of hardware and software, and may execute in any suitable location, including the cloud. Although depicted as discrete components for conceptual clarity, in some embodiments, the interface classifier system 725 and change detection system 720 may be implemented as components of a single system.

[0129] In some embodiments, the interface classifier system 725 uses machine learning to identify or classify user interfaces based on captured image(s), as discussed in more detail below (e.g., with reference to FIG. 9). For example, in the illustrated workflow 700, theinterface classifier system 725 can transmit a prompt, request, or instruction to the user device 730 associated with the user 705 to request that the user 705 capture one or more images of the user interface that they currently use. The interface classifier system 725 may then use one or more machine learning models (e.g., convolutional neural networks) to identify which model or type of interface is depicted, as discussed in more detail below.

[0130] This can enable the interface classifier system 725 and change detection system 720 to accurately and reliably detect changes in user interfaces, as well as to accurately and reliably determine which type or model the user 705 switched to, which can substantially improve therapy results (as well as a wide variety of other systems). For example, as discussed above, identifying the new user interface may enable the system(s) to provide improved services such as part replacement (e.g., to ensure the proper parts are provided at the proper time, based on the specific model of user interface the user 705 is using and / or when the user 705 began using the new interface), different settings for the flow generator 710 (e.g., to improve the therapy results), and the like.

[0131] FIG. 8 depicts an example workflow 800 for detecting interface changes using machine learning, according to some implementations of the present disclosure. In some embodiments, the workflow 800 may be performed by a change detection system, such as the change detection system 720 of FIG. 7. That is, some or all of the depicted components (e.g., the preprocessing component 810, change detection component 815, label component 820, and / or validation component 825) may be components of the change detection system. Though depicted as discrete components for conceptual clarity, in some embodiments, the operations of the depicted components (and others not depicted) may be combined or distributed across any number and variety of components, and may be implemented using hardware, software, or a combination of hardware and software.

[0132] In the illustrated example, therapy data 805 (which may correspond to the therapy data 715 of FIG. 7) is accessed by a preprocessing component 810. The preprocessing component 810 may generally perform a variety of preprocessing operations on the therapy data 805, depending on the particular implementation. For example, in some embodiments, the therapy data 805 may be fairly noisy day-to-day. As an example, the total or average usage duration on any given day may vary substantially from the day before and / or day after, which can obfuscate interface changes.

[0133] In some embodiments, therefore, the preprocessing component 810 may perform a smoothening operation. In some embodiments, to smoothen the data, the preprocessing component 810 may replace each value in the time series with a moving average of surroundingvalues. For example, if the therapy data 805 includes a time series with an individual data point / record for each day, the preprocessing component 810 may, for each given day, compute a multiday average (e.g., the average value of over the last three days, or the average value of the previous day, current day, and subsequent day) and replace the data for the given day with this average. In addition to smoothening the data, in some embodiments, this can also allow the preprocessing component 810 to automatically replace missing values (e.g., due to days with zero usage) because this missing data can be replaced with the moving average.

[0134] In some embodiments, the smoothening operation can additionally or alternatively be performed using other techniques, such as an exponential weighted average. This may allow more recent data points to receive more weight, potentially enabling sudden changes in the time series therapy data 805 to be detected sooner. The preprocessing component 810 may similarly use other techniques to fill in missing data in the time series, such as by filling missing data with the most recent / last available value. Generally, the preprocessing component 810 may perform a wide variety of preprocessing on the multivariate time series data reflected in the therapy data 805.

[0135] In the illustrated workflow 800, the change detection component 815 accesses the (potentially pre-processed) therapy data 805 and processes it using one or more change detection techniques to detect or identify user interface switches. Generally, the change detection component 815 can use any suitable technique that is able to identify change points in multivariate time series data (e.g., data that includes a time series for multiple variables, such as AHI, usage duration, and the like). In some embodiments, the change detection component 815 may use unsupervised machine learning technique(s) to perform change point detection. For example, the change detection component 815 may use (without limitation) a pruned exact linear time (PELT) model, dynamic programming approaches, binary segmentation approaches, Bayesian change point detection approaches, and the like.

[0136] In some embodiments, the change detection component 815 can process data in a rolling or sliding window. For example, the change detection component 815 may periodically (e.g., daily or weekly) evaluate therapy data 805 for a defined window of time (e.g., therapy data 805 from the past two weeks) to identify change point(s) during the window. In some embodiments, the change detection component 815 may assign a confidence score or probability to each potential change point. For example, for each point (e.g., for each day / data point, or for the transition / space between two days / data points), the change detection component 815 may assign a confidence score indicating the probability that the user changed interfaces at that point. In some embodiments, the change detection component 815 mayalternatively identify one or more specific points as possible change points, without assigning an explicit score or confidence. In some embodiments, the change detection component 815 may be configured to identify / search for a specific number of changes in the window (e.g., to identify one change point or the most probable change point).

[0137] In the illustrated example, the (potential) detected change points, identified by the change detection component 815, can be indicated (with or without associated probabilities or confidences) to a label component 820. The label component 820 can evaluate the indicated change points and / or associated therapy data 805 to assign labels (e.g., to predict or infer whether each, in fact, corresponds to a change in the user interface of the user).

[0138] In some embodiments, if the change detection component 815 generates confidence or probability values for the identified change point(s), the label component 820 may compare these generated probabilities against one or more thresholds to determine or predict whether a true interface change occurred. In some embodiments, if the change detection component 815 does not generate or include a probability or confidence of the identified change point(s), the label component 820 may generate a confidence value. For example, the label component 820 may generate or determine a set of pre-change or prior values (e.g., average values for each variable over a defined window, such as seven days, prior to the identified change) and postchange or subsequent values (e.g., average values for each variable over a defined window, such as seven days, subsequent to the identified change). The label component 820 can then quantify or compute the fractional change of each feature across the change point. For example, for each feature, the label component 820 may compute the fractional change as where F is the fractional change of feature f and dy is the change in the averagevalue of the feature f (e.g., computed as Py — 5y), where Py is the average or representative value of feature f prior to the potential change point, and S is the average or representative value of feature f subsequent to the potential change point). Although averages and fractional changes are used as example aggregate values, in some aspects, the label component 820 may additionally or alternatively determine other aggregate values, such as the median values or some other percentiles (rather than average), the absolute change or ratios (as opposed to fractional change), and the like.

[0139] In some embodiments, the label component 820 may evaluate the fractional change(s) for each feature using one or more criteria to determine whether to label the change point as a true change. For example, if at least a defined minimum number of the fractional changes meets a defined minimum threshold, the label component 820 may determine that thepotential change point is a true change point. In some embodiments, the label component 820 may aggregate the fractional change values (e.g., by summation, averaging, weighted averaging, and the like) and evaluate this aggregate score using one or more criteria (e.g., an aggregate threshold value). In some aspects, in addition to or instead of comparing the fractional changes (or other aggregate values) against thresholds, the fractional changes (or other aggregate values) may be used as input to one or more machine learning models (e.g., a binary classifier trained to predict whether the user switched to a new interface).

[0140] In some embodiments, the threshold(s) used to confirm or accept a potential change point may be determined using a variety of techniques to balance false positives and true positives. In some embodiments, rather than using defined threshold(s), the label component 820 may use a machine learning model to classify the change points. For example, a binary classifier (e.g., a logistic regression model) may be used. In some embodiments, the classifier may receive, as input, a variety of features such as the probability score(s) generated by the change detection component 815 (if any), the fractional change value(s) discussed above, and the like. In some embodiments, the binary classifier may further receive input such as the user’s age, an indication as to whether the user or flow generator switched from a first pressure mode to a second pressure mode at the time of the potential interface change, window average(s) of one or more of the therapy data features from prior to and / or subsequent to the potential change, the gender of the user, the number of days that have elapsed between device setup (e.g., when the user began the therapy) and the potential interface change, and the like. In some embodiments, the binary classifier outputs a binary indication as to whether the potential change point (identified by the change detection component 815) is a true or valid change point.

[0141] In some embodiments, the output of the label component 820 generally comprises a label or other indication that the user switched from a first user interface to a second user interface at the specified change point / time (e.g., on a given day or between two specific sleep sessions). This label / indication may be used for a wide variety of purposes, depending on the particular implementation. For example, in some embodiments, the label may be used to trigger other operations, such as notifications transmitted to the user and / or the user’s clinician, requests for additional information (e.g., a request that the user identify or indicate which user interface they switched to, a request for reason(s) why the user switched, etc.), and the like. For example, in some embodiments, the generated label indicating an interface change may be used as the trigger for an interface classifier system (e.g., the interface classifier system 725 of FIG. 7) to use machine learning to identify or classify the user’s user interface.

[0142] In the illustrated example, a validation component 825 can also be (optionally) used to validate the output of the label component 820. In some embodiments, the validation component 825 is used during an initial phase (e.g., a training phase, trial phase, and the like) to validate that the system can accurately identify user interface changes, allowing the processes to be modified as needed (e.g., to update the operations of the preprocessing component 810, change detection component 815, and / or label component 820) to improve accuracy. In some embodiments, once the model(s) and processes are validated, the validation component 825 may be unused and / or removed. Additionally, in some embodiments, the validation component 825 may be used by a first system (e.g., a training system) that creates or defines the process (e.g., that trains the classifier used by the label component 820, if any). Once validated, the model(s) may be deployed to any system. That is, in addition to or instead of validating model output during runtime, the validation component 825 may itself train one or more machine learning models that are used during runtime.

[0143] In the illustrated example, the validation component 825 may generally evaluate the generated labels using a variety of data such as user data 830 and order data 835. Although two discrete data stores are depicted for conceptual clarity, in embodiments, the user data 830 and order data 835 may be distributed across any number of data stores. In some embodiments, the validation component 825 uses the user data 830 and / or order data 835 to identify true “switch” events and / or true “non-s witch” events in order to validate the generated labels.

[0144] For example, in some embodiments, users may be able to manually enter or indicate the user interface that they use (e.g., to indicate which interface they use when therapy starts and / or to indicate when they switch to a new interface). For example, the user may interact with the flow generator itself (e.g., the flow generator 710 of FIG. 7) and / or with an application or website using a user device (e.g., user device 730 of FIG. 7) to indicate which user interface they are using. In an embodiment, a user manually indicating that they are using a new interface may be a reliable indicator of such a change. That is, even if the user does not or cannot accurately indicate the specific type or model of interface that they switched to, it can be reasonably assumed that a switch did, in fact, occur. In other words, these self-reported changes can be used as switch labels to train the change detection models(s) and / or to validate the automatically generated labels (generated by the label component 820).

[0145] Therefore, given these labels for interface switches, the validation component 825 can train the binary classifier used to identify switch points and / or to evaluate the performance of the system / the accuracy of the switch point identifications. For example, for any point that is labeled (by the label component 820) as an interface switch point, the validation component825 may determine (based on user data 830) whether the user in fact indicated a switch at or near that point (e.g., within a week of the identified point). If so, this may represent a true positive. If not, it represents a false positive. Additionally or alternatively, for any switches indicated in the user data 830, the validation component 825 may evaluate the label generated by the label component 820 for one or more windows of time covering that change point. If the label(s) indicate a switch, the validation component 825 may determine it is a true positive. If the label(s) do not indicate a switch, the validation component 825 may identify it as a false negative.

[0146] In some embodiments, in addition to using user data 830 to evaluate performance with respect to true switches, the validation component 825 may use order data 835 to evaluate the performance with respect to true non-switches. For example, based on historical orders for new user interfaces (indicated in the order data 835), the validation component 825 may select or identify users that have never ordered a different user interface. These users may reasonably be considered as true non-switchers, in some embodiments. In an embodiment, for each such user, the validation component 825 may pick random point in time (e.g., randomly), and determine whether the label generated by the label component 820 for one or more windows of time covering that randomly-selected point indicates an interface switch. If the label(s) indicate a switch, the validation component 825 may determine that it is a false positive. If the label(s) do not indicate a switch, the validation component 825 may identify it as a true negative.

[0147] In some embodiments, the validation component 825 can therefore be used to evaluate or validate the performance of the preprocessing component 810, change detection component 815, and / or label component 820. In an embodiment, if the performance meets one or more criteria (e.g., a desired minimum true positive rate and / or true negative rate, a desired maximum false positive and / or false negative rate, and the like), the change identification workflow can be deployed for use (e.g., by a change detection system) to evaluate therapy data during runtime.

[0148] FIG. 9 depicts an example workflow 900 for classifying user interfaces using machine learning, according to some implementations of the present disclosure. In some embodiments, the workflow 900 may be performed by an interface classifier system, such as the interface classifier system 725 of FIG. 7. That is, some or all of the depicted components (e.g., the request component 905, preprocessing component 920, presence component 925, interface component 930, and / or label component 935 may be components of the interface classifier system). Though depicted as discrete components for conceptual clarity, in someembodiments, the operations of the depicted components (and others not depicted) may be combined or distributed across any number and variety of components, and may be implemented using hardware, software, or a combination of hardware and software.

[0149] In the illustrated workflow 900, a request component 905 can transmit a request or instruction to a user device 910 (which may correspond to the user device 730 of FIG. 7) of a user that participates in respiratory therapy. This request generally includes a request to identify the user interface that the user uses (or will use) for therapy. Generally, this request may be triggered by a wide variety of operations or events. For example, in some embodiments, when a user starts or begins respiratory therapy for the first time (e.g., when they first activate their flow generator), the request component 905 may transmit such a request. As another example, in some embodiments, the request component 905 may transmit a request whenever it is determined or inferred that the user has switched to a new user interface. For example, when a change detection system (e.g., the change detection system 720 of FIG. 7) generates a change label or otherwise indicates that the user changed to a new interface, the request component 905 may transmit a request to the user. As yet another example, in some embodiments, the request component 905 may periodically or randomly transmit such a request to various users.

[0150] In some embodiments, the request specifically includes a request to indicate or identify the user interface (e.g., asking which type, such as full face, nasal only, and the like) and / or asking which specific model the user uses. In some embodiments, the request includes a request to capture one or more images of the user’s user interface. For example, the request may instruct the user to place the user interface that they currently use on their bed, nightstand, flow generator, in their hand, and the like, and to capture one or more images (e.g., using a built-in camera or imaging sensor on the user device 910). In some embodiments, the request can indicate the reasoning for the request (e.g., indicating that the user is a new respiratory therapy patient, indicating that the system believes the user may have switched to a new interface, and the like).

[0151] In some embodiments, the user may respond to the request by capturing and transmitting the user image(s) 915 using their user device 910. As illustrated, the user image(s) 915 are accessed or received by a preprocessing component 920. In some embodiments, rather than capture an image, the user may instead indicate the specific model they use. For example, as discussed below in more detail, this indication may be provided to the label component 935. Additionally, in some embodiments, the user may alternatively indicate that they have not switched to a new interface. That is, the user may effectively indicate that the change detectionsystem generated a false positive. Relatedly, in some embodiments, if the system determines that the user did switch interfaces (e.g., the image(s) depict a different interface than exists in the therapy system’s data), the system can effectively determine that the change detection system generated a true positive. Similar approaches may be used to identify true and false negatives, in some embodiments (e.g., if the request component 905 periodically or randomly sends out such requests). In some embodiments, these indications / true and false positives / negatives can be used (e.g., by validation component 825 of FIG. 8) to refine the model(s) or processes used to identify interface switches.

[0152] Generally, the preprocessing component 920 may optionally perform a variety of preprocessing operations on the user images 915. For example, depending on the particular implementation and architecture, the preprocessing component 920 may resize the user images 915 (e.g., to a defined size), apply one or more filters or operations for de-noising, contrast enhancement, and the like. Though the illustrated example depicts a preprocessing component 920, in some embodiments, no preprocessing is performed on the user images 915.

[0153] In the illustrated workflow 900, the (potentially preprocessed) user images 915 are accessed by a presence component 925. The presence component 925 generally evaluates the accessed images to determine whether the user image(s) 915 depict a user interface. For example, in some embodiments, the presence component 925 uses one or more machine learning models to classify the user image(s) 915 as either (i) depicting a user interface or (ii) not depicting a user interface. The specific machine learning architecture may vary depending on the particular embodiment. In some embodiments, the presence component 925 uses a convolutional neural network (CNN) to generate an interface presence measure indicating whether a given input user image 915 depicts a user interface. For example, the interface presence measure may include a binary value indicating whether an interface is depicted, a score indicating the probability or confidence that an interface is depicted, and the like.

[0154] In some embodiments, the presence component 925 uses a machine learning model trained using transfer learning, as discussed in more detail below. For example, a pre-trained image -recognition convolutional neural network (e.g., such as MobileNetV2) may be accessed. Using labeled exemplar images (e.g., images depicting user interfaces and / or images not depicting user interfaces), the pre-trained model may be updated (e.g., updating one or more parameters of one or more layers of the model) to crate the user interface detection model. This can enable improved accuracy and performance with substantially reduced training costs and data needs.

[0155] In the illustrated embodiment, if the presence component 925 determines that thepresence measure satisfies one or more criteria (e.g., that a binary value indicates that a user interface is depicted and / or that a confidence or probability of this classification meets or exceeds a threshold), the user image(s) 915 may be accessed by an interface component 930 for classification. In some embodiments, if the presence component 925 determines that the user image(s) 915 do not (or likely do not) depict a user interface, the images may be rejected. For example, the interface component 930 may refrain from processing them and / or from returning output generated by processing them. In some embodiments, in response to such a determination, the request component 905 may transmit a renewed request / instruction to the user device 910, asking the user to capture a new image of their user interface. That is, though not depicted in the illustrated example, the presence component 925 may cause a request for new images to be transmitted to the user device 910 (e.g., by directly transmitting the request and / or by instructing or causing the request component 905 to transmit the request).

[0156] Although the illustrated example depicts use of a presence component 925 to confirm whether the user image(s) 915 depict an interface at all, in some embodiments, the user image(s) 915 may instead be provided directly to the interface component 930 for classification (without first being evaluated by a presence component 925).

[0157] In the illustrated workflow 900, the (potentially preprocessed) user images 915 are accessed by an interface component 930. The interface component 930 generally evaluates the accessed images to classify or identify the user interface depicted in the user image(s) 915. That is, in some embodiments, the interface component 930 uses one or more multiclass machine learning classification models to classify each user image 915 based on the specific interface model, of a number of models, depicted in the image(s). For example, the interface component 930 may generate output indicating that the user image 915 depicts an AirFit™ F20 user interface, an AirFit™ F30 user interface (each manufactured by ResMed), and the like.

[0158] In some embodiments, the interface component 930 generates a respective probability or confidence for each possible interface model (e.g., in a multidimensional vector, where each value in the vector indicates the confidence or probability that a corresponding interface model is depicted in the image). That is, for each respective interface model that the interface component 930 is configured or trained to recognize, the interface component 930 may generate a corresponding score indicating the probability that the respective interface model is depicted in the user image(s) 915. In some embodiments, in addition to or instead of outputting probability scores for each model, the interface component 930 generates a specific classification (e.g., indicating a specific interface model). For example, one or more layers of the machine learning model used by the interface component 930 (e.g., a final fully-connectedlayer) may generate an output identifying a single model (e.g., using a one-hot encoding vector), or the interface component 930 may compare output probabilities to one or more thresholds.

[0159] Generally, the specific machine learning architecture used by the interface component 930 may vary depending on the particular embodiment. In some embodiments, the interface component 930 uses a CNN to generate a classification and / or set of probabilities or confidences indicating which user interface model is depicted in the input user image 915.

[0160] In some embodiments, the interface component 930 uses a machine learning model trained using transfer learning, as discussed in more detail below. For example, a pre-trained image -recognition convolutional neural network (e.g., such as MobileNetV2) may be accessed. Using labeled exemplar images (e.g., images depicting various models of user interfaces), the pre-trained model may be updated (e.g., updating one or more parameters of one or more layers of the model) to create the interface classification model. This can enable improved accuracy and performance with substantially reduced training costs and data needs.

[0161] In the illustrated workflow 900, the interface component 930 can output the classification(s) and / or probabilities to a label component 935. In some embodiments, the label component 935 may generally evaluate the output of the classification model to generate a label for the user image(s) 915 and / or for the user. For example, in some embodiments, the label component 935 may compare the confidence or probability of the highest-scored interface model against one or more thresholds. In one such embodiment, if the confidence meets or exceeds the threshold, the label component 935 may generate a label / indication that the user image(s) 915 depict the identified interface model and / or that the user associated with the user device 910 uses the identified interface model. For example, the label component 935 may update the therapy records or other information associated with the user to indicate the identified interface model.

[0162] In some embodiments, as illustrated in the depicted workflow 900, the label component 935 may additionally or alternatively transmit a request to the user device 910, asking the user to confirm or approve the classification. For example, in one embodiment, the label component 935 indicates the highest-scored interface model to the user and requests confirmation that the user is using the indicated interface model. In some embodiments, the label component 935 may indicate multiple alternative interface models based on their associated probabilities. For example, the label component 935 may transmit an indication of the two highest-scoring alternatives, the top three alternatives, and the like. In some embodiments, the label component 935 can indicate the N highest- scoring interface models,where N can be a configurable parameter (e.g., set by an administrator). In some embodiments, the label component 935 can indicate any interface models having a generated probability that exceeds a threshold value, which may similarly be set by an administrator. In some embodiments, the label component 935 may indicate the top or highest- scored prediction to the user, asking for confirmation or rejection. If rejected, the label component 935 may indicate the second-most likely interface, and so on until the user confirms the prediction or a defined number of iterations (e.g., three rejections) have been performed. Generally, the number of interface model(s) suggested to the user may vary depending on the particular implementation.

[0163] In an embodiment, based on the response from the user, the label component 935 can generate the label / indication that the user is engaged in respiratory therapy using the identified interface model.

[0164] In this way, the interface classifier system can efficiently generate accurate and reliable classifications indicating which user interfaces are being used by each user, substantially reducing uncertainty and improving therapy results for users that switch to new user interfaces (or that begin therapy without specifying which interface they are using).

[0165] FIG. 10 depicts an example workflow 1000 for training machine learning models to classify user interfaces, according to some implementations of the present disclosure. In some embodiments, the workflow 1000 may be performed by an interface classifier system, such as the interface classifier system 725 of FIG. 7. That is, some or all of the depicted components (e.g., the augmentation component 1015 and / or training component 1025 may be components of the interface classifier system). In other embodiments, the workflow 1000 may be performed by a dedicated training system. Though depicted as discrete components for conceptual clarity, in some embodiments, the operations of the depicted components (and others not depicted) may be combined or distributed across any number and variety of components, and may be implemented using hardware, software, or a combination of hardware and software.

[0166] In the illustrated example, a set of interface images 1005 and non-interface images 1010 can be used to train a presence model 1030 and / or interface classification model 1035. The interface images 1005 and non-interface images 1010 may collectively be referred to as training images, training samples, and / or training exemplars, in some embodiments. The training images / exemplars may generally include appropriate labels that can be used to enable supervised learning, as discussed in more detail below.

[0167] Generally, the interface images 1005 include images depicting user interfaces of various models and in various settings. For example, the interface images 1005 may includeimages depicting user interfaces on beds, nightstands, and other surfaces, held in the hand(s) of users, resting on top of flow generators, and the like. Generally, each of the images in the interface images 1005 may include or be associated with a label indicating that the image depicts a user interface. In some embodiments, the labels can further indicate the specific interface model and / or interface type that is depicted in each image. Generally, any number and variety of user interface models / types (e.g., any type of interface manufactured by any number of entities) may be reflected in the interface images 1005.

[0168] Generally, the non-interface images 1010 include images that do not depict user interfaces (or that depict user interfaces in non-recognizable poses or settings). For example, the non-interface images 1010 may include images depicting various settings such as beds, nightstands, and other surfaces, flow generators, and the like. In some embodiments, the noninterface images 1010 may include one or more images depicting user interfaces in nonpreferred or unrecognizable settings. That is, if there are specific positions that would make the user interface difficult to accurately categorize / identify (e.g., in an overly-dark room, when worn by the user, from a distance, and the like), images of user interfaces in such positions may be depicted in the non-interface images 1010 to allow the presence model 1030 to learn to reject such images. Generally, each of the images in the non-interface images 1010 may include or be associated with a label indicating that the image does not depict a user interface (or does not depict an interface with sufficient clarity such that it can be categorized).

[0169] In the illustrated workflow 1000, an augmentation component 1015 accesses the interface images 1005 and non-interface images 1010 and optionally applies one or more preprocessing operations, transformation operations, and / or augmentations to the training images. In some embodiments, the augmentation component 1015 may apply augmentations to the interface images 1005 without applying such augmentations to the non-interface images 1010. For example, because it may be relatively trivial to collect a large number of images that do not depict a user interface (and relatively more difficult to collect images that do depict a user interface), the augmentation component 1015 may use augmentations to expand the set of interface images 1005 to enable more accurate training.

[0170] Generally, the augmentation component 1015 may generate synthetic training images by applying one or more augmentations to one or more of the training images. Generally, when such augmentations are used, the set of training images may include such synthetic images as well as the original (un- augmented) images. That is, the set of training images may include not only the actual interface images 1005 and non-interface images 1010, but also the generated / synthetic images. The specific combination of augmentations used bythe augmentation component 1015 may vary depending on the particular implementation. In some embodiments, the augmentations are performed with at least some aspect of randomness. For example, the augmentation component 1015 may randomly determine which augmentation(s) (from a set of possible augmentations) to apply to a given image, the scale or amount of the augmentation(s) to apply (from a defined range of scales), and the like. As nonlimiting examples of transformations that may be applied to generate synthetic images, the augmentation component 1015 may use transformations such as image duplication (e.g., generating a second copy of the training image in the training dataset, with or without various transformations applied), rotation (e.g., rotating the image clockwise or counterclockwise by a random amount / at any angle, where empty spaces created by partial rotation (e.g., rotation by 30 degrees) can be padded, such as with black or white pixels), image scaling (e.g., up or down by a random amount), shear adjustment, brightness adjustment, zoom (in or out), height and / or width shifts (e.g., squeezing or stretching the image vertically or horizontally), horizontal and / or vertical flip of the images, and the like.

[0171] In some embodiments, the augmentation component 1015 can augment or modify the training images based at least in part on the real-world distribution, popularity, or commonality of interface models in use. That is, while some augmentation operations (such as those discussed above) may be used in a class-agnostic manner to improve robustness of the models, in some aspects, other augmentation operations (which may be referred to in some aspects as resampling operations) may be used in a class- specific manner to better match a desired class distribution in the training data. That is, based on the numbers / distribution of interface models that are used in respiratory therapies, the augmentation component 1015 may modify the training data to ensure that more popular or common models are represented / weighted more highly, as compared to less popular or common models. For example, the augmentation component 1015 may determine the distribution of interface models based on sales histories, surveys, and the like. In this way, the system may train the interface classification model 1035 based at least in part on this real-world distribution (e.g., to ensure high accuracy for interface models that are popular / common, to bias the interface classification model 1035 towards these popular interface model(s), and the like).

[0172] In some embodiments, the augmentation component 1015 accounts for this distribution by assigning training weights to some or all of the training images in accordance with the distribution of interface models. For example, the weight assigned to each image (which may affect how significantly the machine learning model parameters are updated based on the image) may be adjusted to ensure that the most popular interface model(s) affect themachine learning model the greatest. In some embodiments, the augmentation component 1015 may account for the distribution by duplicating or otherwise generating additional versions of one or more images that depict the popular model(s). For example, the augmentation component 1015 may generate synthetic training images disproportionately to the original set of interface images 1005, such that there are more examples of popular interfaces reflected in the training data, as compared to less popular interfaces.

[0173] In the illustrated example, the training component 1025 uses the (potentially augmented) training images to train a presence model 1030 and / or an interface classification model 1035. For example, in one embodiment, the training component 1025 uses the interface images 1005 as positive exemplars and the non-interface images 1010 as negative exemplars to train the presence model 1030. In some embodiments, the training component 1025 uses the interface images 1005 as exemplars to train the interface classification model 1035. Although the illustrated example depicts the training component 1025 training both the presence model 1030 and the interface classification model 1035 using the interface images 1005, in some embodiments, the interface classification model 1035 may additionally or alternatively be trained using other images that are not used to train the presence model 1030 (and vice versa).

[0174] In some embodiments, the training component 1025 can optionally train or generate the presence model 1030 and / or interface classification model 1035 using transfer learning and a pre-trained image model 1020 (such as MobileNetV2). For example, as discussed above, the training component 1025 may access the pre-trained image model 1020 and update one or more aspects of it based on the training images (e.g., based on the interface images 1005 and / or noninterface images 1010) to generate the presence model 1030 and / or interface classification model 1035.

[0175] In some embodiments, the training component 1025 may strip or remove one or more layers of the image model 1020 (e.g., removing the final layer), or reset the parameters of one or more layers (e.g., setting the parameters of the final layer to randomized values) prior to refining the image model 1020 using the training images. In some embodiments, when refining the pre-trained image model 1020, the training component 1025 may freeze one or more parameters (e.g., refraining from updating weights in the first few layers), while updating or modifying other parameters (e.g., updating the values of weights in the final few layers).

[0176] In this way, the training component 1025 can train accurate and reliable presence models 1030 and interface classification models 1035 with relatively reduced computational expense and with reduced number and diversity of training data, as compared to conventionaltraining methods. In an embodiment, once training of the presence model 1030 and interface classification model 1035 is complete, they can be deployed for runtime use (e.g., to an interface classifier system),

[0177] FIG. 11 is a flow diagram depicting an example method 1100 for detecting interface changes using machine learning, according to some embodiments of the present disclosure. In some embodiments, one or more steps of the method 1100 can be implemented using any element or aspect of the system 100 (FIGS. 1-2) described herein. In some embodiments, the method 1100 is performed by an inferencing system (such as the inferencing device 1700 of FIG. 17). For example, in some embodiments, the method 1100 is performed by a change detection system, such as change detection system 720 of FIG. 7. While the method 1100 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 1100 can be performed in any suitable order.

[0178] In some embodiments, the method 1100 is performed continuously (e.g., as new data becomes available). In some embodiments, the method 1100 is performed periodically, such as daily, weekly, bi-weekly, and the like. Although the method 1100 depicts a flow of operations to process data for a single user for conceptual clarity, in embodiments, the method 1100 may be performed to evaluate data from any number of respiratory therapy users.

[0179] At block 1105, the change detection system accesses therapy data (e.g., therapy data 715 of FIG. 7 and / or 805 of FIG. 8) for a user of a flow generator / engaged in respiratory therapy. As discussed above, the change detection system may generally access the therapy data from any number and variety of data sources, such as from systems used to maintain respiratory therapy information for review and analysis by clinicians. In some embodiments, the therapy data can be collected or provided continuously (e.g., with new data every second) and / or periodically (e.g., with data aggregated and provided every few minutes or every day). Generally, the respiratory therapy data can include information relating to a respiratory therapy the user engages in, such as the usage duration of their flow generator (e.g., the total usage for a period of time, such as a 24 hour period), the number of times the user donned and doffed the user interface of the flow generator during the period or session, the total, maximum, and / or average amount of air leak of the flow generator during the period or session, the AHI of the user during the period or session, and the like.

[0180] In some embodiments, the change detection system accesses all available therapy data for a given user at block 1105. In some embodiments, the change detection system accesses a subset of the data, such as the data from a sliding window (e.g., collected or generated in the past 14 days).

[0181] At block 1110, the change detection system can optionally preprocess the therapy data, as discussed above. For example, the change detection system may apply one or more smoothing operations to the therapy data. In some embodiments, the change detection system uses moving averages to smoothen the data. For example, the change detection system may replace the value(s) of a given day (or other window of time) with the average of the value for the given day (or other window of time) and the value(s) for one or more neighboring day(s) (or other windows of time). In some embodiments, a similar moving average approach can be used to fill in missing data (e.g., days or other windows of time where no usage was recorded). In some embodiments, various other preprocessing operations may be optionally performed, depending on the particular implementation. For example, the change detection system may de-noise the data, remove outliers from the data, and the like.

[0182] At block 1115, the change detection system detects one or more change points for the user by processing the (potentially preprocessed) therapy data using one or more machine learning models. For example, as discussed above, the change detection system may use one or more unsupervised change point detection models or algorithms to identify change points, which each correspond to potential or predicted point or window in time when the user (associated with the therapy data) changed from a first user interface to a second user interface. That is, because different user interface models may result in different therapy data being collected (e.g., different usage durations, different donning / doffing frequencies, and the like), the change detection system may evaluate the therapy data to identify when the user switched to the new interface model.

[0183] At block 1120, the change detection system selects one of the identified (potential) change points. Generally, the change detection system may select the change point using a variety of techniques and criteria (including sequentially, randomly, or pseudo-randomly), as each potential change point can be evaluated during the method 1100. Although an iterative process (selecting and evaluating each change point in turn) is depicted for conceptual clarity, in some embodiments, the change detection system may evaluate multiple change points in parallel. Additionally, though evaluation of multiple change points is depicted, in some embodiments, the change detection system may identify or indicate a single change point in the data, depending on the particular implementation.

[0184] At block 1125, the change detection system determines the confidence of the selected change point (also referred to in some embodiments as the probability of the point). In some embodiments, as discussed above, the change point detection model used to identify the change points (at block 1115) may itself generate a confidence or probability for anyidentified change points. In some embodiments, the change detection system may generate a confidence for the change point based on computing the fractional change(s) in the therapy data from the average values prior to the change point to the average values subsequent to the change point.

[0185] At block 1130, the change detection system determines whether the determined confidence in the identified (potential) change point satisfies one or more defined criteria. For example, in some embodiments, the change detection system may compare the confidence and / or fractional change to one or more defined thresholds. If the confidence and / or fractional change meets or exceeds the threshold(s), the change detection system may determine that the confidence criteria are met. As another example, in some embodiments, the change detection system processes the confidence and / or fractional change using a binary classifier (e.g., a machine learning model trained to classify input as either indicative of a true interface change or not indicative of such a change). In some embodiments, in addition to or instead of processing the confidence and / or fractional change, the binary classifier can process data such as the user’ s age, the pressure mode of the flow generator (before and / or after the change point), and / or a subset of the therapy data itself (e.g., the average values before and / or after the change point).

[0186] If, at block 1130, the change detection system determines that the confidence criteria are not satisfied (e.g., if the change detection system determines that it is insufficiently probable that the identified change point corresponds to an actual or true interface change), the method 1100 continues to block 1140. If, at block 1130, the change detection system determines that the criteria are satisfied, the method 1100 continues to block 1135.

[0187] At block 1135, the change detection system labels the change point or otherwise generates a label or indication that the change point corresponds to a true or real switch to a second interface. For example, in some embodiments, the change detection system can update records or other data associated with the user (e.g., in the therapy data) to indicate that the user (likely) switched user interfaces at the change point. In some embodiments, as discussed above, the change detection system or another system may trigger one or more additional processes, such as requesting that the user identify their user interface (e.g., by taking a picture of it). The method 1100 then continues to block 1140.

[0188] At block 1140, the change detection system determines whether there is at least one (potential) change point remaining to be evaluated. If so, the method 1100 returns to block 1120. If not, the method 1100 returns to block 1105 to begin anew (e.g., immediately, once new therapy data is available, periodically, and the like).

[0189] FIG. 12 is a flow diagram depicting an example method 1200 for classifying user interfaces using machine learning, according to some embodiments of the present disclosure. In some embodiments, one or more steps of the method 1200 can be implemented using any element or aspect of the system 100 (FIGS. 1-2) described herein. In some embodiments, the method 1200 is performed by an inferencing system (such as the inferencing device 1700 of FIG. 17). For example, in some embodiments, the method 1200 is performed by an interface classifier system, such as interface classifier system 725 of FIG. 7. While the method 1200 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 1200 can be performed in any suitable order.

[0190] Although the method 1200 depicts a flow of operations to process data for a single user for conceptual clarity, in embodiments, the method 1200 may be performed to evaluate data from any number of respiratory therapy users.

[0191] At block 1205, the interface classifier system determines whether one or more trigger criteria are satisfied. The trigger criteria may include a variety of considerations, depending on the particular implementation. For example, in some embodiments, evaluating the trigger criteria can include determining whether a user has begun respiratory therapy (e.g., whether they are a new patient with a new user interface). In some embodiments, evaluating the trigger criteria can include determining whether a user has potentially switched user interfaces. For example, if it is determined that the user may have switched to a new interface (e.g., because a system, such as a change detection system, determined that a point was sufficiently probable to be a change point, such as at block 1135 of FIG. 11), the interface classifier system may determine that the trigger criteria are satisfied. In at least some embodiments, in response to determining that a potential change point has been identified or predicted (as discussed above), the interface classifier system may prompt the user to confirm whether they have begun using a new interface. If so (e.g., if the user responds in the affirmative), the interface classifier system may determine that the trigger criteria are satisfied.

[0192] If the trigger criteria are not satisfied, the method 1200 iterates at block 1205. If the interface classifier system determines that the trigger criteria are met, the method 1200 continues to block 1210, where the interface classifier system requests an interface image from the user. For example, as discussed above, the interface classifier system may identify a user device (e.g., a smartphone) associated with the user and / or used by the user during the respiratory therapy. The interface classifier system may then transmit, to the user device, a request that the user capture an image of the respiratory therapy user interface that they are currently using (or were using on an indicated date). Although the illustrated examplediscusses evaluation of a single user image, in embodiments, the interface classifier system may request and / or receive multiple user images and process each using the method 1200.

[0193] At block 1215, the interface classifier system receives an image from the user. Generally, the request may be transmitted and the images may be provided using a variety of technologies, depending on the particular implementation. For example, in some embodiments, the request and / or image may be transmitted via short message service (SMS) and / or multimedia message service (MMS) messaging. In some embodiments, the request and / or image may be transmitted using other means, such as email, via a respiratory therapy application on the user device, and the like. In some embodiments, the received image can be optionally preprocessed prior to processing, such as by resizing them.

[0194] At block 1220, the interface classifier system generates a presence measure by processing the user image using a first machine learning model (e.g., the presence model 1030 of FIG. 10). For example, the interface classifier system may use a convolutional neural network to generate a binary classification (e.g., “yes interface” or “no interface”) and / or a score or probability (e.g., a value indicating how probable it is that the image depicts a user interface). The presence measure generally indicates whether the received image depicts a user interface, as discussed above.

[0195] At block 1225, the interface classifier system determines whether the presence measure satisfies one or more criteria. For example, the interface classifier system may determine whether a binary value indicates that a user interface is present in the image, whether the confidence or probably exceeds or meets a threshold, and the like. If the interface classifier system determines that the presence criteria are not satisfied (e.g., the image likely does not depict a user interface, or does not depict a user interface that can be readily recognized), the method 1200 returns to block 1210 to request a new image. If the interface classifier system determines that the presence criteria are met, the method 1200 continues to block 1230.

[0196] At block 1230, the interface classifier system classifies the user interface by processing the user image using a second machine learning model (e.g., the interface classification model 1035 of FIG. 10). For example, the interface classifier system may use a convolutional neural network to generate a multiclass classification (e.g., indicating which class or interface model is depicted). As discussed above, this classification may indicate the model of the interface depicted in the user image. In some embodiments, the classification includes an indication of the most-probable interface, the three most likely interfaces, and the like. In some embodiments, the machine learning model outputs a set of scores (one for each model that the interface classifier system can classify / identify). The interface classifier systemcan then evaluate these scores to identify which user interface(s) are most probably depicted in the image.

[0197] Advantageously, by first processing images using the first machine learning model (e.g., the presence model) and only selectively processing images using the second model (e.g., the interface classification model), the interface classifier system can substantially reduce the computational complexity of the interface identification process. For example, by refraining from using the classification model when no interface is depicted, the interface classifier system can eliminate the computational expense of using the model. Similarly, the interface classifier system can refrain from generating misleading or confusing data (e.g., an interface classification when, in fact, no interface is depicted). This can substantially improve the operations of any downstream systems that consume the classifications generated by the interface classifier system.

[0198] At block 1235, the interface classifier system determines whether the confidence of the highest- scored classification satisfies one or more criteria. For example, the interface classifier system can determine whether the score of the highest- scored user interface meets or exceeds a threshold. If so, the interface classifier system may determine that no user confirmation is needed, and the method 1200 continues to block 1250. In some embodiments at block 1235, the interface classifier system can determine a phase or setting of the deployed model. For example, the interface classifier system may determine whether the machine learning model is deployed in a testing phase (e.g., where all classifications are subject to user approval) or a runtime phase (e.g., where sufficiently confident classifications can bypass user approval). If the interface classifier system determines, at block 1235, that the criteria are not satisfied, the method 1200 continues to block 1240. In at least one embodiment, if none of the alternative interface models is associated with sufficiently high confidence, the method 1200 may instead return to block 1210, where the interface classifier system can request a new image be captured.

[0199] At block 1240, the interface classifier system outputs one or more alternative classifications to the user. For example, the interface classifier system may transmit an indication of one or more most-probable user interfaces to the user, such as via text message, email, and / or an application used in conjunction with the respiratory therapy. In some embodiments, as discussed above, the interface classifier system can output the N highest- scoring interface models, where N can be a configurable parameter (e.g., set by an administrator). In some embodiments, the interface classifier system can indicate any interface models having a generated probability that exceeds a threshold value, which may similarly beset by an administrator. Generally, the number of interface model(s) suggested to the user may vary depending on the particular implementation. In at least one embodiment, the interface classifier system may indicate the potential user interfaces without specifically indicating the confidence or probability of each (though the interface classifier system may order or sort the alternatives based on their probabilities).

[0200] At block 1245, the interface classifier system receives user confirmation as to which user interface they are using / which interface was depicted in the image. In some embodiments, this may include a user selection of one of the indicated alternatives. In some embodiments, the user may additionally, or alternatively manually enter or indicate the interface they are using. In some embodiments, if the actual user interface model is not included in the set of alternatives, the user may indicate that none of the suggested alternatives is correct. In some embodiments, the interface classifier system may respond by providing one or more additional (lower scored) alternatives, by requesting a new image of the user’s interface, and the like.

[0201] Once confirmation of the model of the user interface is received, the method 1200 continues to block 1250, where the interface classifier system labels the interface based on the confirmation and / or based on the output of the interface classification machine learning model. Generally, the interface classifier system may label the interface or otherwise generate a label or indication that the user is using the identified interface model using a variety of techniques. For example, in some embodiments, the interface classifier system can update records or other data associated with the user (e.g., in the therapy data) to indicate that the user is using the identified user interface model at the time.

[0202] FIG. 13 is a flow diagram depicting an example method 1300 for training machine learning models to classify user interfaces, according to some embodiments of the present disclosure. In some embodiments, one or more steps of the method 1300 can be implemented using any element or aspect of the system 100 (FIGS. 1-2) described herein. In some embodiments, the method 1300 is performed by a training system (such as the training device 1800 of FIG. 18). For example, in some embodiments, the method 1300 is performed by change detection system 720 of FIG. 7 and / or interface classifier system 725 of FIG. 7. While the method 1300 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 1300 can be performed in any suitable order.

[0203] At block 1305, the training system accesses one or more images of one or more user interfaces. For example, the interface images may correspond to interface images 1005 of FIG. 10. In some embodiments, rather than product images used to advertise or sell interfaces (which tend to depict the user interface without background or context, such as in an unrealisticblank setting), some or all of the interface images may depict user interfaces in realistic settings where a respiratory therapy interface may be used, such as on a bed, on a nightstand, and the like.

[0204] At block 1310, the training system can optionally augment the interface image(s) to generate additional synthetic training images using or more transformations or augmentations, as discussed above. For example, as discussed above, the training system may apply transformations such as rotation, flipping, stretching, shearing, brightness and contrast adjustments, zoom and scale adjustments, and the like.

[0205] In some embodiments, as discussed above, the training system may augment the interface images based at least in part on the distribution of user interfaces that are used in the real world. For example, based on data such as surveys and sales data, the training system may determine how common each interface model is (relative to the other models), and augment the training data accordingly (e.g., by generating additional versions of the more common models, relative to less common models, by weighting more common models more heavily, and the like).

[0206] At block 1315, the training system trains or refines an interface classification model (e.g., the interface classification model 1035 of FIG. 10) using the (potentially augmented) interface images. That is, the training system trains the interface classification machine learning model to classify images (and / or identify user interfaces depicted in images) based on the interface model that is depicted in the image. Generally, the particular techniques used to train the interface classification model may vary depending on the particular implementation and architecture of the classification model.

[0207] For example, in the case of a convolutional neural network, the training system may process a training image (from the augmented set of interface images) using the interface classification model to generate an output prediction (e.g., scores or probabilities for each interface model). This prediction can then be compared against the label of the training image (e.g., indicating which interface model is depicted) to generate a loss, which can then be used to refine or update one or more parameters of the classification model (e.g., using backpropagation). In some embodiments, the updating / loss can be determined based at least on part on a training weight (where higher- weighted samples result in larger losses / larger parameter updates). This update process can generally be performed independently for each training image (e.g., using stochastic gradient descent) and / or based on batches of training images (e.g., using batch gradient descent).

[0208] In some embodiments, as discussed above, the training system may train theinterface classification model by using transfer learning. For example, the training system may refine one or more parameters of a pre-trained image model (e.g., image model 1020 of FIG. 10) using the interface images. As one example, the training system may remove or reset one or more portions of the pre-trained model (e.g., removing the final classification layer of the model) prior to beginning training, and update one or more parameters of one or more portions of the model (e.g., the last few layers) based on the losses generated using the training images.

[0209] At block 1320, the training system accesses one or more images of that do not depict user interfaces (or that depict user interfaces in a way that makes identification difficult or impossible, such as due to distance, obfuscation, because the interface is partially occluded, and the like). For example, the non-interface images may correspond to non-interface images 1010 of FIG. 10.

[0210] At block 1325, the training system can optionally augment the interface image(s) to generate additional synthetic training images using or more transformations or augmentations, as discussed above. For example, as discussed above, the training system may apply transformations such as rotation, flipping, stretching, shearing, brightness and contrast adjustments, zoom and scale adjustments, and the like.

[0211] At block 1330, the training system trains or refines a presence model (e.g., the presence model 1030 of FIG. 10) using the (potentially augmented) interface images and the (potentially augmented) non-interface images. That is, the training system trains the presence machine learning model to classify images based on whether they depict a respiratory therapy user interface using positive examples (e.g., interface images) as well as negative examples (e.g., non-interface images). Generally, the particular techniques used to train the presence model may vary depending on the particular implementation and architecture of the model.

[0212] For example, in the case of a convolutional neural network, the training system may process a training image (from the augmented set of interface images and non-interface images) using the presence model to generate an output prediction. This prediction can then be compared against the label of the training image (e.g., indicating whether the image depicts a user interface) to generate a loss, which can then be used to refine or update one or more parameters of the presence model (e.g., using backpropagation). This update process can generally be performed independently for each training image (e.g., using stochastic gradient descent) and / or based on batches of training images (e.g., using batch gradient descent).

[0213] In some embodiments, as discussed above, the training system may train the presence model by using transfer learning. For example, the training system may refine one or more parameters of a pre-trained image model (e.g., image model 1020 of FIG. 10) using theinterface images and non-interface images. As one example, the training system may remove or reset one or more portions of the pre-trained model (e.g., removing the final classification layer of the model) prior to beginning training, and update one or more parameters of one or more portions of the model (e.g., the last few layers) based on the losses generated using the training images.

[0214] Although the illustrated example suggests training of the interface classification model and presence model together or jointly (e.g., using overlapping training data and / or at the same time) for conceptual clarity, in embodiments, the models may be trained separately (e.g., on different systems, at different times, and / or using different or non-overlapping sets of training data).

[0215] At block 1335, the training system determines whether one or more termination criteria are satisfied. Generally, evaluating the termination criteria may include a wide variety of considerations, depending on the particular implementation. For example, in some embodiments, the training system may determine whether there are any remaining training images available for training. In some embodiments, the training system may determine whether a defined maximum amount of time and / or computational resources has been spent training the models. In some embodiments, the training system determines whether the model(s) meet a desired or defined optimization metric, such as a minimum prediction accuracy.

[0216] If, at block 1335, the training system determines that the termination criteria are not met, the method 1300 returns to block 1305. If the training system determines that the termination criteria are met, the method 1300 continues to block 1340, where the training system deploys the presence model and interface classification model for runtime use. For example, as discussed above, the models may be deployed to an interface classification system for use.

[0217] Although not included in the illustrated example, in some embodiments, the training system may further train additional models, such as a binary classifier used to determine whether a potential change point is a true change point. For example, as discussed above with reference to FIG. 8, a binary classifier may be used to process data (such as therapy data, user age, and the like) to predict or determine whether an identified potential change point (e.g., identified using an unsupervised model) in order to classify it as a (likely) true or (likely) false change point. In some embodiments, the training system may train this classifier, such as by using labeled therapy data (e.g., with labels indicating whether the corresponding user switched user interfaces and / or indicating when the switch occurred).

[0218] FIG. 14 is a flow diagram depicting an example method 1400 for method for identifying user interface switches, according to some embodiments of the present disclosure. In some embodiments, one or more steps of the method 1400 can be implemented using any element or aspect of the system 100 (FIGS. 1-2) described herein. In some embodiments, the method 1400 is performed by an inferencing system (such as the inferencing device 1700 of FIG. 17). For example, in some embodiments, the method 1400 is performed by a change detection system, such as change detection system 720 of FIG. 7. While the method 1400 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 1400 can be performed in any suitable order.

[0219] At block 1405, respiratory therapy data (e.g., therapy data 710 of FIG. 7 and / or therapy data 805 of FIG. 8) of a user (e.g., user 210 of FIG. 2 and / or user 705 of FIG. 7) of a flow generator (e.g., respiratory therapy device 122 of FIGS. 1, 2, and 6 and / or flow generator 710 of FIG. 7) is accessed, the respiratory therapy data comprising a time series of records.

[0220] At block 1410, a change point is identified by processing the respiratory therapy data using a machine learning model (e.g., by change detection component 815 of FIG. 8).

[0221] At block 1415, a confidence measure indicating a probability that the user switched from a first user interface for the flow generator to a second user interface (e.g., user interfaces 124 of FIGS. 1-2, user interface 300 of FIGS. 3A-3B, user interface 400 of FIGS. 4A-4B, and / or user interface 500 of FIGS. 5A-5B) for the flow generator at the change point is generated (e.g., by change detection component 815 of FIG. 8 and / or label component 820 of FIG. 8).

[0222] At block 1420, a label indicating that the user switched to the second user interface at the change point is generated based on the confidence measure (e.g., by label component 820 of FIG. 8).

[0223] FIG. 15 is a flow diagram depicting an example method 1500 for classifying user interfaces, according to some embodiments of the present disclosure. In some embodiments, one or more steps of the method 1500 can be implemented using any element or aspect of the system 100 (FIGS. 1-2) described herein. In some embodiments, the method 1500 is performed by an inferencing system (such as the inferencing device 1700 of FIG. 17). For example, in some embodiments, the method 1500 is performed by an interface classifier system, such as interface classifier system 725 of FIG. 7. While the method 1500 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 1500 can be performed in any suitable order.

[0224] At block 1505, an image (e.g., user image 915 of FIG. 9) captured by a user (e.g.,user 210 of FIG. 2 and / or user 705 of FIG. 7) of a flow generator (e.g., respiratory therapy device 122 of FIGS. 1, 2, and 6 and / or flow generator 710 of FIG. 7) to identify a user interface (e.g., user interfaces 124 of FIGS. 1-2, user interface 300 of FIGS. 3A-3B, user interface 400 of FIGS. 4A-4B, and / or user interface 500 of FIGS. 5A-5B) of the flow generator is accessed.

[0225] At block 1510, a first classification of the user interface of the flow generator is generated by processing the image using a first machine learning model (e.g., interface classification model 1035 of FIG. 10), the first classification indicating a model of the user interface.

[0226] At block 1515, a first confidence measure of the first classification is determined (e.g., by interface component 930 of FIG. 9 and / or label component 935 of FIG. 9).

[0227] At block 1520, a label indicating the first classification of the user interface is generated based at least in part on the first confidence measure (e.g., by label component 935 of FIG. 9).

[0228] FIG. 16 is a flow diagram depicting an example method 1600 for training machine learning models to classify user interfaces, according to some embodiments of the present disclosure. In some embodiments, one or more steps of the method 1600 can be implemented using any element or aspect of the system 100 (FIGS. 1-2) described herein. In some embodiments, the method 1600 is performed by a training system (such as the training device 1800 of FIG. 18). For example, in some embodiments, the method 1600 is performed by change detection system 720 of FIG. 7 and / or interface classifier system 725 of FIG. 7. While the method 1600 has been shown and described herein as occurring in a certain order, more generally, the steps of the method 1600 can be performed in any suitable order.

[0229] At block 1605, a first plurality of training images depicting user interfaces for flow generators (e.g., interface images 1005 of FIG. 10) is accessed.

[0230] At block 1610, a plurality of classifications for the first plurality of training images is determined, each respective classification of the plurality of classifications indicating a respective model of a user interface depicted in a respective image.

[0231] At block 1615, a first machine learning model (e.g., interface classification model 1035 of FIG. 10) is trained, based on the first plurality of training images and the plurality of classifications, to predict user interface models in captured images.

[0232] FIG. 17 depicts an example inferencing device 1700 configured to perform various aspects of the present disclosure, according to some embodiments disclosed herein. Although depicted as a physical device, in embodiments, the inferencing device 1700 may be implemented using virtual device(s), and / or across a number of devices (e.g., in a cloudenvironment). In one embodiment, the inferencing device 1700 corresponds to any element or aspect of the system 100 (depicted in FIGS. 1-2), the change detection system 720 of FIG. 7 and / or the interface classifier system 725 of FIG. 7.

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

[0234] In some embodiments, I / O devices 1735 (such as keyboards, monitors, etc.) are connected via the I / O interface(s) 1720. Further, via the network interface 1725, the inferencing device 1700 can be communicatively coupled with one or more other devices and components (e.g., via a network, which may include the Internet, local network(s), and the like). As illustrated, the CPU 1705, memory 1710, storage 1715, network interface(s) 1725, and I / O interface(s) 1720 are communicatively coupled by one or more buses 1730.

[0235] In the illustrated embodiment, the memory 1710 includes a preprocessing component 1750, a change point component 1755, a presence component 1760, an interface component 1765, and a label component 1770, which may perform one or more embodiments discussed above. Although depicted as discrete components for conceptual clarity, in embodiments, the operations of the depicted components (and others not illustrated) may be combined or distributed across any number of components. Further, although depicted as software residing in memory 1710, in embodiments, the operations of the depicted components (and others not illustrated) may be implemented using hardware, software, or a combination of hardware and software.

[0236] In some embodiments, the preprocessing component 1750 can be used to perform various preprocessing operations, if needed, on various input data. For example, the preprocessing component 1750 may correspond to the preprocessing component 810 of FIG. 8 and / or the preprocessing component 920 of FIG. 9. In some embodiments, the preprocessing component 1750 can apply operations such as rolling average smoothing to input therapy data. In some embodiments, the preprocessing component 1750 can apply operations such asresizing to input user images. Generally, the particular operations of the preprocessing component 1750 (if any) may vary depending on the particular implementation.

[0237] In some embodiments, the change point component 1755 can be used to perform change point detection, as discussed above. For example, the change point component 1755 may correspond to the change detection component 815 of FIG. 8. In some embodiments, the change point component 1755 uses one or more machine learning techniques (e.g., unsupervised machine learning models) to identify potential change points in therapy data, where each change point corresponds to a time when the corresponding user potentially changed to a new user interface for their respiratory therapy.

[0238] In some embodiments, the presence component 1760 can be used to determine whether input images depict user interfaces, as discussed above. For example, the presence component 1760 may correspond to the presence component 925 FIG. 9 and may use machine learning models (e.g., the presence model 1030 of FIG. 10) to determine whether input images (e.g., captured by users) depict respiratory therapy user interfaces.

[0239] In some embodiments, the interface component 1765 can be used to classify the user interface(s) depicted in images based on the model(s) of the depicted interface(s), as discussed above. For example, the interface component 1765 may correspond to the interface component 930 FIG. 9 and may use machine learning models (e.g., the interface classification model 1035 of FIG. 10) to determine which user interface model(s) are depicted in input images.

[0240] In some embodiments, the label component 1770 may be used to label various data based on the corresponding output of machine learning models, as discussed above. For example, the label component 1770 may correspond to the label component 820 of FIG. 8 and / or the label component 935 of FIG. 9. In some embodiments (such as in a change point detection embodiment), the label component 1770 may evaluate data such as the change point confidence or probability, fractional change information, other user information such as their age, and the like in order to determine whether a potential change point (identified by the change point component 1755) is likely a true or real change point. In some embodiments, as discussed above, the label component 1770 can use one or more machine learning models (e.g., binary classifiers) to identify such valid changes. In some embodiments (such as in an interface classification embodiment), the label component 1770 may evaluate data such as the confidence of the interface classification model (generated by the interface component 1765) and / or the input or confirmation from a user in order to determine which interface model(s) are depicted in input images.

[0241] In the illustrated example, the storage 1715 includes therapy data 1775 (which may correspond to therapy data 715 of FIG. 7 and / or therapy data 805 of FIG. 8). The storage 1715 also includes user data 1780 (which may correspond to user data 830 of FIG. 8, order data 835 of FIG. 8, and the like), and one or more machine learning models 1785 (which may correspond to the change point detection model used to identify change points, the binary classification model used to classify or confirm potential change points, the presence model 1030 of FIG. 10, and / or the interface classification model 1035 of FIG. 10). Although depicted as residing in storage 1715, the depicted data may be stored in any suitable location, including memory 1710.

[0242] Generally, the depicted components (and others not depicted) in memory 1710 may evaluate and / or use the depicted data (and others not depicted) in storage 1715 to provide therapy data-based detection of user interface swaps or changes and / or image-based identification / classification of user interfaces, as discussed above.

[0243] FIG. 18 depicts an example training device 1800 configured to perform various aspects of the present disclosure, according to some embodiments disclosed herein. Although depicted as a physical device, in embodiments, the training device 1800 may be implemented using virtual device(s), and / or across a number of devices (e.g., in a cloud environment). In one embodiment, the training device 1800 corresponds to any element or aspect of the system 100 (depicted in FIGS. 1-2), the change detection system 720 of FIG. 7 and / or the interface classifier system 725 of FIG. 7. In some embodiments, the training device 1800 is an independent system that performs training of models, which are then provided to the inferencing system(s).

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

[0245] In some embodiments, I / O devices 1835 (such as keyboards, monitors, etc.) are connected via the I / O interface(s) 1820. Further, via the network interface 1825, the trainingdevice 1800 can be communicatively coupled with one or more other devices and components (e.g., via a network, which may include the Internet, local network(s), and the like). As illustrated, the CPU 1805, memory 1810, storage 1815, network interface(s) 1825, and I / O interface(s) 1820 are communicatively coupled by one or more buses 1830.

[0246] In the illustrated embodiment, the memory 1810 includes a preprocessing component 1850, an augmentation component 1855, a training component 1860, and a validation component 1865, which may perform one or more embodiments discussed above. Although depicted as discrete components for conceptual clarity, in embodiments, the operations of the depicted components (and others not illustrated) may be combined or distributed across any number of components. Further, although depicted as software residing in memory 1810, in embodiments, the operations of the depicted components (and others not illustrated) may be implemented using hardware, software, or a combination of hardware and software.

[0247] In some embodiments, the preprocessing component 1850 can be used to perform various preprocessing operations, if needed, on various training data. For example, the preprocessing component 1850 may apply operations such as determining average values for therapy data (e.g., to train a binary classifier to identify change points), to apply operations such as resizing to input user images to train image / interface classification models, and the like. Generally, the particular operations of the preprocessing component 1850 (if any) may vary depending on the particular implementation.

[0248] In some embodiments, the augmentation component 1855 can be used to generate synthetic training data using various augmentations or transformations, as discussed above. For example, the augmentation component 1855 may correspond to the augmentation component 1015 of FIG. 10. In some embodiments, the augmentation component 1855 uses transformations such as skewing, shearing, stretching, zooming, rotating, or otherwise modifying training images to improve training, as discussed above. In some embodiments, the augmentation component 1855 can selectively apply some augmentations based on interface commonality / distribution in the real world, as discussed above.

[0249] In some embodiments, the training component 1860 can be used to train machine learning models using training data, as discussed above. For example, the training component 1860 may correspond to the training component 1025 FIG. 10 and may train machine learning models (e.g., the presence model 1030 of FIG. 10, the interface classification model 1035 of FIG. 10, the binary classifier used by the label component 820 of FIG. 8, and the like).

[0250] In some embodiments, the validation component 1865 can be used to validate thatthe various system components are operating accurately, as discussed above. For example, the validation component 1865 may correspond to the validation component 825 FIG. 8 and may evaluate the operations of deployed components or systems, such as the change point detection models, image classification models, and the like in order to confirm that they are operating accurately.

[0251] In the illustrated example, the storage 1815 includes training data 1870 (which may correspond to interface images 1005 of FIG. 10, non-interface images 1010 of FIG. 10, and / or other data used to train binary classifiers for change point detection). The storage 1815 also includes user data 1875 (which may correspond to user data 830 of FIG. 8), order data 1880 (which may correspond to order data 835 of FIG. 8), and one or more machine learning models 1885 (which may correspond to the change point detection model used to identify change points, the binary classification model used to classify or confirm potential change points, the presence model 1030 of FIG. 10, and / or the interface classification model 1035 of FIG. 10). Although depicted as residing in storage 1815, the depicted data may be stored in any suitable location, including memory 1810.

[0252] Generally, the depicted components (and others not depicted) in memory 1810 may evaluate and / or use the depicted data (and others not depicted) in storage 1815 to train machine learning models for therapy data-based detection of user interface swaps or changes and / or image -based identification / classification of user interfaces, as discussed above.Example Clauses

[0253] Clause 1: A method, comprising: accessing respiratory therapy data of a user of a flow generator, the respiratory therapy data comprising a time series of records; identifying a change point by processing the respiratory therapy data using a machine learning model; generating a confidence measure indicating a probability that the user switched from a first user interface for the flow generator to a second user interface for the flow generator at the change point; and generating, based on the confidence measure, a label indicating that the user switched to the second user interface at the change point.

[0254] Clause 2: A method according to Clause 1, wherein the respiratory therapy data comprises at least one of: (i) usage duration of the flow generator, (ii) a number of times the user donned and doffed a user interface of the flow generator, (iii) an amount of air leak of the flow generator, (iv) an amount of air pressure of the flow generator, or (v) an apnea-hypopnea index (AHI) of the user.

[0255] Clause 3: A method according to Clause 1 or 2, further comprising, prior to identifying the change point, applying a smoothing operation to the respiratory therapy datausing moving averages.Clause 4: A method according to any of Clauses 1-3, wherein identifying the change point comprises processing a sliding window of the respiratory therapy data using the machine learning model.

[0256] Clause 5: A method according to any of Clauses 1-4, wherein generating the confidence measure comprises processing the respiratory therapy data using the machine learning model.

[0257] Clause 6: A method according to any of Clauses 1-5, wherein generating the confidence measure comprises: determining one or more pre-change point averages for a subset of the respiratory therapy data from prior to the change point; determining one or more postchange point averages for a subset of the respiratory therapy data from subsequent to the change point; and quantifying fractional changes between the one or more pre-change point averages and the one or more post-change point averages.

[0258] Clause 7: A method according to any of Clauses 1-6, wherein generating the label based on the confidence measure comprises comparing the confidence measure to one or more thresholds.

[0259] Clause 8: A method according to any of Clauses 1-7, wherein generating the label based on the confidence measure comprises processing the confidence measure using a binary classifier.

[0260] Clause 9: A method according to Clause 8, wherein generating the label further comprises using the binary classifier to process one or more of (i) an age of the user, (ii) a pressure mode of the flow generator, or (iii) at least a subset of the respiratory therapy data.

[0261] Clause 10: A method according to any of Clauses 1-9, further comprising, in response to the label indicating that the user switched to the second user interface, prompting the user to identify the second user interface.

[0262] Clause 11 : A method according to Clause 10, wherein prompting the user to identify the second user interface comprises requesting that the user to capture an image of their user interface, the method further comprising processing the image with a trained image classifier to identify the second user interface.

[0263] Clause 12: A method, comprising: accessing an image captured, by a user of a flow generator, to identify a user interface of the flow generator; generating a first classification of the user interface of the flow generator by processing the image using a first machine learning model, the first classification indicating a model of the user interface; determining a first confidence measure of the first classification; and generating a label indicating the firstclassification of the user interface based at least in part on the first confidence measure.

[0264] Clause 13: A method according to Clause 12, further comprising generating an interface presence measure by processing the image using a second machine learning model, wherein the interface presence measure indicates whether the image depicts a user interface.

[0265] Clause 14: A method according to Clause 13, wherein generating the first classification is performed in response to determining that the interface presence measure satisfies one or more criteria.

[0266] Clause 15: A method according to any one of Clauses 12-14, further comprising: outputting the first classification in response to determining that the first confidence measure is a highest confidence measure generated by the first machine learning model based on the image; and requesting confirmation that the first classification is correct for the user interface.

[0267] Clause 16: A method according to Clause 15, further comprising: generating a second classification with a second confidence measure by processing the image using the first machine learning model; outputting the second classification in response to determining that the second confidence measure is a second highest confidence measure generated by the first machine learning model based on the image; and requesting confirmation that the second classification is correct for the user interface.

[0268] Clause 17: A method according to any one of Clauses 15-16, wherein generating the label indicating the first classification is performed in response to receiving confirmation of the first classification.

[0269] Clause 18: A method according to any one of Clauses 12-17, wherein generating the label indicating the first classification is performed in response to determining that the first confidence measure satisfies one or more criteria.

[0270] Clause 19: A method according to any one of Clauses 12-18, wherein the first machine learning model was trained using transfer learning, comprising: accessing a trained machine learning model; accessing one or more labeled training images of user interfaces; and updating one or more parameters of one or more layers of the trained machine learning model based on the one or more labeled training images.

[0271] Clause 20: A method according to any one of Clauses 12-19, further comprising, prior to accessing the image: predicting, based on processing respiratory therapy data of the user using a change detection model, that the user switched from a first user interface to a second user interface; and requesting that the user capture the image of the user interface of the flow generator.

[0272] Clause 23: A method, comprising: accessing a first plurality of training imagesdepicting user interfaces for flow generators; determining a plurality of classifications for the first plurality of training images, each respective classification of the plurality of classifications indicating a respective model of a user interface depicted in a respective image; and training a first machine learning model, based on the first plurality of training images and the plurality of classifications, to predict user interface models in captured images.

[0273] Clause 24: A method according to Clause 23, wherein training the first machine learning model comprises using transfer learning, comprising: accessing a trained machine learning model; and updating one or more parameters of one or more layers of the trained machine learning model based on the first plurality of training images.

[0274] Clause 25: A method according to Clause 23 or Clause 24, further comprising: generating a plurality of synthetic training images by applying a plurality of transformations to the first plurality of training images; and training the first machine learning model based further on the plurality of synthetic training images.

[0275] Clause 26: A method according to any one of Clauses 23-25, further comprising: accessing a second plurality of training images that do not depict user interfaces for flow generators; and training a second machine learning model, based on the second plurality of training images, to predict whether captured images depict one or more user interfaces.

[0276] Clause 27: A method according to any one of Clauses 23-26, further comprising: determining a distribution of user interface models in use by respiratory therapy patients; and training the first machine learning model based at least in part on the distribution of user interface models.

[0277] Clause 28: A method according to Clause 27, wherein training the first machine learning model based at least in part on the distribution of user interface models comprises assigning training weights to each training image of the first plurality of training images based on the distribution of user interface models.

[0278] Clause 29: A method according to any one of Clauses 27-28, wherein training the first machine learning model based at least in part on the distribution of user interface models comprises generating additional versions of one or more training images of the first plurality of training images based on the distribution of user interface models.

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

[0280] Clause 31: A system, comprising means for performing a method in accordancewith any one of Clauses 1-29.

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

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

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

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

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

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

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

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

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

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

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

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

Claims

CLAIMSWHAT IS CLAIMED IS:

1. A method, comprising: accessing respiratory therapy data of a user of a flow generator, the respiratory therapy data comprising a time series of records; identifying a change point by processing the respiratory therapy data using a machine learning model; generating a confidence measure indicating a probability that the user switched from a first user interface for the flow generator to a second user interface for the flow generator at the change point; and generating, based on the confidence measure, a label indicating that the user switched to the second user interface at the change point.

2. The method of claim 1, wherein the respiratory therapy data comprises at least one of: (i) usage duration of the flow generator, (ii) a number of times the user donned and doffed a user interface of the flow generator, (iii) an amount of air leak of the flow generator, (iv) an amount of air pressure of the flow generator, or (v) an apnea-hypopnea index (AHI) of the user.

3. The method of claim 1, further comprising, prior to identifying the change point, applying a smoothing operation to the respiratory therapy data using moving averages.

4. The method of claim 1, wherein identifying the change point comprises processing a sliding window of the respiratory therapy data using the machine learning model.

5. The method of claim 1, wherein generating the confidence measure comprises processing the respiratory therapy data using the machine learning model.

6. The method of claim 1, wherein generating the confidence measure comprises: determining one or more pre-change point averages for a subset of the respiratory therapy data from prior to the change point; determining one or more post-change point averages for a subset of the respiratory therapy data from subsequent to the change point; andquantifying fractional changes between the one or more pre-change point averages and the one or more post-change point averages.

7. The method of claim 1, wherein generating the label based on the confidence measure comprises comparing the confidence measure to one or more thresholds.

8. The method of claim 1, wherein generating the label based on the confidence measure comprises processing the confidence measure using a binary classifier.

9. The method of claim 8, wherein generating the label further comprises using the binary classifier to process one or more of (i) an age of the user, (ii) a pressure mode of the flow generator, or (iii) at least a subset of the respiratory therapy data.

10. The method of claim 1, further comprising, in response to the label indicating that the user switched to the second user interface, prompting the user to identify the second user interface.

11. The method of claim 10, wherein prompting the user to identify the second user interface comprises requesting that the user to capture an image of their user interface, the method further comprising processing the image with a trained image classifier to identify the second user interface.

12. A non-transitory computer-readable medium comprising computer-executable instructions that, when executed by one or more processors of a processing system, cause the processing system to perform an operation comprising: accessing respiratory therapy data of a user of a flow generator, the respiratory therapy data comprising a time series of records; identifying a change point by processing the respiratory therapy data using a machine learning model; generating a confidence measure indicating a probability that the user switched from a first user interface for the flow generator to a second user interface for the flow generator at the change point; and generating, based on the confidence measure, a label indicating that the user switched to the second user interface at the change point.

13. The non-transitory computer-readable medium of claim 12, wherein the respiratory therapy data comprises at least one of: (i) usage duration of the flow generator, (ii) a number of times the user donned and doffed a user interface of the flow generator, (iii) an amount of air leak of the flow generator, (iv) an amount of air pressure of the flow generator, or (v) an apnea-hypopnea index (AHI) of the user.

14. The non-transitory computer-readable medium of claim 12, wherein generating the confidence measure comprises: determining one or more pre-change point averages for a subset of the respiratory therapy data from prior to the change point; determining one or more post-change point averages for a subset of the respiratory therapy data from subsequent to the change point; and quantifying fractional changes between the one or more pre-change point averages and the one or more post-change point averages.

15. The non-transitory computer-readable medium of claim 12, the operation further comprising, in response to the label indicating that the user switched to the second user interface, prompting the user to identify the second user interface.

16. The non-transitory computer-readable medium of claim 15, wherein prompting the user to identify the second user interface comprises requesting that the user to capture an image of their user interface, the operation further comprising processing the image with a trained image classifier to identify the second user interface.

17. A system, comprising: a memory comprising computer-executable instructions; and one or more processors configured to execute the computer-executable instructions and cause the system to perform an operation comprising: accessing respiratory therapy data of a user of a flow generator, the respiratory therapy data comprising a time series of records; identifying a change point by processing the respiratory therapy data using a machine learning model;generating a confidence measure indicating a probability that the user switched from a first user interface for the flow generator to a second user interface for the flow generator at the change point; and generating, based on the confidence measure, a label indicating that the user switched to the second user interface at the change point.

18. The system of claim 17, wherein the respiratory therapy data comprises at least one of: (i) usage duration of the flow generator, (ii) a number of times the user donned and doffed a user interface of the flow generator, (iii) an amount of air leak of the flow generator, (iv) an amount of air pressure of the flow generator, or (v) an apnea-hypopnea index (AHI) of the user.

19. The system of claim 17, wherein generating the confidence measure comprises: determining one or more pre-change point averages for a subset of the respiratory therapy data from prior to the change point; determining one or more post-change point averages for a subset of the respiratory therapy data from subsequent to the change point; and quantifying fractional changes between the one or more pre-change point averages and the one or more post-change point averages.

20. The system of claim 17, the operation further comprising: in response to the label indicating that the user switched to the second user interface, prompting the user to identify the second user interface, wherein prompting the user to identify the second user interface comprises requesting that the user to capture an image of their user interface; and processing the image with a trained image classifier to identify the second user interface.

Images