System and method for determining health status by a device local to a respiratory system user

Abstract

The method and system determine a health condition from health data of a user of a respiratory system or operational conditions of the respiratory system. The health data or operational data is collected by a processing device local to the user. The method and system include analyzing the collected data to initially determine a potential health condition associated with the user or a potential operational fault condition of the respiratory system. In response to the determination of the potential condition, a command is transmitted for reception by a remote server. The command is for providing a health assessment module including instructions for analyzing the health data or an operational fault assessment module including instructions for analyzing the operational data to further evaluate the initially determined potential condition. The health assessment module or operational fault assessment module is received by the processing device, which is updated to store the assessment module as executable instructions for analyzing the health data or operational data to verify the initial determination.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 058,775, filed July 30, 2020, the disclosure of which is incorporated herein by reference in its entirety.

[0002] The present disclosure relates generally to systems and methods for determining the health status of a user using a respiratory system, and more particularly to systems and methods for determining the health status of a user from health data collected, stored, and analyzed on a device local to the user. [Background technology]

[0003] Many people suffer from sleep-related and / or breathing disorders, such as sleep-disordered breathing (SDB), including periodic limb movement disorder (PLMD), restless legs syndrome (RLS), obstructive sleep apnea (OSA), central sleep apnea (CSA), and other types of apnea, including mixed apneas and hypopneas; respiratory effort-related arousals (RERA); Cheyne-Stokes respiration (CSR); respiratory failure; obesity hyperventilation syndrome (OHS); chronic obstructive pulmonary disease (COPD); neuromuscular disorders (NMD); rapid eye movement (REM) behavior disorder (also known as RBD); dream actout (DEB); hypertension; diabetes; stroke; insomnia; and chest wall disorders. Summary of the Invention [Problem to be solved by the invention]

[0004] Many of these sleep-related disorders can be treated using respiratory therapy systems, which deliver pressurized air to a user's airways overnight and collect various data about the user and the system's operation. Users may be concerned about the privacy of collected personal data, including how their health data is handled. Some users may not begin using or discontinue using a respiratory therapy system unless they are assured that their data will remain private or are shown the benefits of using the respiratory therapy system. The present disclosure is directed to solving these problems and others. [Means for solving the problem]

[0005] According to some implementations of the present disclosure, a method for determining one or more health conditions from health data of a user of a respiratory system includes analyzing health data collected by and stored in memory of one or more processing devices local to the user. The method includes analyzing the collected health data of the user to make an initial determination of one or more potential health conditions associated with the user of the respiratory system. In response to determining the one or more potential health conditions associated with the user, the method includes transmitting, for reception by a remote server, commands to provide one or more health assessment modules including instructions for analyzing the health data and further evaluating the initially determined one or more identified potential health conditions. In response to providing the one or more health assessment modules by the remote server, receiving the one or more health assessment modules at one or more processing devices local to the user. The one or more processing devices local to the user are updated to store the one or more health assessment modules as executable instructions. One or more of the received health assessment modules are executed to analyze the health data and verify the initial determination that the user has one or more potential health conditions.

[0006] According to some implementations, a system includes a control system including one or more processors and a memory having machine-readable instructions stored thereon. The control system is coupled to the memory. A method for determining one or more health conditions from health data of a user of a respiratory system is performed when the machine-executable instructions in the memory are executed by at least one of the one or more processors of the control system.

[0007] According to some implementations, a system for determining one or more health conditions from health data of a user of a respiratory system includes a control system configured to implement a method. The method includes analyzing collected health data of the user by a processing device local to the user and making an initial determination of one or more potential health conditions associated with the user of the respiratory system. In response to determining the one or more potential health conditions associated with the user, the method includes transmitting, for reception by a remote server, commands to provide one or more health assessment modules including instructions for analyzing the health data and further evaluating the initially determined one or more identified potential health conditions. In response to providing the one or more health assessment modules by the remote server, receiving the one or more health assessment modules at a processing device local to the user. The processing device local to the user is updated to store the one or more health assessment modules as executable instructions. One or more of the received health assessment modules is executed to analyze the health data and verify the initial determination that the user has one or more potential health conditions.

[0008] According to some implementations, a computer program product includes instructions that, when executed by a computer, cause the computer to perform a method for determining one or more health conditions from health data of a user of a respiratory system. The method includes analyzing health data collected by and stored in memory of one or more processing devices local to the user to make an initial determination of one or more potential health conditions associated with the user of the respiratory system. In response to determining the one or more potential health conditions associated with the user, the method includes transmitting, for reception by a remote server, commands to provide one or more health assessment modules including instructions for analyzing the health data to further evaluate the initially determined one or more identified potential health conditions. In response to providing the one or more health assessment modules by the remote server, receiving the one or more health assessment modules at one or more processing devices local to the user. The one or more processing devices local to the user are updated to store the one or more health assessment modules as executable instructions. One or more of the received health assessment modules are executed to analyze the health data and verify the initial determination that the user has one or more potential health conditions. According to some implementations, the computer program product is a non-transitory computer-readable medium.

[0009] According to some implementations of the present disclosure, a method for determining one or more operational fault conditions from operational data of a respiratory system includes analyzing operational data collected by and stored in memory of one or more processing devices local to a user of the respiratory system. The method includes analyzing the operational data of the respiratory system to make an initial determination of one or more potential operational fault conditions associated with the respiratory system. The operational data is collected by the one or more processing devices local to the user. In response to determining the one or more potential operational fault conditions associated with the respiratory system, the method includes transmitting, for reception by a remote server, commands to provide one or more operational fault assessment modules including instructions for analyzing the operational data to further evaluate the initially determined one or more identified potential operational fault conditions. In response to providing the one or more operational fault assessment modules by the remote server, receiving the one or more operational fault assessment modules at the one or more processing devices local to the user. The one or more processing devices local to the user are updated to store the one or more operational fault assessment modules as executable instructions. Executing one or more of the received operational fault assessment modules to analyze the operational data and verify the initial determination that the respiratory system has one or more potential operational fault conditions.

[0010] According to some implementations, a system includes a control system including one or more processors and a memory having machine-readable instructions stored thereon. The control system is coupled to the memory. A method for determining one or more operational fault conditions from operational data of a respiratory system is performed when the machine-executable instructions in the memory are executed by at least one of the one or more processors of the control system.

[0011] According to some implementations, a system for determining one or more operational fault conditions from operational data of a respiratory system includes a control system configured to implement a method. The method includes analyzing operational data of the respiratory system to make an initial determination of one or more potential operational fault conditions associated with the respiratory system. The operational data is collected by one or more processing devices local to a user. In response to determining the one or more potential operational fault conditions associated with the respiratory system, the method includes transmitting, for reception by a remote server, commands to provide one or more operational fault assessment modules including instructions for analyzing the operational data to further evaluate the initially determined one or more identified potential operational fault conditions. In response to providing the one or more operational fault assessment modules by the remote server, receiving the one or more operational fault assessment modules at the one or more processing devices local to the user. The one or more processing devices local to the user are updated to store the one or more operational fault assessment modules as executable instructions. One or more of the received operational fault assessment modules are executed to analyze the operational data and verify the initial determination that the respiratory system has one or more potential operational fault conditions.

[0012] According to some implementations, a computer program product includes instructions that, when executed by a computer, cause the computer to perform a method for determining one or more operational fault conditions from operational data of a respiratory system. The method includes analyzing operations collected by and stored in memory of one or more processing devices local to a user to make an initial determination of one or more potential operational fault conditions associated with the respiratory system. In response to determining the one or more potential operational fault conditions associated with the respiratory system, the method includes transmitting, for reception by a remote server, commands to provide one or more operational fault modules including instructions for analyzing the operational data to further evaluate the initially determined one or more identified potential operational fault conditions. In response to providing the one or more operational fault evaluation modules by the remote server, receiving the one or more operational fault evaluation modules at one or more processing devices local to the user. The one or more processing devices local to the user are updated to store the one or more operational fault evaluation modules as executable instructions. Executing one or more of the received operational fault evaluation modules to analyze the operational data and verify the initial determination that the user has one or more potential operational fault conditions. According to some implementations, the computer program product is a non-transitory computer-readable medium.

[0013] The above summary is not intended to describe each implementation or every aspect of the present disclosure. Additional features and benefits of the present disclosure will be apparent from the following detailed description and drawings. [Brief explanation of the drawings]

[0014] [Figure 1A] FIG. 1 is a functional block diagram of a system configuration according to some implementations of the present disclosure. [Figure 1B] FIG. 1 is a functional block diagram of a system configuration according to some implementations of the present disclosure. [Figure 2]1B is a perspective view of at least a portion of the system of FIG. 1A, a user, and a bed companion, according to some implementations of the present disclosure. FIG. [Figure 3] FIG. 1 illustrates an example timeline of a sleep session for collecting health data, according to some implementations of the present disclosure. [Figure 4] FIG. 4 illustrates an example hypnogram associated with analysis of health data collected during the sleep session of FIG. 3, according to some implementations of the present disclosure. [Figure 5] FIG. 1 is a process flow diagram of a method for determining the health status of a user of a respiratory system from health data collected, stored, and analyzed on a device local to the user, according to some implementations of the present disclosure. [Figure 6] FIG. 1 is a process flow diagram of a method for determining operational fault conditions for a user of a respiratory system from operational data collected, stored, and analyzed on a device local to the user, according to some implementations of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0015] 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 are herein described in detail. It is to be understood, however, that it is not intended to limit the disclosure to the particular forms disclosed, but rather, the 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.

[0016] Many people suffer from sleep-related and / or breathing-related disorders, such as sleep-disordered breathing (SDB), including periodic limb movement disorder (PLMD), restless legs syndrome (RLS), obstructive sleep apnea (OSA), central sleep apnea (CSA), and other types of apnea, including mixed apneas and hypopneas; respiratory effort-related arousals (RERA); Cheyne-Stokes respiration (CSR); respiratory failure; obesity hyperventilation syndrome (OHS); chronic obstructive pulmonary disease (COPD); neuromuscular disorders (NMD); rapid eye movement (REM) behavior disorder (also known as RBD); dream actout (DEB); hypertension; diabetes; stroke; insomnia; and chest wall disorders.

[0017] Obstructive sleep apnea (OSA) is a form of sleep-disordered breathing (SDB) characterized by events such as obstruction or failure of the upper airway during sleep due to an abnormally small upper airway in combination with the normal loss of muscle tone in the areas of the tongue, soft palate, and posterior oropharynx.

[0018] Central sleep apnea (CSA) is another form of SDB that occurs when the brain temporarily stops sending signals to the muscles that control breathing. More generally, apnea generally refers to the cessation of breathing or respiratory function caused by air blockage. Typically, individuals stop breathing for about 15 to about 30 seconds during an obstructive sleep apnea event. Mixed sleep apnea is another form of SDB that is a combination of OSA and CSA.

[0019] Other types of apnea include hypopnea, hyperpnea, and hypercapnia. Hypopnea is generally characterized by slow or shallow breathing caused by narrowing of the airway rather than airway obstruction. Hyperpnea is generally characterized by an increase in the depth and / or rate of breathing. Hypercapnia is generally characterized by a sudden or excessive amount of carbon dioxide in the bloodstream, usually resulting from insufficient breathing.

[0020] Respiratory effort-related arousal (RERA) events are typically characterized by increased respiratory effort for 10 seconds or more leading to arousal from sleep and do not meet the criteria for an apnea or hypopnea event. In 1999, an AASM task force defined RERA as "a series of breaths characterized by increased respiratory effort leading to arousal from sleep but not meeting the criteria for an apnea or hypopnea." These events must meet both of the following criteria: 1. A pattern of gradually increasing negative esophageal pressure terminated by an abrupt change in pressure to a lower negative pressure level and arousal; and 2. The event must last 10 seconds or more. In 2000, a study conducted at New York University School of Medicine titled "Non-Invasive Detection of Respiratory Effort-Related Arousals (RERAs) by a Nasal Cannula / Pressure Transducer System" and published in Sleep, Vol. 23, No. 6, pp. 763-771, demonstrated that a nasal cannula / pressure transducer system was suitable and reliable for detecting RERAs. A RERA detector may be based on an actual flow signal derived from a respiratory therapy (e.g., PAP) device. For example, based on the flow signal, a measure of flow limitation may be determined. A measure of arousal may then be derived as a function of the measure of flow limitation and the measure of ventilation surge. Such methods are described in International Publication No. WO 2008 / 138040, U.S. Pat. No. 9,358,353, U.S. Pat. No. 10,549,053, and U.S. Patent Application Publication No. 2020 / 0197640, each of which is incorporated herein by reference in its entirety.

[0021] Cheyne-Stokes respiration (CSR) is another form of SDB. CSR is a disorder of the patient's respiratory control that results in alternating periods of waxing and waning ventilation, known as CSR cycles. CSR is characterized by repeated deoxygenation and reoxygenation of arterial blood.

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

[0023] Chronic obstructive pulmonary disease (COPD) encompasses any of a group of lower respiratory tract disorders that share certain characteristics, such as increased resistance to air movement, a prolonged expiratory phase of breathing, and loss of normal lung elasticity.

[0024] Neuromuscular disorders (NMDs) encompass a number of diseases and illnesses that impair muscle function directly through intrinsic muscle pathology or indirectly through neuropathology. Chest wall disorders are a group of thoracic deformities that result in an inefficient connection between the respiratory muscles and the rib cage.

[0025] These and other disorders are characterized by specific events that occur during an individual's sleep (e.g., snoring, apnea, hypopnea, restless legs, sleep disturbances, choking, increased heart rate, difficulty breathing, asthma attacks, epileptic episodes, seizures, or any combination thereof).

[0026] 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 a user during a sleep session by the total number of hours of sleep in that sleep session. An event may be, for example, a pause in breathing lasting at least 10 seconds. An AHI of less than 5 is considered normal. An AHI of 5 to less than 15 is considered to indicate mild sleep apnea. An AHI of 15 to less than 30 is considered to indicate moderate sleep apnea. An AHI of 30 or greater is considered to indicate severe sleep apnea. In children, an AHI 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 saturation to indicate the severity of obstructive sleep apnea.

[0027] 1A and 1B, functional block diagrams of a system 100 are shown, according to some implementations of the present disclosure. The system 100 is for delivering pressurized air to a user's airway during a sleep session using a respiratory treatment system and for changing pressure settings of the respiratory treatment system. 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 optionally further includes a respiratory system 120. In some implementations, the system 100 is optionally connected to a remote server system 190 via a computer network (see, for example, FIG. 1B), allowing for the transmission of data or instructions to the remote server 190 and the reception of assessment modules, such as a health assessment module, from the remote server.

[0028] The control system 110 includes one or more processors 112 (hereinafter processors 112). The control system 110 is generally used to control (e.g., operate) various components of the system 100 and / or analyze data acquired and / or generated by the components of the system 100. In some implementations, it is contemplated that health data of a user of the system 100 is collected, the collected data is stored and analyzed locally (e.g., in the respiratory device 122, the user device 172, the memory device 114, the control system 110, and / or the processor 112, which are local to the user), and an underlying health condition of the user associated with the collected data is determined. The processor 112 may be a general-purpose or special-purpose processor or microprocessor. While one processor 112 is shown in FIG. 1A, the control system 110 may include any suitable number of processors (e.g., one processor, two processors, five processors, ten processors, etc.), which may reside in a single housing or may be located remotely from one another. The control system 110 may, for example, be coupled to and / or located within the housing of the user device 170 and / or the housing of one or more sensors 130. The control system 110 may be centralized (in one such housing) or distributed (in two or more such housings that are physically separate). In such implementations that include two or more housings housing the control system 110, such housings may be located proximate to one another and / or may be located remotely.

[0029] In some implementations, control system 110 (or any other control system) or a portion of control system 110, such as processor 112 (or any other processor of any other control system or part of any other control system), may be used to perform one or more steps of any of the methods described and / or claimed herein.

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

[0031] In some implementations, the memory device 114 (FIG. 1A) stores a user profile associated with the user. The user profile may include, for example, health-related data, such as 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 previous sleep sessions), or any combination thereof. The demographic information may include, for example, information indicative of the user's age, the user's gender, the user's race, family history (e.g., family history of insomnia or sleep apnea), the user's employment status, the user's education status, the user's socioeconomic status, or any combination thereof. The medical information may include, for example, information indicative of one or more current or past medical conditions associated with the user, medication use by the user, or both. The medical information data may further include, for example, an Epworth Sleepiness Score (ESS), 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 may include, for example, information indicative of a self-reported subjective sleep score (poor, fair, good, etc.), the user's self-reported subjective stress level, the user's self-reported subjective fatigue level, the user's self-reported subjective health status, recent life events experienced by the user, or any combination thereof.

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

[0033] As noted above, in some implementations, system 100 optionally includes a respiratory system 120 (also referred to as a respiratory treatment system or respiratory pressure treatment system). Respiratory system 120 may include a respiratory device 122 (also referred to as a respiratory treatment device or respiratory pressure treatment device), a user interface 124 (also referred to as a mask or patient interface), a conduit 126 (also referred to as a tubing or air circuit), a display device 128, a humidification tank 129, or a combination thereof. In some implementations, control system 110, memory device 114, display device 128, one or more of sensors 130, and humidification tank 129 are part of respiratory device 122. Respiratory pressure treatment refers to the application of a supply of air to the entrance of a user's airways at a controlled target pressure that is nominally positive relative to atmosphere throughout the user's respiratory cycle (as opposed to negative pressure therapies such as an iron lung or thoracostomy). The respiratory system 120 is generally used to treat individuals suffering from one or more sleep-related breathing disorders (e.g., obstructive sleep apnea, central sleep apnea, mixed sleep apnea), other breathing disorders such as COPD, or other disorders that lead to respiratory insufficiency and can manifest both during sleep and wakefulness.

[0034] Respiratory device 122 is typically used to generate pressurized air delivered to a user (e.g., using one or more motors driving one or more compressors). In some implementations, respiratory device 122 generates a continuous, constant air pressure delivered to a user. In other implementations, respiratory 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, respiratory device 122 is configured to generate a variety of different air pressures within a predetermined range. For example, respiratory device 122 can deliver at least about 6 cm H2O, at least about 10 cm H2O, at least about 20 cm H2O, between about 6 cm H2O and about 10 cm H2O, between about 7 cm H2O and about 12 cm H2O, etc. Respiratory device 122 can also deliver pressurized air at a predetermined flow rate, e.g., between about -20 L / min and about 150 L / min, while maintaining a positive pressure (relative to ambient pressure). In some implementations, the control system 110, the memory device 114, the electronic interface 119, or any combination thereof may be coupled to and / or located within the housing of the respiratory device 122.

[0035] The user interface 124 engages a portion of the user's face and delivers pressurized air from the breathing device 122 to the user's airway to help prevent narrowing and / or obstruction of the airway during sleep. This may also increase the user's oxygen intake while sleeping. Depending on the therapy being applied, the user interface 124 may, for example, form a seal with an area or portion of the user's face to facilitate delivery of gas at a pressure sufficiently different from ambient pressure to effect therapy, e.g., approximately 10 cm H2O positive pressure relative to ambient pressure. In other forms of therapy, such as oxygen delivery, the user interface may not include a seal sufficient to facilitate delivery of a gas supply to the airway at approximately 10 cm H2O positive pressure.

[0036] In some implementations, the user interface 124 is or includes a face mask that covers the user's nose and mouth (see, e.g., FIG. 2 ). Alternatively, the user interface 124 is or includes a nasal mask that provides air to the user's nose or a nasal pillow mask that delivers air directly to the user's nostrils. The user interface 124 may include a strap assembly having multiple straps (e.g., hook-and-loop fasteners, etc.) for positioning and / or stabilizing the user interface 124 in a desired position (e.g., on the user's face) and a contoured cushion (e.g., silicone, plastic, foam, etc.) that helps provide an airtight seal between the user interface 124 and the user. In some implementations, the user interface 124 may include a connector and one or more vents. The one or more vents can be used to allow carbon dioxide and other gases exhaled by the user to escape. In other implementations, the user interface 124 includes a mouthpiece (e.g., a night guard mouthpiece shaped to fit the contours of the user's teeth, a mandibular repositioning device, etc.). In some implementations, the connector is separate from, but connectable to, the user interface 124 (and / or the conduit 126). The connector is configured to connect and fluidly couple the user interface 124 to the conduit 126.

[0037] A conduit 126 (also called an air circuit or tube) allows air to flow between two components of the respiratory system 120, such as the respiratory device 122 and the user interface 124. In some implementations, the conduit may have separate branches for inhalation and exhalation. In other implementations, a single-branch conduit is used for both inhalation and exhalation. Generally, the respiratory system 120 forms an air pathway extending between the motor of the respiratory device 122 and the user and / or the user's airways. As such, the air pathway generally includes at least the motor of the respiratory device 122, the user interface 124, and the conduit 126.

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

[0039] The display device 128 is typically used to display images, including still images, moving images, or both, and / or information, related to the respiratory device 122 and / or other components of the respiratory system 120. For example, the display device 128 may provide information regarding the status of the respiratory device 122 (e.g., whether the respiratory device 122 is on or off, the pressure of the air being delivered by the respiratory device 122, the temperature of the air being delivered by the respiratory device 122, etc.), the current date / time, personal information of the user 210, and / or other information (e.g., a sleep score or a treatment score (such as a myAir® score as described in International Publication No. WO 2016 / 061629 and U.S. Patent Application Publication No. 2017 / 0311879, each of which is incorporated by reference herein in its entirety)), etc. In some implementations, the display device 128 functions as a human-machine interface (HMI), including as an input interface a graphical user interface (GUI) configured to display images. The display device 128 may be an LED display, an OLED display, an LCD display, etc. The input interface may be, for example, a touch screen or touch-sensitive substrate, a mouse, a keyboard, or any sensor system configured to detect inputs made by a human user interacting with the breathing device 122.

[0040] The humidification tank 129 is coupled to or integrated with the respiratory device 122. The humidification tank 129 also contains a reservoir of water that can be used to humidify the pressurized air delivered from the respiratory device 122. The respiratory device 122 can include a heater to heat the water in the humidification tank 129 to humidify the pressurized air provided to the user. Additionally, in some implementations, the conduit 126 can also include a heating element (coupled to or embedded in the conduit 126) that heats the pressurized air delivered to the user. In some implementations, the respiratory treatment device 122 or the conduit 126 can include a waterless humidifier. The waterless humidifier can incorporate sensors that interface with other sensors located elsewhere in the system 100.

[0041] The breathing system 120 can be used, for example, as a mechanical ventilator or as a positive airway pressure (PAP) system, such as a continuous positive airway pressure (CPAP) system, an automatic positive airway pressure (APAP) system, a bilevel or variable positive airway pressure (BPAP or VPAP) system, or any combination thereof. A CPAP system delivers a predetermined air pressure (e.g., determined by a sleep physician) to a user. An APAP system automatically varies the air pressure delivered to a user, for example, based at least in part on respiratory data related to the user. A BPAP or VPAP system is configured to deliver a first predetermined pressure (e.g., inspiratory positive airway pressure or IPAP) and a second predetermined pressure (e.g., expiratory positive airway pressure or EPAP) that is lower than the first predetermined pressure. Ventilators such as the ResMed Elisee® 150 ventilator and ResMed VS III® ventilator may support invasive and non-invasive dependent ventilation of adult or pediatric patients suitable for treating many conditions, and in some implementations include providing volume and pressure ventilation modes with single-limb or dual-limb circuits.

[0042] Referring to FIG. 2, a portion of the system 100 (see FIGS. 1A and 1B) according to some implementations is shown. A user 210 and a bed partner 220 of the respiratory system 120 are positioned in a bed 230, lying on a mattress 232. A user interface 124 (e.g., a full-face mask) may be worn by the user 210 during a sleep session. The user interface 124 is fluidly coupled and / or connected to a respiratory device 122 via a conduit 126. The respiratory device 122 then delivers pressurized air to the user 210 via the conduit 126 and the user interface 124, increasing the air pressure in the user's 210's throat and helping to prevent the airway from closing and / or narrowing during sleep. The respiratory device 122 may include a display device 128, which may allow the user to interact with the respiratory device 122. The respiratory device 122 may further include a humidification tank 129 that stores water used to humidify the pressurized air. The respiratory device 122 may be placed on a nightstand 240 directly adjacent to the bed 230, as shown in FIG. 2, or more generally on any surface or structure generally adjacent to the bed 230 and / or user 210.

[0043] 1A , the one or more sensors 130 of system 100 include a pressure sensor 132, a flow sensor 134, a temperature sensor 136, a motion sensor 138, a microphone 140, a speaker 142, a radio frequency (RF) receiver 146, an RF transmitter 148, a camera 150, an infrared (IR) sensor 152, a photoplethysmogram (PPG) sensor 154, an electrocardiogram (ECG) sensor 156, an electroencephalogram (EEG) sensor 158, a capacitance sensor 160, a force sensor 162, a strain gauge sensor 164, an electromyogram (EMG) sensor 166, an oxygen sensor 168, an analyte sensor 174, a moisture sensor 176, a lidar (LiDAR) sensor 178, or any combination thereof. Generally, one or each of sensors 130 is configured to output or generate sensor data that is received and stored by memory device 114 or one or more other memory devices. The sensor 130 may further include an electro-oculography (EOG) sensor, a peripheral blood oxygen saturation (SpO2) sensor, a galvanic skin response (GSR) sensor, a carbon dioxide (CO2) sensor, or any combination thereof.

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

[0045] Health data may be generated using one or more sensors 130. For example, one or more sensors may be used to generate physiological data, acoustic data, respiratory system operational data, respiratory treatment duration data, user interface data, facial feature data, or combinations thereof, related to a user of the respiratory system 120 (such as user 210 in FIG. 2 ), the respiratory system 120, both the user and the respiratory system 120, or other entities, objects, activities, etc. The physiological data generated by one or more of the sensors 130 may be used by the control system 110 to determine a sleep-wake signal and one or more sleep-related parameters related to the user during a sleep session. The sleep-wake signal may indicate one or more sleep stages (sometimes referred to as sleep states) including distinct sleep stages such as sleep, wakefulness, relaxed wakefulness, microarousals, or rapid eye movement (REM) stages (which may include both typical and atypical REM stages), a first non-REM stage (often referred to as "N1"), a second non-REM stage (often referred to as "N2"), a third non-REM stage (often referred to as "N3"), or any combination thereof. Methods for determining sleep stages based on physiological data generated by one or more sensors, such as sensor 130, are described, for example, in International Publication No. 2014 / 047310, U.S. Pat. No. 10,492,720, U.S. Pat. No. 10,660,563, U.S. Patent Application Publication No. 2020 / 0337634, International Publication No. 2017 / 132726, International Publication No. 2019 / 122413, U.S. Patent Application Publication No. 2021 / 0150873, International Publication No. 2019 / 122414, and U.S. Patent Application Publication No. 2020 / 0383580, each of which is incorporated by reference in its entirety.

[0046] The sleep-wake signal may also be time-stamped to indicate the time the user gets into bed, the time the user gets out of bed, the time the user attempts to fall asleep, etc. The sleep-wake signal may be measured by one or more of the sensors 130 during a sleep session at a predetermined sampling rate, such as 1 sample per second, 1 sample per 30 seconds, or 1 sample per minute. Examples of one or more sleep-related parameters that may be determined for a user during a sleep session based at least in part on the sleep-wake signal include total time in bed, total sleep time, total wake time, sleep onset latency, wake-after-sleep parameter, sleep efficiency, fragmentation index, amount of time asleep, consistency of breathing rate, time to fall asleep, time to wake, percentage of sleep disturbances, number of movements, or any combination thereof. In some implementations, the system may also track apnea and hypopnea events and types with one or more sensors to understand an effective AHI for one or more sleep sessions (e.g., a user may use a therapeutic device for only part of a sleep session or in-bed session).

[0047] Additionally, physiological and / or acoustic data generated by one or more sensors 130 can be used to determine a respiratory signal associated with the user during a sleep session. The respiratory signal generally indicates the user's breathing or breathing during a sleep session. The respiratory signal can indicate, for example, respiratory rate, respiratory rate variability, inspiratory amplitude, expiratory amplitude, inspiratory / expiratory ratio, amplitude ratio, inspiratory / expiratory duration ratio, number of events per hour, pattern of events, pressure setting of the respiratory device 122, or any combination thereof. Events may include snoring, apnea, central apnea, obstructive apnea, mixed apnea, hypopnea, RERA, flow limitation (e.g., an event resulting in no increase in flow despite an increase in negative intrathoracic pressure indicating increased effort), mask leak (e.g., from the user interface 124), restless legs, sleep disturbances, choking, increased heart rate, heart rate variability, dyspnea, asthma attack, epileptic episode, seizure, fever, coughing, sneezing, snoring, gasping, presence of illness such as a cold or flu, elevated stress levels, etc. Events may be detected by any means known in the art, such as, for example, those described in U.S. Pat. No. 5,245,995, U.S. Pat. No. 6,502,572, WO 2018 / 050913, WO 2020 / 104465, each of which is incorporated herein by reference in its entirety.

[0048] 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., a barometric sensor) that generates sensor data indicative of a user's breathing (e.g., inhalation and / or exhalation) and / or ambient pressure of the respiratory system 120. In such implementations, the pressure sensor 132 can be coupled to or integrated with the respiratory device 122, the user interface 124, or the conduit 126. The pressure sensor 132 can be used to determine the air pressure of the respiratory device 122, the air pressure of the conduit 126, the air pressure of the user interface 124, or a combination thereof. The pressure sensor 132 can be, for example, a capacitive sensor, an electromagnetic sensor, an inductive sensor, a resistive sensor, a piezoelectric sensor, a strain gauge sensor, an optical sensor, a potentiometric sensor, or any combination thereof. In one example, the pressure sensor 132 can be used to determine the user's blood pressure.

[0049] The flow sensor 134 outputs flow 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 flow sensor 134 is used to determine the airflow rate from the respiratory device 122, the airflow rate through the conduit 126, the airflow rate through the user interface 124, or any combination thereof. In such implementations, the flow sensor 134 can be coupled to or integrated with the respiratory device 122, the user interface 124, or the conduit 126. The flow sensor 134 can be, for example, a mass flow sensor such as a rotary flow meter (e.g., a Hall effect flow meter), a turbine flow meter, an orifice flow meter, an ultrasonic flow meter, a hot wire sensor, a vortex sensor, a membrane sensor, or any combination thereof.

[0050] The temperature sensor 136 outputs temperature data that may 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 temperature data indicative of the user's core body temperature, the user's skin temperature, the temperature of the air flowing from the respiratory device 122 and / or through the conduit 126, the temperature within the user interface 124, the ambient temperature, or any combination thereof. The temperature sensor 136 may be, for example, a thermocouple sensor, a thermistor sensor, a silicon bandgap temperature sensor or semiconductor-based sensor, a resistance temperature detector, or any combination thereof.

[0051] The motion sensor 138 outputs motion data that may be stored in the memory device 114 and / or analyzed by the processor 112 of the control system 110. The motion sensor 138 may be used to detect the user's movements during a sleep session and / or the movements of any of the components of the respiratory treatment system 120, such as the respiratory treatment device 122, the user interface 124, or the conduit 126. The motion sensor 138 may include one or more inertial sensors, such as, for example, an accelerometer, a gyroscope, and a magnetometer. The motion sensor 138 may be used to detect movements or accelerations associated with arterial pulses, such as pulses in or around the user's face and pulses proximal to the user interface 124, and is configured to detect pulse shape, rate, amplitude, or volume characteristics.

[0052] The microphone 140 outputs acoustic data that may be stored in the memory device 114 and / or analyzed by the processor 112 of the control system 110. As described in further detail herein, the acoustic data generated by the microphone 140 can be played back as one or more sounds (e.g., sounds from the user) during a sleep session to determine one or more sleep-related parameters (e.g., using the control system 110). As described in further detail herein, the acoustic data from the microphone 140 can also be used to identify events experienced by the user during a sleep session (e.g., using the control system 110). In other implementations, the acoustic data from the microphone 140 represents noises associated with the respiratory system 120. The microphone 140 may be coupled to or integrated with the respiratory system 120 (or system 100) in generally any configuration. For example, the microphone 140 may be disposed within the respiratory device 122, the user interface 124, the conduit 126, or other components. The microphone 140 may also be located adjacent to or coupled to the outside of the respiratory device 122, the outside of the user interface 124, the outside of the conduit 126, or the outside of any other component. The microphone 140 may also be a component of the user device 170 (e.g., the microphone 140 is a microphone in a smartphone). The microphone 140 may be integrated into the user interface 124, the conduit 126, the respiratory device 122, or any combination thereof. In general, the microphone 140 may be located anywhere in or adjacent to the air path of the respiratory system 120, which includes at least the motor of the respiratory device 122, the user interface 124, and the conduit 126. The air path is therefore also referred to as the acoustic path.

[0053] The speaker 142 outputs sound waves that are audible to the user. The speaker 142 can be used, for example, as an alarm clock or to play alerts or messages to the user (e.g., in response to an event). In some implementations, the speaker 142 can be used to communicate acoustic data generated by the microphone 140 to the user. The speaker 142 can be coupled to or integrated with the respiratory device 122, the user interface 124, the conduit 126, or the user device 170.

[0054] The microphone 140 and the speaker 142 can be used as independent devices. In some implementations, the microphone 140 and the speaker 142 can be combined into an acoustic sensor 141 (e.g., a SONAR sensor), for example, as described in International Publication Nos. WO 2018 / 050913 and WO 2020 / 104465, each of which is incorporated by reference in its entirety. In such implementations, the speaker 142 generates or emits sound waves at predetermined intervals and / or at predetermined frequencies, and the microphone 140 detects reflections of the sound waves emitted from the speaker 142. The sound waves generated or emitted by the speaker 142 have a frequency inaudible to the human ear (e.g., below 20 Hz or above about 18 kHz) so as not to disturb the sleep of the user or the user's bed partner (e.g., bed partner 220 in FIG. 2 ). Based at least in part on data from microphone 140 and / or speaker 142, control system 110 can determine the user's position and / or one or more of the sleep-related parameters described herein, such as a respiratory signal, a respiratory rate, an inhalation amplitude, an exhalation amplitude, an inhalation / exhalation ratio, a number of events per hour, a pattern of events, a sleep stage, a pressure setting of respiratory device 122, or any combination thereof. In this context, a SONAR sensor may be understood to involve active acoustic sensing, such as by generating / transmitting an ultrasonic or low-frequency ultrasonic sensing signal (e.g., within a frequency range of approximately 17-23 kHz, 18-22 kHz, or 17-18 kHz) through the air. Such a system may be considered in connection with the above-mentioned International Publication Nos. WO 2018 / 050913 and WO 2020 / 104465. In some implementations, speaker 142 is a bone conduction speaker. In some implementations, the one or more sensors 130 include (i) a first microphone that is the same as or similar to microphone 140 and integrated into acoustic sensor 141, and (ii) a second microphone that is the same as or similar to microphone 140 but is independent and separate from the first microphone that is integrated into acoustic sensor 141.

[0055] 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, a long-wave signal, a short-wave signal, etc.). The RF receiver 146 detects reflections of the radio waves emitted from the RF transmitter 148, and this data can be analyzed by the control system 110 to determine the location of the user 210 ( FIG. 2 ) and / or one or more of the sleep-related parameters described herein. The 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 device 122, the one or more sensors 130, the user device 170, or any combination thereof. While the RF receiver 146 and the RF transmitter 148 are shown in FIG. 1A as separate and distinct elements, in some implementations the RF receiver 146 and the RF transmitter 148 are combined as part of the RF sensor 147 (e.g., a RADAR sensor). In some such implementations, the RF sensor 147 includes control circuitry. The specific form of RF communication may be WiFi, Bluetooth, etc.

[0056] In some implementations, RF sensor 147 is part of a mesh system. An example of a mesh system is a WiFi mesh system, which may include mesh nodes, mesh routers, and mesh gateways, each of which may be mobile / mobile or fixed. In such implementations, the WiFi mesh system includes a WiFi router and / or a WiFi controller and one or more satellites (e.g., access points), each of which includes an RF sensor identical or similar to RF sensor 147. The WiFi router and satellites continuously communicate with each other using WiFi signals. The WiFi mesh system can be used to generate motion data based at least in part on changes in the WiFi signal between the router and the satellite (e.g., differences in received signal strength) due to movement of an object or person partially obstructing the signal. This motion data may indicate movement, breathing, heart rate, gait, falls, behavior, etc., or any combination thereof.

[0057] The camera 150 outputs image data that can be played back as one or more images (e.g., still images, moving images, thermal images, or a 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. For example, the image data from the camera 150 can be used to identify a user's location, determine when the user enters the user's bed (such as bed 230 in FIG. 2 ), and determine when the user leaves the bed 230. The camera 150 can also be used to track eye movement, pupil dilation (if one or both of the user's eyes are open), blink rate, or any changes during REM sleep. The camera 150 can also be used to track the user's location, which can affect the duration and / or severity of apnea episodes in a user suffering from positional obstructive sleep apnea.

[0058] The IR sensor 152 outputs infrared image data that can be played back as one or more infrared images (e.g., still images, moving 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 the user's temperature and / or the user's movement. 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.

[0059] The IR sensor 152 outputs infrared image data that can be played back as one or more infrared images (e.g., still images, moving 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 the user's temperature and / or the user's movement. The IR sensor 152 can also be used in combination with the camera 150 to measure the user's presence, location, and / or movement. The IR sensor 152 can also be used in combination with the camera 150 to measure the user's presence, location, and / or movement. 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.

[0060] The PPG sensor 154 outputs physiological data related to the user that can be used to determine one or more sleep-related parameters, such as heart rate, heart rate pattern, heart rate variability, cardiac cycle, respiration rate, inspiration amplitude, expiration amplitude, inspiration / expiration ratio, estimated blood pressure parameters, or any combination thereof. The PPG sensor 154 can be worn by the user, embedded in clothing and / or fabric worn by the user, embedded in and / or coupled to the user interface 124 and / or its associated headgear (e.g., straps, etc.). In some implementations, PPG sensing can be performed remotely, such as by processing changes in pixel or sub-pixel values, such as color values ​​or color intensities, detected by video from a camera, such as a smartphone. Such PPG sensing can be performed via video of an area, such as a portion of the face, and can be used to estimate heart rate, respiration rate, pulse transit time, hemoglobin level, blood pressure, etc. Such PPG can use visible light imaging and / or near-infrared imaging, depending on lighting conditions.

[0061] The ECG sensor 156 outputs physiological data related to the electrical activity of the user's heart. In some implementations, the ECG sensor 156 includes one or more electrodes placed on or around a portion of the user during a 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.

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

[0063] The capacitance sensor 160, the force sensor 162, and the strain gauge sensor 164 output data that may 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 related to electrical activity produced by one or more muscles. The oxygen sensor 168 outputs oxygen data indicative of the oxygen concentration of a gas (e.g., in the conduit 126 or at the user interface 124). The oxygen sensor 168 may be, for example, an ultrasonic oxygen sensor, an electrical oxygen sensor, a chemical oxygen sensor, an optical oxygen 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.

[0064] The analyte sensor 174 can be used to detect the presence of analytes in the user's exhaled breath. Data output by the analyte sensor 174 is stored in the memory device 114 and can be used by the control system 110 to determine the identity and concentration of any analytes in the user's breath. In some implementations, the analyte sensor 174 is placed near the user's mouth to detect analytes in the breath exhaled from the user's mouth. For example, if the user interface 124 is a face mask that covers the user's nose and mouth, the analyte sensor 174 can be placed in the face mask to monitor the user's mouth breathing. In other implementations, if the user interface 124 is a nasal mask or nasal pillows mask, the analyte sensor 174 can be placed near the user's nose to detect analytes in the breath exhaled from the user's nose. In yet other implementations, if the user interface 124 is a nasal mask or nasal pillows mask, the analyte sensor 174 can be placed near the user's mouth. In this implementation, the analyte sensor 174 can be used to detect whether air is inadvertently leaking from the user'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, such as carbon dioxide. In some implementations, the analyte sensor 174 can also be used to detect whether a user is breathing through their nose or mouth. For example, if the presence of an analyte is detected by data output by the analyte sensor 174 positioned near the user's mouth or within a face mask (in implementations where the user interface 124 is a face mask), the control system 110 can use this data as an indication that the user is breathing through their mouth.

[0065] 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 face of the user 210, near the junction of the conduit 126 with the user interface 124, near the junction of the conduit 126 with the respiratory device 122, etc.). Thus, in some implementations, the moisture sensor 176 can be coupled to or integrated with the user interface 124 or the conduit 126 to monitor the humidity of the pressurized air from the respiratory device 122. In other implementations, the moisture sensor 176 is positioned near any area where humidity levels need to be monitored. The moisture sensor 176 can also be used to monitor the humidity of the ambient environment surrounding the user, for example, the air in the user's bedroom. The moisture sensor 176 can also be used to track the user's biological responses to environmental changes.

[0066] One or more LiDAR sensors 178 can be used for depth sensing. This type of optical sensor (e.g., a laser sensor) can be used to detect objects and create a three-dimensional (3D) map of a surrounding environment, such as a living space. LiDAR typically uses a pulsed laser to measure time of flight. LiDAR is also referred to as 3D laser scanning. In one use case of such a sensor, a stationary or mobile device (such as a smartphone) with a LiDAR sensor 178 can measure and map an area more than five meters away from the sensor. LiDAR data can be fused with point cloud data estimated, for example, by an electromagnetic RADAR sensor. The LiDAR sensor 178 can also automatically create geofences for a RADAR system by using artificial intelligence (AI) to detect and classify features in a space that may pose a problem for the RADAR system, such as glass windows (which may be highly reflective to the RADAR). LiDAR can also be used to estimate a person's height and changes in height that occur when a person sits, falls, etc. LiDAR can be used to create a 3D mesh representation of the environment. In a further application, for solid surfaces through which radio waves pass (e.g., radio-transparent materials), LiDAR allows classification of different types of obstacles due to reflections from such surfaces.

[0067] 1A , any combination of one or more sensors 130 may be integrated with and / or coupled to any one or more of the components of system 100, including respiratory device 122, user interface 124, conduit 126, humidification tank 129, control system 110, user device 170, or any combination thereof. For example, acoustic sensor 141 and / or RF sensor 147 may be integrated with and / or coupled to user device 170. In such implementations, user device 170 may be considered a secondary device that generates additional or secondary data used by system 100 (e.g., control system 110) according to some aspects of the present disclosure. In some implementations, pressure sensor 132 and / or flow sensor 134 are integrated with or coupled to respiratory device 122. In some implementations, at least one of the one or more sensors 130 is not coupled to the respiratory device 122, the control system 110, or the user device 170, but is positioned generally adjacent to the user during a sleep session (e.g., placed on or against a portion of the user, worn by the user, coupled to or placed on a nightstand, coupled to a mattress, coupled to a ceiling, etc.). More generally, the one or more sensors 130 can be positioned in any suitable location relative to the user such that the one or more sensors 130 can generate physiological data related to the user and / or bed companions 220 during one or more sleep sessions.

[0068] Data from one or more sensors 130 can be analyzed to determine one or more sleep-related parameters, which may include a respiratory signal, a respiratory rate, a respiratory pattern, an inhalation amplitude, an exhalation amplitude, an inhalation / exhalation ratio, the occurrence of one or more events, the number of events per hour, the pattern of events, the average duration of events, the range of event durations, the ratio of different event counts, a sleep stage, an apnea-hypopnea index (AHI), or any combination thereof. The one or more events may include snoring, apnea, central apnea, obstructive apnea, mixed apnea, hypopnea, intentional user interface leak, unintentional user interface leak, mouth leak, coughing, restless legs, sleep disorder, choking, increased heart rate, dyspnea, asthma attack, epileptic episode, seizure, elevated blood pressure, hyperventilation, or any combination thereof. Many of these sleep-related parameters are physiological parameters, but some sleep-related parameters are considered non-physiological parameters. Other types of physiological and non-physiological parameters can also be determined based on either data from one or more sensors 130 or other types of data.

[0069] User device 170 ( FIG. 1A ) includes a display device 172. User device 170 may be, for example, a mobile device such as a smartphone, tablet, or laptop. Alternatively, user device 170 may be an external sensing system, a television (e.g., a smart television), or another smart home device (e.g., a smart speaker such as Google Home, Amazon Echo, or Alexa). In some implementations, user device 170 is a wearable device (e.g., a smart watch). Display device 172 is generally used to display images, including still images, moving images, or both. In some implementations, display device 172 functions as a human-machine interface (HMI), including a graphical user interface (GUI) configured to display images and an input interface. Display device 172 may be an LED display, an OLED display, an LCD display, or the like. The input interface may be, for example, a touchscreen or touch-sensitive substrate, a mouse, a keyboard, or any sensor system configured to detect inputs made by a human user interacting with user device 170. In some implementations, one or more user devices 170 may be used by and / or included in the system 100 .

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

[0071] Although system 100 is shown as including all of the above components, implementations of the present disclosure may include more or fewer components for generating physiological data and determining recommended notifications or actions for the user. For example, a first alternative system includes control system 110, memory device 114, and at least one of one or more sensors 130. As another example, a second alternative system includes control system 110, memory device 114, at least one of one or more sensors 130, and user device 170. As yet another example, a third alternative system includes control system 110, memory device 114, respiratory system 120, at least one of one or more sensors 130, and user device 170. Thus, any portion of the components shown and described herein can be used and / or combined with one or more other components to form a variety of systems.

[0072] 1B , in some implementations, system 100 is communicatively coupled to a computer network and further communicatively coupled to a remote server system 190. This implementation allows system 100 to send and receive communications to and from remote server system 190. For example, system 100 may send instructions or commands (e.g., in the form of electronic or electromagnetic signals) over the computer network to provide specific modules required by system 100. These commands are received by remote server system 190. In response to the received commands, remote server system 190 transmits the requested modules over the network for reception by system 100.

[0073] The present disclosure is directed to systems and methods for determining one or more health conditions from health data of a user of a respiratory system, such as the respiratory system 120 described for system 100. In some implementations, at least some of the health data can be generated and / or collected by one or more sensors 130 during a sleep session of the user of the respiratory system 120. The health data can be collected and stored in memory device 114 of one or more processing devices local to the user, such as processor 112 or a processor that is part of a user device 170 (e.g., a smartphone, a tablet), the respiratory system 120, or the sensor 130. In some implementations, the health data can be received from the user or another entity (e.g., a physician or caregiver) via control system 110, the respiratory system 120, and / or the user device 170.

[0074] To illustrate the generation and collection of health data, an exemplary embodiment of a sleep session collecting selected health data is shown in Figure 3, along with an exemplary hypnogram associated with analyzing the health data collected during the sleep session of Figure 3. The data used to generate the exemplary depiction is generated from sensors 130.

[0075] As used herein, a sleep session can be defined in several ways, for example, based at least in part on an initial start time and end time. In some implementations, a sleep session is the duration during which a user is asleep, i.e., the sleep session has a start time and an end time, and the user does not wake up during the sleep session until the end time. That is, time during which the user is awake is not included in the sleep session. From this first definition of a sleep session, if a user wakes up and falls asleep multiple times in one night, each sleep period separated by a wake period constitutes a sleep session.

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

[0077] In some implementations, a sleep session is defined as the total time from when a user first goes to bed that night to when the user last gets out of bed the next morning. In other words, a sleep session can be defined as the time beginning at a first time (e.g., 10:00 PM) on a first date (e.g., Monday, January 6, 2020) that may refer to the current night when the user first goes to bed with the intention to sleep (as opposed to, for example, when the user first intends to watch TV or use their smartphone before going to sleep) and ending at a second time (e.g., 7:00 AM) on a second date (e.g., Tuesday, January 7, 2020) that may refer to the next morning when the user first wakes up with the intention not to go back to sleep that next morning.

[0078] In some implementations, a user may manually define the start of a sleep session and / or manually end a sleep session. For example, a user may select (e.g., by clicking or tapping) one or more user-selectable elements displayed on display device 172 of user device 170 (FIG. 1) to manually start or end a sleep session.

[0079] Referring to Figure 3, an exemplary timeline 300 of a sleep session is shown. The timeline 300 begins with bedtime (t bed ) and sleep onset time (t GTS ) and initial sleep time (t sleep ), the first micro-awakening MA1, the second micro-awakening MA2, the awakening A, and the wake-up time (t wake ) and wake-up time (t rise ) and,

[0080] bedtime t bed is associated with the time when the user first goes to bed (e.g., bed 230 in FIG. 2) (e.g., when the user lies or sits in bed) before falling asleep. bed can be determined based at least in part on a bedtime threshold duration to distinguish between a time when a user goes to bed to sleep and a time when a user goes to bed for other reasons (e.g., to watch television). For example, the bedtime threshold duration can be at least about 10 minutes, at least about 20 minutes, at least about 30 minutes, at least about 45 minutes, at least about 1 hour, at least about 2 hours, etc. As used herein, a bedtime t in relation to a bed is bed However, more generally, the bedtime t bed may represent the time when the user first settles into some location (e.g., sofa, chair, sleeping bag, etc.) to sleep.

[0081] The time of sleep onset (GTS) is the time when the user goes to bed (t bed ) is associated with the time at which a user first attempts to fall asleep after getting into bed. For example, after getting into bed, a user may engage in one or more activities to relax before attempting to fall asleep (e.g., reading, watching television, listening to music, using the user device 170, etc.). The initial sleep time (t sleep ) is the time when the user first falls asleep. For example, the initial sleep time (t sleep ) may be the time when the user first entered the first non-REM sleep stage.

[0082] wake up time t wakeis the time associated with the time the user wakes up without going back to sleep (as opposed to, for example, the user waking up in the middle of the night and going back to sleep). After the user initially falls asleep, they may experience one of many involuntary micro-awakenings (e.g., micro-awakenings MA1 and MA2) that have short durations (e.g., 5 seconds, 10 seconds, 30 seconds, 1 minute, etc.). The wake-up time t wake In contrast to the above, the user goes through micro-awakenings MA1 and MA2, respectively, and then falls asleep again. Similarly, the user may have one or more conscious awakenings (e.g., Awakening A) after initially falling asleep (e.g., getting up to go to the bathroom, caring for a child or pet, sleepwalking, etc.). However, the user falls asleep again after Awakening A. Therefore, the user may wake up at the wake-up time t wake may be defined, for example, based at least in part on an awakening threshold duration (eg, the user is awake for 15 minutes or more, 20 minutes or more, 30 minutes or more, 1 hour or more, etc.).

[0083] Similarly, the wake-up time t rise is associated with the time when the user is absent from bed with the intent of ending a sleep session (as opposed to, for example, the user getting up to go to the bathroom during the night, caring for a child or pet, sleepwalking, etc.). In other words, the wake-up time t rise is the time when the user last left bed without returning to bed until the next sleep session (e.g., the next night). Therefore, the wake-up time t rise may be defined, for example, based at least in part on a wake threshold duration (e.g., the user has left bed for 15 minutes or more, 20 minutes or more, 30 minutes or more, 1 hour or more, etc.). bed may also be defined at least in part based on a wake threshold duration (e.g., the user has been out of bed for 4 hours or more, 6 hours or more, 8 hours or more, 12 hours or more, etc.).

[0084] As mentioned above, the user must first bed to the last t riseIn some implementations, the last wake-up time t wake and / or last wake-up time t rise is identified or determined based at least in part on a predetermined threshold duration of time following an event (e.g., falling asleep or leaving bed). Such threshold duration may be customized for the user. For a typical user who goes to bed at night and wakes up and gets out of bed in the morning, it may be any time between about 12 hours and about 18 hours (between the time the user wakes up (t)). wake ) or wake up (t rise ) and the user goes to bed (t bed ), falling asleep (t GTS ) or sleep (t sleep ) can be used. A shorter threshold time (e.g., about 8 to about 14 hours) can be used for users who spend a lot of time in bed. The threshold time period may be initially selected and / or later adjusted based at least in part on the system monitoring the user's sleep behavior.

[0085] Total time in bed (TIB) is the time from bedtime t bed From wake-up time t rise t. Total sleep time (TST) is the duration from the initial sleep time t to the wake-up time, excluding conscious or unconscious awakenings and / or microarousals in between. Typically, total sleep time (TST) will be shorter than total time in bed (TIB) (e.g., 1 minute shorter, 10 minutes shorter, 1 hour shorter, etc.). For example, referring to timeline 300 of FIG. 3, total sleep time (TST) is the duration from the initial sleep time t to the wake-up time, excluding conscious or unconscious awakenings and / or microarousals in between. sleep and alarm time t wake , but excluding the duration of the first micro-awakening MA1, the second micro-awakening MA2, and Awakening A. As shown, in this example, the total sleep time (TST) is less than the total time in bed (TIB).

[0086] In some implementations, total sleep time (TST) may be defined as total continuous sleep time (PTST). In such implementations, total continuous sleep time excludes a predetermined initial portion or period of a first non-REM stage (e.g., a light sleep stage). For example, this predetermined initial portion may be about 30 seconds to about 20 minutes, about 1 minute to about 10 minutes, about 3 minutes to about 5 minutes, etc. Total continuous sleep time is a measure of continuous sleep and smooths the sleep-wake hypnogram. For example, when a user first falls asleep, the user may enter the first non-REM stage for a very short time (e.g., about 30 seconds), then return to a wakefulness stage for a short time (e.g., 1 minute), before returning to the first non-REM stage. In this example, total continuous sleep time excludes the first instance (e.g., about 30 seconds) of the first non-REM stage.

[0087] In some implementations, a sleep session begins at bedtime (t bed ) and wake-up time (t rise ), i.e., a sleep session is defined as the total time in bed (TIB). In some implementations, a sleep session is defined as ending at the initial sleep time (t sleep ) and wake up at the alarm time (t wake ) In some implementations, a sleep session is defined as total sleep time (TST). In some implementations, a sleep session is defined as a sleep session ending at sleep onset time (t GTS ) and wake up at the alarm time (t wake ) In some implementations, a sleep session is defined as ending at sleep onset time (t GTS ) and wake-up time (t rise ) In some implementations, a sleep session is defined as ending at bedtime (t bed ) and wake up at the alarm time (t wake ) In some implementations, a sleep session is defined as ending at an initial sleep time (t sleep ) and wake-up time (t rise ) is defined as ending in

[0088] 4, an example hypnogram 400 corresponding to the timeline 300 (FIG. 3) according to some implementations is shown. As shown, the hypnogram 400 includes a sleep-wake signal 401, a wake stage axis 410, a REM stage axis 420, a light sleep stage axis 430, and a deep sleep stage axis 440. The intersection of the sleep-wake signal 401 with one of the axes 410-440 indicates the sleep stage at any given time during the sleep session.

[0089] The sleep-wake signal 401 may be generated (e.g., generated by one or more of the sensors 130 described herein) based at least in part on physiological data associated with the user (e.g., certain health data). The sleep-wake signal may indicate one or more sleep stages, including wakefulness, relaxed wakefulness, microarousal, REM stage, first non-REM stage, second non-REM stage, third non-REM stage, or any combination thereof. In some implementations, one or more of the first non-REM stage, second non-REM stage, and third non-REM stage may be grouped and classified as a light sleep stage or a deep sleep stage. For example, a light sleep stage may include a first non-REM stage, and a deep sleep stage may include a second non-REM stage and a third non-REM stage. 4 includes a light sleep stage axis 430 and a deep sleep stage axis 440, in some implementations, the hypnogram 400 may include an axis for each of a first non-REM stage, a second non-REM stage, and a third non-REM stage. In other implementations, the sleep-wake signal may indicate a respiratory signal, a respiratory rate, an inspiratory amplitude, an expiratory amplitude, an inspiratory / expiratory amplitude ratio, an inspiratory / expiratory duration ratio, a number of events per hour, a pattern of events, or any combination thereof. Information describing the sleep-wake signal may be stored in the memory device 114.

[0090] The hypnogram 400 can be used to determine one or more sleep-related parameters, such as, for example, sleep onset latency (SOL), wake-up-after-sleep (WASO), sleep efficiency (SE), sleep fragmentation index, sleep blocks, or any combination thereof.

[0091] Sleep onset latency (SOL) is the time of sleep onset (t GTS ) to the initial sleep time (t sleep ) In other words, sleep onset latency indicates the time it takes from the user's first attempt to fall asleep to actually falling asleep. In some implementations, sleep onset latency is defined as persistent sleep onset latency (PSOL). Continuous sleep onset latency differs from sleep onset latency in that it is defined as the duration from the time of sleep onset to a predetermined amount of continuous sleep. In some implementations, the predetermined amount of continuous sleep may include, for example, at least 10 minutes of sleep in the second non-REM stage, the third non-REM stage, and / or a REM stage including two minutes or less of wakefulness, the first non-REM stage, and / or transitions therebetween. In other words, continuous sleep onset latency requires, for example, a maximum of eight minutes of continuous sleep in the second non-REM stage, the third non-REM stage, and / or a REM stage. In other implementations, the predetermined amount of continuous sleep may include at least 10 minutes of sleep in the first non-REM stage, the second non-REM stage, the third non-REM stage, and / or the REM stage after the initial sleep time. In such implementations, the predetermined amount of continuous sleep may exclude any microarousals (e.g., after a 10-second microarousal, the 10 minutes are not resumed).

[0092] A wake-up-after-sleep-onset (WASO) is associated with the total duration a user is awake between the initial sleep time and the wake-up time. Thus, a wake-up-after-sleep-onset (WASO) includes brief microarousals (e.g., microarousals MA1 and MA2 shown in FIG. 4 ) during a sleep session, whether conscious or unconscious. In some implementations, a wake-up-after-sleep-onset (WASO) is defined as a persistent wake-up-after-sleep-onset (PWASO), which includes only total durations of awakenings having a predetermined length (e.g., 10 seconds or more, 30 seconds or more, 60 seconds or more, about 5 minutes or more, about 10 minutes or more, etc.).

[0093] Sleep efficiency (SE) is determined as the ratio of total time in bed (TIB) to total sleep time (TST). For example, if the total time in bed is 8 hours and the total sleep time is 7.5 hours, the sleep efficiency for that sleep session is 93.75%. Sleep efficiency indicates a user's sleep hygiene. For example, if a user goes to bed and spends time on other activities (e.g., watching TV) before going to sleep, sleep efficiency decreases (e.g., the user is at a disadvantage). In some implementations, sleep efficiency (SE) can be calculated based at least in part on the total time in bed (TIB) and the total time the user attempts to fall asleep. In such implementations, the total time the user attempts to fall asleep is defined as the duration from the GTS time to the wake-up time, as described herein. For example, in an implementation where the total sleep time is 8 hours (e.g., from 11 PM to 7 AM), the fall asleep time is 10:45 PM, and the wake-up time is 7:15 AM, the sleep efficiency parameter is calculated to be approximately 94%.

[0094] The fragmentation index is determined based at least in part on the number of arousals during a sleep session. For example, if a user had two micro-arousals (e.g., micro-arousals MA1 and MA2 shown in FIG. 4), the fragmentation index may be expressed as 2. In some implementations, the fragmentation index is scaled between a predetermined range of integers (e.g., between 0 and 10).

[0095] Sleep blocks are associated with transitions between any sleep stage (e.g., a first non-REM stage, a second non-REM stage, a third non-REM stage, and / or REM) and a wake stage. For example, sleep blocks can be calculated with a 30-second resolution.

[0096] In some implementations, the systems and methods described herein generate or analyze a hypnogram including a sleep-wake signal to determine a time to bed (t) based at least in part on the sleep-wake signal of the hypnogram. bed ), sleep onset time (t GTS ), initial sleep time (t sleep), one or more first micro-arousals (e.g., MA1 and MA2), wake-up time (t wake ), wake-up time (t rise ), or any combination thereof.

[0097] In other implementations, one or more of the sensors 130 are used to measure bedtime (t bed ), sleep onset time (t GTS ), initial sleep time (t sleep ), one or more first micro-arousals (e.g., MA1 and MA2), wake-up time (t wake ), wake-up time (t rise ), or any combination thereof, can define a sleep session. bed may be determined based at least in part on data generated by, for example, motion sensor 138, microphone 140, camera 150, or any combination thereof. For example, the time of sleep onset may be determined based at least in part on data from motion sensor 138 (e.g., data indicating that the user is not moving), data from camera 150 (e.g., data indicating that the user is not moving and / or data indicating that the user has turned off the lights), data from microphone 140 (e.g., data indicating that the user has turned off the television), data from user device 170 (e.g., data indicating that the user is no longer using user device 170), data from pressure sensor 132 and / or flow sensor 134 (e.g., data indicating that the user has turned on respiratory device 122, data indicating that the user has put on user interface 124, etc.), or any combination thereof.

[0098] 3 and 4, it is contemplated that heart rate data may be collected in addition to processing a user's sleep stages during a sleep session. Trends from the collected health data may then be analyzed to determine whether there is a correlation with a particular underlying health condition and / or whether the trend is consistent with other collected parameters such as user interface leakage, usage, residual AHI, etc.

[0099] In addition to collecting and storing health data of a user of the respiratory system, it is contemplated that the health data may be processed on a device local to the user, such as the respiratory device 122, the user device 170, and / or an associated local control system 110 or processor 112. For example, an initial determination of a potential health condition associated with the user may be made based on local analysis of the collected user health data.

[0100] If a potential health condition is identified, the disclosed methods and systems can receive a health assessment module from a remote server to further evaluate the initially identified potential health condition. For example, the received health assessment module can enable the collection of additional health data and / or further analysis of already collected data to further refine or verify the initial determination of the potential health condition. Because the health data and analysis are performed locally on the device, the present disclosure is particularly desirable because it helps maintain the privacy of the respiratory system user's personal health data. In some implementations, the received health assessment module or another received module includes instructions for changing therapy settings on the respiratory device and / or for modifying components of the respiratory system, such as the user interface (e.g., changing from a nasal mask to a full facial mask), based on the verified determination of the health condition.

[0101] Individuals often have privacy concerns, including what happens to their personal data, such as how secure their health data is and who has access to it. The present disclosure addresses the issue of how to address privacy while providing efficient, customized services to users of respiratory systems, such as an assessment of potential health conditions the user may have from collected health data. The assessment can be completed entirely or nearly entirely on a device local to the user, without the need to share the health data with systems other than the local system controlled by the user. For example, the local device controlled by the user may receive a highly focused health assessment module or series of health assessment modules. These modules may apply machine learning or artificial intelligence to analyze the localized health data and identify the user's potential health conditions based on the local analysis. The present disclosure may minimize, and in some cases effectively eliminate, privacy concerns that arise when pushing sensitive health data for storage and / or analysis on a remote server system (e.g., the cloud). The benefit is that users of respiratory systems can identify potential health conditions they may not be aware of and seek treatment without compromising their privacy. For example, the user may be notified by system 100 of a verified determination of the potential health condition. This may be a visual, audio, or other human-perceptible notification, such as via a speaker, display, tactile component, electronic device, etc. of the respiratory device associated with system 100. By providing customized services, the present disclosure identifies acute and chronic health conditions that may otherwise go unnoticed by users of the respiratory system, thereby increasing the likelihood of a positive medical outcome for the user of the respiratory system.

[0102] In some implementations, a health assessment module is prepared and deployed to the respiratory system 120 or other device local to the user (e.g., user device 170) via an over-the-air software update. In some implementations, sensitive health data is stored locally for a period of time and then destroyed. In some implementations, only the last value determined from the collected health data is stored on the device local to the user. For example, if the health assessment module, or an initial assessment module (suitable for initial determination of one or more potential health conditions), is looking for patterns in the health data, the complete distribution of the health data may be stored without the specific values ​​used to determine the distribution.

[0103] In some implementations, it is contemplated that a particular health assessment application or module-based system will be continuously stored on the local device. This application or module will be used more frequently to evaluate a user's health data for potential health conditions. For less frequently used health assessment applications or module-based systems, the application or module may be received over a network from a remote server 190 and executed on the device local to the user. Once the processing steps associated with evaluating a potential health condition are complete, the health assessment application or module may be removed from the local device to conserve local memory and processing resources. Monitoring and adjusting local resource bandwidth (e.g., memory utilization, processing utilization) can provide benefits in improving the use of spare computing and / or memory resources when executing health assessment modules, allowing for dynamic execution of applications and modules, and the generation of features and insights from the analyzed health data.

[0104] It is contemplated that pooling of local processing and memory resources, such as the processing and memory components of the respiratory system (e.g., CPAP system, ventilator, etc.) and the user device (e.g., smartphone, tablet, smart speaker, smart glasses, smart garment, etc.), can provide the necessary computing power to apply the machine learning-based health assessment module to the collected health data. Additionally, in some aspects, the user device can also provide valuable resources for tracking sensors and receiving sensor data.

[0105] In some implementations, the initial determination of a potential health condition, or additional assessment by any received health assessment module, may include artificial intelligence or machine learning algorithms to analyze selected user health data collected and stored by a device local to the user. For example, in some aspects, a decision tree may be used on the health data to categorize various types of health data into demographic, biometric, medical, self-reported, sleep parameters, and / or sensor data. The data may include mechanical performance data, mask data, facial recognition data, time and / or duration data for respiratory system use, and system sensor data collected and / or stored on a device local to the user. After the data is analyzed by a decision tree and classified into particular categories, such as by an artificial intelligence algorithm, some of the data may be deleted, while some of the data may remain stored locally. For example, once certain raw health data is processed by a health assessment module, only the results of the assessment remain relevant and stored locally for further use, after which the raw data may be deleted. In some implementations, at least some of the health data may be encrypted. In some implementations, selected health data may be de-identified or anonymized and stored locally after processing upon completion of the health assessment module.

[0106] In some implementations, the received health assessment module includes artificial intelligence or machine learning algorithms for analyzing the collected health data, allowing the module to make inferences about the local device itself. The health assessment module can also access remote data sources in addition to local data sources to make inferences about the local device. Such machine learning and artificial intelligence allows the module to train itself to look for specific types of health data or events personalized to the user of the respiratory system.

[0107] In some implementations, the collected and stored health data can be analyzed using artificial intelligence or machine learning. For example, a machine learning algorithm is used to create data correlations. The machine learning algorithm may implement a machine learning structure such as a neural network, a decision tree ensemble, a support vector machine, a Bayesian network, or a gradient boosting machine. Such a structure can be configured to implement either a linear or nonlinear predictive model for determining and assessing various health conditions. For example, data processing, such as determining the respiratory system user's health status, may be performed by any one or more of supervised machine learning, deep learning, convolutional neural networks, and recurrent neural networks, whether configured before (e.g., based on another large pool of health data) or after (e.g., based on the user's personal health data) the health assessment module is received by a processing device local to the user. In some aspects, descriptive and predictive supervised machine learning with hand-crafted features is implemented by the machine learning algorithm. It is also contemplated that the implemented machine learning algorithm can use more variables than hand-crafted features or simple decision trees.

[0108] Convolutional neural networks (CNNs) are widely used in speech and image processing (e.g., facial recognition) to infer information and can be applied to audio spectrograms and even population-scale genomic datasets created from collected data represented as images. When performing image or spectrogram processing, the system cognitively "learns" temporal and frequency characteristics from the intensity, spectral, and statistical estimates of the digitized image or spectrogram data.

[0109] In contrast to CNNs, not all problems can be expressed with fixed-length inputs and outputs. For example, processing respiratory or cardiac sounds is similar to speech recognition and time series prediction. Therefore, acoustic analysis can benefit from systems that store and use context information, such as recurrent neural networks (RNNs), which can take previous outputs or hidden states as inputs. In other words, they may be multi-layered neural networks that can store information in context nodes. RNNs allow for variable-length inputs and outputs by maintaining state information between time steps. They may also include LSTMs (long-short-term memories, a type of "neuron" for enhanced RNN control that can be unidirectional or bidirectional). As a result, they manage the problem of vanishing gradients or use gradient clipping.

[0110] It is envisioned that machine learning algorithms may be trained for supervised learning of known respiratory system user states from known data inputs to aid in the analysis of the input data. Machine learning algorithms may also be trained for unsupervised learning to determine unknown correlations between input data and user status, expanding the scope of analysis by the received health status assessment module.

[0111] Collecting health data from a population beyond a single user of the respiratory system allows for the analysis of health data from large populations to provide a more accurate assessment of underlying health conditions. The collected data may be used to improve artificial intelligence or machine learning algorithms that may be incorporated into the received health assessment module.

[0112] In some implementations, to allow a user of the respiratory system to maintain control of their collected and stored health data, the user of the respiratory system is asked to provide permission to transmit any of their health data from storage and collection devices local to the user or to send requests to a remote server for a health assessment module. In some aspects, the stored health data is encrypted.

[0113] 5, a process flow diagram is depicted for a method 500 of determining a potential health condition of a respiratory system user based on health data collected, stored, and analyzed on a device local to the user. One or more steps of method 500 may be implemented using any element or aspect of system 100 (FIGS. 1A, 1B, and 2) described herein.

[0114] In addition to the many examples of health data described elsewhere herein, the user's health data may include historical health data collected by one or more processing devices, for example, from the user's electronic medical / health record and / or historical data received from one or more sensors 130. In some implementations, the user's health data includes real-time data collected by one or more processing devices, such as based on data received from sensors 130. It is also contemplated that the user's health data may include information received from the user, therapy data collected during operation of the respiratory system, user interface data, facial feature data, time and / or duration data of respiratory system use, audio data (including health data obtained from audio processing and analysis), patient sensor data, sleep stage information, apnea-hypopnea index, user demographic information, user physiological data, respiratory system operational data, or combinations thereof.

[0115] Step 502 of method 500 includes analyzing collected user health data by a processing device local to a user of the respiratory system to make an initial determination of one or more potential health conditions associated with the user. In some implementations, the one or more processing devices local to the user can be a respiratory device of the respiratory system, an electronic device associated with the respiratory system, such as a user device, or both. In some implementations, the respiratory system can be a positive airway pressure therapy system or a mechanical ventilator. In some implementations, the electronic device is a mobile device (e.g., a smartphone) or tablet controller connected to the respiratory system. In some implementations, the mobile device and the respiratory system can be wirelessly connected. In some implementations, the initial determination of the health condition can also include determining whether the user is likely to be adversely affected by the health condition.

[0116] In some implementations of method 500, the electronic device associated with the respiratory system may provide additional services, for example, via a rich user interface that may be highly interactive (e.g., user interface, voice control, connection and control of other smart home devices, etc.), and may include a secure connection to the respiratory system and / or cloud services, while still maintaining sensitive data on the device local to the user. In some implementations, the electronic device may include multiple sensors, such as one or more of sensors 130 (e.g., acoustic sensor 141). Furthermore, it is contemplated that electronic devices, such as smartphones or tablets, may assist in managing data privacy, including data sharing between applications. For example, collected health data may be shared with online support programs and applications that automatically transmit data from the respiratory system 120 to another computing device (e.g., a smartphone) local to the user, in the form of treatment scores (e.g., myAir®) and / or sleep scores. For sensitive data that is not transmitted from the respiratory system to the cloud (e.g., a cloud-based patient management system like Airview® Secure for online patient monitoring) via cellular or other wireless connection, electronic devices such as smartphones or tablets can connect to the respiratory system via wireless technologies such as Bluetooth®. For example, ResMed's myAir® application can retrieve health assessment modules (and, if necessary, treatment modules) from the cloud and determine what should be uploaded to the respiratory system and run locally or in the smartphone's application sandbox, thereby protecting user privacy. As another example, flow data or data from user interface sensors may be downloaded to treat cardiac-related health issues. In some implementations, the data sent to the cloud server can be limited to include, for example, when a service is activated.The results of the health assessment module analysis can then be shared with third parties, such as comprehensive care providers, private cardiologists, web-based medical service providers, etc., who may provide screening services by, for example, supplying the user with a cardiac ECG monitor, glucose monitor, blood pressure monitor, or analyte monitor.

[0117] In some implementations, the health condition for which an initial determination is made from the collected health data may include one or more of a cardiac abnormality, edema, hypertension, or chronic obstructive pulmonary disease. Other health conditions may include atrial fibrillation, drug-resistant hypertension, diabetes, obstructive sleep apnea and chronic obstructive pulmonary disease overlap, obstructive sleep apnea, apnea, central apnea, mixed apnea, hypopnea, chronic heart failure, stroke, obesity, metabolic syndrome, depression, coronary artery disease, asthma, periodic limb movement (PLM), restless legs syndrome (RLS), sleep-disordered breathing (SDB), Cheyne-Stokes respiration (CSR), respiratory failure, obesity hyperventilation syndrome (OHS), neuromuscular disease (NMD), and chest wall disorders. In some implementations, the initial health condition determination may also include determining whether the user is likely to be adversely affected by the health condition.

[0118] In some implementations, cardiac abnormalities can be determined from a respiratory system (such as a PAP system) based on detecting cardiac output from an estimate of carbon dioxide using processing of microphone signals. In some implementations, cardiac abnormalities can additionally or alternatively be based on processing one or more of cardiogenic oscillations in a flow signal, heart rate, oxygen saturation, pulse transit time, or blood pressure from a pulse oximeter that can be coupled to the respiratory system. In some implementations, cardiac abnormalities can additionally or alternatively be based on processing one or more signals from another mattress sensor or a wearable device. In some implementations, electronic health records can be accessed to determine cardiac abnormalities.

[0119] In some implementations, edema can be detected by assessing weight gain, such as from a weighing scale, or by processing images or video from a smartphone camera, such as a photograph of the foot, to determine swelling.

[0120] In some implementations, hypertension can be detected or determined by blood pressure sensing from a blood pressure cuff monitor, a finger-worn device, a watch, or other sensing device, hi some implementations, hypertension can be detected or determined from other blood pressure sensing modalities, such as derivation from an electronic health record or video-based PPG.

[0121] In some implementations, chronic obstructive pulmonary disease can be detected or determined via respiratory rate and inspiratory / expiratory ratio from a flow sensor in the respiratory system, from a wearable device such as a watch, patch, or earring, or from a cough monitor based on audio processing, etc.

[0122] In some implementations, other health conditions that can be detected or determined include atrial fibrillation, which can be detected via irregular heartbeats detected by a flow sensor (cardiogenic oscillation) in the respiratory system, from an optical PPG sensor, from an ECG sensor (such as a watch, patch, or chest electrode), from a sensor in a user interface, etc. Drug-resistant hypertension can be detected or determined based on input from an electronic health record and associated blood pressure measurements from the electronic health record or blood pressure measurements taken by a sensor. Diabetes can be detected or determined based on blood or optical measurements of blood glucose levels or based on gas analysis of exhaled breath into a user interface. Overlap between obstructive sleep apnea and chronic obstructive pulmonary disease can be detected or determined by correlating respiratory system data with COPD detection data. Central apnea can be detected or determined by the respiratory system, such as by using forced oscillations to determine whether the airway is obstructed or by using another sensor to track whether breathing has stopped without paradoxical breathing. Mixed apneas can be detected or determined in a similar manner as a mixture of central and obstructive events.

[0123] In some implementations, still other health conditions that can be detected or determined include chronic heart failure, which can be detected based on changes in heart rate, cardiac output, edema, etc., and a detected deterioration in one of these parameters. Stroke can be detected or determined based on an increase in atrial fibrillation, detection of flutter, or other arrhythmias. Depression can be detected or determined based on changes in heart rate trends derived from a heart rate sensor compared to individuals without depression. Coronary artery disease can be detected or determined based on cardiac output data. Asthma can be detected or determined based on changes in respiratory rate (e.g., increased respiratory rate). Periodic limb movement (PLM) and restless legs syndrome (RLS) can be detected or determined based on various movement features of respiratory system flow signals or microphone signals, or by a separate movement sensor. Cheyne-Stokes respiration (CSR) is a form of periodic breathing typical of central apnea and can be detected or determined from a characteristic waxing and waning amplitude modulation shape that can be determined from the respiratory system flow signal or from a stand-alone contact or non-contact respiratory sensor.

[0124] Health data relating to health conditions disclosed herein may be communicated directly to and collected by the memory of one or more processing devices local to the user via wired or wireless communications. Additionally or alternatively, health data obtained by a user, physician, or caregiver from an electronic medical / health record, or any combination thereof, may be entered into one or more processing devices.

[0125] If, at step 504 of method 500, it is determined that there are no potential health conditions associated with the user of the respiratory system, the method ends. However, if there is an initial determination that the user of the respiratory system has one or more potential health conditions, the method proceeds to step 506. In some implementations, if the initial determination to assess whether the user has a potential health condition is inconclusive, the method proceeds to step 506. In some implementations, the initial determination of a potential health condition may have a confidence level assigned to it for determining whether a potential health condition exists. For example, in some aspects, if the initial determination assigns a confidence level of 50 percent or greater to the existence of a potential health condition (e.g., zero percent means no health condition, and 100 percent means a health condition exists), the method proceeds to step 506. However, if the confidence level falls below 50 percent, the method ends. In some implementations, different confidence level thresholds for determining whether a potential health condition exists are contemplated (e.g., 20 percent, 25 percent, 30 percent, 40 percent, 55 percent, 60 percent, 70 percent, 75 percent, etc.). In some implementations, the confidence level threshold for the initial determination of whether an underlying health condition is present may also vary depending on the immediacy of the adverse health impact of the underlying health condition (acute vs. chronic health condition).

[0126] Step 506 of method 500 is performed in response to making an initial determination that one or more potential health conditions are associated with the user based on an analysis of health data collected by and stored in a memory of a processing device local to the user. Step 506 includes transmitting a command to a remote server to provide one or more health assessment modules including instructions for analyzing the health data and further evaluating the initially determined one or more potential health conditions. The instructions are transmitted over a computer network to which both system 100 and the remote server are connected, for example, as shown in FIG. 1B . In some implementations, the transmitted command to provide one or more health assessment modules includes instructions for providing at least one additional module to obscure a particular health assessment module associated with the user's determined potential health condition. For example, if a module is instructed to further evaluate the health data to determine whether the user has a cardiac abnormality, the transmitted command may include a request for modules to evaluate the cardiac abnormality and asthma. The asthma module is used to conceal or mask flagged health conditions a user may have when it may be difficult to correctly assign a particular health condition to a particular user, thus further helping to maintain the privacy of the user's health data and / or health conditions. In some implementations, sending commands to provide one or more health assessment modules is performed by the respiratory device 122, an electronic device (such as the electronic user device 170), or both.

[0127] In some example implementations, the health assessment module may include instructions for detecting a worsening of an existing health condition or for detecting the emergence of a new health problem or condition. For example, in some cases, if atrial fibrillation or drug-resistant hypertension is detected by the health assessment module, one or more pre-existing or new conditions may be present, such as a person with known OSA and medicated hypertension. In some example implementations, the health assessment module may include instructions for detecting decompensation of heart failure or worsening of COPD due to a viral or bacterial illness (e.g., influenza, Covid-19), such that a determination is made that the patient needs further treatment or hospitalization.

[0128] Step 508 of method 500 includes receiving one or more health assessment modules at one or more processing devices local to the user, such as respiratory device 122, user device 170, memory device 114, control system 110, or a combination thereof. The modules are received in response to provision of the health assessment modules by remote server system 190 (see FIG. 1B ). In some implementations, the received health assessment modules include machine learning algorithms for analyzing selected health data, such as all or a portion of the health data of the user of the respiratory system. In some implementations, the received health assessment modules include at least one additional module for masking specific health assessment modules associated with an initially determined underlying health condition of the user. For example, if the requested module relates to further evaluating the health data to determine whether the user has an overlap between obstructive sleep apnea and a cardiac abnormality associated with chronic obstructive pulmonary disease, the received modules may include a first module for assessing the overlap between obstructive sleep apnea and chronic obstructive pulmonary disease and a second module for assessing hypertension. The hypertension module is used to conceal or mask any flagged underlying health conditions.

[0129] In some implementations, the health assessment module is a mobile device application. In some implementations, the health assessment module is a component of an existing application, is integrated into an existing application, or is a standalone application. The health assessment module or existing application can be stored on a smartphone or other mobile device, or on the respiratory device.

[0130] Step 510 of method 500 includes updating one or more processing devices local to the user to store one or more health assessment modules as executable instructions. For example, updating the processing device to store the health assessment modules can be performed in one or more of the respiratory device 122, the user device 170, or the memory device 114 in combination with the control system 110.

[0131] Step 512 of method 500 includes executing one or more of the received health assessment modules to analyze the health data and verify the initial determination that the user has one or more underlying health conditions. Execution of the health assessment modules can be performed on one or more of the devices updated in step 510. In some implementations, analyzing the health data by the one or more received health assessment modules includes assessing whether one or more health conditions exist. In some implementations, analyzing the health data by the one or more received health assessment modules includes assessing whether the user is likely to be adversely affected by the health conditions determined to exist. In some aspects, the received health assessment modules include instructions for collecting additional health data for the user.

[0132] In some implementations of method 500, an anonymized summary report is generated based on the user's evaluated health data. In some embodiments, the anonymized summary report may be transmitted from one or more processing devices local to the user for reception by a remote or separate server. In some embodiments, input may be received from the user indicating permission or authorization to transmit the anonymized summary report, or portions thereof, to the remote or separate server. In some embodiments, the anonymized summary report, or portions thereof, may be encrypted before transmission. In some embodiments, it is contemplated that the remote or separate server may be associated with a data escrow, a respiratory system manufacturer, or a healthcare provider.

[0133] In some implementations of method 500, a notification related to the transmitted anonymized summary report is received at one or more processing devices local to the respiratory system user. In some aspects, the notification is for an update of the anonymized health assessment module.

[0134] In some implementations of method 500, the health assessment module may include a treatment module executed on the respiratory system (e.g., respiratory system 120). In other implementations, the treatment module may be received as a separate step on a device local to the user (e.g., respiratory system 120) in response to provision of the treatment module by a remote server. The treatment module may include one or more instructions for execution on the respiratory system to provide a respiratory treatment for a particular health condition associated with the user determined from analysis of the collected health data. The respiratory system is updated to store the received treatment module and executes to modify an existing respiratory treatment being delivered to the user by the respiratory system. In some implementations, it is contemplated that the treatment module may include, by way of non-limiting example, a cognitive behavioral therapy (CBTi) module for insomnia. In some implementations, a user via a device local to the user (e.g., respiratory system, smartphone) may connect to and communicate with a remote, anonymized software-as-a-service (SaaS) provider of CBTi associated with the treatment module.

[0135] In some embodiments, the system includes a control system having one or more processors and a memory having machine-readable instructions stored therein, the control system coupled to the memory such that method 500 is performed when the machine-executable instructions in the memory are executed by at least one of the one or more processors of the control system.

[0136] In some embodiments, a system for determining a health status from health data of a user of a respiratory system includes a control system having one or more processors configured to implement method 500.

[0137] In some aspects, a computer program product includes instructions that, when executed by a computer, cause the computer to perform the method 500. The computer program product may be a non-transitory computer-readable medium.

[0138] In some implementations, steps 502 through 512 may be repeated, including one or more of additional implementations or aspects. For example, it is contemplated that the health status of a user of a respiratory system may change over time, and a different or more targeted health assessment module may be received and executed on a device local to the user.

[0139] 6, there is shown a process flow diagram of a method 600 for determining potential respiratory system operational fault conditions from operational data collected, stored, and analyzed on a device local to a user. One or more steps of method 600 may be implemented using any element or aspect of system 100 (FIGS. 1A, 1B, and 2) described herein.

[0140] Examples of operational data may include historical operational data collected about the respiratory system or components of the respiratory system (e.g., respiratory devices, conduits, user interfaces, etc.). In some implementations, the respiratory system operational data includes real-time data collected by one or more processing devices, such as based on data received from sensors 130. It is also contemplated that the respiratory system operational data may include information regarding motor health, pressure, user data, humidifier data, conduit data, user interface data, environmental data, power supply data, display data, and flow sensor data, as well as general information about the respiratory system for monitoring how various system parameters change over time.

[0141] Step 602 of method 600 includes analyzing operational data of the respiratory system, the data collected by a device local to the user. The operational data is used to make an initial determination of one or more potential operational fault conditions associated with the respiratory system. In some implementations, the one or more processing devices local to the user can be the respiratory system, an electronic device associated with the respiratory system (e.g., a user device), or both. In some implementations, the respiratory system can be a positive airway pressure therapy system or a mechanical ventilator. In some implementations, the electronic device is a mobile device (e.g., a smartphone) or tablet controller connected to the respiratory system. In some implementations, the mobile device and the respiratory system can be wirelessly connected. In some implementations, the initial determination of the operational fault condition can also include determining whether the respiratory system is likely to be adversely affected by the operational fault condition.

[0142] In some implementations of method 600, an electronic device associated with the respiratory system may provide additional services, for example, via a rich user interface that may be highly interactive (e.g., user interface, voice control, connection and control of other smart home devices, etc.), while maintaining sensitive data on the device local to the user, and may include a secure connection to the respiratory system and / or cloud services. In some implementations, the electronic device may include multiple sensors, such as one or more of the sensors 130 (e.g., acoustic sensor 141). It is further contemplated that an electronic device such as a smartphone or tablet may assist in managing data privacy, including data sharing between applications. For example, collected operational data may be shared with online support programs and applications that automatically transmit data from the respiratory system 120 to another computing device (e.g., a smartphone) local to the user. For some sensitive data that is not transmitted from the respiratory system to the cloud (e.g., a cloud-based patient management system like Airview® Secure for online patient monitoring) via cellular or other wireless connection, an electronic device such as a smartphone or tablet may connect to the respiratory system via Bluetooth®. For example, the application can retrieve operational evaluation modules from the cloud and determine what should be uploaded to the respiratory system and run locally or in an application sandbox on the smartphone, thereby protecting user privacy. For example, flow data, pressure data, acoustic data, or other operational data may be downloaded from the respiratory system to address various operational issues. In some implementations, the data sent to the cloud server can be limited to include when the service is activated.The results of the operational evaluation module analysis can then be shared with third parties, such as comprehensive care providers, respiratory system manufacturers, etc., who can then send patches, software updates, etc. back to the respiratory system or associated electronic devices as needed.

[0143] In some implementations, operational fault conditions for which an initial determination is made from collected operational data may include one or more of a motor failure, a pressure problem, a user discomfort problem, a humidifier problem, a conduit problem, a user interface problem, a power supply failure, an electrical connection problem, a display problem, or a flow sensor problem.

[0144] In some implementations, motor failure can be determined or detected by collecting operational data regarding the health of a motor in a respiratory device. For example, the health of a respiratory device motor can be determined by comparing acoustic signature data using comparison tools such as direct spectral estimation or echo cepstrum processing. These tools can be used in conjunction with the lifetime of a respiratory device by comparing the signature of the actual blower motor's performance after a specific lifetime of use with the known signature of a blower motor during its lifetime of normal operation. The determined acoustic signature can then be analyzed based on where the actual blower motor falls in the distribution compared to the known performance of the blower motor during normal operation. A determination of the likelihood of premature failure of the respiratory device's blower motor can then be made based on the comparison. It is also contemplated that potential sudden failure of a blower motor can be determined or detected by evaluating abrupt changes in the signature from the baseline or expected operation of the blower motor. Such abrupt changes may indicate motor failure due to defects or damage to the respiratory device, such as mishandling or water damage. The received operational fault assessment module can then be executed to diagnose newly identified problem types or to implement cluster analysis of a fleet or production batch of respiratory devices.

[0145] In some implementations, pressure problems can be determined or detected by collecting operational data related to pressure within the breathing device. For example, the breathing device may be experiencing insufficient pressure as a result of a blower motor problem or a filter problem. Executing the received operational fault assessment module can diagnose a motor problem or a clogged filter based on abnormal motor and noise behavior of the breathing device, which may be related to a pressure or airflow problem.

[0146] In some implementations, operational data related to changes in the acoustic signature of the motor can be collected to determine or detect user discomfort issues. For example, some acoustic changes can potentially cause discomfort to a user, potentially leading them to refrain from using the breathing system. While acoustic changes in the operation of the motor may not affect the actual treatment of a user of the breathing system, identifying the problem is desirable if discomfort is a factor that may lead to a decrease in adherence to treatment.

[0147] In some implementations, operational data collected from the humidifier can determine or detect problems with the humidifier. For example, data collection of noise based on water volume or lack of water can be compared to known acoustic signatures that may cause operational disturbances. In another example, a determination can be made whether a heater or sensor associated with the humidifier is malfunctioning. In yet another example, a determination can be made whether an expected acoustic signature associated with the humidifier is not present when a respiratory device requests humidification. In some aspects, such acoustic signatures may differ due to deterioration of the humidifier seal.

[0148] In some implementations, problems with the conduit can be determined or detected by collecting operational data, such as sensors or acoustic signatures associated with the conduit. For example, the conduit may have a poor connection with the breathing device, which could cause a leak. Such a leak may be detected when the acoustic signature does not match that of a properly connected conduit, or when a pressure sensor determines that there is lower than expected pressure in or near the conduit.

[0149] In some implementations, power supply malfunctions can be determined or detected by collecting operational data such as noise or abnormal acoustic signatures. Such abnormal acoustic signatures may indicate, for example, unexpected coil whine or changes in coil whine. A change in acoustic signature may indicate an early onset of power supply failure or a potential safety risk. A change in acoustic signature may be due to a problem with the power supply circuitry on the respiratory device's printed circuit board or may be due to an observed change in supply voltage.

[0150] In some implementations, electrical connection problems can be determined or detected by collecting operational data such as noise or unusual acoustic signatures indicative of an electrical connection problem. For example, the operational data may relate to unexpected shutdown / startup symptoms for the respiratory device.

[0151] In some implementations, problems with the display device can be determined or detected by collecting operational data regarding, for example, noise or unusual acoustic signatures, such as from a noisy backlight in the display device. Display device diagnostics can be received and performed to determine such operational faults.

[0152] In some implementations, problems with the flow sensor can be determined or detected by collecting operational data, such as flow sensor data and an acoustic signature of the sound of the respiratory device. For example, an operational fault may be determined if the sound of the respiratory device does not match the flow or pressure sensor readings, or the blower motor rotation speed (e.g., rpm) readings. After determining whether such a discrepancy exists, it may be desirable to perform additional evaluations to further determine whether the respiratory device has a component failure, a reading error, or a sensor error.

[0153] The operational data relating to the operational fault conditions disclosed herein may be communicated directly to and collected by the memory of one or more processing devices local to the user via wired or wireless communication. Additionally or alternatively, the operational data may be input into the one or more processing devices by a user, a physician, or a caregiver, or any combination thereof.

[0154] In some aspects, building machine learning models of the blower motor and humidifier noise or acoustic signatures over time may be implemented. Such machine learning models may then be applied, for example, as part of an initial determination of operational faults or as part of an operational fault assessment module. The machine learning models may be developed over the expected lifespan of the breathing system and may include monitoring how operational parameters change over time.

[0155] If step 604 of method 600 determines that there are no potential operational fault conditions associated with the respiratory system, the method ends. However, if there is an initial determination that there are one or more potential operational fault conditions in the respiratory system, the method proceeds to step 606. In some implementations, if the initial determination to evaluate whether there is a potential operational fault condition in the respiratory system is inconclusive, the method proceeds to step 606. In some implementations, the initial determination of a potential operational fault condition may have a confidence level assigned to it for determining whether there is a potential operational fault condition. For example, in some aspects, if the initial determination assigns a confidence level of 50 percent or greater that a potential operational fault condition exists (e.g., 0 percent means there is no operational fault condition, and 100 percent means there is an operational fault condition), the method proceeds to step 606. However, if the confidence level falls below 50 percent, the method ends. In some implementations, different confidence level thresholds for determining whether there is a potential operational fault condition are contemplated (e.g., 20 percent, 25 percent, 30 percent, 40 percent, 55 percent, 60 percent, 70 percent, 75 percent, etc.). In some implementations, the confidence level threshold for the initial determination of whether a potential operational fault condition exists may also vary depending on the immediacy of the adverse effect of the potential operational fault condition (e.g., whether it is a short-term or long-term operational condition that causes the breathing system to cease normal operation).

[0156] Step 606 of method 600 is performed in response to making an initial determination that one or more potential operational fault conditions are associated with the respiratory system based on an analysis of operational data collected by and stored in a memory of a processing device local to the user. Step 606 includes transmitting a command to a remote server to provide one or more operational fault assessment modules including instructions for analyzing the operational data and further evaluating the initially determined one or more potential operational fault conditions. The command is transmitted over a computer network to which both system 100 and the remote server are connected, for example, as shown in FIG. 1B . In some implementations, the transmitted command to provide one or more operational fault assessment modules includes instructions for providing at least one additional module to identify a particular operational fault assessment module associated with the determined potential operational fault condition of the respiratory system. For example, if the module is related to further evaluating the operational data to determine whether there is a pressure problem in the respiratory system, the transmitted command may include a request for modules to evaluate a pressure problem and a humidifier problem. The humidifier problem module is used to conceal or mask flagged operational fault conditions when it may be difficult to correctly assign a specific operational fault condition, thus further helping to maintain the privacy of operational data related to the user's respiratory system. In some implementations, sending commands to provide one or more operational fault assessment modules is performed by the respiratory device 122, an electronic device (such as the electronic user device 170), or both.

[0157] Step 608 of method 600 includes receiving one or more operational fault assessment modules at one or more processing devices local to the user, such as the respiratory device 122, the user device 170, the memory device 114, the control system 110, or a combination thereof. The modules are received in response to provision of the operational fault assessment modules by a remote server system 190 (see FIG. 1B ). In some implementations, the received operational fault assessment modules include machine learning algorithms for analyzing selected operational data, such as all or a portion of the operational data of the respiratory system. In some implementations, the received operational fault assessment modules include at least one additional module for concealing a particular operational fault assessment module associated with an initially determined potential operational fault condition of the respiratory system. For example, if the requested module relates to further evaluating the operational data to determine whether the respiratory system has a user discomfort issue, the received modules may include a first module for assessing a user discomfort issue and a second module for assessing a motor malfunction. The motor malfunction module is used to conceal or mask the flagged potential operational fault condition.

[0158] In some implementations, the operational impairment assessment module is a mobile device application. In some implementations, the operational impairment assessment module is a component of an existing application, is integrated into an existing application, or is a standalone application. The operational impairment assessment module or an existing application can be stored on a smartphone or other mobile device, or on the respiratory device.

[0159] Step 610 of method 600 includes updating one or more processing devices local to the user to store one or more operational fault assessment modules as executable instructions. For example, updating the processing device to store the operational fault assessment modules can be performed in one or more of the respiratory device 122, the user device 170, or the memory device 114 in combination with the control system 110.

[0160] Step 612 of method 600 includes executing one or more of the received operational fault assessment modules to analyze the operational data and verify the initial determination that the respiratory system has one or more potential operational fault conditions. Execution of the operational fault assessment modules can be performed on one or more of the devices updated in step 510. In some implementations, analyzing the operational data with the one or more received operational fault assessment modules includes evaluating whether one or more operational fault conditions exist. In some implementations, analyzing the operational data with the one or more received operational fault assessment modules includes evaluating whether the respiratory system is likely to be adversely affected by the operational fault conditions determined to exist. In some aspects, the received operational fault assessment module includes instructions for collecting additional operational data of the respiratory system. In some implementations, the received operational fault assessment module or another received module includes instructions for modifying operational settings of the respiratory device and / or modifying components of the respiratory system, such as a user interface (e.g., replacing or repairing the user interface), based on the verified determination of the operational fault condition.

[0161] In some implementations of method 600, an anonymized summary report is generated based on the evaluated operational data of the respiratory system. In some embodiments, the anonymized summary report may be transmitted from one or more processing devices local to the user for reception by a remote or separate server. In some embodiments, input may be received from the user indicating permission or authorization to transmit the anonymized summary report, or portions thereof, to the remote or separate server. In some embodiments, the anonymized summary report may be encrypted before transmission. In some embodiments, it is contemplated that the remote or separate server may be associated with a data escrow, a respiratory system manufacturer, or a healthcare provider.

[0162] In some implementations of method 600, a notification related to the transmitted anonymized summary report is received at one or more processing devices local to the respiratory system user. In some aspects, the notification is for an update of the anonymized operational fault assessment module.

[0163] In some aspects, the system includes a control system having one or more processors and a memory having machine-readable instructions stored therein, the control system being coupled to the memory such that method 600 is performed when the machine-executable instructions in the memory are executed by at least one of the one or more processors of the control system.

[0164] In some embodiments, a system for determining operational fault conditions from respiratory system operational data includes a control system having one or more processors configured to implement method 600.

[0165] In some aspects, a computer program product includes instructions that, when executed by a computer, cause the computer to perform the method 600. The computer program product may be a non-transitory computer-readable medium.

[0166] In some implementations, steps 602 through 612 may be repeated, including one or more of additional implementations or aspects. For example, it is contemplated that potential operational fault conditions of the respiratory system may change over time, and a different or more targeted operational fault assessment module may be received and executed on a device local to the user.

[0167] One or more elements, aspects, steps or portions thereof from any one or more of the following claims 1-61 may be combined with one or more elements, aspects, steps or portions thereof from any one or more other claims 1-61 or combinations thereof to form one or more further implementations and / or claims of the present disclosure.

[0168] 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 modifications are possible 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 further implementations according to various aspects of the present disclosure may combine any number of features from any of the implementations described herein.

Claims

1. A method of operation of a system for determining one or more health states from health data of a user of a respiratory system, the health data being collected by and stored in memory of one or more processing devices local to the user, the method comprising: analyzing user health data collected by the processing device local to the user to make an initial determination of one or more potential health conditions associated with the user of the respiratory system; In response to determining one or more potential health conditions associated with the user, transmitting commands received by a remote server that provide one or more health assessment modules including instructions for analyzing the health data to further assess the initially determined one or more identified potential health conditions; receiving, at the one or more processing devices local to the user, the one or more health assessment modules in response to the remote server providing the one or more health assessment modules; updating the one or more processing devices local to the user to store the one or more health assessment modules as executable instructions; and executing one or more of the received health assessment modules to analyze the health data and verify the initial determination that the user has one or more underlying health conditions.

2. 2. The method of claim 1, wherein the one or more health conditions comprise at least one of cardiac abnormalities, edema, hypertension, chronic obstructive pulmonary disease, atrial fibrillation, drug-resistant hypertension, diabetes, insomnia, overlapping obstructive sleep apnea and chronic obstructive pulmonary disease, obstructive sleep apnea, central sleep apnea, mixed apnea, hypopnea, chronic heart failure, stroke, obesity, metabolic syndrome, depression, coronary artery disease, asthma, periodic limb movement (PLM), restless legs syndrome (RLS), sleep-disordered breathing (SDB), Cheyne-Stokes respiration (CSR), respiratory failure, obesity-hyperventilation syndrome (OHS), neuromuscular disease (NMD), and / or chest wall disorders.

3. 3. A method of operating a system as described in claim 1 or claim 2, wherein the initial determination of one or more health conditions associated with the user includes determining whether the user is likely to be adversely affected by one or more health conditions associated with the user.

4. 4. The method of operating a system according to claim 1, wherein the analysis of the health data by the one or more received health assessment modules comprises assessing whether the one or more health conditions are present.

5. 5. The method of claim 4, wherein the analysis of the health data by the one or more received health assessment modules includes assessing whether the user is likely to be adversely affected by the one or more health conditions determined to exist.

6. 6. A method of operating a system as described in any one of claims 1 to 5, wherein the transmitted commands to provide one or more health assessment modules include instructions to provide at least one additional module for concealing a particular health assessment module associated with the determined underlying health condition of the user.

7. A method of operating a system as described in any one of claims 1 to 6, wherein the received one or more health assessment modules include at least one additional module for concealing a particular health assessment module associated with the determined underlying health condition of the user.

8. 8. A method of operating a system according to any preceding claim, wherein the health data of the user comprises historical health data collected by the one or more processing devices local to the user.

9. A method of operating a system according to any preceding claim, wherein the health data of the user comprises real-time data collected by the one or more processing devices.

10. 10. The method of operating a system according to any one of claims 1 to 9, wherein the health data of the user includes information received from the user, treatment data collected during operation of the respiratory system, duration of respiratory treatment, user interface data, facial feature data, user sensor data, sleep stage information, apnea-hypopnea index, user demographic information, user physiological data, operational data of the respiratory system, or a combination thereof.

11. A method of operating a system according to any one of claims 1 to 10, wherein the one or more processing devices local to the user include a respiratory device of the respiratory system, an electronic device associated with the respiratory system, or both.

12. The method of claim 11 , wherein the electronic device is a mobile device.

13. The method of claim 12, wherein the mobile device and the respiratory system are wirelessly connected.

14. 14. A method of operating a system according to any one of claims 11 to 13, wherein the sending of the command to provide one or more health assessment modules is performed by a respiratory device of the respiratory system, the electronic device associated with the respiratory system, or both.

15. A method of operation of a system according to any one of claims 1 to 14, wherein the health assessment module is an application on a mobile device.

16. 16. A method of operating a system according to any preceding claim, wherein executing the one or more received health assessment modules comprises executing instructions to collect additional health data for the user.

17. 17. A method of operating a system as described in any one of claims 1 to 16, further comprising generating an anonymized summary report based on (i) the health data of the user, (ii) the initially determined one or more underlying health conditions, or (iii) both (i) and (ii).

18. 20. The method of claim 17, further comprising transmitting the anonymized summary report from the one or more processing devices local to the user for receipt by the remote server or another server.

19. 20. A method of operating a system as claimed in claim 17, wherein the anonymised summary report is encrypted before being transmitted.

20. A method of operating a system according to any preceding claim, wherein the stored health data is encrypted.

21. 20. A method of operating a system as described in any one of claims 18 to 19, further comprising receiving input from the user at the one or more processing devices local to the user, the input indicating permission to transmit the anonymized summary report to the remote server or another server.

22. 20. A method of operating a system as described in any one of claims 18 to 19, further comprising receiving input from the user at the one or more processing devices local to the user, the input indicating permission to transmit a portion of the anonymized summary report to the remote server or another server.

23. 23. A method of operating a system according to any one of claims 18, 21 or 22, wherein the remote server or another server is associated with a data escrow, a respiratory system manufacturer or a healthcare provider.

24. 24. A method of operating a system as claimed in any one of claims 18, 21 to 23, further comprising receiving a notification relating to the transmitted anonymised summary report at the one or more processing devices local to the user.

25. 25. The method of claim 24, wherein the notification is for an update of an anonymized health assessment module.

26. 26. A method of operating a system according to any preceding claim, wherein the one or more health assessment modules include machine learning algorithms for analyzing selected health data of the user.

27. A method of operating a system according to any one of claims 1 to 26, wherein the respiratory system is a positive airway pressure therapy system.

28. A method of operating a system according to any one of claims 1 to 26, wherein the breathing system is a ventilator.

29. 1. A system comprising: a control system including one or more processors; a memory storing machine-readable instructions; The control system is coupled to the memory, and when machine-executable instructions in the memory are executed by at least one of the one or more processors of the control system, the method of operating the system described in any one of claims 1 to 28 is performed.

30. A system for determining a health status from health data of a user of a respiratory system, the system comprising a control system configured to implement a method for operating the system according to any one of claims 1 to 28.

31. A computer program product comprising instructions which, when executed by a computer, cause the computer to carry out a method of operating a system according to any one of claims 1 to 28.

32. 32. The computer program product of claim 31, which is a non-transitory computer-readable medium.

Images