Remote Respiratory Therapy Device Management

Abstract

Automatically manage and maintain updates (e.g., software, settings, firmware) for multiple and diverse patient devices. [Solution] The method includes storing an upgrade specification in a memory section of a machine management service (MMS) system 106, processing the received electronic message via a transceiver, making a determination as to whether a broker request is present in the queue based on identification data for the patient device 102, and based on a determination that there is no broker request in the queue, accessing and processing the upgrade specification to retrieve a first upgrade segment of a plurality of upgrade segments, and removing the broker request from the queue and generating an upgrade message to be transmitted to the patient device via the wireless transceiver.

Description

[Technical Field]

[0001] 1 Cross-reference to related applications This application claims priority to U.S. Provisional Application No. 62 / 935,356, filed November 14, 2019, the entire contents of which are incorporated herein by reference. U.S. Publication No. 2017 / 0136198, the entire contents of which are incorporated herein by reference. [Background technology]

[0002] 2. Technical Background 2.1 Technology field The present technology relates to one or more of screening, diagnosing, monitoring, treating, preventing, and ameliorating respiratory-related disorders. The present technology also relates to medical devices or apparatus and their uses. The present technology relates to medical devices or apparatus, their uses, and updates.

[0003] 2.2 Description of Related Art 2.2.1 The human respiratory system and its disorders The body's respiratory system facilitates gas exchange. The nose and mouth form the entrance to a patient's airways.

[0004] These airways contain a series of branching tubes that become narrower, shorter, and more numerous the deeper they travel into the lungs. The primary function of the lungs is gas exchange, transferring oxygen from inhaled air into the venous blood and expelling carbon dioxide. The trachea divides into the right and left main bronchi, which further divide into the terminal bronchioles. The bronchi constitute conducting airways and do not participate in gas exchange. The airways further divide into respiratory bronchioles and ultimately into alveoli. Gas exchange occurs in the alveolar region of the lung, known as the respiratory zone. See: "Respiratory Physiology," by John B. West, Lippincott Williams & Wilkins, 9th edition published 2012.

[0005] A range of respiratory disorders exists, and particular disorders may be characterized by particular manifestations such as apnea, hypopnea, and hyperpnea.

[0006] Examples of respiratory disorders include obstructive sleep apnea (OSA), Cheyne-Stokes respiration (CSR), respiratory failure, obesity hyperventilation syndrome (OHS), chronic obstructive pulmonary disease (COPD), neuromuscular diseases (NMD), and chest wall disorders.

[0007] 2.2.2 Treatment A variety of respiratory therapies (e.g., continuous positive airway pressure (CPAP) therapy, noninvasive ventilation (NIV), invasive ventilation (IV), and high-flow therapy (HFT)) are used to treat one or more of the above-mentioned respiratory disorders.

[0008] Respiratory pressure therapy is the application of air supply to the airway entrance at a controlled target pressure that is nominally positive relative to atmosphere throughout the patient's respiratory cycle (as opposed to negative pressure therapy such as a tank ventilator or positive-negative pressure extracorporeal ventilator).

[0009] Continuous positive airway pressure (CPAP) therapy is used in the treatment of obstructive sleep apnea (OSA). Its mechanism of action is that the continuous positive airway pressure acts as a pneumatic splint, for example, by pushing the soft palate and tongue forward or backward against the posterior oropharyngeal wall, thereby preventing closure of the upper airway. Because treatment of OSA with CPAP therapy can be voluntary, patients may choose not to adhere to treatment if they perceive one or more of the following about the device used to deliver the treatment: it is uncomfortable, difficult to use, expensive, or aesthetically unattractive.

[0010] Noninvasive ventilation (NIV) provides ventilatory support to a patient through the upper airway to assist the patient in breathing and / or maintain adequate oxygen levels in the body by performing some or all of the respiratory functions. Ventilatory support is provided through a noninvasive patient interface. NIV is used to treat CSR and respiratory failure in forms such as OHS, COPD, NMD, and chest wall disorders. In some forms, it can improve the comfort and effectiveness of these treatments.

[0011] Invasive ventilation (IV) provides ventilatory support to patients who are no longer able to breathe effectively on their own and may be provided using a tracheostomy tube. In some forms, the comfort and effectiveness of these treatments may be improved.

[0012] Ventilators can control the timing and pressure of breaths pumped into a patient and monitor the breaths the patient takes. These patient control and monitoring methods typically include volume-controlled and pressure-cycled methods. Examples of volume-controlled methods include pressure-controlled volume-controlled ventilation (PRVC), volume-controlled ventilation (VV), and volume-controlled continuous mandatory ventilation (VC-CMV) techniques. Examples of pressure-cycled methods include assist-control (AC), synchronized intermittent mandatory ventilation (SIMV), controlled mechanical ventilation (CMV), pressure-support ventilation (PSV), continuous positive airway pressure (CPAP), or positive end-expiratory pressure (PEEP) techniques.

[0013] 2.2.3 Respiratory Treatment Systems These respiratory therapies may be provided by respiratory treatment systems or devices. Such systems and devices may also be used to screen, diagnose, or monitor disease without treating it.

[0014] The respiratory therapy system may include a respiratory pressure therapy device (RPT device), an air circuit, a humidifier, a patient interface, an oxygen breathing source, and data management.

[0015] 2.2.3.1 Patient Interface A patient interface may be used to provide a wearer with an interface to a respiratory appliance, for example, by providing airflow to the airway entrance. Airflow may be provided via a mask to the nose and / or mouth, a tube to the mouth, or a tracheostomy tube to the patient's trachea. Depending on the treatment being applied, the patient interface may form a seal with, for example, an area of ​​the patient's face, thereby facilitating gas delivery at a pressure sufficient to disperse with ambient pressure for treatment to occur (e.g., at a positive pressure of approximately 10 cmH2O relative to ambient pressure). In other forms of treatment, such as oxygen delivery, the patient interface may not include a seal sufficient to facilitate delivery of a gas supply to the airways at a positive pressure of approximately 10 cmH2O. For flow treatments, such as nasal HFT, the patient interface is configured to insufflate the nares and specifically avoid a complete seal. One example of such a patient interface is a nasal cannula.

[0016] CPAP therapy is highly effective in treating certain breathing disorders when patients comply with the therapy. If the mask is uncomfortable or difficult to use, patients may not comply with the therapy. Because patients are often encouraged to clean their masks regularly, if the mask is difficult to clean (e.g., difficult to assemble or disassemble), patients may not be able to clean the mask, which may affect patient compliance.

[0017] Masks for other uses (e.g., aviators) may be unsuitable for use in treating sleep-disordered breathing, and masks designed for use in treating sleep-disordered breathing may be suitable for other uses.

[0018] For these reasons, patient interfaces for CPAP delivery during sleep form a distinct field.

[0019] 2.2.3.2 Respiratory Pressure Therapy (RPT) Devices Respiratory pressure therapy (RPT) devices can be used individually or as part of a system to deliver one or more of the therapies described above, for example, by operating the device to generate an air delivery flow to an interface with the airway. The air flow can be pressure-controlled (for respiratory pressure therapy) or flow-controlled (for flow therapy such as HFT). As such, RPT devices can also function as flow therapy devices. Examples of RPT devices include CPAP devices and mechanical ventilators. RPT devices are known as flow generators.

[0020] Air pressure generators are known for a wide range of applications (e.g., industrial-scale ventilation systems). However, air pressure generators for medical applications have specific requirements that cannot be met by more common air pressure generators (e.g., the reliability, size, and weight requirements of medical equipment). In addition, even devices designed for medical treatment may suffer from deficiencies related to one or more of the following: comfort, noise, ease of use, effectiveness, size, weight, manufacturability, cost, and reliability.

[0021] One example of a special requirement for a particular RPT device is acoustic noise.

[0022] Table of noise output levels of conventional RPT devices (measured on one sample only at 10cmH2O in CPAP mode using the test method specified in ISO3744). [Table 1]

[0023] A device designer may be presented with a myriad of choices. Often, conflicting design criteria may make certain design choices unconventional or unavoidable. Furthermore, the comfort and effectiveness of a particular implementation may be significantly affected by minor changes in one or more parameters.

[0024] 2.2.3.3 Air Circuit An air circuit is a conduit or tube constructed and arranged so that, in use, airflow travels between two components of a respiratory therapy system (e.g., an RPT device and a patient interface). In some cases, there may be separate legs of the air circuit for inhalation and exhalation. In other cases, a single leg air circuit is used for both inhalation and exhalation.

[0025] 2.2.3.4 Humidifier Delivery of the airflow without humidification can lead to drying of the airway. When a humidifier is used with an RPT device and patient interface, humidified gas is produced, minimizing drying of the nasal mucosa and increasing comfort of the patient's airway. Additionally, in cooler climates, the application of warm air to the facial area surrounding the patient interface generally provides more comfort than cool air. Therefore, humidifiers often have the ability to not only humidify but also heat the airflow.

[0026] 2.2.3.5 Data Management For clinical reasons, data may be obtained to determine whether a patient prescribed respiratory therapy is "compliant" (e.g., whether the patient adheres to one or more "compliance rules" with their RPT device). An example of a compliance rule for CPAP therapy may require a patient to use the RPT device for at least four hours per night for at least 21 days out of 30 consecutive days to be considered compliant. To determine patient compliance, a provider of the RPT device (e.g., a healthcare provider) may manually obtain data describing the patient's treatment with the RPT device, calculate usage rates over a given period, and compare this to the compliance rules. Once the healthcare provider determines that the patient has used their RPT device in accordance with the compliance rules, the healthcare provider may notify a third party that the patient is compliant.

[0027] There may be other aspects of patient care that benefit from communication of treatment data to third parties or external systems.

[0028] Existing processes for communicating and managing such data can be costly, time consuming, and / or error prone. Summary of the Invention [Means for solving the problem]

[0029] 3. Brief description of the technology The present technology relates to the provision of medical devices for use in screening, diagnosing, monitoring, ameliorating, treating or preventing respiratory disorders, which medical devices have one or more of improved comfort, cost, effectiveness, ease of use and manufacturability.

[0030] An aspect of certain forms of the present technology is to provide methods and / or devices that improve patient compliance with respiratory therapy.

[0031] One form of the present technology includes technology for automatically managing and maintaining updates (eg, software, settings, firmware) to multiple and diverse patient devices.

[0032] Another aspect of one form of the present technology is the use of rules-based processing, which responds to individually submitted requests from patient devices. These requests include identification data associated with specific devices. Such information allows the system to automatically determine what updates to apply to the patient devices (without the need to manually apply such updates).

[0033] The described methods, systems, devices, and apparatus may be implemented to enable improved functionality in a processor (e.g., a processor in a special purpose computer, a respiratory monitor, and / or a respiratory treatment device). Additionally, the described methods, systems, devices, and apparatus (including, e.g., devices that provide sleep disordered breathing monitoring and / or treatment) enable advancements in the art of automated management, monitoring, and / or treatment of respiratory diseases.

[0034] Of course, some of the aspects may form sub-aspects of the present technology, and various sub-aspects and / or aspects may be combined in various ways to form further aspects or sub-aspects of the present technology.

[0035] Other features of the present technology will become apparent in light of the information contained in the following detailed description, abstract, drawings, and claims.

[0036] 4 Brief description of the drawings The present technology is illustrated by way of example and not limitation in the accompanying drawings in which like reference numerals include like elements as follows: [Brief explanation of the drawings]

[0037] [Figure 1A] 4.1 Respiratory Treatment System: A system is shown including a patient 1000 wearing a patient interface 3000, which takes the form of nasal pillows and receives air at positive pressure supplied by an RPT device 4000. The air from the RPT device 4000 is conditioned by a humidifier 5000 and travels along an air circuit 4170 to the patient 1000. A bed companion 1100 is also shown. The patient is sleeping in a supine sleeping position. [Figure 1B] A system is shown including a patient 1000 wearing a patient interface 3000, which takes the form of a nasal mask and receives air at positive pressure supplied by an RPT device 4000. The air from the RPT device is humidified by a humidifier 5000 and travels along an air circuit 4170 to the patient 1000. [Figure 1C] The system includes a patient 1000 wearing a patient interface 3000. The patient interface 3000 takes the form of a full face mask and receives a supply of positive pressure air from an RPT device 4000. Air from the RPT device is humidified by a humidifier 5000 and travels along an air circuit 4170 to the patient 1000. The patient is sleeping in a lateral sleeping position. [Figure 2A] 4.2 Respiratory System and Facial Anatomy: Provides an overview of the human respiratory system, including the nasal and oral cavities, larynx, vocal folds, esophagus, trachea, bronchi, lungs, alveolar sacs, heart, and diaphragm. [Figure 3A] 4.3 Patient Interface: A patient interface in the form of a nasal mask is shown in accordance with one form of the present technology. [Figure 4C] 4.4 RPT Device: A schematic diagram of the electrical components of an RPT device in accordance with one aspect of the present technology. [Figure 4D] FIG. 1 is a schematic diagram of an algorithm executed in an RPT device in accordance with one form of the present technology; [Figure 4E] 4D in accordance with one aspect of the present technology. [Figure 5A] 4.5 Humidifier: An isometric view of a humidifier in accordance with one form of the present technology. [Figure 5B] FIG. 10 is an isometric view of a humidifier in accordance with one form of the present technology, showing the humidifier reservoir 5110 removed from the humidifier reservoir dock 5130. [Figure 6A] 4.6 Respiration waveform: A model of a typical human respiration waveform during sleep is shown. [Figure 7] 4.7 Data Management System: An exemplary machine management service system 106 is shown that is used to communicate with and provide updates to the patient devices 102 (102A, 102B, 102C) according to a particular example. [Figure 8]8 is a signal diagram illustrating communication between an example RPT device and the example machine management service system of FIG. 7. [Figure 9A] 1 is a flowchart of computer operations that may be performed in certain examples. [Figure 9B] 1 is a flowchart of computer operations that may be performed in certain examples. [Figure 10A] 1 illustrates a signal diagram of communications that may occur between various computing devices and / or services in connection with delivery of a brokered request to a patient device in accordance with certain examples. [Figure 10B] 1 illustrates a signal diagram of communications that may occur between various computing devices and / or services in connection with delivery of a broker request to a patient device in accordance with certain examples. [Figure 10C] 1 illustrates a signal diagram of communications that may occur between various computing devices and / or services in connection with delivery of a broker request to a patient device in accordance with certain examples. [Figure 11] 4.8 Computing Device: An exemplary computing device that may be used in some embodiments to implement the features described herein. DETAILED DESCRIPTION OF THE INVENTION

[0038] 5 Detailed description of examples of this technology Before describing the present technology in further detail, it should be understood that the present technology is not limited to the specific examples described herein, which may vary. It should also be understood that the terminology used in the present disclosure is for the purpose of describing the specific examples described herein, and is not intended to be limiting.

[0039] The following description is provided in connection with various examples that may share one or more common characteristics and / or features. It should be understood that one or more features of any one example may be combined with one or more features of another example or other examples. In addition, any single feature or combination of features in any of these examples may constitute an additional example.

[0040] 5.1 Treatment In one form, the present technology includes a method for treating a breathing disorder. The method includes applying positive pressure to the entrance of the airways of a patient 1000. In a particular example of the present technology, a supply of air at positive pressure is provided to the patient's nasal passages via one or both nostrils. In a particular example of the present technology, mouth breathing is restricted, limited, or prevented.

[0041] 5.2 Respiratory Treatment Systems In one form, the present technology includes a respiratory treatment system for the treatment of respiratory disorders. The respiratory treatment system may include an RPT device 4000 that delivers airflow to a patient 1000 via an air circuit 4170 and a patient interface 3000 or 3800.

[0042] 5.3 Patient Interface A non-invasive patient interface 3000 in accordance with one aspect of the present technology includes the following functional features: a seal-forming structure 3100, a plenum chamber 3200, a positioning and stabilizing structure 3300, a vent 3400, a form of connection port 3600 for connection to an air circuit 4170, and a forehead support 3700. In some forms, the functional features may be provided by one or more physical components. In some forms, a single physical component may provide one or more functional features. In use, the seal-forming structure 3100 is positioned to surround an entrance to the patient's 1000 airway passages so as to maintain positive pressure at the entrance(s) to the patient's airway passages. As such, the sealed patient interface 3000 is suitable for delivery of positive pressure therapy.

[0043] If the patient interface cannot comfortably deliver a minimum level of positive pressure to the airway, the patient interface may be unsuitable for respiratory pressure therapy.

[0044] A patient interface 3000 in accordance with one form of the present technology is constructed and arranged to provide an air supply at a positive pressure of at least 6 cmH2O relative to ambient.

[0045] A patient interface 3000 in accordance with one form of the present technology is constructed and arranged to provide an air supply at a positive pressure of at least 10 cmH2O relative to ambient.

[0046] A patient interface 3000 in accordance with one form of the present technology is constructed and arranged to provide an air supply at a positive pressure of at least 20 cmH2O relative to ambient.

[0047] 5.4 RPT Device An RPT device 4000 according to one aspect of the present technology includes mechanical, pneumatic, and / or electrical components and is configured to execute one or more algorithms 4300 (e.g., any of the methods, processes, software modules, etc. described herein, in whole or in part). The RPT device 4000 can be configured to generate an airflow that is delivered to a patient's airways for the treatment of, for example, one or more of the respiratory ailments described anywhere herein.

[0048] In one form, the RPT device 4000 is constructed and arranged to deliver airflow in the range of -20 L / min to +150 L / min while maintaining a positive pressure of at least 6 cmH2O, or at least 10 cmH2O, or at least 20 cmH2O.

[0049] Referring now to FIG. 4C , the RPT device 4000 can have an electrical power source 4210, one or more input devices 4220, a central controller 4230, a therapy device controller 4240, a pressure generator 4140, one or more protection circuits 4250, a memory 4260, a transducer 4270, a data communication interface 4280, and one or more output devices 4290. The electrical components 4200 can be mounted on a single printed circuit board assembly (PCBA) 4202. In an alternative, the RPT device 4000 can include more than one PCBA 4202. In certain exemplary embodiments, the RPT device 400 can include a computing device as described in connection with FIG. 11 . In certain examples, the electrical components described in connection with FIG. 4C can correspond to their counterparts as described in FIG. 11 .

[0050] 5.4.1 RPT Device Electrical Components 5.4.1.1 Power supply The power supply 4210 may be located inside or outside the housing of the RPT device 4000.

[0051] In one form of the present technology, the power supply 4210 powers only the RPT device 4000. In another form of the present technology, power is provided from the power supply 4210 to both the RPT device 4000 and the humidifier 5000.

[0052] 5.4.1.2 Input Devices In one form of the present technology, the RPT device 4000 includes one or more input devices 4220 in the form of buttons, switches, or dials to allow a human to interact with the device. The buttons, switches, or dials may be physical or software devices accessible via a touchscreen. The buttons, switches, or dials may be physically connected to the external housing 4010 in one form, or may communicate wirelessly with a receiver electrically connected to the central controller 4230 in another form.

[0053] In one form, input device 4220 may be constructed and arranged to allow a human to select values ​​and / or menu options.

[0054] 5.4.1.3 Central Controller In one form of the present technology, the central controller 4230 is one or more hardware processors suitable for controlling the RPT device 4000.

[0055] Suitable processors may include x86 INTEL processors, such as processors based on the ARM® Cortex®-M processor from ARM Holdings (e.g., the STM32 series of microcontrollers from STMicroelectronics). In certain alternative forms of the present technology, 32-bit RISC CPUs (e.g., the STR9 series of microcontrollers from ST Microelectronics) or 16-bit RISC CPUs (e.g., processors from the MSP430 family of microcontrollers (manufacturer: TEXAS INSTRUMENTS)) may also be suitable.

[0056] In one form of the present technology, the central controller 4230 is a specialized electronic circuit.

[0057] In one form, the central controller 4230 is an application specific integrated circuit. In another form, the central controller 4230 includes discrete electronic components.

[0058] The central controller 4230 may be configured to receive input signal(s) from one or more transducers 4270, one or more input devices 4220 and the humidifier 5000.

[0059] The central controller 4230 may be configured to provide output signal(s) to one or more of the output device 4290, the therapy device controller 4240, the data communication interface 4280, and the humidifier 5000.

[0060] In some forms of the present technology, the central controller 4230 is configured to implement one or more methods described herein (e.g., one or more algorithms 4300 (described in connection with FIG. 4D) expressed as a computer program stored in, such as, a non-transitory computer-readable storage medium (e.g., memory 4260)). In some forms of the present technology, the central controller 4230 may be integrated with the RPT device 4000. However, in some forms of the present technology, some methods may be performed by a remotely located computing device (e.g., computing device 1100). For example, the remotely located device may determine ventilator control settings or detect respiratory-related events through analysis of stored data (e.g., from any of the sensors described herein).

[0061] 5.4.1.4 Clock The RPT device 4000 may include a clock 4232 connected to the central controller 4230 .

[0062] 5.4.1.5 Therapy Device Controller In one form of the present technology, the therapy device controller 4240 is a therapy control module 4330 that forms part of the algorithm 4300 executed by the central controller 4230.

[0063] In one form of the present technology, the therapy device controller 4240 is a dedicated motor control integrated circuit. For example, in one form, the MC33035 Brushless DC Motor Controller (manufacturer: ONSEMI) is used.

[0064] 5.4.1.6 Protection circuit The one or more protection circuits 4250 according to the present technology may include electrical protection circuits, temperature and / or pressure safety circuits.

[0065] 5.4.1.7 Memory In accordance with one form of the present technology, the RPT device 4000 includes memory 4260 (e.g., non-volatile memory). In some forms, the memory 4260 may include battery-powered static RAM. In some forms, the memory 4260 may include volatile RAM.

[0066] Memory 4260 may be located on PCBA 4202. Memory 4260 may take the form of EEPROM or NAND flash.

[0067] Additionally or alternatively, the RPT device 4000 includes a removable form of memory 4260 (eg, a memory card made in accordance with the Secure Digital (SD) standard).

[0068] In one form of the present technology, the memory 4260 functions as a non-transitory computer-readable storage medium on which are stored computer program instructions (e.g., one or more algorithms 4300) embodying one or more of the methods described herein.

[0069] 5.4.1.8 Data communication systems In one form of the present technology, a data communications interface 4280 is provided and connected to the central controller 4230. The data communications interface 4280 may be connectable to a remote external communications network 4282 and / or a local external communications network 4284. The remote external communications network 4282 may be connectable to a remote external device 4286. The local external communications network 4284 may be connectable to a local external device 4288.

[0070] In one form, the data communication interface 4280 is part of the central controller 4230. In another form, the data communication interface 4280 is separate from the central controller 4230 and may include an integrated circuit or processor.

[0071] In one form, remote external communications network 4282 is the Internet. Data communications interface 4280 may use wired communications (e.g., via Ethernet or fiber optics) or wireless protocols (e.g., CDMA, GSM, LTE) to connect to the Internet.

[0072] In one form, the local external communications network 4284 uses one or more communications standards (eg, Bluetooth or consumer infrared protocols).

[0073] In one form, the remote external device 4286 is one or more computers (e.g., a cluster of networked computers). In one form, the remote external device 4286 may be a virtual computer rather than a physical computer. In either case, such a remote external device 4286 may be accessible to appropriately authorized personnel (e.g., a clinician).

[0074] The local external device 4288 may be a personal computer, a mobile phone, a tablet or a remote control and communicates with the data communication interface 4280 of the RPT device 4000 via a local external communication network 4284.

[0075] 5.4.1.9 Optional displays and output devices, including warnings Output devices 4290 according to the present technology may take the form of one or more of visual, audio and tactile units. A visual display may be a liquid crystal display (LCD) or a light emitting diode (LED) display.

[0076] 5.4.1.9.1 Display Driver Display driver 4292 receives as input characters, symbols or images to be displayed on display 4294 and converts these into commands that cause display 4294 to display the characters, symbols or images.

[0077] 5.4.1.9.2 Display Display 4294 is configured to visually display characters, symbols, or images in response to commands received from display driver 4292. For example, display 4294 may be an eight-segment display, in which case each character or symbol (e.g., the number "0") is converted by display driver 4292 into eight logic signals (indicating which of the eight segments is activated to display the particular character or symbol).

[0078] 5.4.1.10 Transducer(s) The transducer 4270 may be provided internal to the RPT device or external to the RPT device. An external transducer may, for example, be located on the air circuit or form part of the air circuit (e.g., a patient interface). The external transducer may take the form of a non-contact sensor (e.g., a Doppler radar movement sensor that transmits or moves data RPT device).

[0079] In one form of the present technology, one or more transducers 4270 are positioned upstream and / or downstream of the pressure generator. The one or more transducers 4270 may be constructed and arranged to generate a signal indicative of a characteristic of the airflow (e.g., flow rate, pressure, or temperature at that point in the pneumatic path).

[0080] In one form of the present technology, one or more transducers 4270 may be positioned proximate the patient interface 3000.

[0081] In one form, the signal from the converter 4270 may be filtered, for example, by low-pass, high-pass, or band-pass filtering.

[0082] 5.4.1.10.1 Flow Sensor A flow sensor 4274 according to the present technology may be based on a differential pressure transducer (eg, SDP600 series differential pressure transducers from SENSIRION).

[0083] In one form, a signal generated by the flow sensor 4274 and representative of the flow rate is received by the central controller 4230.

[0084] 5.4.1.10.2 Pressure Sensor A pressure sensor 4272 according to the present technology can be placed in fluid communication with the pneumatic path. One example of a suitable pressure sensor is a transducer from the HONEYWELL ASDX series. Another suitable pressure sensor is a transducer from the NPA series from GENERAL ELECTRIC.

[0085] In one form, the signal generated by the pressure sensor 4272 is received by the central controller 4230.

[0086] 5.4.1.10.3 Motor Speed ​​Converter In one form of the present technology, a motor speed transducer 4276 is used to determine the rotational speed of the motor and / or blower of the RPT device 4000. A motor speed signal from the motor speed transducer 4276 may be provided to the therapy device controller 4240. The motor speed transducer 4276 may be, for example, a speed sensor (e.g., a Hall effect sensor).

[0087] 5.4.2 RPT Device Algorithm As noted above, in some forms of the present technology, the central controller 4230 may be configured to execute one or more algorithms 4300, such as those shown in Figure 4D. These algorithms may be expressed as computer programs stored in a non-transitory computer-readable storage medium (e.g., memory 4260). The algorithms 4300 are generally grouped into modules or groups called software modules.

[0088] In other forms of the present technology, part or all of the algorithm 4300 may be embodied by a controller of an external device, such as a local external device 4288 or a remote external device 4286. In such forms, input signals required for the portion of the algorithm 4300 executed on the external device and / or data representing intermediate algorithm outputs may be communicated to the external device via a local external communications network 4284 or a remote external communications network 4282. In such forms, the portion of the algorithm 4300 executed on the external device may be represented as a computer program stored on a non-transitory computer-readable storage medium accessible to the controller of the external device. Such a program configures the controller of the external device to execute part of the algorithm 4300.

[0089] In such an embodiment, treatment parameters generated by the external device via the treatment engine module 4320 (in such an embodiment, some portions of the algorithm 4300 are executed by the external device) may be communicated to the central controller 4230 and passed to the treatment control module 4330.

[0090] 5.4.2.1 Pre-processing module A pre-processing module 4310 in accordance with one form of the present technology receives as input a signal from a transducer 4270 (e.g., a flow sensor 4274 or a pressure sensor 4272) and performs one or more process steps to calculate one or more output values ​​that are used as inputs to another module (e.g., a therapy engine module 4320).

[0091] In one form of the present technology, the output values ​​include interface pressure Pm, respiratory flow Qr and leak flow Ql.

[0092] In various forms of the present technology, the pre-processing module 4310 includes one or more of the following algorithms: interface pressure estimation 4312, ventilation flow estimation 4314, leak flow estimation 4316, and respiratory flow estimation 4318.

[0093] 5.4.2.1.1 Interface Pressure Estimation In one form of the present technology, an interface pressure estimation algorithm 4312 receives as input a signal indicative of the pressure in the pneumatic path near the outlet of the pneumatic block (device pressure Pd) from a pressure sensor 4272 and a signal indicative of the flow rate of the airflow exiting the RPT device 4000 (device flow Qd) from a flow sensor 4274. The device flow Qd, which does not include any supplemental gas, may be used as the total flow Qt. The interface pressure estimation algorithm 4312 estimates the pressure drop ΔP through the air circuit 4170. The dependency of the pressure drop ΔP on the total flow Qt may be modeled for a particular air circuit 4170 by a pressure drop characteristic ΔP(Q). The interface pressure estimation algorithm 4312 then provides as output an estimated pressure Pm in the patient interface 3000 or 3800. The pressure Pm in the patient interface 3000 or 3800 may be estimated as the device pressure Pd minus the air circuit pressure drop ΔP.

[0094] 5.4.2.1.2 Airflow rate estimation In one form of the present technology, an airflow estimation algorithm 4314 receives as input the estimated pressure Pm in the patient interface 3000 or 3800 from the interface pressure estimation algorithm 4312 and estimates the airflow Qv of air from the vent 3400 in the patient interface 3000 or 3800. The usage dependency of the airflow Qv on the interface pressure Pm at a particular vent 3400 may be modeled by an airflow characteristic Qv(Pm).

[0095] 5.4.2.1.3 Estimation of leakage flow rate In one form of the present technology, a leak flow estimation algorithm 4316 receives as input the total flow Qt and the ventilation flow Qv and provides as output an estimate of the leak flow Ql, hi one form, the leak flow estimation algorithm estimates the leak flow Ql by calculating the average difference between the total flow Qt and the ventilation flow Qv over a period long enough to include several respiratory cycles (e.g., about 10 seconds).

[0096] In one form, the leak flow estimation algorithm 4316 provides a leak flow Ql as an output and receives as inputs the total flow Qt, ventilation flow Qv, and estimated pressure Pm in the patient interface 3000 or 3800 by calculating the leak conductance and determining the leak flow Ql as a function of the leak conductance and the pressure Pm. The leak conductance is calculated as the low-pass filtered square root of the pressure Pm and the quotient of the low-pass filtered non-ventilated flow equal to the difference between the total flow Qt and the ventilation flow Qv, with the low-pass filter time constant having a value sufficient to include several respiratory cycles (e.g., about 10 seconds). The leak flow Ql may be estimated as the product of the leak conductance and the pressure function Pm.

[0097] 5.4.2.1.4 Respiratory flow estimation In one form of the present technology, the respiratory flow estimation algorithm 4318 receives as inputs the total flow Qt, ventilation flow Qv and leakage flow Ql and estimates the respiratory airflow Qr for the patient (by dividing the ventilation flow Qv and leakage flow Ql from the total flow Qt). 5.4.2.2 Treatment Engine Module

[0098] In one form of the present technology, the therapy engine module 4320 receives as inputs one or more of the pressure Pm in the patient interface 3000 or 3800 and the respiratory flow of air Qr to the patient and provides one or more therapy parameters as outputs.

[0099] In one form of the present technology, the treatment parameter is a treatment pressure, Pt.

[0100] In one form of the present technology, the treatment parameters are one or more of the amplitude of pressure change, base pressure, and target ventilation.

[0101] In various embodiments, the therapy engine module 4320 includes one or more of the following algorithms: phase determination 4321, waveform determination 4322, ventilation determination 4323, inspiratory flow limitation determination 4324, apnea / hypopnea determination 4325, snoring determination 4326, airway patency determination 4327, target ventilation determination 4328, and therapy parameter determination 4329.

[0102] 5.4.2.2.1 Phase Determination In one form of the present technology, the RPT device 4000 does not determine the phase.

[0103] In one form of the present technology, a phase determination algorithm 4321 receives as an input a signal indicative of respiratory flow Qr and provides as an output Φ the phase of the patient's 1000 current respiratory cycle.

[0104] In some forms known as discrete phase determination, the phase output Φ is a discrete variable. One implementation of discrete phase determination provides a binary phase output Φ having a value of inspiration or expiration, represented, for example, as values ​​of 0 revolutions and 0.5 revolutions (upon detection of the onset of spontaneous inspiration and expiration, respectively). The RPT device 4000 that "triggers" and "cycles" effectively performs discrete phase determination because the trigger and cycle points are the instants at which the phase changes from expiration to inspiration and inspiration to expiration, respectively. In one implementation of binary phase determination, the phase output Φ is determined to have a discrete value of 0 (thereby "trigging" the RPT device 4000) when respiratory flow Qr has a value greater than a positive threshold, and a discrete value of 0.5 revolutions (thereby "cycling" the RPT device 4000) when the value of respiratory flow Qr is more negative than a negative threshold. The inspiration time Ti and expiration time Te may be typical values ​​estimated over many respiratory cycles of time spent with phase Φ equal to 0 (indicating inspiration) and 0.5 (indicating expiration), respectively.

[0105] Another implementation of the discrete phase decision results in a three-valued phase output Φ with one value of inspiration, pause during inspiration, and expiration.

[0106] In other forms, known as continuous phase determination, the phase output Φ is a continuous variable, varying, for example, between 0 and 1 revolution or 0 and 2π radians. An RPT device 4000 with continuous phase determination may trigger and cycle when the continuous phase reaches 0 and 0.5 revolutions, respectively. In one implementation of continuous phase determination, the continuous value of phase Φ is determined using fuzzy logic analysis of the respiratory flow Qr. The continuous value of phase determined in this implementation is often referred to as the "fuzzy phase." In one implementation of the fuzzy phase determination algorithm 4321, the following rules are applied to the respiratory flow Qr: 1. When respiratory flow is zero and increasing rapidly, the number of phase rotations is 0. 2. When respiratory flow is large, positive, and stable, the phase rotation rate is 0.25. 3. If respiratory flow is zero and rapidly decreasing, the phase rotation rate is 0.5. 4. When respiratory flow is large and stable, the phase rotation rate is 0.75. 5. When respiratory flow is zero and stable and the 5-second low-pass filtered absolute value of respiratory flow is large, the phase rotation number is 0.9. 6. If the respiratory flow is positive and the phase is exhalation, the number of rotations of the phase is 0. 7. If respiratory flow is negative and the phase is inspiration, the number of phase rotations is 0.5. 8. If the 5 second low-pass filtered absolute value of respiratory flow is large, the phase increases at a constant rate equal to the patient's respiratory rate low-pass filtered by a 20 second time constant.

[0107] The output of each rule can be represented as a vector, where the phase is the result of the rule and the magnitude is the fuzzy range (where the rule is true). The fuzzy ranges where respiratory flow is, for example, "high" or "stable" are determined by appropriate membership functions. The rule results, represented as vectors, are then combined by some function (e.g., taking a centroid). In such a combination, the rules may be weighted equally or differently.

[0108] In another implementation of continuous phase determination, phase Φ, as well as inspiration time Ti and expiration time Te, are first estimated separately from respiratory flow Qr as described above. Continuous phase Φ at any instant is determined as half the fraction of inspiration time Ti that has elapsed since the preceding trigger instant, or 0.5 revolutions, plus the fraction of expiration time Te that has elapsed since the preceding cycle instant (whichever is more recent).

[0109] 5.4.2.2.2 Waveform determination In one form of the present technology, the therapy parameter determination algorithm 4329 provides a nearly constant therapy pressure throughout the patient's respiratory cycle.

[0110] In another form of the present technology, the therapy control module 4330 controls the pressure generator 4140 to provide a therapy pressure Pt that varies as a function of the phase Φ of the patient's respiratory cycle according to a waveform template Π(Φ).

[0111] In one form of the present technology, the waveform determination algorithm 4322 provides a waveform template Π(Φ) having values ​​in the range [0,1] for the domain of the phase values ​​Φ provided by the phase determination algorithm 4321 to be used by the treatment parameter determination algorithm 4329.

[0112] In one embodiment, suitable for a discrete or continuous phase, the waveform template Π(Φ) is a square wave template having a value of 1 for phase values ​​up to 0.5 revolutions and a value of 0 for phase values ​​above 0.5 revolutions. In one embodiment, suitable for a continuous phase, the waveform template Π(Φ) includes two smoothly curved sections (i.e., a smoothly curved (e.g., raised cosine) rise from 0 to 1 for phase values ​​up to 0.5 revolutions, and a smoothly curved (e.g., exponential) fall from 1 to 0 for phase values ​​above 0.5 revolutions). In one embodiment, suitable for a continuous phase, the waveform template Π(Φ) is based on a square wave, but has a smooth rise from 0 to 1 for phase values ​​up to a "rise time" below 0.5 revolutions, and a smooth fall from 1 to 0 for phase values ​​within a "fall time" after 0.5 revolutions, with a "fall time" below 0.5 revolutions.

[0113] In some forms of the present technology, the waveform determination algorithm 4322 selects a waveform template Π(Φ) from a library of waveform templates depending on the settings of the RPT device. Each waveform template Π(Φ) in the library may be provided as a look-up table of values ​​Π versus phase values ​​Φ. In other forms, the waveform determination algorithm 4322 calculates the waveform template Π(Φ) "on the fly" using a predetermined functional form, perhaps parameterized by one or more parameters (e.g., the time constant of an exponential curve portion). These parameters of the functional form may be predetermined or may depend on the current state of the patient 1000.

[0114] In some forms of the present technology suitable for the discrete binary phase of inspiration (Φ=0 revolutions) or expiration (Φ=0.5 revolutions), the waveform determination algorithm 4322 calculates the waveform template Π "on the fly" as a function of the discrete phase Φ and time t measured from the most recent trigger instant. In one such form, the waveform determination algorithm 4322 calculates the waveform template Π(Φ,t) in two parts (inspiration and expiration) as follows:

number

[0115] 5.4.2.2.3 Ventilation determination In one form of the present technology, a ventilation determination algorithm 4323 receives respiratory flow Qr as an input and determines a measurement indicative of the current patient ventilation Vent.

[0116] In some implementations, the ventilation determination algorithm 4323 determines a measurement of ventilation Vent that is an estimate of actual patient ventilation. One such implementation is to take half of the absolute value of the respiratory flow rate Qr, which is optionally filtered by a low-pass filter (e.g., a second-order Bessel low-pass filter) with a corner frequency of 0.11 Hz.

[0117] In other implementations, the ventilation determination algorithm 4323 determines a measurement of ventilation Vent that is broadly proportional to actual patient ventilation. In one such implementation, the peak respiratory flow rate Qpeak is estimated over the inspiratory portion of the cycle. Using the above and other procedures with sampling of the respiratory flow rate Qr, a measurement that is broadly proportional to ventilation is generated (provided that the flow waveform does not change significantly, where the two respiratory shapes are taken as similar if the flow waveforms of the respirations normalized in time and amplitude are similar). To give some simple examples, there are the median of the positive respiratory flow rates, the median of the absolute values of the respiratory flow rates, and the standard deviation of the flow rates. Any linear combination of any order statistic of the absolute value of the respiratory flow rate using positive coefficients (and even using both positive and negative coefficients) is generally proportional to ventilation. As another example, there is the average of the respiratory flow rate at the (temporal) mid-K proportion of the inspiratory portion, where 0 < K < 1. When the flow shape is constant, there are any number of measurements that are highly proportional to ventilation.

[0118] 5.4.2.2.4 Determination of Inspiratory Flow Limitation In one form of the technology, the central controller 4230 executes an inspiratory flow limitation determination algorithm 4324 for determining a range of inspiratory flow limitation.

[0119] In one form, the inspiratory flow limitation determination algorithm 4324 receives the respiratory flow rate signal Qr as an input and provides as an output a measure of the range in which the inspiratory portion of the respiration indicates an inspiratory flow limitation.

[0120] In one form of the present technology, the inspiration portion of each breath is identified by a zero-crossing detector. A number of equally spaced points (e.g., 65 points) representing time points are interpolated along the inspiration flow-time curve for each breath by an interpolator. The curve described by these points is then scaled to have unit length (duration / period) and unit area by a scaler, thereby eliminating the effects of changes in breathing rate and depth. The scaled breath is then compared in a comparator to a pre-stored template (similar to the inspiration portion of the breath shown in FIG. 6A) representing a normal, unobstructed breath. If at any point during inspiration the breath deviates from this template (as determined by a test element) by more than a specified threshold (typically 1 scaling unit) (e.g., due to coughing, sighing, swallowing, or hiccuping), it is rejected. If the data is not rejected, a running average of the first such scaled point is calculated by the central controller 4230 for several preceding inspiration events. This is then repeated for the same inspiration event, for example, for a second such point. Thus, for example, 65 scaled data points may be generated by the central controller 4230 to represent a moving average of several preceding inspiratory events (e.g., three events). Hereinafter, this moving average of successively updated values ​​of (e.g., 65) points will be referred to as the "scaled flow rate" and designated as Qs(t). Alternatively, a single inspiratory event may be used in place of the moving average.

[0121] From the scaled flow rate, two shape factors relevant to determining partial occlusion can be calculated.

[0122] The shape factor 1 is the ratio of the mean of the midpoint (e.g., 32) scaled flow points to the overall mean (e.g., 65) scaled flow points. If this ratio exceeds 1, the breath is considered normal. If this ratio is less than or equal to 1, the breath is considered obstructed. A ratio of approximately 1.17 is taken as the threshold between partially obstructed and unobstructed breaths, equivalent to a certain level of obstruction, allowing maintenance of adequate oxygen administration in a typical patient.

[0123] Shape factor 2 is calculated as the mean square deviation from unit-scaled flow rate, taken over intermediate (e.g., 32) points. A mean square deviation of approximately 0.2 units is considered normal. A mean square deviation of zero is considered globally respiratory flow limited. The closer the mean square deviation is to zero, the more pronounced the respiratory flow limitation is considered.

[0124] Shape factors 1 and 2 may be used alternatively or in combination. In other forms of the present technology, the number of sampled points, breaths, and midpoints may be different from those described above. Additionally, the thresholds may also be different from those described above.

[0125] 5.4.2.2.5 Apnea and Hypopnea Determination In one form of the present technology, the central controller 4230 executes an apnea / hypopnea determination algorithm 4325 for determining the presence of apneas and / or hypopneas.

[0126] In one form, the apnea / hypopnea decision algorithm 4325 receives as an input the respiratory flow signal Qr and provides as an output a flag indicating whether an apnea or hypopnea has been detected.

[0127] In one form, apnea is detected when a function of respiratory flow Qr falls below a flow threshold for a predetermined period of time. The function may determine peak flow, a relatively short-term average flow, or a flow intermediate between the relatively short-term average and peak flow (e.g., RMS flow). The flow threshold may be a relatively long-term measure of flow.

[0128] In one form, hypopnea is detected when a function of respiratory flow Qr falls below a second flow threshold for a predetermined period of time. This function may determine peak flow, a relatively short-term average flow, or a flow intermediate between the relatively short-term average and peak flow (e.g., RMS flow). The second flow threshold may be a relatively long-term measure of flow. The second flow threshold is higher than the flow threshold used to detect apnea.

[0129] 5.4.2.2.6 Snoring Determination In one form of the present technology, a central controller 4230 executes one or more snore determination algorithms 4326 for determining the extent of snoring.

[0130] In one form, the snore determination algorithm 4326 receives as an input the respiratory flow signal Qr and provides as an output a measure of the extent to which snoring is present.

[0131] The snore determination algorithm 4326 may include determining the strength of the flow signal within the range of 30-300 Hz. Additionally, the snore determination algorithm 4326 may include filtering the respiratory flow signal Qr to reduce background noise (e.g., airflow noise in the system from the blower).

[0132] 5.4.2.2.7 Determining Airway Patency In one form of the present technology, the central controller 4230 executes one or more airway patency determination algorithms 4327 for determining the extent of airway patency.

[0133] In one form, the airway patency determination algorithm 4327 receives as input the respiratory flow signal Qr and determines the power of the signal within a frequency range of about 0.75 Hz to about 3 Hz. The presence of a peak within this frequency range is considered to indicate an open airway. The absence of a peak is considered to indicate an airway closure.

[0134] In one embodiment, the frequency range searched for the peak is the frequency of a small forced oscillation at the treatment pressure Pt. In one implementation, the forced oscillation has a frequency of 2 Hz and an amplitude of approximately 1 cmH2O.

[0135] In one form, the airway patency determination algorithm 4327 receives as input the respiratory flow signal Qr and determines the presence or absence of a cardiogenic signal. If a cardiogenic signal is absent, it is assumed that there is an airway obstruction.

[0136] 5.4.2.2.8 Determining target ventilation In one form of the present technology, the central controller 4230 takes as input a measurement of the current ventilation, Vent, and executes one or more target ventilation determination algorithms 4328 for the determination of a target value, Vtgt, for the ventilation measurement.

[0137] In some forms of the present technology, there is no target ventilation determination algorithm 4328, and the target value Vtgt is predetermined, for example by hard coding during configuration of the RPT device 4000 or by manual entry through the input device 4220.

[0138] In other forms of the present technology, such as adaptive servo ventilation (ASV), the target ventilation determination algorithm 4328 calculates a target value Vtgt from the value Vtyp that is indicative of the patient's typical recent ventilation.

[0139] In some forms of adaptive servo-ventilation, the target ventilation Vtgt is calculated as a high percentage of the typical recent ventilation Vtyp and a value less than the typical recent ventilation Vtyp. The high percentage in such forms can be in the range (80%, 100%) or (85%, 95%) or (87%, 92%).

[0140] In other forms of adaptive servo-ventilation, the target ventilation, Vtgt, is calculated as a slightly greater than one multiple of the typical current ventilation, Vtyp.

[0141] Typical recent ventilation Vtyp is the value around which the distribution of measurements of current ventilation Vent over multiple times over a certain predetermined time scale tends to cluster (i.e., a measure of central tendency of measurements of current ventilation over recent history). In one implementation of the target ventilation determination algorithm 4328, the recent history may be on the order of several minutes, but in any case should be longer than the time scale of a Cheyne-Stokes ramp-up and ramp-down cycle. The target ventilation determination algorithm 4328 may use any of a variety of well-known measures of central tendency to determine typical recent ventilation Vtyp from measurements of current ventilation Vent. One such measure is the output of a low-pass filter on measurements of current ventilation Vent, with a time constant equal to 100 seconds.

[0142] 5.4.2.2.9 Determination of Treatment Parameters In some forms of the present technology, the central controller 4230 executes one or more treatment parameter determination algorithms 4329 for determining one or more treatment parameters using values ​​returned from one or more of the other algorithms in the treatment engine module 4320.

[0143] In one form of the present technology, the treatment parameter is the instantaneous treatment pressure Pt. In one implementation of this form, the treatment parameter determination algorithm 4329 determines the treatment pressure Pt using the above formula:

number

[0144] If the waveform determination algorithm 4322 provides the waveform template Π(Φ,t) as a lookup table of values ​​Π indexed by the phase Φ, the treatment parameter determination algorithm 4329 applies equation (1) by locating the closest lookup table entry to the current value Φ of the phase returned from the phase determination algorithm 4321 or by interpolating between two entries that span the current value Φ of the phase.

[0145] The value of the amplitude A base pressure P0 can be set in the manner described below depending on the respiratory pressure treatment mode selected by the treatment parameter determination algorithm 4329.

[0146] 5.4.2.3 Treatment Control Module The therapy control module 4330 according to one aspect of the present technology receives as input therapy parameters from the therapy parameter determination algorithm 4329 of the therapy engine module 4320 and controls the pressure generator 4140 to deliver airflow from the pressure generator in accordance with these therapy parameters.

[0147] In one form of the present technology, the treatment parameter is a treatment pressure Pt, and the treatment control module 4330 controls the pressure generator 4140 to deliver an airflow from the pressure generator 4140 such that the interface pressure Pm at the patient interface 3000 or 3800 is equal to the treatment pressure Pt.

[0148] 5.4.2.4 Detecting Fault Conditions In one form of the present technology, the central controller 4230 executes one or more methods 4340 for detecting a fault condition. The fault condition detected by the one or more methods 4340 may include at least one of the following: ● Power outage (no power or power shortage) ● Converter failure detection ● No detection of the presence of components ● Operating parameters are outside the recommended range (e.g., pressure, flow, temperature, PaO2) • No test warning for the generation of a detectable warning signal.

[0149] When a fault condition is detected, the corresponding algorithm 4340 signals the presence of the fault by one or more of the following: ● Initiation of audible, visual and / or kinetic (e.g., vibration) warnings. ● Sending messages to external devices Incident recording

[0150] 5.5 Air Circuit The air circuit 4170 according to one aspect of the present technology is a conduit or tube constructed and arranged such that, in use, air flow travels between two components (e.g., the RPT device 4000 and the patient interface 3000 or 3800).

[0151] In particular, the air circuit 4170 may be fluidly connected to the outlet of the pneumatic block and the patient interface. The air circuit may be referred to as an air delivery tube. In some cases, separate legs of the circuit may be provided for inhalation and exhalation. In other cases, a single leg is used.

[0152] In some forms, the air circuit 4170 may include one or more heating elements configured to heat the air in the air circuit, for example, to maintain or increase the air temperature. The heating elements may take the form of a hot wire circuit and may include one or more transducers (e.g., temperature sensors). In one form, the hot wire circuit may be spirally wound around the axis of the air circuit 4170. The heating elements may be in communication with a controller (e.g., central controller 4230).

[0153] 5.6 Humidifier In one form of the present technology, a humidifier 5000 is provided (for example as shown in FIG. 5A) for altering the absolute humidity of air or gas to be delivered to a patient relative to ambient air. Typically, the humidifier 5000 is used to increase the absolute humidity and raise the temperature (relative to ambient air) of the air stream prior to delivery to the patient's respiratory tract.

[0154] The humidifier 5000 may include a humidifier reservoir 5110, a humidifier inlet 5002 that receives an airflow, and a humidifier outlet 5004 for delivering a humidified airflow. In some forms, such as shown in Figures 5A and 5B, the inlet and outlet of the humidifier reservoir 5110 may be the humidifier inlet 5002 and the humidifier outlet 5004, respectively. The humidifier 5000 may further include a humidifier base 5006. The humidifier base 5006 may be adapted to receive the humidifier reservoir 5110 and may include a heating element 5240.

[0155] The humidifier reservoir 5110 may include a water level indicator 5150, as shown in Figures 5A-5B. In some arrangements, the humidifier reservoir dock 5130 may include a locking feature (e.g., a locking lever 5135 configured to hold the reservoir 5110 within the humidifier reservoir dock 5130). According to one arrangement, the reservoir 5110 includes a conductive portion 5120 configured to enable efficient heat transfer from the heating element 5240 to the volume of liquid in the reservoir 5110. In one form, the conductive portion 5120 may be arranged as a plate, although other shapes may be suitable.

[0156] 5.7 Respiratory waveform Figure 6A shows a model of a typical human respiratory waveform during sleep. The horizontal axis is time, and the vertical axis is respiratory flow. Because parameter values ​​can vary, a typical breath may have the following approximate values: tidal volume, Vt, 0.5 L; inspiratory time, Ti, 1.6 seconds; peak inspiratory flow, Qpeak, 0.4 L / sec; expiratory time, Te, 2.4 seconds; peak expiratory flow, Qpeak, -0.5 L / sec. The total duration of the breath, Ttot, is approximately 4 seconds. Humans typically breathe at approximately 15 breaths per minute (BPM), with a ventilation, Vent, of approximately 7.5 L / min. A typical duty cycle, the ratio of Ti to Ttot, is approximately 40%.

[0157] 5.8 Respiratory Therapy Mode A variety of respiratory therapy modes can be implemented by the disclosed respiratory therapy system.

[0158] 5.8.1 CPAP treatment In some implementations of respiratory pressure therapy, the central controller 4230 sets the therapy pressure Pt according to the therapy pressure equation (1) as part of the therapy parameter determination algorithm 4329. In some such implementations, the amplitude A is equal to zero, so that the therapy pressure Pt (representing the target value achieved by the interface pressure Pm at the current instant in time) is equal to the base pressure P0 throughout the respiratory cycle. Such implementations are generally grouped under the heading of CPAP therapy. In such implementations, the therapy engine module 4320 is not required to determine the phase Φ or waveform template Π(Φ).

[0159] In CPAP therapy, the base pressure P0 may be a constant value, hard-coded or manually entered into the RPT device 4000. The central controller 4230 may iteratively calculate the base pressure P0 as a function of sleep disordered breathing indicators or measurements (e.g., one or more of flow limitation, apnea, hypopnea, patency, and snoring) returned from each algorithm in the therapy engine module 4320. This alternative is also referred to as APAP therapy.

[0160] 4E is a flow chart illustrating a method 4500 executed by the central controller 4230. In the method 4500, when the pressure support A is equal to zero, the base pressure P0 is continuously calculated as part of the APAP therapy implementation of the therapy parameter determination algorithm 4329.

[0161] Method 4500 begins at step 4520. In step 4520, the central controller 4230 compares the measurement of the presence of apnea / hypopnea to a first threshold to determine whether the measurement of the presence of apnea / hypopnea exceeds the first threshold for a predetermined period of time (indicating the occurrence of an apnea / hypopnea). Method 4500 proceeds to step 4540; if not, method 4500 proceeds to step 4530. In step 4540, the central controller 4230 compares the measurement of airway patency to a second threshold. If the measurement of airway patency exceeds the second threshold, indicating a patent airway, the detected apnea / hypopnea is deemed to be central, and method 4500 proceeds to step 4560. If the measurement of airway patency does not exceed the second threshold, the apnea / hypopnea is deemed to be obstructive, and method 4500 proceeds to step 4550.

[0162] In step 4530, the central controller 4230 compares the measure of flow limitation to a third threshold. If the measure of flow limitation exceeds the third threshold, it indicates that the inspiratory flow is limited. In that case, the method 4500 proceeds to step 4550. If the measure of flow limitation does not exceed the third threshold, the method 4500 proceeds to step 4560.

[0163] In step 4550, if the resulting therapeutic pressure Pt does not exceed the maximum therapeutic pressure Pmax, the central controller 4230 increases the base pressure P0 by a predetermined pressure increment ΔP. In one implementation, the predetermined pressure increment ΔP and the maximum therapeutic pressure Pmax are 1 cmH2O and 25 cmH2O, respectively. In other implementations, the pressure increment ΔP can be as low as 0.1 cmH2O and as high as 3 cmH2O, or as low as 0.5 cmH2O and as high as 2 cmH2O. In other implementations, the maximum therapeutic pressure Pmax can be as low as 15 cmH2O and as high as 35 cmH2O, or as low as 20 cmH2O and as high as 30 cmH2O. The method 4500 then returns to step 4520.

[0164] In step 4560, if the reduced base pressure P is not below the minimum therapeutic pressure P, the central controller 4230 reduces the base pressure P by a decrement. The method 4500 then returns to step 4520. In one implementation, the decrement is proportional to the value of P minus P, so that in the absence of a detected event, the reduction of P to the minimum therapeutic pressure P is exponential. In one implementation, the proportionality constant is set so that the time constant τ of the exponential reduction of P is 60 minutes and the minimum therapeutic pressure P is 4 cmH2O. In other implementations, the time constant τ can be as short as 1 minute and as long as 300 minutes, or as short as 5 minutes and as long as 180 minutes. In other implementations, the minimum therapeutic pressure P can be as low as 0 cmH2O and as high as 8 cmH2O, or as low as 2 cmH2O and as high as 6 cmH2O. Alternatively, the decrement of P0 may be predetermined such that the decrease of P0 to the minimum therapeutic pressure Pmin is linear in the absence of a detected event.

[0165] 5.8.2 Bilevel therapy In other implementations of this form of the technology, the value of the amplitude A in equation (1) can be positive. Such implementations are known as bilevel therapy because when the treatment pressure Pt is determined using equation (1) with a positive amplitude A, the treatment parameter determination algorithm 4329 oscillates the treatment pressure Pt between two values ​​or levels in synchronization with the patient's 1000 spontaneous breathing efforts. That is, based on the exemplary waveform template Π(Φ,t) described above, the treatment parameter determination algorithm 4329 increases the treatment pressure Pt to P0+A (known as IPAP) at the beginning or during inspiration and decreases the treatment pressure Pt to the base pressure P0 (known as EPAP) at the beginning or during expiration.

[0166] In some forms of bilevel therapy, IPAP is the same therapeutic pressure as in CPAP therapy, and EPAP is IPAP minus amplitude A, a "small" value (a few cmH2O) also known as expiratory pressure release (EPR). This form is also known as EPR-assisted CPAP therapy and is generally considered more comfortable than direct CPAP therapy. In EPR-assisted CPAP therapy, either or both of IPAP and EPAP may be constant values, hard-coded or manually entered into the RPT device 4000. Alternatively, the therapy parameter determination algorithm 4329 may iteratively calculate IPAP and / or EPAP during EPR-assisted CPAP. In this alternative example, the therapy parameter determination algorithm 4329 iteratively calculates EPAP and / or IPAP as a function of sleep-disordered breathing indicators or measurements returned from the respective algorithms in the therapy engine module 4320. This is done similarly to the calculation of base pressure P0 in APAP therapy, as described above.

[0167] In other forms of bilevel therapy, the amplitude A is large enough to allow the RPT device 4000 to perform some or all of the respiratory functions of the patient 1000. In this form, known as pressure support ventilation therapy, the amplitude A is referred to as pressure support or swing. In pressure support ventilation therapy, IPAP is the base pressure P0 plus pressure support A, and EPAP is the base pressure P0.

[0168] In some forms of pressure support ventilation therapy, known as constant pressure support ventilation therapy, the pressure support A is fixed at a predetermined value (e.g., 10 cmH2O). This predetermined pressure support value is a setting of the RPT device 4000 and may be set, for example, by hard coding when configuring the RPT device 4000, or by manual entry via the input device 4220.

[0169] In another form of pressure-support ventilation therapy, broadly known as servo-ventilation, the therapy parameter determination algorithm 4329 takes as inputs a certain currently measured or estimated parameter of the respiratory cycle (e.g., the current measurement of ventilation, Vent) and a target value for that respiratory parameter (e.g., the target value of ventilation, Vtgt), and iteratively adjusts the parameters of equation (1) to bring the current measurement of the respiratory parameter closer to the target value. In a form of servo-ventilation known as adaptive servo-ventilation (ASV), which is used in CSR therapy, the respiratory parameter is ventilation, and the target ventilation, Vtgt, is calculated by the target ventilation determination algorithm 4328 from a typical recent ventilation, Vtyp, as described above.

[0170] In some forms of servo-ventilation, the therapy parameter determination algorithm 4329 applies a control method that iteratively calculates pressure support A to drive a current measurement of a respiratory parameter toward a target value. One such control method is proportional-integral (PI) control. In one implementation of PI control suitable for ASV mode, where the target ventilation Vtgt is set to be slightly lower than the typical recent ventilation Vtyp, pressure support A is iteratively calculated as follows:

number

[0171] Other servo-ventilation control methods that may be applied by the therapy parameter determination algorithm 4329 include proportional (P), proportional-derivative (PD) and proportional-integral-derivative (PID).

[0172] The value of pressure support A calculated via equation (2) may be clipped to a range defined as [Amin, Amax]. In this implementation, pressure support A defaults to the minimum pressure support Amin until the current ventilation Vent measurement (which is the point at which A begins to increase) falls below the target ventilation Vtgt, only to drop back down to Amin when Vent again exceeds Vtgt.

[0173] The pressure support limits Amin and Amax are settings of the RPT device 4000 and may be set, for example, by hard coding when configuring the RPT device 4000 or by manual entry through the input device 4220.

[0174] In pressure support ventilation therapy mode, the EPAP is the base pressure P0. Similar to the base pressure P0 in CPAP therapy, the EPAP can be a constant value, prescribed or determined during titration. Such a constant EPAP may be set, for example, by hard coding during configuration of the RPT device 4000, or by manual entry via the input device 4220. This alternative is also referred to as fixed EPAP pressure support ventilation therapy. Titration of the EPAP for a given patient can be performed by a clinician during a titration session using PSG for the purpose of preventing obstructive apnea, thereby maintaining an open airway for pressure support ventilation therapy in a manner similar to titration of the base pressure P0 in constant CPAP therapy.

[0175] Alternatively, the therapy parameter determination algorithm 4329 may repeatedly calculate a base pressure P during pressure support ventilation therapy. In such an implementation, the therapy parameter determination algorithm 4329 repeatedly calculates EPAP as a function of sleep disordered breathing indicators or measurements (e.g., one or more of flow limitation, apnea, hypopnea, patency, and snoring) returned from each algorithm in the therapy engine module 4320. Because the continuous calculation of EPAP is similar to a clinician's manual adjustment of EPAP during EPAP titration, this process is also referred to as auto-titration of EPAP, and the therapy mode is known as auto-titration EPAP pressure support ventilation therapy or automatic EPAP pressure support ventilation therapy.

[0176] 5.9 Data Management System Figure 7 illustrates an example machine management service system 106 used to communicate with and provide updates to patient devices 102 (102A, 102B, 102C) in accordance with certain examples. The signal diagram illustrated in Figure 8 illustrates communication between example patient devices and the example machine management service system of Figure 7. It is understood that at least the examples illustrated in Figures 7-10C should not be construed as limiting the disclosure of the scope or usefulness of the features described herein.

[0177] Returning to Figure 7, the patient device 102 communicates with a machine management services (MMS) system 106 via a network 104. The MMS system 106 may include one or more computing devices (e.g., those described in connection with Figure 11). In certain examples, certain functionality provided by the MMS system 106 may be provided on a cloud-based computing architecture (e.g., via Amazon AWS, Microsoft Azure, etc.).

[0178] 7 are shown in communication with the MMS system 106. It should also be understood that although three different patient devices 102 (102A, 102B, and 102C) are shown in communication with the MMS system 106, any number of patient devices may be provided and may be in communication with the MMS system. In other words, the MMS system 106 may be configured to communicate with one or more fleets of patient devices (each including multiple individual patient devices) used by patients around the world.

[0179] Patient devices may include different types of patient devices. For example, a patient device may be an RPT 4000, a humidifier 5000, or a patient interface 3000. In certain examples, a patient device may include components that are part of an individual patient device. For example, a patient device that is an RPT device may include a cellular modem used to communicate with the MMS system 106 over the network 104. The components of a patient device may include different hardware and / or software components of the device. For example, a Bluetooth software driver may be one component, and another component may be an application that controls the functionality of a flow generator for AutoSet. Another component may be a BIOS for an SoC used to control the flow generator. In certain examples, any type of device or component that runs software, firmware, or is otherwise programmable may be considered a patient device according to the technology described herein. In other words, the components of a patient device themselves may be considered a “patient device” according to the technology described herein.

[0180] In general, an individual patient device 102 may include any of the components described in connection with FIG. 11 and / or FIG. 4C . For example, a flow generator may include one or more processors 1102, one or more memory devices 1104, and one or more network interface devices 1106. One of the network interface devices may be, for example, a Bluetooth transceiver. In certain examples, a given patient device may communicate with another computing device (e.g., a cell phone or personal computer). This other computing device may then relay communications or messages provided from the patient device to the MMS system 106. Components may be associated with or have firmware, software, etc. that enable use of the given component.

[0181] In many places throughout this document (including, but not limited to, FIG. 7), reference is made to software modules (etc.) and actions performed by the software modules (etc.). This is for ease of explanation, and when a software module is described herein as performing an action, it should be understood that it is always the hardware elements (e.g., processors and memory devices) (below the software module) that actually perform the action in accordance with the instructions contained in the software module. Further details in this regard are provided below, such as in the description of FIG. 11.

[0182] As described herein, the patient device 102 may communicate one or more pieces of identification data. This is shown at 200 in FIG. 8 . Examples of identification data include, for example, a version number, a domain identifier or name, a component type (e.g., the component to which the version applies), or other identifiers. In certain examples, the identification data transmitted from the patient device may be data that is agnostic to the patient(s) using the patient device. In other words, the transmitted identification data may exclude patient identification data. This type of implementation may be advantageous in certain examples because patient data does not need to be obtained or transmitted to the MMS system 106 in order for an upgrade package to be deployed for an individual patient device.

[0183] In certain examples, the identification data that may be transmitted includes a unique identifier associated with a transceiver included with the patient device 102. For example, a cellular identifier associated with a cellular transceiver / module is included with the patient device 102. In certain examples, the identifier may uniquely identify a given patient device 102. In other certain examples, the identification data may include a patient identifier. In certain examples, the device identification data transmitted from each patient device 102 is unique (e.g., a GUID / UUID) and can therefore be used (by the MMS 106) to determine details of other components or devices included with the patient device (e.g., by consulting the status DB 112).

[0184] In any event, the MMS system 106 receives messages from and delivers messages to each patient device 102. A rules manager module 108, which may be included in the MMS system 106, is configured to determine whether to deliver an upgrade package to a corresponding patient device (or associated computing device) based on information sent from the corresponding patient device. As described in more detail below, in certain examples, the determination of whether to deliver an upgrade package may be further based on data stored in the status DB 112.

[0185] The MMS system 106 may include a rules database 110 in which rules used by the rules manager module 108, the status database 112, the pending requests database 114, and the upgrade packages 116 are stored. As used herein, the term "database" includes any organized collection of data about a computer system, and may include, for example, a relational database, an XML or JSON (or other file type) file, etc.

[0186] In certain exemplary embodiments, the MMS system 106 allows upgrade requests to be processed in a stateless manner, eliminating the need for the MMS system 106 to track the correct processing of each individual upgrade request (e.g., job) by each individual patient device 102. This type of execution may provide benefits over other types of stateful execution (e.g., job-based systems).

[0187] The rules manager module 108 determines the details of the upgrade package to be applied and / or delivered to a given patient device 102. This process, described in more detail in conjunction with Figures 8 and 9B, may include, for example, using device identification data (e.g., transmitted from the patient device 102B at 200) to determine the various components of that device (e.g., having updatable data fields, software, and / or firmware), determining which components may have applicable updates, and then delivering those updates (for updating and / or installation on the patient device) (or notifying the patient device of the existence of such updates). Such a process may include obtaining device profile information from the status database 112 at 201 and checking that data against one or more rules at 202 to determine (at 204) the upgrade package to be delivered at 206 to the patient device 102.

[0188] Each rule may be a separate entry or record in the rules database 110, and each rule may correspond to an upgrade package containing one or more upgrades for firmware / software / settings or all of the above. Each rule may indicate or specify the version of a component or other data on the patient device that will be used in triggering a given rule. Each rule may also include a task or upgrade file to be applied or communicated to the patient device when the corresponding rule is triggered. Examples of rules that may be stored in the rules database 110 are shown in conjunction with Tables 1-4 below.

[0189] As used herein, it is understood that the term "upgrade" is intended to encompass situations in which changes occur to a device's data, software, or firmware. Thus, in some cases, the term "upgrade" may include a downgrade (e.g., due to a security flaw), for example, which rolls back a previously applied update. For example, an "upgrade" package may be delivered that modifies, reinstalls, or rolls back an application from version 10 to version 9.

[0190] The MMS system 106 may also include a status database 112 containing a record of the currently installed versions / configurations for each patient device's components. Exemplary data that may be included in the status database 112 may be similar to the "Identification Profiles" shown in Tables 2-4 and 8 below, where the various components of each given device are stored in association with the version or other identifier of the firmware or software (or configuration) version currently in use on the device's components. In a particular example, the rules manager module 108 may use the status database 112 to obtain versioning information for each component of a given device specified by provided identification data. For example, the identification data communicated from a given device to the MMS system may be a GUID or other unique identifier and used in looking up all of the components (and associated versioning information) included with the given device. Such information may then be used (via the rules manager module 108) to determine whether any of the rules 110 are applicable to the components installed on the given patient device. The status database 112 may be a data store for all characteristics, attributes, or other configuration information. Storing such information within the MMS system 106 may be advantageous because it allows for retrieval of the information without having to transmit the information from the patient device each time the patient device checks in to the MMS system 106 (to determine if an upgrade is available).

[0191] However, in certain instances, some or all of the data stored in the status database 112 may be communicated (eg, each time) when an individual patient device checks into the MMS system 106 .

[0192] In certain exemplary embodiments, the status database 112 is populated with component information at the time of manufacture of each individual patient device. At the time of manufacture, a unique identifier may be assigned to the device (or its components). The unique identifier may then be stored in association with component data for the various components included with the device. In certain examples, a distributor or other third party may also provide data about the versioning and component information of individual devices. In certain examples, the status database 112 may include an organization and / or region identifier that is also stored in association with each unique patient device identifier. Such information may be advantageously used to target upgrade packages to specific organizations and / or specific regions around the world (e.g., upgrade packages for patient devices in China).

[0193] Pending requests 114 may include a list / queue (or other data structure) of all currently pending requests. In certain examples, pending requests are a collection of pending requests that still need to be communicated to an individual patient device (e.g., a request for the device to take some particular action (e.g., apply a firmware or software upgrade or change a setting)). In certain examples, as described herein, when a patient device checks in and provides device identification data, that data can be used to look up whether there are any pending requests for that device.

[0194] The MMS system 106 communicates with a given patient device and instructs that device to handle a specific request. The request could be to apply a specific upgrade package (e.g., to download and install a file). In certain examples, once a request is communicated to a patient device and added to the pending requests 114, the MMS system 106 no longer tracks the successful completion of that particular request. This may provide a stateless system of how requests are handled by the MMS system 106. In other certain examples, a record of pending requests communicated to a patient device is maintained within the pending requests 114 and marked as "in progress" or "successfully completed," etc., based on notifications or other information provided by the patient device. This latter implementation may result in a stateful system in how requests are handled by the MMS system 106 (e.g., by tracking the state of the request). In certain examples (and examples applicable to both of the above implementations), the MMS system 106 may track any information status and / or fault condition(s) as reported by the patient device and store that information in a pending request 114. The pending request 114 may be stored in a queue or other data structure (e.g., as queue 404 in FIGS. 10A-10C). In certain examples, the pending request 114 may be stored in a database or the like.

[0195] The upgrade package 116 may be a data store for all upgrade packages that may be applied to any of the patient devices. An upgrade package may include code changes to software or firmware and / or setting changes for adjusting one or more parameters of a given patient device. Such parameter, software, and / or firmware changes may then affect or change the manner in which the patient device operates. For example, the operation of a fan or blower in an RPT device's flow generator may be adjusted to more effectively deliver therapy to the patient. As described elsewhere herein, in certain instances, adjusting the settings of a patient device may require additional authorization from a clinician or other medical professional. Thus, in certain instances, the rules manager module may determine whether to apply an upgrade (e.g., setting change) based on such additional input. In certain examples, the upgrade package may include any or all of the following: security improvements, additional functionality (e.g., new therapy modes newly available on the RPT device), different languages ​​(e.g., different language packs containing different voices and / or text for updating language strings embedded in the RPT device), patient surveys or questionnaires, patient coaching or tips, or other settings, configurations, or applications.

[0196] In certain exemplary embodiments, the upgrade package 116 stores a list of network or website addresses where each upgrade file / data can be obtained by the patient device. Thus, the MMS system 106 can be configured to provide links to where the upgrade files can be found (rather than to the upgrade files themselves). In certain examples, the actual installation files can be stored separately from the MMS system 106.

[0197] Tables 1-4 below show examples of upgrade specifications that may appear in association with the rules database 110. Table 1 illustrates the manner in which an upgrade specification may be constructed in association with several different rules that use identification profiles to trigger an upgrade package. The identification profile included in each rule may be a subset of the device profile data stored for each patient device in the status database 112. The different rules (also called segments of the upgrade specification) and the identification profiles used in triggering these rules, as well as the upgrade package to be delivered in association with each identification profile, are shown in association with Tables 2, 3, and 4. Each trigger (e.g., precondition) may be associated with a unique identifier that allows the MMS system 106 to reference and / or track the rule (segment). This may allow for determining the number of times a given upgrade has been delivered across a fleet of devices. [Table 2]

[0198] In Table 2, an upgrade of FG AutoSetApplication from version 4.0.1 to 4.0.3 is triggered if the device identification data of the flow generator component includes the following version values: 1) “BootloaderIdentifier”: “SW03901.00.3.0.0.48255”; 2) “ApplicationIdentifier”: “SW03900.01.4.0.1.50578”; and 3) “ConfigurationIdentifier”: “CF03900.01.03.00.50578”. If this precondition is met, the rules manager module 108 determines whether the indicated “UpgradeFile” should be applied to the component of the patient device. A notification is sent to the patient device, and the indicated upgrade file is applied from the patient device. In a particular example, after the “PostCondition” is met, the status DB 112 may be updated (e.g., to 4.0.3) to reflect that the corresponding device has been updated. In certain instances, the post-condition portion of the rule may be ignored. [Table 3]

[0199] In Table 3, an upgrade of FG AutoSetApplication from version 4.0.2 to 4.0.3 is triggered if the Device Identification Data Stream Generator component contains the following values: 1) “BootloaderIdentifier”: “SW03901.00.3.0.0.48255”; 2) “ApplicationIdentifier”: “SW03900.01.4.0.2.50813”; and 3) “ConfigurationIdentifier”: “CF03900.01.03.00.50813”. If this precondition is met, the rules manager module 108 determines whether the indicated “UpgradeFile” should be applied to the patient device components. The patient device is notified and the indicated upgrade file is applied. In a particular example, after the “PostCondition” value is met, the status DB 112 is updated to reflect that the corresponding device has been updated (e.g., to 4.0.3). It should be understood that Tables 2 and 3 show upgrade packages for the same version of the same component, but because the preconditions are different, two different identification profiles may be used to trigger upgrades for patient devices with different versions of the component. [Table 4]

[0200] In Table 4, a Bluetooth iOS upgrade is triggered when the Device Identification Data Stream Generator component contains the following value: 1) “'ApplicationIdentifier': 'SW03900.01.4.0.3.50927'” and the Device Identification Data of the Bluetooth Module component contains the following value: 1) “'ApplicationIdentifier': 'ST266.1.1.2.182.2'”. Thus, a pre-condition may include versioning data for multiple components of the system. If this pre-condition is met, the rules manager module 108 determines whether the indicated “UpgradeFile” should be applied to the patient device component. The patient device is notified and the indicated upgrade file is applied. In a particular example, after the “PostCondition” value is met, the status DB 112 may be updated to reflect that the corresponding device has been updated (e.g., to ST266.1.1.3.199.2). [Table 5]

[0201] After the appropriate rule and its corresponding upgrade package are determined based on the provided device identification data (and / or device profile data retrieved from the status DB 112), the patient device 102 may be notified of the upgrade package at 206. In certain examples, this may include providing the data to be applied to the upgrade in a message delivered from the MMS system 106. In other examples, the delivery of the upgrade package may include the specification of a URI or other address (along with other data (e.g., information, size, file name)) so that one or more files can subsequently be downloaded using the displayed URI.

[0202] At 208, the patient device applies the upgrade package, which may include verifying (e.g., running a checksum) that the upgrade package is complete, accurate, or otherwise uncorrupted, and overwriting existing settings and / or installing software and / or firmware updates.

[0203] After the upgrade is installed by the patient device, the patient device 102 may check in again with the MMS system 106 and communicate new version information of the updated components to the MMS system 106. The updated version information may then be stored in the status DB 112 (e.g., by overwriting the previous value) in association with the patient device and the given component. Thus, the MMS system 106 is kept up to date with the firmware / software / configuration versions currently installed on the given patient device. This type of implementation may advantageously allow the system to run without the need for continuous tracking of individual upgrade requests. In certain examples, upon completion of the upgrade by the patient device 102, the patient device 102 may again communicate a status update to the MMS system 106. Device identification data and / or component identification data (e.g., software or firmware version) that may be included in this message may then be used by the MMS system 106 to verify that the update has been performed / installed by the patient device 102. In certain examples, the patient device 102 may communicate its progress in the upgrade process back to the MMS system 106, including whether any failures have occurred (that prevent the patient device 102 from successfully completing the request). This progress or failure information may be stored by the MMS system 106 in the pending request 114. The progress information may include, for example, that the file was successfully downloaded, that the upgrade is being applied, that the upgrade is in progress, that the upgrade is complete and the patient device is rebooting, etc.

[0204] It will be appreciated that by enabling the creation of individual rules that can be included in the overall rule specification, an automated system for managing updates can be provided that can scale across thousands or even millions of different patient devices. This is achieved because communications from individual patient devices facilitate the rules manager module 108 in properly selecting the correct upgrade package to be sent to each individual patient device (based on device profile data obtained from the status DB 112 and the rule specification from the rules 110). This may reduce the need to manually monitor patient device updates as new upgrade packages become available for installation / application to the device.

[0205] 9A and 9B are flowcharts of computer operations that may be performed in particular examples, for example, by the patient device 102 and the MMS system 106, respectively. FIG. 9A illustrates exemplary client-side processing that may be performed on the exemplary patient device 102, and FIG. 9B illustrates exemplary server-side processing that may be performed by one or more processors of the MMS system 106.

[0206] 9A, at 300, the patient device determines whether a check-in process should occur. This check may occur daily, weekly, or monthly, for example. In a particular example, a clock 4232 may be used to determine when the check-in process should occur. If it is not time to check in, the process returns to 300.

[0207] At 302, if a check-in process is to occur, the patient device 102 transmits device identification data to another computer system (e.g., the MMS system 106). As described herein, the device identification data may be or be associated with the patient device's GUID (e.g., so as to be unique among other patient devices). In certain exemplary embodiments, the GUID is assigned to the network interface used by the patient device 102. In certain other examples, the transmitted data may include transmission of software / firmware / configuration version information. It is understood that the term "GUID" is used in connection with a patient device or component thereof herein, although other identifiers (whether unique or not) may also be used to facilitate identification of the patient device or component thereof.

[0208] At 304, after transmitting the device identification data, the patient device 102 receives an upgrade data package from the MMS system 106. In certain exemplary embodiments, the upgrade data package may include a link, URI, or other location to download the file(s) for the upgrade. Thus, upon receiving such information in the upgrade data package at 304, the patient device may submit a request to the indicated location (e.g., a remote computer system) to retrieve the file(s) specified by the upgrade data package. Once such file(s) are received, the process may proceed to step 306.

[0209] In certain exemplary embodiments, the upgrade data package may include (or may be) data for configuration or other parameters to be changed on the patient device. Table 5 shows examples of "BrokerItem" elements that may be included as part of the upgrade data package delivered to the patient device via step 304. [Table 6]

[0210] Thus, when the patient device 102 receives this broker item included in the upgrade data package, the broker item can be applied to the configuration profile of the patient device.

[0211] In certain exemplary embodiments, the contents of the upgrade data package may also include software or firmware to be applied to the patient device 102. Thus, instead of separately requesting software or firmware files (e.g., as shown in Table 9) after receiving the upgrade data package from the MMS system 106, such files may be provided in association with the upgrade data package.

[0212] At 306, the received upgrade data package is verified by the patient device. This may include verifying the message sent from the MMS system 106 and / or verifying the separately retrieved upgrade file. This may include hashing the received data or other file and comparing this hash with a hash value included in the upgrade data package message. In certain examples, this verification may include comparing the expected file size received (e.g., as displayed by the MMS system 106) with the actual file size of the retrieved file. If the upgrade file verification fails, the patient device may retry downloading the file. In certain examples, the patient device may send a notification to the MMS system of the download or message or file verification failure. The failure may be recorded by the MMS system 106 (or other device) for future analysis and / or reporting.

[0213] In certain examples, a failure to download the upgrade file may terminate client-side processing (e.g., after reporting the failure to the MMS system 106), and the process may return to 300 to wait until the next check-in time is activated. When the check is performed again, the patient device may be provided with the same upgrade data package that previously failed to upgrade.

[0214] At 308, after successful verification, the upgrade data package may be applied to the patient device 102. Examples of this may include, for example, overwriting or replacing certain parameter values ​​used by the patient device 102 and / or installing or otherwise applying software and / or firmware updates to the patient device. This installation procedure may be verified by the patient device (e.g., whether the installation failed or was successful).

[0215] At 310, the patient device transmits the status of the upgrade back to the MMS system 106. In certain exemplary embodiments, this may include reporting the current versioning information of the components just upgraded on the patient device. In certain examples, the status report may be for multiple different components (e.g., the flow generator and Bluetooth module). In certain examples, the status report may relate to the upgrade request as a whole (e.g., that the request was successful). Table 6 shows exemplary elements that may be transmitted to the MMS system 106. In certain exemplary embodiments, the contents of Table 6 may be transmitted from the patient device to the MMS system 106 upon receipt of the upgrade data package at 304 (e.g., to verify that the request was received or any failures occurred related to the request). [Table 7]

[0216] In certain examples, the device status transmitted at 310 may include a failure notification for the application of the upgrade (and possibly a failure error code or message) or versioning information for the component(s) just upgraded. In other words, in certain examples, the success of the upgrade is implicit from the patient device providing current versioning information to the MMS system 106. Thus, the MMS system may be notified of the status of the patient device 102 and / or the upgrade package delivered to the patient device.

[0217] FIG. 9B illustrates exemplary server-side processing that may be performed by the MMS system 106.

[0218] At 350, device identification data is received from the patient device. As described herein, device identification data can be provided in a variety of different ways. Table 7 below shows examples of how device identification data can be submitted to the MMS system 106. [Table 8]

[0219] In the above example from Table 7, the GUID (uid in the URI) that uniquely identifies the patient device issuing the request is the cellular ID paired with the patient device (in this case the flow generator). This ID is assigned to each cellular module manufactured and is therefore unique, so it can be used to locate the patient device paired with that cellular module. This is submitted to the MMS system 106 as part of the HTTP get method.

[0220] At 351, the MMS system 106 uses the provided device identification data to look up (by referencing the status database 112) the device profile data (e.g., all of its components) for the displayed patient device. Table 8 is an example of how portions of the device profile data may be located within the status database 112. [Table 9]

[0221] Here, the universal identifier can be an identifier that is device identification data sent from the patient device. It is used to find all records (e.g., all "IdentificationProfiles" in the status DB 112 associated with that universal identifier). The above example from Table 8 shows a flow generator component along with "hardware" versioning information and the currently installed "software" version of that component present on the patient device associated with the displayed identifier. Additional records may also be provided in the status DB 112 for different components of the device. For example, a Bluetooth module, a cellular module, a humidifier module, etc. may each have a separate entry. Each of these components is also associated with a universal identifier entry ("'UniversalIdentifier':'6a7a2e7e-5d9d-4c87-b45e-faa3563f21a8'"), allowing for lookup of all components of a given patient device. In certain examples, the universal identifier is the same for all components in a device. In certain instances, the universal identifier is different for several components within (or coupled to) the same patient device.

[0222] At 352, the versioning information from the various component identification profiles is then processed via the rules manager module 108 (against rules stored on the MMS system 106) to determine if there are any upgrade packages available for this patient device component. If no upgrades are available, the process ends and the MMS system 106 may simply respond to the request with "None" (or a similar message indicating that no upgrades are available at this time).

[0223] If there is one or more available upgrade package(s), these upgrade packages are transmitted to the patient device at 354. If there are multiple upgrade packages, the multiple packages may be applied sequentially from the patient device to the MMS system 106 via multiple different requests. In other words, each sequential application of rules by the rules manager module 108 (e.g., in response to different instances when the same device checks into the MMS system 106) may be used to determine additional upgrades to be applied to a given patient device. Thus, the order in which these rules are processed by the rules manager module 108 may determine the upgrade package (from multiple possible upgrade packages) to be applied. In certain examples, the manner in which the MMS system 106 determines and then delivers upgrade packages to the device allows for the upgrades to be applied sequentially and / or deterministically. For example, a device may meet multiple different preconditions (e.g., multiple upgrades need to be applied). The MMS system 106 may advantageously arbitrate such requests by determining which package to deliver based on the order of segments in the upgrade specification. Thus, for example, instead of selecting the precondition that is satisfied, the MMS system may select the first precondition in the upgrade specification (e.g., assuming that the first preconditions are processed in order). This type of exemplary approach enables the MMS system 106 to build (e.g., a known, secure chain of upgrades for requesting devices).

[0224] In any event, the upgrade package is sent to the patient device at 354. Then, at 356, the device status (e.g., that sent in step 310 in FIG. 9A) is received by the MMS system 106.

[0225] At 358, the device status received at 356 is stored. For example, if the patient device sends version information for a given component, that versioning information may be stored in the status DB 112 (e.g., overwriting previously stored versioning information for that component). Alternatively, if the upgrade was not successful, a record of the error may be stored and flagged for possible future follow-up.

[0226] In certain examples, the MMS system 106 may include one or more services, each of which may execute or be hosted on a different computing device. An example system including such services is shown in FIG. 10A . The services may include a cloud service 400, a request service 402, a queue 404, and / or an upgrade service 406. The example MMS system may include a cloud service 400 that interfaces with / communicates with the patient device 102. In certain examples, the cloud service 400 may be hosted in a cloud computing environment (e.g., Amazon AWS, Microsoft Azure) to provide geolocated services for increased availability uptime and reduced latency. Each or any of the services described herein may be hosted within a separate virtual container or instance within a cloud-based computer system. In certain examples, some services may be hosted outside of the cloud-based execution and may communicate with other services within the cloud-based execution. In certain examples, each or any service may be hosted on its own computing node, some or any of which may be located within the cloud-based system and other external services. A computing node may include separate physical computer hardware and / or separate virtual containers or instances.

[0227] The cloud service 400 may communicate with a separately provided request service 402 used to manage and generate requests. In certain examples, a request is used to encapsulate an upgrade package (e.g., a request for a given device to apply an upgrade package). The generated request may be stored in pending requests 114. In certain examples, a request may also include a request to update or change the configuration or other settings of a given patient device and / or its components. The request service 402 may interface with a queue 404 used to store pending requests (e.g., requests that have not yet been sent to and / or completed by the patient device). The request service 402 may also communicate with an upgrade service 406. The upgrade service 406 is used to determine whether a software or firmware upgrade is available for a given request (or to generate a request if an upgrade is available, as described in FIG. 10B ).

[0228] Returning to FIG. 10A, an example of retrieval of a request with (or without) broker involvement is shown according to a specific example. In FIGS. 10A-10C, distributed services (e.g., 400, 402, 404, and 406) are provided on separate computing resources, each providing different functionality. In a specific example, each or any of these services may be provided on a cloud computing environment. As noted above, such services may collectively be provided within the overall MMS system 106.

[0229] At 410, the patient device 102 transmits patient device identification data to the cloud service 400. This may be, for example, a cellular module universal identifier or other unique identifier used to uniquely identify the patient device 102. In a particular example, a MAC address may be used if the request from the patient device is sent through the patient device's network interface card as opposed to the cellular modem.

[0230] At 412, the cloud service 400 issues a request to the request service 402 to obtain the current request associated with the submitted identification data (in other words, to determine if there is a current request associated with the provided ID). The request service 402 then accesses the queue 404 at 414 to find the current request.

[0231] The request in queue 404 is then returned at 416 to the request service 402 as a broker request, which then returns it to the cloud service 400 at 418. The broker request is then returned at 420 to the patient device 102. With this type of architecture, the functionality of the request and upgrade services can be encapsulated by the cloud service (at least from the perspective of any patient device that is checking in).

[0232] An example of data ("BrokerItem") that may be provided as part of the broker's request sent back to the patient device 102 is the Broker Item in Table 5 shown above. Another example is shown below in Table 9. This example relates to a broker's request for an upgrade data package (in this case, a firmware upgrade). [Table 10]

[0233] Another example is shown below in Table 10. This example relates to a settings profile request that may be included in a broker request. [Table 11]

[0234] Thus, profiles for patient device configurations can be delivered via a broker request.

[0235] In certain exemplary embodiments, a broker request delivered to a patient device may include items with one or more broker involvements. In such instances, items with individual broker involvements in the overall request may be delivered separately (and sequentially) to the patient device. In other words, the patient device processes one BrokerItem and then requests the next BrokerItem. For example, each of the BrokerItems from Table 5, Table 9, and Table 10 may be included in a single broker request for a given patient device. Each BrokerItem may be delivered to the patient device according to embodiments described herein. In certain examples, each request may include only a single BrokerItem, and multiple requests may be generated for a given patient device.

[0236] In certain exemplary embodiments, once a broker request is received, each or any BrokerItem in the corresponding request may be parsed, and appropriate action may be taken by the patient device 102. Next, for example, the file(s) that may be displayed in the BrokerItem may be downloaded. In certain exemplary embodiments, the patient device 102 may provide a report to the cloud service 400 that the file download was successful. This status may then be attached to or incorporated into a currently pending request (e.g., a request stored in the queue 404) for the given patient device. After the file is downloaded, it may be applied to the patient device 102. Next, in certain examples, the patient device 102 may restart, and a device status message may be sent to the cloud service indicating that the upgrade components are now at the upgrade version (e.g., the upgrade version number may be specified). In certain examples, the status message may include information that the upgrade was successfully applied to the patient device 102.

[0237] In certain examples, a BrokerItem may be removed from the queue 404 after being sent to the device (e.g., a previously submitted broker request may be removed). In certain examples, a BrokerItem associated with the request may be removed due to the successful application of a firmware upgrade. If there are no pending BrokerItems, the broker request(s) in the queue 404 may be cleared for the patient device 102.

[0238] In certain examples, if an error occurs during the upgrade process for the patient device 102, the nature of the error may be reported back through the cloud service 400 and analyzed for future analysis.

[0239] 10B, an example of a firmware upgrade request with broker involvement is provided, where at 500, identification data is sent from the patient device 102 to the cloud service 400. The cloud service 400 then requests at 502 current broker requests from the request service 402 based on the provided identification data. The request service 402 queries through the queue 404 to discover at 504 current requests.

[0240] However, in this example, there are no current requests, so an empty set is returned at 506. The request service 402 then submits a request to the upgrade service 406 to determine if firmware, software, or other upgrades are available based on the provided identification data for the patient device 102. As described herein, this may include querying the status DB 112 to obtain patient device profile data associated with the provided identification data and / or using the rules manager module 108 to determine whether an upgrade or change should be applied to the given patient device 102.

[0241] If firmware (or other upgrades to software, etc.) are available, details of the upgrade are sent back to the request service 402 from the upgrade service 406 at 510. Such details may be similar to those shown in Table 9. For example, the location where the file(s) are located may be provided, as well as hashes of those files, their sizes, the components of the patient device that the files are intended for, etc.

[0242] Once the upgrade details are returned to the request service 402, the request service 402 may generate a broker request based on these details at 512. This may include generating one or more BrokerItems as shown in the table above for a broker request. The generated request or item is then added to the queue 404 at 514 and then returned at 516 (e.g., similar to the return of the request at 416 in FIG. 1A). This allows the system to track the progress of the request (including the upgrade) as it needs to be processed for each individual patient device. The generated broker request (or BrokerItem) is then routed back to the cloud service 400 at 518, which then communicates the broker request back to the patient device 102 at 520. Subsequent processing may be similar to that described above in connection with FIG. 10A (wherein the upgrade may be verified and applied).

[0243] 10C shows a detailed signal diagram of what occurs when there is no broker request for the patient device 102. At 600, the patient device 102 submits identification data to the cloud service 400. The cloud service then submits a request for the broker request to the request service at 602. The request service queries the queue 404 at 604. Since there is nothing in the queue 404, nothing is returned at 606. The request service then submits a request at 608 to the upgrade service 406 to retrieve the upgrade details. If there is a response of "nothing" or other similar response at 610 (e.g., if there are no applicable upgrades), the upgrade service 406 returns an indication that no upgrade exists for the indicated device. The none response is returned at 612 to the cloud service 400, which relays this response to the patient device 102 at 614.

[0244] 5.10 Computing Devices 11 is a block diagram of an exemplary computing device 1100 (which may also be referred to as a “computer device,” “computer system,” or “computing system,” for example) according to some embodiments. In some embodiments, the computing device 1100 includes one or more of the following: one or more processors 1102; one or more memory devices 1104; one or more network interface devices 1106; one or more display interfaces 1108; and one or more user input adapters 1110. Additionally, in some embodiments, the computing device 1100 is connected to or includes display device(s) 1112. Additionally, in some embodiments, the computing device 1100 is connected to or includes one or more input devices 1114. In some embodiments, the computing device 1100 may be connected to one or more external devices 1116. As described below, these elements (e.g., processor 1102, memory device 1104, network interface device 1106, display interface 1108, user input adapter 1110, display device 1112, input device 1114, external device 1116) are hardware devices (e.g., electronic circuits or combinations of circuits) that are configured to perform a variety of different functions for and / or associated with computing device 1100.

[0245] In some embodiments, each or any of the processors 1102 is or includes, for example, a single-core or multi-core processor, a microprocessor (e.g., what may be referred to as a central processing unit or CPU), a digital signal processor (DSP), a microprocessor associated with a DSP core, an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, or a system-on-a-chip (SOC) (e.g., an integrated circuit that includes, for example, a CPU, a GPU, and other hardware components (e.g., memory and / or a memory controller (e.g., Northbridge), an I / O controller (e.g., Southbridge), a networking interface)). In some embodiments, each or any of the processors 1102 uses an instruction set architecture (e.g., x86 or Advanced RISC Machine (ARM)). In some embodiments, each or any of the processors 1102 is or includes, for example, a graphical processing unit (GPU) (which may be an electronic circuit designed to generate images, etc.).

[0246] In some embodiments, each or any of the memory devices 1104 is or includes random access memory (RAM) (e.g., dynamic RAM (DRAM) or static RAM (SRAM)), flash memory (e.g., based on NAND or NOR technology), a hard disk, a magneto-optical medium, an optical medium, a cache memory, a register (e.g., that holds instructions that can be executed by one or more of the processors 1102), or other types of devices that provide volatile or non-volatile storage of data and / or instructions (e.g., software running on or by the processor 1102). In some embodiments, each or any of the memory devices 1104 is removable from the computing device 1100 (e.g., a USB flash drive, a floppy disk, a compact disc (CD), etc.). The memory devices 1104 are examples of non-transitory computer-readable storage. As used herein, the term "non-transitory computer-readable storage medium" includes: registers, cache memory, ROM, semiconductor memory devices (e.g., D-RAM, S-RAM or other RAM), magnetic media (e.g., flash memory, hard disks, magneto-optical media), optical media (e.g., CD-ROM, DVD, or Blu-ray Disc), or other types of devices for non-transitory electronic data storage. The term "non-transitory computer-readable storage medium" does not include transitory, propagating electromagnetic signals.

[0247] In some embodiments, each or any of the network interface devices 1106 includes one or more circuits (e.g., a baseband processor and / or a wired or wireless transceiver) and implements one or more wired communication technologies (e.g., Ethernet (IEEE 802.3)) and / or wireless communication technologies (e.g., Bluetooth, WiFi (IEEE 802.11), GSM, CDMA2000, UMTS, LTE, Layer 1, Layer 2, and / or higher layers for LTE Advanced (LTE-A), and / or other short-, medium-, and / or long-range wireless communication technologies). A transceiver may include circuitry for a transmitter and a receiver. The transmitter and receiver may share a common housing and may share some or all of the circuitry within the housing to transmit and receive. In some embodiments, the transmitter and receiver of a transceiver may not share any common circuitry and / or may be provided in the same or separate housings.

[0248] In some embodiments, each or any of the display interfaces 1108 is or includes one or more circuits that: receive data from the processor(s) 1102; generate corresponding image data based on the received data (e.g., via a discrete GPU, an integrated GPU, a CPU that performs graphical processing, etc.); and / or output the image data to a display device 1112 (that displays the image data) via (e.g., a high-definition multimedia interface (HDMI), a display port interface, a video graphics array (VGA) interface, a digital video interface (DVI), etc.). Alternatively or additionally, in some embodiments, each or any of the display interfaces 1108 is or includes, for example, a video card, a video adapter, or a graphics processing unit (GPU). In other words, each or any of the display interfaces 1108 may include a processor therein that is used to generate image data. The generation of such images may occur in connection with processing performed by one or more of the processors 1102.

[0249] In some embodiments, each or any of the user input adaptors 1110 is or includes one or more circuits that receive and process user input data from one or more user input devices 1114 (included in, attached to, or otherwise in communication with computing device 1100) and output data to processor 1102 based on the received input data. Alternatively or additionally, in some embodiments, each or any of the user input adaptors 1110 is or includes, e.g., a PS / 2 interface, a USB interface, a touchscreen controller, etc., and / or facilitates input from the user input devices 1114.

[0250] In some embodiments, the display device 1112 may be a liquid crystal display (LCD) display, a light emitting diode (LED) display, or other types of display devices. In embodiments in which the display device 1112 is a component of the computing device 1100 (e.g., the computing device and the display device are provided in a unitary housing), the display device 1112 may be a touchscreen display or a non-touchscreen display. In embodiments in which the display device 1112 is connected to the computing device 1100 (e.g., is external to the computing device 1100 and communicates with the computing device 1100 via wired and / or wireless communication techniques), the display device 1112 may be, for example, an external monitor, projector, television, or display screen.

[0251] In some embodiments, each or any of the input devices 1114 is or includes mechanical and / or electronic equipment that generates signals provided to the user input adapter(s) 1110 in response to physical phenomena. Examples of the input devices 1114 include, for example, a keyboard, a mouse, a trackpad, a touchscreen, buttons, a joystick, sensors (e.g., accelerometers, gyro sensors, temperature sensors, pressure sensors (e.g., measuring gas pressure), flow sensors (e.g., measuring the rate of flow of gas or liquid), etc.), and microphones. In some examples, one or more of the input devices 1114 generate signals provided in response to input provided by a user (e.g., by pressing a button, speaking a voice command, etc.). In other examples, one or more of the input devices generate signals based on a sensed physical quantity (e.g., force, pressure, temperature). In some embodiments, each or any of the input devices 1114 is a component of a computing device (e.g., a button is provided on a housing that includes the processor 1102, memory device 1104, network interface device 1106, display interface 1108, user input adapter 1110, etc.).

[0252] In some embodiments, each or any of the external device(s) 1116 may include other computing devices that communicate with the computing device 1100 (e.g., other instances of the computing device 1100). Examples include server computers, client computer systems, mobile computing devices, cloud-based computer systems, computing nodes, Internet of Things (IoT) devices, flow generators, etc., all of which may communicate with the computing device 1100. In general, the external device(s) 1116 may include devices that communicate (e.g., electronically) with the computing device 1100. As an example, the computing device 1100 is a mobile device that communicates with a flow generator or a patient interface device or mask (e.g., examples of external devices 1116). Conversely, the computing device 1100 may be a flow generator and communicate with a server or cloud-based computer system. This server or cloud-based computer system is an example of an external device 1116 and provides data and / or software updates to the flow generator.

[0253] In various embodiments, computing device 1100 includes one or two, or three, four, or more of each or any of the above elements (e.g., processor(s) 1102, memory device(s) 1104, network interface device(s) 1106, display interface(s) 1108, user input adapter(s) 1110, display device(s) 1112, input device(s) 1114). Alternatively or additionally, in some embodiments, computing device 1100 includes one or more of the following: a processing system including processor 1102; a memory or storage system including memory device 1104; and a network interface system including network interface device 1106.

[0254] The computing device 1100 may be arranged in many different manners in various embodiments. By way of example only, the computing device 1100 may be arranged such that the processor 1102 includes: a multi-core (or single-core) processor; a first network interface device (e.g., implementing WiFi, Bluetooth, NFC, etc.); a second network interface device implementing one or more cellular communication technologies (e.g., 3G, 4G LTE, CDMA, etc.); and a memory or storage device (e.g., RAM, flash memory, or hard disk). The processor, first network interface device, second network interface device, and memory device may be integrated as part of the same SOC (e.g., a single integrated circuit chip). As another example, the computing device 1100 may be arranged such that the processor 1102 includes two, three, four, five, or more multi-core processors; the network interface device 1106 includes a first network interface device implementing Ethernet and a second network interface device implementing WiFi and / or Bluetooth; and the memory device 1104 includes RAM and flash memory or a hard disk. As another example, the computing device 5|00 may include a SoC together with: one or more processors 5|02, multiple network interface devices 5|06 (e.g., one that communicates via a cellular connection and one that communicates via a Bluetooth connection), a memory device 5|04 including system memory and memory for application programs and other software, a display interface 5|08 configured to output video signals, a display device 5|12 integrated with the housing and stacked with a touchscreen input device 5|14, and multiple input devices 5|14 (e.g., one or more buttons and / or one or more sensors).

[0255] As noted above, whenever this document describes a software module or software process performing any action, that action is actually performed by the underlying hardware component according to instructions including the software module. Consistent with the above, in various embodiments, cloud service 400, request service 402, queue 404, upgrade service 406, MMS system 106, rules manager module 108, rules 110, status database 112, upgrade package 116, and pending requests 114, each individually or in any combination, will be referred to as a "component" for clarity in the remainder of this paragraph and will be implemented using the example computing device 1100 of FIG. 5. In such embodiments, the following applies with respect to each component: (a) the components of the computing device 1100 shown in FIG. 11 (i.e., one or more processors 1102, one or more memory devices 1104, one or more network interface devices 1106, one or more display interfaces 1108, and one or more user input adapters 1110), or any suitable combination or subset of the above, with or without one or more display devices 1112, one or more input devices 1114, and / or external devices 1116) are configured, adapted, and / or programmed to perform each or any combination of the actions, activities, or functions described herein as performed by the component and / or by any software modules described herein as included within the component;(b) Alternatively, or additionally, to the extent described herein that one or more software modules are provided within a component, in some embodiments, such software modules (and any data described herein as handled and / or used by the software modules) are stored within memory device 1104 (e.g., in various embodiments, stored within a volatile memory device (e.g., RAM or instruction registers) and / or a non-volatile memory device (e.g., flash memory or a hard disk)), and all actions described herein as performed by the software modules are performed by other elements within computing device 1100 and / or other elements connected to computing device 1100 (e.g., network interface device 1106, display interface 1108, user input adapter 1110, display device(s) 1112, input device(s) 1113, or the like). 1104 and / or external device(s) 1116, as appropriate; (c) alternatively or additionally, to the extent described herein, the component processes and / or others manipulate data, and in some embodiments, such data is stored in memory device 1104 (e.g., in some embodiments, in a volatile memory device (e.g., RAM) and / or a non-volatile memory device (e.g., flash memory or a hard disk)) and / or is processed / handled by processor 1102, as appropriate, in conjunction with other elements within computing device 1100 and / or connected to computing device 1100 (e.g., network interface device 1106, display interface 1108, user input adapter 1110, display device(s) 1112, input device(s) 1114 and / or external device(s) 1116);(d) Alternatively or additionally, in some embodiments, the memory device 1102 stores instructions that, when executed by the processor 1102, in conjunction with other elements provided within and / or connected to the computing device 1100 (e.g., the memory device 1104, the network interface device 1106, the display interface 1108, the user input adapter 1110, the display device(s) 1112, the input device(s) 1114, and / or the external device(s) 1116), as appropriate, cause the processor 1102 to perform each or a combination of the actions described herein as performed by and / or by any software modules described herein as provided within the components;

[0256] The hardware configuration shown in Figure 11 and described above is by way of example, and the subject matter described herein may be used in connection with a variety of different hardware architectures and elements. For example: in many of the figures in this document, individual function / action blocks are illustrated; in various embodiments, the functions of these blocks may be performed (a) using individual hardware circuits, (b) using application specific integrated circuits (ASICs) specifically configured to perform the described functions / actions, (c) using one or more digital signal processors (DSPs) specifically configured to perform the described functions / actions, (d) using the hardware configuration described above with reference to Figure 11, (e) via other hardware arrangements, architectures, and configurations, and / or via a combination of the techniques described in (a)-(e).

[0257] 5.11 Glossary For purposes of this disclosure, in certain aspects of the technology, one or more of the following definitions may apply. In other aspects of the technology, other definitions may apply.

[0258] 5.11.1 General Air: In certain forms of the present technology, air may refer to atmospheric air, while in other forms of the present technology, air may refer to a combination of other breathable gases (e.g., oxygen-rich atmospheric air).

[0259] Surroundings: In certain forms of the present technology, the term "surroundings" should be taken to mean (i) outside the treatment system or patient, and (ii) that which immediately surrounds the treatment system or patient.

[0260] For example, the ambient humidity for a humidifier may be the humidity of the air immediately surrounding the humidifier (e.g., the humidity inside the room where the patient is sleeping). Such ambient humidity may differ from the humidity outside the room where the patient is sleeping.

[0261] In another example, the ambient pressure may be the pressure immediately surrounding or external to the body.

[0262] In certain embodiments, ambient (e.g., acoustic) noise can be considered the background noise level in the room the patient is in, other than noise emanating from, for example, the RPT device or from the mask or patient interface. Ambient noise can originate from sources outside the room.

[0263] Flow Rate: The instantaneous amount (or mass) of air delivered per unit time. Flow rate can refer to an instantaneous quantity. Sometimes, when referring to flow rate, it refers to a scalar quantity (i.e., a quantity that has only magnitude). In other cases, when referring to flow rate, it refers to a vector quantity (i.e., a quantity that has both magnitude and direction). Flow rate may be given the symbol Q. "Flow rate" may also be called "flow" or "airflow" for shorthand.

[0264] Flow Therapy: Respiratory therapy that involves delivering airflow to the entrance to the airways at a controlled flow rate, called the therapeutic flow rate, which is usually positive pressure throughout the patient's respiratory cycle.

[0265] Humidifier: The word "humidifier" is construed to mean a humidifying device constructed, arranged, or configured with a physical structure capable of providing a therapeutically beneficial amount of water (H2O) vapor to an air stream to ameliorate a medical respiratory condition in a patient.

[0266] Patient: A person with or without respiratory disease.

[0267] Respiratory Pressure Therapy (RPT): The application to the airway entrance of an air supply at therapeutic pressure, typically positive pressure relative to atmosphere.

[0268] Ventilator: A mechanical device that provides pressure support to a patient while they perform some or all of the work of breathing.

[0269] 5.12 Other Notes A portion of the disclosure of this patent document contains material that is entitled to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of this patent document or this patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but reserves all copyright rights therefor for all other purposes.

[0270] Unless otherwise clearly indicated from the context and unless a range of values ​​is provided, it is understood that each intervening value, to the tenth of the unit of the lower limit, between the upper and lower limits of the range, and for any other stated or intervening value in the stated range, is encompassed by the technology. The upper and lower limits of these intervening ranges, independently included in the intervening range, are also encompassed by the technology if they specifically exceed the limits in the stated range. If the stated range includes one or both of these limits, then ranges exceeding either or both of these stated limits are also encompassed by the technology.

[0271] Furthermore, when a value or values ​​are embodied herein as part of the present technology, unless otherwise specified, it is understood that such values ​​may be approximated and may be used to any appropriate significant figures to the extent practical technical practice permits or requires.

[0272] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this technology belongs. Although any methods and materials similar or equivalent to those described herein can be used in the practice or testing of this technology, a limited number of exemplary methods and materials are described herein.

[0273] Although particular materials are described as being suitable for use in the construction of components, obvious alternative materials having similar properties may be substituted. Furthermore, unless stated to the contrary, any and all components described herein are understood to be manufacturable and therefore may be manufactured collectively or separately.

[0274] Please note that as used herein and in the appended claims, the singular forms "a," "an," and "the" include their plural equivalents unless the context clearly dictates otherwise.

[0275] All publications mentioned herein are incorporated by reference to disclose and describe the methods and / or materials that are the subject of these publications. The publications mentioned herein are provided solely for their disclosure prior to the filing date of this application. Nothing herein should be construed as an admission that the present technology does not antedate such publications by virtue of prior patents. Furthermore, the dates of publications mentioned may differ from the actual publication dates, which may require independent confirmation.

[0276] The terms "comprises" and "comprising" should be construed to refer to elements, components, or steps in a non-exclusive sense, indicating that a described element, component, or step can be present in, utilized with, or combined with other elements, components, or steps not specifically described.

[0277] The headings used in the detailed description are for the convenience of the reader and should not be used to limit the content found in the disclosure or claims as a whole. These headings should not be used in interpreting the scope of the claims or the claim limitations.

[0278] Although the technology herein has been described with reference to specific examples, it should be understood that these examples are merely illustrative of the principles and applications of the technology. In some cases, terms and symbols may indicate specific details that are not necessary for the practice of the technology. For example, although the terms "first" and "second" (etc.) are used, unless otherwise specified, these terms are not intended to indicate any order but are used to distinguish between separate elements. Furthermore, although the description or illustration of process step 1 in the method may be described in an order, such order is not required. Those skilled in the art will recognize that such order can be changed and / or aspects thereof can be performed simultaneously or even synchronously.

[0279] It is therefore to be understood that numerous modifications may be made in the illustrative examples and that other arrangements may be devised without departing from the spirit and scope of the present technology.

Claims

1. 1. A non-transitory computer-readable medium storing computer-executable instructions for use with a computer system in communication with a patient respiratory device, the patient respiratory device including an electronic memory storing firmware and / or software used to control operation of the patient respiratory device, the computer-executable instructions including: receiving a first message from the patient respiratory device, the first message including identification data for the patient respiratory device, the first message being communicated from the patient respiratory device without a first prompt from the computer system; obtaining device profile data for the patient respiratory devices from one or more records of a status database including records for a plurality of patient respiratory devices, each of the records including versioning data identifying firmware and / or software installed on each of a plurality of different patient respiratory devices, the device profile data obtained based on processing the received first message, and the identification data of the patient respiratory device included in the first message; selecting at least one upgrade package from a plurality of available upgrade packages to be applied to the patient respiratory device based on the device profile data for the patient respiratory device, each of the plurality of available upgrade packages being associated with at least one upgrade rule including identification profile data; generating a second message containing data used to update the software and / or firmware of the patient respiratory device based on the at least one selected upgrade package; sending the second message to the patient-respiratory device, the second message causing the patient-respiratory device to perform an update process that applies the update to the firmware and / or software to the patient-respiratory device; A non-transitory computer-readable medium comprising instructions configured to cause the computer to perform operations including:

2. 2. The non-transitory computer-readable medium of claim 1, wherein selecting the at least one upgrade package comprises selecting the upgrade rule to apply based on a comparison of the device profile data to the identification profile data.

3. The operation further comprises: accessing a rules database containing a plurality of records each corresponding to a different upgrade rule; 2. The non-transitory computer-readable medium of claim 1, wherein selecting the at least one upgrade package comprises selecting the upgrade rule to apply based on a comparison of the device profile data to the identification profile data.

4. each of the plurality of records in the rules database includes at least one precondition; 4. The non-transitory computer-readable medium of claim 3, wherein selecting the at least one upgrade package comprises matching the at least one precondition of the upgrade rule with data of the device profile data of the patient-respiratory device.

5. The operation further comprises:

10. The non-transitory computer-readable medium of claim 1, further comprising determining whether there is a pending request for the patient respiratory device based on the identification data for the patient respiratory device included in the first message.

6. The operation further comprises:

6. The non-transitory computer-readable medium of claim 5, further comprising, based on a determination that a pending request exists for the patient respiratory device, generating a request and storing the request in a data structure, the request including data based on the selected at least one upgrade package.

7. The non-transitory computer-readable medium of claim 1 , wherein a determination of whether there are pending requests is made prior to retrieving one or more records from the status database.

8. The operation further comprises:

10. The non-transitory computer-readable medium of claim 7, comprising generating and sending an update message to a second patient respiratory device without first obtaining a device profile for the second patient respiratory device based on a determination that there is a pending request for the second patient respiratory device.

9. The operation further comprises:

10. The non-transitory computer-readable medium of claim 8, comprising generating and transmitting an update message to a second patient respiratory device without first selecting an upgrade package from a plurality of upgrade packages based on a determination that there is a pending request for the second patient respiratory device.

10. 10. The non-transitory computer-readable medium of claim 1, wherein the device profile data for the patient respiratory device includes a unique identifier that uniquely identifies the patient respiratory device from other patient respiratory devices.

11. 11. The non-transitory computer-readable medium of claim 10, wherein the unique identifier is associated with a transceiver included with the patient respiratory device.

12. 10. The non-transitory computer-readable medium of claim 1, wherein versioning information for the software or firmware of the patient respiratory device is not included in the first message.

13. The non-transitory computer-readable medium of claim 1 , wherein the computer system includes a first computing node and a second computing node that each perform different ones of the operations.

14. The operation further comprises:

10. The non-transitory computer-readable medium of claim 1, comprising parsing through a plurality of upgrade segments specified in an upgrade specification until a precondition of one of the upgrade segments is aligned with the versioning data of the device profile data for the patient-respiratory device.

15. 1. A system for updating firmware and / or software, said system comprising:

10. An update system comprising the computer system of claim 1, wherein the update system is located remotely from the patient respiratory device; and and the patient respiratory device of claim 1, wherein the patient respiratory device comprises: communicating the first message with the update system, the first message including identification data for the patient respiratory device; receiving the second message; performing an update process to apply the update to the firmware and / or software to the patient respiratory device based on the second message; 1. A system configured to perform operations including:

16. 1. A method implemented in a computer system for managing updates provided to a patient respiratory device, the method comprising: receiving a first message from a patient respiratory device, the first message including identification data for the patient respiratory device, the patient respiratory device including an electronic memory storing firmware and software used to control operation of the patient respiratory device, the first message being communicated from the patient respiratory device without a first prompt from the computer system; obtaining device profile data for the patient respiratory devices from one or more records of a status database including records for a plurality of patient respiratory devices, each of the records including versioning data identifying firmware and / or software installed on each of a plurality of different patient respiratory devices, the device profile data obtained based on processing the received first message, and the identification data of the patient respiratory device included in the first message; selecting at least one upgrade package from a plurality of available upgrade packages to be applied to the patient respiratory device based on the device profile data for the patient respiratory device, each of the plurality of available upgrade packages being associated with at least one upgrade rule including identification profile data; generating a second message containing data used to update the software and / or firmware of the patient respiratory device based on the at least one selected upgrade package; sending the second message to the patient-respiratory device, the second message causing the patient-respiratory device to perform an update process to apply the update to the firmware and / or software to the patient-respiratory device; receiving a third message including identification data for the patient respiratory device, the third message being communicated from the patient respiratory device without a first prompt from the computer system; and sending a fourth message based on the third message back to the patient respiratory device identified in the third message, the fourth message including data for applying an update to firmware and / or software.

17. retrieving an existing broker request specifying firmware and / or software to be upgraded as a result of receiving the third message; and generating the fourth message based on a request of the existing broker; 17. The method of claim 16, wherein, once the third message is received, generating the fourth message is performed without relying on obtaining device profile data or selecting an upgrade package from a plurality of available upgrade packages.

Images