Management of remote respiratory therapy devices

Abstract

This technology relates to one or more of the following: screening, diagnosis, monitoring, treatment, prevention, and improvement of respiratory disorders. [Solution] A server is provided which is programmed to automatically determine whether there are applicable upgrades to the code or data (e.g., software or firmware) stored in the electronic memory of a patient device, based on identification data that uniquely identifies the patient device. In response to the determination that there are applicable upgrades, a data package is delivered to the patient device via a first wireless transceiver, and the data package is to be automatically applied to the electronic memory of the patient device.

Description

Technical Field

[0001] 1 Cross - reference to related applications This application claims priority to U.S. Provisional Application No. 62 / 935,356 (filed on November 14, 2019). The entire content of this document is incorporated herein by reference. Regarding U.S. Publication No. 2017 / 0136198, the content of this document is incorporated herein by reference.

Background Art

[0002] 2 Background of the technology 2.1 Field of the technology This technology relates to one or more of screening, diagnosis, monitoring, treatment, prevention, and improvement of respiratory - related disorders. This technology also relates to medical devices or apparatuses and their use. This technology relates to medical devices or apparatuses, their use, and updates.

[0003] 2.2 Description of related technologies 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 the patient's airway.

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

[0005] A range of respiratory impairments is present. Specific impairments may be characterized by specific onsets (e.g., apnea, hypopnea, and hyperventilation).

[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 disorders (NMD), and chest wall disorders.

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

[0008] Respiratory pressure therapy involves adding air to the airway inlet at a controlled target pressure. This target pressure is nominally positive relative to the atmosphere throughout the patient's respiratory cycle (in contrast to negative pressure therapy, such as tank ventilators or positive / negative pressure external ventilators).

[0009] Continuous positive airway pressure (CPAP) therapy is used in the treatment of obstructive sleep apnea (OSA). Its mechanism of action involves, for example, the continuous positive airway pressure acting as an air pressure splint by pushing the soft palate and tongue forward or backward against the posterior oropharyngeal wall, thereby preventing upper airway obstruction. Since CPAP treatment for OSA can be voluntary, patients may choose not to adhere to treatment if they notice one or more of the following regarding the device used to deliver the treatment: discomfort, difficulty of use, high cost, or lack of aesthetic appeal.

[0010] Non-invasive ventilation (NIV) provides ventilatory support to the patient through the upper airway to assist with breathing and / or maintain adequate oxygen levels throughout the body by performing some or all of the respiratory function. Ventilation support is provided through a non-invasive patient interface. NIV is used to treat forms of respiratory failure and pulmonary stenosis, 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 can be improved.

[0012] Mechanical ventilators can control the timing and pressure of the breath pumped into the patient and monitor the patient's breathing. These methods of patient control and monitoring typically include volume-controlled and pressure-cycled methods. Examples of volume-controlled methods include pressure-controlled volume-controlled ventilation (PRVC), tidal volume (VV), and volume-controlled continuous forced ventilation (VC-CMV) techniques. Examples of pressure-cycled methods include assisted control (AC), synchronous intermittent forced ventilation (SIMV), controlled mechanical ventilation (CMV), pressure-assisted ventilation (PSV), continuous positive airway pressure (CPAP), or positive end-expiratory pressure (PEEP) techniques.

[0013] 2.2.3 Respiratory Therapy Systems These respiratory therapies may be provided by respiratory therapy systems or devices. Such systems and devices may also be used for screening, diagnosis, or monitoring without treating the disease.

[0014] A respiratory therapy system may include respiratory pressure therapy devices (RPT devices), air circuits, humidifiers, patient interfaces, oxygen sources, and data management.

[0015] 2.2.3.1 Patient Interface A patient interface may be used to provide the wearer with an interface to a respiratory appliance, for example, by providing airflow to the airway inlet. 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 applied, the patient interface may form a seal with, for example, the area of ​​the patient's face, thereby facilitating gas delivery at a pressure of sufficient dispersion with the ambient pressure for the performance of the treatment (for example, at a positive pressure of about 10 cmH2O relative to the ambient pressure). In other forms of treatment, such as oxygen delivery, the patient interface may not include a seal sufficient to facilitate the delivery of gas to the airway at a positive pressure of about 10 cmH2O. In the case of flow therapies such as nasal HFT, the patient interface is configured to allow blowing into the nostrils and explicitly avoid a complete seal. An example of such a patient interface is a nasal cannula.

[0016] CPAP therapy is highly effective in treating certain respiratory disorders when the patient consents to the treatment. Patients may refuse treatment if the mask is uncomfortable or difficult to use. Since patients are often advised to wash their masks regularly, if the mask is difficult to clean (e.g., difficult to assemble or disassemble), the patient may be unable to clean the mask, which can affect patient compliance.

[0017] Masks designed for other purposes (e.g., pilot use) may be unsuitable for treating sleep-disordered breathing, while masks designed for treating sleep-disordered breathing may be suitable for other purposes.

[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 A respiratory pressure therapy (RPT) device can be used individually for the delivery of one or more of the above-mentioned therapies, or as part of a system, for example, by operating the device to generate an air delivery flow to an interface to the airway. The air flow can be pressure-controlled (for respiratory pressure therapy) or flow-controlled (for flow therapy such as HFT). Therefore, the RPT device can also function as a flow therapy device. Examples of RPT devices include CPAP devices and ventilators. The RPT device is known as a flow generator.

[0020] Air pressure generators are known in a wide range of applications (e.g., industrial scale ventilation systems). However, air pressure generators for medical applications have specific requirements that are not satisfied by more general air pressure generators (e.g., reliability requirements, size requirements, and weight requirements for medical devices). In addition, even devices designed for medical treatment may be defective in relation to one or more of the following: comfort, noise, ease of use, effectiveness, size, weight, manufacturability, cost, and reliability.

[0021] An example of a special requirement for a specific RPT device is acoustic noise.

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

[0023] Designers of devices can be presented with countless options. Since design criteria often conflict with each other, certain design options may be far from convention or unavoidable. Furthermore, the comfort and effectiveness of a particular aspect can also be greatly affected by minor changes in one or more parameters.

[0024] 2.2.3.3 Air Circuit The air circuit is a conduit or tube constructed and arranged such that, in use, an air flow moves between two components of a respiratory therapy system (e.g., an RPT device and a patient interface). In some cases, it can be a separate leg 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 If the delivery of the air flow is performed without humidification, it can lead to drying of the airway. When a humidifier is used with an RPT device and a patient interface, humidified gas is generated, thus minimizing drying of the nasal mucosa and increasing patient airway comfort. Additionally, in a cooler climate, generally adding warm air to the facial area around the patient interface increases comfort more than in the case of cold air. Therefore, humidifiers often have the ability to not only humidify the air flow but also heat it.

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

[0027] In patient treatment, there may be other ways in which communication of treatment data to third parties or external systems may be beneficial.

[0028] Existing processes for communicating and managing such data can be costly, time-consuming, and prone to errors. [Overview of the project] [Means for solving the problem]

[0029] 3. A brief explanation of the technology This technology relates to the provision of medical devices used in the screening, diagnosis, monitoring, improvement, treatment, or prevention of respiratory disorders, which have one or more of the following advantages: improved comfort, cost-effectiveness, efficacy, ease of use, and manufacturability.

[0030] One aspect of a particular form of this technology is to provide a method and / or apparatus for improving patient compliance with respiratory therapy.

[0031] One form of this technology includes a technique for automatically managing and maintaining updates (e.g., software, settings, firmware) for multiple diverse patient devices.

[0032] Another aspect of this technology is the use of rule-based processing. This rule-based processing responds to individually submitted requests from patient devices. These requests include identification data associated with a particular device. This information allows the system to automatically determine what updates to apply to the patient device (without requiring manual updates).

[0033] The methods, systems, devices, and apparatus described may be embodied in a way that enables improvements in the functionality of processors (e.g., the processors of computers for specific purposes, respiratory monitors, and / or respiratory therapy devices). Furthermore, the methods, systems, devices, and apparatus described (including, for example, devices that provide monitoring and / or treatment of sleep-disordered breathing) may enable improvements in the field of automated management, monitoring, and / or treatment of respiratory diseases.

[0034] Of course, some embodiments may form sub-embodiments of the present technology. Furthermore, various combinations of sub-embodiments and / or various other embodiments may constitute even further embodiments or sub-embodiments of the present technology.

[0035] Other features of this 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 This technology is illustrated non-limitingly as an example in the attached drawings. In the drawings, similar reference numerals include the following similar elements. [Brief explanation of the drawing]

[0037] [Figure 1A] 4.1 Respiratory Therapy System: The system includes a patient 1000 wearing a patient interface 3000. This system takes the form of a nasal pillow and receives positive-pressure air supplied from an RPT device 4000. The air from the RPT device 4000 is regulated by a humidifier 5000 and travels to the patient 1000 along an air circuit 4170. A bedmate 1100 is also illustrated. The patient is sleeping in a supine sleeping position. [Figure 1B] The system includes a patient 1000 wearing a patient interface 3000. This system takes the form of a nasal mask and receives positive-pressure air supplied from an RPT device 4000. The air from the RPT device is humidified by a humidifier 5000 and travels to the patient 1000 along an air circuit 4170. [Figure 1C] The system includes a patient 1000 wearing a patient interface 3000. The patient interface 3000 removes a full face mask and receives positive pressure air from an RPT device 4000. The air from the RPT device is humidified by a humidifier 5000 and travels to the patient 1000 along an air circuit 4170. The patient is sleeping in a lateral sleeping position. [Figure 2A] 4.2 Anatomical Structures of the Respiratory System and Face: An overview of the human respiratory system is provided, including the nasal cavity and oral cavity, larynx, vocal cord 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, according to one embodiment of this technology, is shown. [Figure 4C] 4.4 RPT Device: This is a schematic diagram of the electrical components of an RPT device according to one aspect of this technology. [Figure 4D] This is a schematic diagram of an algorithm executed in an RPT device according to one form of this technology. [Figure 4E] This is a flowchart illustrating a method implemented by the treatment engine module shown in Figure 4D, according to one aspect of this technology. [Figure 5A] 4.5 Humidifier: This is an isometric view of a humidifier according to one embodiment of this technology. [Figure 5B] This is an isometric view of a humidifier according to one embodiment of this technology, showing the humidifier reservoir 5110 removed from the humidifier reservoir dock 5130. [Figure 6A] 4.6 Respiratory waveform: A model of a typical human respiratory waveform during sleep is shown. [Figure 7] 4.7 Data Management System: An exemplary machine management service system 106 is shown, which is used to communicate with patient devices 102 (102A, 102B, 102C) and to provide updates to patient devices 102 (102A, 102B, 102C) according to a specific example. [Figure 8]This is a signal diagram showing communication between an exemplary RPT device and the exemplary machine management service system shown in Figure 7. [Figure 9A] This is a flowchart of computer operations that may be performed in a specific example. [Figure 9B] This is a flowchart of computer operations that may be performed in a specific example. [Figure 10A] This diagram shows the signaling of communications that may occur between various computing devices and / or services in connection with the delivery of a brokered request to a patient device, following a specific example. [Figure 10B] This diagram shows the signaling of communications that may occur between various computing devices and / or services in connection with the delivery of a broker request to a patient device, following a specific example. [Figure 10C] This diagram shows the signaling of communications that may occur between various computing devices and / or services in connection with the delivery of a broker request to a patient device, following a specific example. [Figure 11] 4.8 Computing Devices: Exemplary computing devices that may be used in some embodiments for performing the features described herein are shown. [Modes for carrying out the invention]

[0038] 5. Detailed explanation of examples of this technology Before describing the technology in further detail, it should be understood that the technology is not limited to the specific examples that may be described herein. It should also be understood that the terms used in this disclosure are for illustrative purposes only and are not limiting.

[0039] The following description is provided in relation to a variety of examples that may share one or more common properties 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 any other example. In addition, any single feature or combination of features in any of these examples may constitute further examples.

[0040] 5.1 Treatment In one embodiment, the technology includes a method for treating respiratory disorders. The method includes applying positive pressure to the airway entrance of patient 1000. In a particular example of the technology, the air supply in positive pressure is provided to the patient's nasal passages through one or both nostrils. In a particular example of the technology, mouth breathing is restricted, limited, or prevented.

[0041] 5.2 Respiratory Therapy Systems In one embodiment, the technology includes a respiratory therapy system for the treatment of respiratory disorders. The respiratory therapy system may include an RPT device 4000 that supplies 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 according to one aspect of this technology includes the following functional modes: a seal-forming structure 3100, a plenum chamber 3200, a positioning and stabilizing structure 3300, a vent 3400, a connection port 3600 in one form for connection to an air circuit 4170, and a forehead support 3700. In some embodiments, the functional modes may be provided by one or more physical components. In some embodiments, one physical component may provide one or more functional modes. When in use, the seal-forming structure 3100 is positioned to surround the entrance to the patient's airway so as to maintain positive pressure at the entrance(s) of the patient's airway. Thus, the sealed patient interface 3000 is suitable for the delivery of positive pressure therapy.

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

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

[0045] A patient interface 3000 in one embodiment of this technology is constructed and positioned to provide an air supply with a positive pressure of at least 10 cmH2O relative to the surroundings.

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

[0047] 5.4 RPT Devices An RPT device 4000 according to one aspect of this technology includes mechanical, pneumatic, and / or electrical components and is configured to perform one or more algorithms 4300 (e.g., any of the methods described herein, either entirely or in part, such as processes, software modules, etc.). The RPT device 4000 may be configured to generate an airflow delivered to a patient's airway for the treatment of one or more of the respiratory diseases described in any of the documents.

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

[0049] Referring here to Figure 4C, the RPT device 4000 may have an electrical power supply 4210, one or more input devices 4220, a central controller 4230, a therapeutic 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 may be mounted on a single printed circuit board assembly (PCBA) 4202. In one alternative embodiment, the RPT device 4000 may include more than one PCBA 4202. In a particular exemplary embodiment, the RPT device 400 may include a computing device as described in relation to Figure 11. In a particular example, the electrical components described in relation to Figure 4C may correspond to the counterparts shown in Figure 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 embodiment of this technology, the power supply 4210 supplies power only to the RPT device 4000. In another embodiment of this technology, power is supplied from the power supply 4210 to both the RPT device 4000 and the humidifier 5000.

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

[0053] In one embodiment, the input device 4220 may be constructed and configured to allow a human to select a value and / or a menu option.

[0054] 5.4.1.3 Central Controller In one embodiment of this 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, which are based on ARM® Cortex®-M processors from ARM Holdings (e.g., STM32 series microcontrollers from ST Microelectronics). In certain other forms of this technology, a 32-bit RISC CPU (e.g., STR9 series microcontrollers from ST Microelectronics) or a 16-bit RISC CPU (e.g., processors from the MSP430 family of microcontrollers (manufactured by Texas Instruments)) may also be suitable.

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

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

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

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

[0060] In some embodiments of this technology, the central controller 4230 is configured to implement one or more methods described herein (e.g., one or more algorithms 4300 (described in relation to Figure 4D) expressed as computer programs stored in a non-temporary computer-readable storage medium (e.g., memory 4260)). In some embodiments of this technology, the central controller 4230 may be integrated with the RPT device 4000. However, in some embodiments of this 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 by analyzing stored data (e.g., from any of the sensors described herein).

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

[0062] 5.4.1.5 Therapeutic device controllers In one embodiment of this technology, the therapeutic device controller 4240 is a therapeutic control module 4330 that forms part of the algorithm 4300 executed by the central controller 4230.

[0063] In one embodiment of this technology, the treatment device controller 4240 is a dedicated motor control integrated circuit. For example, in one embodiment, an MC33035 brushless DC motor controller (manufacturer: ONSEMI) is used.

[0064] 5.4.1.6 Protection circuit One or more protection circuits 4250 in this technology may include electrical protection circuits, temperature and / or pressure safety circuits.

[0065] 5.4.1.7 Memory In one embodiment of this technology, the RPT device 4000 includes a memory 4260 (e.g., non-volatile memory). In some embodiments, the memory 4260 may include battery-powered static RAM. In some embodiments, the memory 4260 may include volatile RAM.

[0066] Memory 4260 may be located on PCBA4202. 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 (for example, a memory card manufactured in accordance with the Secure Digital (SD) standard).

[0068] In one embodiment of this technology, the memory 4260 functions as a non-temporary computer-readable storage medium. Computer program instructions (e.g., one or more algorithms 4300) representing one or more methods described herein are stored on this storage medium.

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

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

[0071] In one embodiment, the remote external communication network 4282 is the Internet. The data communication interface 4280 may use wired communication (e.g., via Ethernet or optical fiber) or wireless protocols (e.g., CDMA, GSM, LTE) to connect to the Internet.

[0072] In one configuration, the local external communication network 4284 uses one or more communication standards (e.g., Bluetooth or consumer infrared protocol).

[0073] In one embodiment, the remote external device 4286 is one or more computers (e.g., a cluster of networked computers). In another embodiment, 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 a properly authorized person (e.g., a clinician).

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

[0075] 5.4.1.9 Optional output devices including displays and warnings The output device 4290 according to this technology may take the form of one or more of visual, auditory, and haptic units. The visual display may be a liquid crystal display (LCD) or a light-emitting diode (LED) display.

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

[0077] 5.4.1.9.2 Display The display 4294 is configured to visually display characters, symbols, or images in response to commands received from the display driver 4292. For example, the display 4294 may be an 8-segment display. In this case, the display driver 4292 converts each character or symbol (e.g., the number "0") into eight logical signals (indicating that each of the eight segments has been activated to display a particular character or symbol).

[0078] 5.4.1.10 Converters (singular or plural) The transducer 4270 may be located inside the RPT device or outside the RPT device. The external transducer may be located on, for example, an air circuit or form part of an air circuit (e.g., a patient interface). The external transducer may take the form of a non-contact sensor (e.g., a Doppler radar motion sensor that transmits or moves the data RPT device).

[0079] In one embodiment of this technology, one or more transducers 4270 are positioned upstream and / or downstream of a pressure generator. One or more transducers 4270 may be constructed and positioned to generate signals that describe the characteristics of the airflow (e.g., flow rate, pressure, or temperature at that point in the pneumatic path).

[0080] In one embodiment of this technology, one or more transducers 4270 may be located near the patient interface 3000.

[0081] In one embodiment, 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 The flow sensor 4274 based on this technology can be based on a differential pressure transducer (for example, the SDP600 series differential pressure transducer from SENSIRION).

[0083] In one configuration, a signal representing the flow rate, generated by the flow sensor 4274, is received by the central controller 4230.

[0084] 5.4.1.10.2 Pressure Sensor The pressure sensor 4272 using this technology can be positioned in communication with both pneumatic and fluid pathways. An example of a suitable pressure sensor is a transducer from the HONEYWELL ASDX series. Another suitable pressure sensor is a transducer from the GENERAL ELECTRIC NPA series.

[0085] In one configuration, 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 embodiment of this technology, the motor speed transducer 4276 is used to determine the rotational speed of the motor and / or the blower of the RPT device 4000. The motor speed signal from the motor speed transducer 4276 may be provided to the treatment 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 described above, in some forms of this technology, the central controller 4230 may be configured to execute one or more algorithms 4300 as shown in Figure 4D. These algorithms may be represented as computer programs stored in a non-temporary computer-readable storage medium (e.g., memory 4260). The algorithms 4300 are generally grouped into groups called modules or software modules.

[0088] In other embodiments of this 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 embodiments, input signals and / or data representing intermediate algorithm outputs required for the portion of the algorithm 4300 executed by the external device may be communicated to the external device via a local external communication network 4284 or a remote external communication network 4282. In such embodiments, the portion of the algorithm 4300 executed by the external device may be represented as a computer program stored in a non-temporary computer-readable storage medium accessible to the controller of the external device. Such a program configures the controller of the external device to execute the portion of the algorithm 4300.

[0089] In this configuration, treatment parameters generated by an external device via the treatment engine module 4320 (in this configuration, a portion of the algorithm 4300 is executed by the external device) can be transmitted to the central controller 4230 and passed to the treatment control module 4330.

[0090] 5.4.2.1 Preprocessing Module A pre-processing module 4310, according to one embodiment of this technology, receives a signal from a transducer 4270 (e.g., a flow sensor 4274 or a pressure sensor 4272) as input and performs one or more process steps to calculate one or more output values. These output values ​​are used as input to another module (e.g., a therapeutic engine module 4320).

[0091] In one embodiment of this technology, the output values ​​include interface pressure Pm, respiratory flow rate Qr, and leakage flow rate Ql.

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

[0093] 5.4.2.1.1 Interface Pressure Estimation In one embodiment of this technology, the interface pressure estimation algorithm 4312 receives a signal from pressure sensor 4272 indicating the pressure in the pneumatic path near the outlet of the pneumatic block (device pressure Pd) and a signal from flow sensor 4274 indicating the flow rate of the airflow discharging the RPT device 4000 (device flow rate Qd). The device flow rate Qd, which contains no replenishment gas, can be used as the total flow rate 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 rate Qt can be modeled for a particular air circuit 4170 by the pressure drop characteristic ΔP(Q). Next, the interface pressure estimation algorithm 4312 provides an estimated pressure Pm in the patient interface 3000 or 3800 as an output. The pressure Pm in the patient interface 3000 or 3800 can be estimated as the device pressure Pd minus the air circuit pressure drop ΔP.

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

[0095] 5.4.2.1.3 Estimation of leakage flow rate In one embodiment of this technology, the leakage flow rate estimation algorithm 4316 receives a total flow rate Qt and a permeable flow rate Qv as inputs and provides an estimate of the leakage flow rate Ql as an output. In one embodiment, the leakage flow rate estimation algorithm estimates the leakage flow rate Ql by calculating the average difference between the total flow rate Qt and the permeable flow rate Qv over a sufficiently long period of time, including several breathing cycles (e.g., about 10 seconds).

[0096] In one embodiment, the leakage flow rate estimation algorithm 4316 receives the total flow rate Qt, the vent flow rate Qv, and the estimated pressure Pm in the patient interface 3000 or 3800 as inputs, by providing the leakage flow rate Ql as output, calculating the leakage conductance, and determining that the leakage flow rate Ql is a function of the leakage conductance and the pressure Pm. The leakage conductance is calculated as the low-pass filtered square root of the pressure Pm and the quotient of the low-pass filtered non-vent flow rate equal to the difference between the total flow rate Qt and the vent flow rate Qv, where the low-pass filtered time constant has a sufficient value to include several respiratory cycles (e.g., about 10 seconds). The leakage flow rate Ql can be estimated as the product of the leakage conductance and the pressure Pm as a function.

[0097] 5.4.2.1.4 Respiratory flow estimation In one embodiment of this technology, the respiratory flow rate estimation algorithm 4318 receives total flow rate Qt, inlet flow rate Qv, and leakage flow rate Ql as inputs, and estimates the respiratory air flow rate Qr for the patient (by dividing the inlet flow rate Qv and leakage flow rate Ql by the total flow rate Qt). 5.4.2.2 Treatment Engine Module

[0098] In one embodiment of this technology, the treatment engine module 4320 receives one or more of the pressure Pm and the air breathing flow rate Qr to the patient as inputs from the patient interface 3000 or 3800, and provides one or more treatment parameters as outputs.

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

[0100] In one embodiment of this technology, the treatment parameters are one or more of the following: the amplitude of the pressure change, the base pressure, and the target ventilation.

[0101] In various forms, the therapeutic 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 / respiratory depression determination 4325, snoring determination 4326, airway patency determination 4327, target ventilation determination 4328, and therapeutic parameter determination 4329.

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

[0103] In one embodiment of this technology, the phase determination algorithm 4321 receives a signal indicating the respiratory flow rate Qr as input and provides the current respiratory cycle phase of patient 1000 as output Φ.

[0104] In several forms known as discrete phase determination, the phase output Φ is a distinct variable. One execution of discrete phase determination provides a binary phase output Φ having inspiratory or expiratory values, which are represented, for example, as rotation 0 and rotation 0.5 (at the detection of the start of spontaneous inhalation and exhalation, respectively). The RPT device 4000, which "triggers" and "cycles," effectively performs discrete phase determination because the trigger point and cycle point are the moments when the phase changes from exhalation to inhalation and from inhalation to exhalation, respectively. In one execution of binary phase determination, the phase output Φ is determined to have a discrete value of 0 when the respiratory flow rate Qr is above a positive threshold (thus "triggering" the RPT device 4000), and a discrete value of 0.5 rotations when the respiratory flow rate Qr is above a negative threshold (thus "cycles" the RPT device 4000). The inspiratory time Ti and expiratory time Te may be typical values ​​estimated over many respiratory cycles with phases Φ equal to 0 (representing inspiration) and 0.5 (representing expiration), respectively.

[0105] Another execution of discrete phase determination yields a tri-phase output Φ with one of the following values: inhalation, pause during inhalation, and exhalation.

[0106] In other forms, the phase output Φ, known as continuous phase determination, is a continuous variable, for example, fluctuating between 0 and 1 revolution or 0 and 2π radians. The RPT device 4000 performing continuous phase determination can be triggered and cycled when the continuous phase reaches 0 revolutions and 0.5 revolutions, respectively. In one run of continuous phase determination, the continuous value Φ of the phase is determined using fuzzy logic analysis of the respiratory flow rate Qr. The continuous value of the phase determined in this run is often called the "fuzzy phase". In one run of the fuzzy phase determination algorithm 4321, the following rules apply to the respiratory flow rate Qr: 1. If the respiratory flow rate is zero and rapidly increasing, the phase turnover is 0. 2. When the respiratory flow rate is large, positive, and stable, the phase turnover rate is 0.25. 3. When the respiratory flow rate is zero and rapidly decreasing, the phase rotation rate is 0.5. 4. When the respiratory flow rate is large and stable, the phase turnover is 0.75. 5. When the respiratory flow rate is zero and stable, and the absolute value of the respiratory flow rate after 5 seconds of low-pass filtering is large, the phase turnover is 0.9. 6. When the respiratory flow rate is positive and the phase is exhalation, the phase rotation is 0. 7. When the respiratory flow rate is negative and the phase is inspiration, the phase rotation rate is 0.5. 8. If the absolute value of the respiratory flow filtered by the low-pass filter over 5 seconds is large, the phase increases at a constant rate equal to the patient's respiratory rate filtered by the low-pass filter with a time constant of 20 seconds.

[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 a fuzzy range (where the rule is true). The fuzzy range for respiratory flow, for example, "large" or "stable," is determined by an appropriate membership function. The rule results, represented as vectors, are then combined by some function (e.g., centroid acquisition). In such a combination, these rules may be weighted equally or in different ways.

[0108] In another execution of continuous phase determination, phase Φ, like inspiratory time Ti and expiratory time Te, is first estimated individually from respiratory flow rate Qr as described above. The continuous phase Φ at any given moment is determined as half the proportion of inspiratory time Ti elapsed since the preceding trigger moment, or 0.5 rotations, plus the proportion of expiratory time Te elapsed since the preceding cycle moment (of these, the more recent moment).

[0109] 5.4.2.2.2 Waveform Determination In one embodiment of this technology, the treatment parameter determination algorithm 4329 provides a nearly constant treatment pressure throughout the patient's entire respiratory cycle.

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

[0111] In one embodiment of this technology, the waveform determination algorithm 4322 provides a waveform template Π(Φ). The waveform template has a range of values ​​within [0,1] for the phase value Φ provided by the phase determination algorithm 4321, which is to be used by the treatment parameter determination algorithm 4329.

[0112] In one form, suitable for discrete or continuous phases, the waveform template Π(Φ) is a square wave template with a value of 1 for phase values ​​up to 0.5 turns and a value of 0 for phase values ​​exceeding 0.5 turns. In one form, suitable for continuously valued phases, the waveform template Π(Φ) includes two smoothly curved portions (i.e., a smoothly curved rise from 0 to 1 (e.g., rising cosine) for phase values ​​up to 0.5 turns, and a smoothly curved fall from 1 to 0 (e.g., exponential) for phase values ​​exceeding 0.5 turns). In one form, suitable for continuously valued phases, 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" lower than 0.5 turns, and a smooth fall from 1 to 0 for phase values ​​within the "fall time" after 0.5 turns, with a "fall time" lower than 0.5 turns.

[0113] In some forms of this 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 lookup table of values ​​Π for a phase value Φ. In other forms, the waveform determination algorithm 4322 calculates the waveform template Π(Φ) "on the fly" using a predetermined functional form, possibly parameterized by one or more parameters (e.g., time constants for the exponential curve portion). These parameters of the functional form may be predetermined or may depend on the current state of patient 1000.

[0114] In some forms of this technique suitable for discrete binary phases of inhalation (Φ=0 rotations) or exhalation (Φ=0.5 rotations), 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 moment. In one such form, the waveform determination algorithm 4322 calculates the waveform template Π(Φ,t) in two parts (inhalation and exhalation) as follows:

number

[0115] 5.4.2.2.3 Ventilation Decision In one embodiment of this technology, the ventilation determination algorithm 4323 receives respiratory flow rate Qr as input and determines a measurement that indicates the current patient ventilation Vent.

[0116] In some implementations, the ventilation determination algorithm 4323 determines a measurement of ventilation Vent, which is an estimate of actual patient ventilation. One such implementation is to take half 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 is 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 measurement of the range in which the inspiratory portion of the respiration indicates an inspiratory flow limitation.

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

[0121] From the scaled flow rate, two shape factors related to the determination of partial blockage can be calculated.

[0122] The shape factor 1 is the ratio of the average of intermediate (e.g., 32) scaled flow points to the overall average of scaled flow points (e.g., 65) scaled flow points. If this ratio is greater than 1, respiration is considered normal. If this ratio is less than 1, respiratory obstruction is considered to be occurring. A ratio of approximately 1.17 is taken as a threshold between partially obstructive and unobstructed respiration, equivalent to a certain level of obstruction, and allows for appropriate oxygen administration maintenance in a typical patient.

[0123] The shape factor 2 is calculated as the mean squared deviation from a unit-scaled flow rate and is taken over intermediate points (e.g., 32 points). A mean squared deviation of approximately 0.2 units is considered normal. A mean squared deviation of zero indicates that the respiratory flow is generally restricted. The closer the mean squared deviation is to zero, the more pronounced the respiratory flow restriction is considered to be.

[0124] Shape factors 1 and 2 may be used interchangeably or in combination. In other embodiments of this technique, the number of sampled points, breaths, and midpoints may differ from those described above. Furthermore, the threshold may also differ from those described above.

[0125] 5.4.2.2.5 Determination of apnea and respiratory depression In one embodiment of this technology, the central controller 4230 executes an apnea / respiratory depression determination algorithm 4325 to determine the presence of apnea and / or respiratory depression.

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

[0127] In one embodiment, apnea is detected when the function of respiratory flow rate Qr falls below a flow threshold for a predetermined period. This function can determine the peak flow rate, the average flow rate over a relatively short period, or the flow rate median between the average and peak flow rates over a relatively short period (e.g., RMS flow rate). The flow threshold may be a relatively long-term measurement of the flow rate.

[0128] In one embodiment, respiratory depression is detected when the function of respiratory flow rate Qr falls below a second flow threshold over a predetermined period. This function can determine the peak flow rate, the average flow rate over a relatively short period, or the median flow rate between the average and peak flow rates over a relatively short period (e.g., RMS flow rate). The second flow threshold may be a relatively long-term measurement of the flow rate. The second flow threshold is higher than the flow threshold used to detect apnea.

[0129] 5.4.2.2.6 Determining Snoring In one embodiment of this technology, the central controller 4230 executes one or more snoring determination algorithms 4326 to determine the range of snoring.

[0130] In one embodiment, the snoring determination algorithm 4326 receives a respiratory flow signal Qr as input and provides as output measurements of the range in which snoring is present.

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

[0132] 5.4.2.2.7 Determining airway patency In one embodiment of this technology, the central controller 4230 executes one or more airway patency determination algorithms 4327 to determine the range of airway patency.

[0133] In one configuration, the airway patency determination algorithm 4327 receives a respiratory flow signal Qr as input and determines the signal output within a frequency range of approximately 0.75 Hz to approximately 3 Hz. If there is a peak within this frequency range, it is considered to indicate airway opening. If there is no peak, it is considered to indicate airway closure.

[0134] In one configuration, the frequency range for peak detection is the frequency of small forced vibrations at the therapeutic pressure Pt. In one run, the forced vibration has a frequency of 2 Hz and an amplitude of approximately 1 cmH2O.

[0135] In one configuration, the airway patency determination algorithm 4327 receives a respiratory flow signal Qr as input and determines the presence or absence of a cardiac signal. If there is no cardiac signal, airway obstruction is assumed.

[0136] 5.4.2.2.8 Determining the Target Ventilation In one embodiment of this technology, the central controller 4230 takes the current ventilation measurement Vent as input and executes one or more target ventilation determination algorithms 4328 to determine the target value Vtgt for ventilation measurement.

[0137] In some forms of this technology, the target ventilation determination algorithm 4328 is absent, and the target value Vtgt is predetermined, for example, by hardcoding during the configuration of the RPT device 4000 or by manual input through the input device 4220.

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

[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. In such forms, the high percentage may range from (80%, 100%) to (85%, 95%) or (87%, 92%).

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

[0141] A typical recent ventilation (Vtyp) is a value at which the distribution of current ventilation (Vent) measurements over multiple time points over a given time scale tends to cluster (i.e., a measurement of the central trend of current ventilation measurements over recent history). In one run of the target ventilation determination algorithm 4328, the recent history is on the order of several minutes, but in any case, it must be longer than the time scale of the Chain-Stokes increasing and decreasing cycles. The target ventilation determination algorithm 4328 may use any of a variety of well-known measurements of central trend to determine a typical recent ventilation (Vtyp) from current ventilation (Vent) measurements. One such measurement is a low-pass filtered output of current ventilation (Vent) measurements with a time constant equal to 100 seconds.

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

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

number

[0144] If the waveform determination algorithm 4322 provides a waveform template Π(Φ,t) as a lookup table of values ​​Π indexed by phase Φ, the treatment parameter determination algorithm 4329 applies equation (1) by either locating the nearest lookup table input to the current value Φ of the phase returned from the phase determination algorithm 4321 or by interpolation between two inputs spanning the current value Φ of the phase.

[0145] The amplitude A-based pressure P0 value 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 According to one aspect of this technology, the treatment control module 4330 receives treatment parameters from the treatment parameter determination algorithm 4329 of the treatment engine module 4320 as input, and controls the pressure generator 4140 to deliver airflow from the pressure generator 4140 according to these treatment parameters.

[0147] In one embodiment of this technology, the treatment parameter is the treatment pressure Pt, and the treatment control module 4330 controls the pressure generator 4140 so that the interface pressure Pm at the patient interface 3000 or 3800 is equal to the treatment pressure Pt, and the airflow from the pressure generator 4140 is delivered.

[0148] 5.4.2.4 Detection of Fault Conditions In one embodiment of this technology, the central controller 4230 performs one or more methods 4340 for detecting a fault condition. The fault conditions detected by one or more methods 4340 may include at least one of the following: ● Power outage (no power or insufficient power) ● Detection of converter failure ● No detection of the presence of components. ● Operating parameters are outside the recommended range (e.g., pressure, flow rate, temperature, PaO2) ● There should be no test warnings for generating detectable warning signals.

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

[0150] 5.5 Air Circuit An air circuit 4170 according to one aspect of this technology is a conduit or tube constructed and positioned so that airflow moves between two components (e.g., an RPT device 4000 and a patient interface 3000 or 3800) during use.

[0151] In detail, the air circuit 4170 may be fluidly connected to the outlet and patient interface of the pneumatic block. The air circuit may be called 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 embodiments, 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. These heating elements may take the form of a heating wire circuit and may include one or more transducers (e.g., temperature sensors). In one embodiment, the heating wire circuit may be spirally wound around the axis of the air circuit 4170. The heating elements may communicate with a controller (e.g., a central controller 4230).

[0153] 5.6 Humidifier In one embodiment of this technology, a humidifier 5000 is provided for changing the absolute humidity of air or gas to be delivered to a patient relative to the ambient air (for example, as shown in Figure 5A). Typically, the humidifier 5000 is used to increase the absolute humidity and the temperature of the airflow (relative to the ambient air) before delivery to the patient's airway.

[0154] The humidifier 5000 may include a humidifier reservoir 5110, a humidifier inlet 5002 for receiving an airflow, and a humidifier outlet 5004 for delivering the humidified airflow. In some embodiments, such as those 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 and 5B. In some configurations, the humidifier reservoir dock 5130 may include a locking mechanism (e.g., a locking lever 5135 configured to hold the reservoir 5110 within the humidifier reservoir dock 5130). According to one configuration, the reservoir 5110 includes a conductive portion 5120 configured to allow efficient heat transfer from the heating element 5240 to a fixed amount of liquid in the reservoir 5110. In one embodiment, the conductive portion 5120 may be arranged as a plate, but other shapes may also be appropriate.

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

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

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

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

[0160] Figure 4E is a flowchart of method 4500 performed by the central controller 4230. In method 4500, if pressure assist A is equal to zero, the base pressure P0 is continuously calculated as part of the APAP treatment execution of the treatment 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 / respiratory depression to a first threshold and determines whether the measurement of the presence of apnea / respiratory depression exceeds the first threshold over a predetermined period (indicating the occurrence of apnea / respiratory depression). Method 4500 proceeds to step 4540, or, if not, 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, it indicates that the airway is patent and the detected apnea / respiratory depression is considered central, and Method 4500 proceeds to step 4560. If the measurement of airway patency does not exceed the second threshold, the apnea / respiratory depression is considered obstructive, and Method 4500 proceeds to step 4550.

[0162] In step 4530, the central controller 4230 compares the flow limit measurement with a third threshold. If the flow limit measurement exceeds the third threshold, it indicates that the intake airflow is restricted. In that case, method 4500 proceeds to step 4550. If the flow limit measurement does not exceed the third threshold, method 4500 proceeds to step 4560.

[0163] In step 4550, if the obtained 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 run, the predetermined pressure increment ΔP and the maximum therapeutic pressure Pmax are 1 cmH2O and 25 cmH2O, respectively. In another run, 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 another run, 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. Method 4500 then returns to step 4520.

[0164] In step 4560, if the decreased base pressure P0 is not below the minimum therapeutic pressure Pmin, the central controller 4230 decrements the base pressure P0 by a certain amount. Method 4500 then returns to step 4520. In one run, since the decrement is proportional to the value of P0-Pmin, if no events are detected, the decrease of P0 to the minimum therapeutic pressure Pmin is exponential. In one run, the proportionality constant is set such that the time constant τ for the exponential decrease of P0 is 60 minutes and the minimum therapeutic pressure Pmin is 4 cmH2O. In other runs, 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 runs, the minimum therapeutic pressure Pmin 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 so that the decrease in P0 to the minimum therapeutic pressure Pmin is linear when no events are detected.

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

[0166] In some forms of bilevel therapy, IPAP is the same therapeutic pressure as in CPAP therapy mode, and EPAP is the IPAP minus amplitude A, and has a “small” value (a few cmH2O) also called expiratory pressure release (EPR). This form is also called CPAP therapy with EPR and is generally considered to be more comfortable than direct CPAP therapy. In CPAP therapy with EPR, either or both of IPAP and EPAP can be constant values ​​and are hardcoded or manually entered into the RPT device 4000. Alternatively, the therapy parameter determination algorithm 4329 may iteratively calculate IPAP and / or EPAP in the case of CPAP with EPR. In this alternative example, the therapy parameter determination algorithm 4329 iteratively calculates EPAP and / or IPAP as a function of the sleep-disordered breathing index or measurement returned from each algorithm in the therapy engine module 4320. This is done similarly to the calculation of the base pressure P0 in APAP therapy described above.

[0167] In other forms of bilevel therapy, the amplitude A is large enough for the RPT device 4000 to perform some or all of the patient's respiratory function. In such forms known as pressure-assisted ventilation therapy, the amplitude A is called pressure assist or swing. In pressure-assisted ventilation therapy, IPAP is base pressure P0 + pressure assist A, and EPAP is base pressure P0.

[0168] In some forms of pressure-assisted ventilation, known as constant-pressure assisted ventilation, the pressure assist A is fixed at a predetermined value (e.g., 10 cmH2O). This predetermined pressure assist value is a setting of the RPT device 4000, which may be set, for example, by hardcoding during the configuration of the RPT device 4000, or by manual input through the input device 4220.

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

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

number

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

[0172] The value of pressure assist A calculated via equation (2) can be clipped to a range defined as [Amin, Amax]. In this implementation, pressure assist A defaults to a minimum pressure assist Amin until the current ventilation measurement Vent (the point at which A begins to increase) falls below the target ventilation Vtgt, and then simply drops back down to Amin once Vent exceeds Vtgt again.

[0173] The pressure assist limits Amin and Amax are settings of the RPT device 4000, which may be set by hardcoding, for example, when configuring the RPT device 4000, or by manual input via the input device 4220.

[0174] In pressure-assisted ventilation therapy mode, EPAP is the base pressure P0. Similar to the base pressure P0 in CPAP therapy, EPAP can be a constant value and is prescribed or determined during titration. Such a constant EPAP may be set by hardcoding, for example, when configuring the RPT device 4000, or by manual input through the input device 4220. This alternative is also called fixed EPAP pressure-assisted ventilation therapy. Titration of EPAP for a given patient may be performed by a clinician during a titration session using PSG for the purpose of preventing obstructive apnea, thereby maintaining airway security for pressure-assisted ventilation therapy in a manner similar to the titration of base pressure P0 in constant CPAP therapy.

[0175] Alternatively, the treatment parameter determination algorithm 4329 may iteratively calculate the base pressure P0 during pressure-assisted ventilation therapy. In such an execution, the treatment parameter determination algorithm 4329 iteratively calculates EPAP as a function of sleep-disordered breathing indicators or measurements (e.g., one or more of flow limitation, apnea, respiratory depression, patency, and snoring) returned from each algorithm in the treatment engine module 4320. Because the continuous calculation of EPAP is analogous to the manual adjustment of EPAP by a clinician during EPAP titration, this process is also called automated EPAP titration, and the treatment mode is known as automated titrated EPAP pressure-assisted ventilation therapy or automated EPAP pressure-assisted ventilation therapy.

[0176] 5.9 Data Management System Figure 7 shows an exemplary machine management service system 106 used to communicate with patient devices 102 (102A, 102B, 102C) and to provide updates to patient devices 102 (102A, 102B, 102C) according to a specific example. The signal diagram shown in Figure 8 shows communication between the exemplary patient devices and the exemplary machine management service system in Figure 7. It is understood that the examples shown in at least Figures 7 to 10C should not be considered to limit the scope or disclosure of the features or usefulness described herein.

[0177] Returning to Figure 7, the patient device 102 communicates with the Machine Management Service (MMS) system 106 via the network 104. The MMS system 106 may include one or more computing devices (e.g., those described in relation to Figure 11). In a particular example, certain functions provided by the MMS system 106 may be hosted on a cloud-based computing architecture (e.g., via Amazon AWS, Microsoft Azure, etc.).

[0178] While Figure 7 shows three different patient devices 102 (102A, 102B, and 102C) communicating with the MMS system 106, it should be understood that any number of patient devices may be provided and communicate 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 containing multiple individual patient devices) used by patients worldwide.

[0179] A patient device may include different types of patient devices. For example, a patient device may be an RPT4000, a humidifier 5000, or a patient interface 3000. In a particular example, 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 for communication with the MMS system 106 via the network 104. 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 functional mode of the flow generator for AutoSet. Another component may be a BIOS for the SoC used to control the flow generator. In a particular example, 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] Generally, individual patient devices 102 may include any of the components described in relation to Figure 11 and / or Figure 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 a particular example, a given patient device may communicate with another computing device (e.g., a mobile 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 enables the use of a given component.

[0181] Numerous parts of this document (for example, Figure 7) describe software modules (etc.) and the actions performed by them. This is for the sake of clarity, and it should be understood that wherever a document states that a software module performs an action, it is always the hardware elements (e.g., the processor and memory devices) (below the software module) that actually perform that action, in accordance with the instructions including the software module. Further details regarding this are provided below, including in Figure 11.

[0182] As described herein, the patient device 102 may communicate one or more pieces of identification data, as shown in Figure 8, 200. Examples of identification data include, for example, a version number, a region 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 agnostic data for 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 it eliminates the need to acquire or transmit patient data to the MMS system 106 in order to deploy upgrade packages for individual patient devices.

[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 can uniquely identify a given patient device 102. In other specific 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., GUID / UUID) and can therefore be used (by MMS 106) to determine other components or device details included with the patient device (e.g., by examining the status DB 112).

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

[0185] The MMS system 106 may include a rules database 110. The rules database 110 stores rules used by the rules manager module 108, the status database 112, the pending request database 114, and the upgrade package 116. As used herein, the term “database” includes any organized collection of data about a computer system, such as relational databases, XML or JSON (or other file types) files, etc.

[0186] In a particular exemplary embodiment, the MMS system 106 can process upgrade requests in a stateless manner, eliminating the need for the MMS system 106 to track whether each individual patient device 102 is processing individual upgrade requests (e.g., jobs) correctly. This type of execution may offer advantages over other types of stateful execution (e.g., job-based systems).

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

[0188] Each rule may be a separate entry or record in the rule database 110, and each rule may correspond to an upgrade package that includes one or more upgrades to firmware / software / configurations or all of the above. Each rule may display or specify the version or other data of the patient device components used to trigger a given rule. Each rule may also include tasks or upgrade files that should be applied to or communicated to the patient device when the corresponding rule is triggered. Examples of rules that may be stored in the rule database 110 are shown below in relation to Tables 1-4.

[0189] As used herein, the term “upgrade” is understood to encompass situations in which changes occur to the device’s data, software, or firmware. Therefore, in some cases, the term “upgrade” may include a downgrade that rolls back a previously applied update (for example, due to a security vulnerability). For example, an “upgrade” package might deliver changes, reinstallation, or rollback from version 10 of an application to version 9.

[0190] The MMS system 106 may also include a status database 112 containing records of the currently installed versions / configurations for each patient device component. Exemplary data that may be included in the status database 112 may be similar to the “IdentificationProfiles” shown in Tables 2-4 and 8 below, where the various components of a given device are stored in relation to the version or other identifier of the firmware or software (or configuration) version currently used in the device's components. In a particular example, the rule manager module 108 may use the status database 112 to retrieve versioning information for each component of a given device specified by the 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, used to look up all components (and associated versioning information) included with the given device. Such information may then be used (via the rule manager module 108) to determine whether any of the rules 110 are applicable to the components installed on a given patient device. The status database 112 may be a data storage unit for all characteristics, traits, or other configuration information. Storing such information within the MMS system 106 may be advantageous because it allows for retrieval of the information without the need to transmit it 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 cases, when individual patient devices check in to the MMS system 106, some or all of the data stored in the status database 112 can be communicated (for example, each time).

[0192] In a particular exemplary embodiment, at the time of manufacturing each individual patient device, the status database 112 is populated with component information. At the time of manufacturing, a unique identifier may be assigned to the device (or its components). The unique identifier may be stored in relation to component data for the various components included with the device. In a particular example, data on the versioning and component information of individual devices may also be provided by the vendor or other third party. In a particular example, the status database 112 may include organization and / or region identifiers, which are similarly stored in relation to each unique patient device identifier. Such information may be advantageously used to target upgrade packages for a particular organization and / or a particular region worldwide (e.g., an upgrade package for patient devices within China).

[0193] The pending requests 114 may contain a list / queue (or other data structure) of all currently pending requests. In a particular example, pending requests are a collection of requests that are pending and still need to be communicated to individual patient devices (for example, requests for a specific action, such as applying a firmware or software upgrade or changing settings). In a particular example, once a patient device checks in and provides device identification data as described herein, it becomes possible to look up whether there are any pending requests for that device using that data.

[0194] The MMS system 106 communicates with a given patient device and instructs the device to handle a specific request. The request may be to apply a specific upgrade package (for example, to download and install files). In a particular example, after the request is communicated to the patient device and appended to an pending request 114, the MMS system 106 no longer tracks the completion success of that particular request. This allows information on how the request was handled by the MMS system 106 to be provided to a stateless system. In another particular example, a record of the pending request communicated to the patient device is maintained within the pending request 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 of how requests are handled by the MMS system 106 (for example, by tracking the status of requests). In certain cases (and in cases applicable to both of the above executions), the MMS system 106 may track some information status and / or fault conditions (one or more) reported by the patient device and store such information in an undecided request 114. The undecided request 114 may be stored in a queue or other data structure (for example, as queue 404 in Figures 10A-10C). In certain cases, the undecided request 114 may be stored in a database or the like.

[0195] Upgrade package 116 may be a data storage unit for all upgrade packages that may be applied to any of the patient devices. An upgrade package may include code changes to the software or firmware and / or configuration changes to adjust one or more parameters of a given patient device. Such parameter, software, and / or firmware changes may affect or alter the operating mode of the patient device. For example, the operation of the fan or blower of a flow generator in an RPT device may be adjusted to more effectively deliver treatment to the patient. In certain examples, as described anywhere in this specification, further authorization from a clinician or other healthcare professional may be required to adjust the settings of the patient device. Therefore, in certain examples, the rules manager module may determine whether to apply an upgrade (e.g., configuration change) based on such further input. In specific cases, an upgrade package may include any or all of the following: enhanced security, additional features (e.g., new treatment modes newly available on the RPT device), different languages ​​(e.g., different language packs containing different voice and / or text for updating language strings embedded in the RPT device), patient surveys or questionnaires, patient coaching or hinting, or other settings, configurations, or applications.

[0196] In a particular exemplary embodiment, the upgrade package 116 stores a list of network or website addresses from which the patient device can retrieve each upgrade file / data. Thus, the MMS system 106 may be configured to provide links (not to the upgrade files themselves) to locations where the upgrade files can be found. In a particular example, the actual installation files may be stored separately from the MMS system 106.

[0197] Tables 1 to 4 below show examples of upgrade specifications that may be found in relation to the rule database 110. Table 1 shows the form of an upgrade specification constructed in relation to several different rules that use an identification profile to trigger an upgrade package. The identification profile included in each rule may be a subset of device profile data stored for each patient device in the status database 112. Different rules (also called segments of upgrade specifications) and the identification profiles used to trigger these rules, and the upgrade packages that should be provided in relation to each identification profile are shown in relation to Tables 2, 3, and 4. Each trigger (e.g., a precondition) may be associated with a unique identifier that enables the MMS system 106 to refer to and / or track the rule (segment). This may make it possible to determine how many times a given upgrade has been provided across a fleet of devices. [Table 2]

[0198] In Table 2, an upgrade from version 4.0.1 to 4.0.3 of FG AutoSetApplication is triggered if the device identification data of a 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 displayed "UpgradeFile" should be applied to the component of the patient device. A notification is sent to the patient device, and the displayed upgrade file is applied from the patient device. In a specific 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 cases, the ex postconditional portion of the rule may be ignored. [Table 3]

[0199] In Table 3, an upgrade from version 4.0.2 to 4.0.3 of the FG AutoSetApplication is triggered if the device identification data flow 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 displayed "UpgradeFile" should be applied to the components of the patient device. The patient device is notified and the displayed upgrade file is applied. In a specific example, after the "PostCondition" value is met, the status DB 112 is updated to reflect that the corresponding device has been updated (for example, to 4.0.3). It should be understood that Tables 2 and 3 show upgrade packages for identical components of the same version. However, due to differing preconditions, two different identification profiles may be used to trigger upgrades for patient devices with different versions of components. [Table 4]

[0200] In Table 4, a Bluetooth iOS upgrade is triggered when the device identification data flow 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, the precondition may include versioning data for multiple components of the system. If this precondition is met, the rule manager module 108 determines whether the displayed “UpgradeFile” should be applied to the components of the patient device. The patient device is notified and the displayed 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 rules and the corresponding upgrade package for those rules are determined based on the provided device identification data (and / or device profile data retrieved from status DB112), the upgrade package may be notified to the patient device 102 in 206. In certain examples, this may include providing 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 a URI or other address specification (along with other data (e.g., information, size, file name)) so that the use of the displayed URI allows for the subsequent download of one or more files.

[0202] In 208, the patient device applies an upgrade package. This may include verifying (e.g., performing a checksum) that the upgrade package is complete, accurate, and otherwise undamaged, 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 with the MMS system 106 again, communicating new version information of the updated components to the MMS system 106. The updated version information can then be stored in the status DB 112 in relation to the patient device and the given components (e.g., by overwriting previous values). Thus, the MMS system 106 maintains the latest status regarding the firmware / software / configuration versions currently installed on a given patient device. This type of execution can allow the system to operate more efficiently without the need for continuous tracking of individual upgrade requests. In a specific example, upon completion of the upgrade by the patient device 102, the patient device 102 may communicate a status update to the MMS system 106 again. The device identification data and / or component identification data (e.g., software version or firmware version) that may be included in this message can then be used by the MMS system 106 to verify that the update was performed / installed by the patient device 102. In a specific example, the patient device 102 may recommunicate its progress in the upgrade process to the MMS system 106 regarding any failures that may have occurred (preventing the patient device 102 from successfully completing its request). This progress or failure information may be stored by the MMS system 106 during the pending request 114. The progress information may include, for example, that the file download was successful, that the upgrade is being applied, that the upgrade is in progress, or that the upgrade is complete and the patient device is restarting.

[0204] It is understood that the ability to generate individual rules that may be included in the overall rule specification allows for an automated system for managing updates that can scale across thousands or millions of different patient devices. This is achieved because communication from individual patient devices facilitates the rule manager module 108 to appropriately select the correct upgrade package to be sent to each patient device (based on device profile data obtained from status DB 112 and rule specifications from rule 110). Therefore, there may be less need to manually monitor patient device updates when new upgrade packages that can be installed / applied to devices become available.

[0205] Figures 9A and 9B are flowcharts of computer operations that may be performed by, for example, the patient device 102 and the MMS system 106 in a particular example. Figure 9A shows an exemplary client-side process that may be performed by the exemplary patient device 102, and Figure 9B shows an exemplary server-side process that may be performed by one or more processors of the MMS system 106.

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

[0207] In 302, if a check-in process is required, the patient device 102 transmits device identification data to another computer system (e.g., MMS system 106). As described herein, the device identification data may be or may be associated with the GUID of the patient device (e.g., 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 the transmission of software / firmware / configuration version information. The term “GUID” is understood to be used herein in reference to the patient device or its components, where other identifiers (whether unique or not) may also be used to facilitate the identification of the patient device or its components.

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

[0209] In certain exemplary embodiments, the upgrade data package may (or could be) include configuration data or other parameters to be modified on the patient device. Table 5 shows an example of a “BrokerItem” element that may be included as part of an upgrade data package delivered to the patient device via step 304. [Table 6]

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

[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. Therefore, instead of separately requesting software or firmware files (e.g., those shown in Table 9) after receiving the upgrade data package from the MMS system 106, such files may be provided in conjunction with the upgrade data package.

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

[0213] In certain cases, a failure to download the upgrade file may cause the client-side process to terminate (for example, after reporting the failure to the MMS system 106), and the process may return to 300 and 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] In 308, after successful verification, the upgrade data package may be applied to the patient device 102. For example, this may involve overwriting or replacing specific parameter values ​​used by the patient device 102, and / or installing software updates and / or firmware, or otherwise applying software updates 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 succeeded).

[0215] In 310, the patient device again transmits the upgrade status to the MMS system 106. In a particular exemplary embodiment, this may include reporting the current versioning information of the components that have just been upgraded on the patient device. In a particular example, the status report may be for several different components (e.g., a flow generator and a Bluetooth module). In a particular example, 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 a particular exemplary embodiment, the contents of Table 6 may be transmitted from the patient device to the MMS system 106 when the upgrade data package is received in 304 (e.g., to verify that the request has been received or any failures that occurred in connection with the request). [Table 7]

[0216] In a particular case, the device status transmitted in 310 may include failure notifications for the application of an upgrade (and possibly a failure error code or message) or versioning information for the recently upgraded component(s). In other words, in a particular case, the success of the upgrade is implicitly provided by the patient device providing the 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 supplied to the patient device.

[0217] Figure 9B shows an example of server-side processing that can be performed by the MMS system 106.

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

[0219] In the example above 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 unique because it is assigned to each manufactured cellular module. Therefore, 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 HTTPget method.

[0220] In step 351, the MMS system 106 uses the provided device identification data to look up the device profile data (e.g., all components) of the displayed patient device (by referencing the status database 112). Table 8 shows an example of how some of the device profile data may be located in the status DB 112. [Table 9]

[0221] Here, the universal identifier can be an identifier that is device identification data transmitted from the patient device. This is used to find all records (e.g., all "IdentificationProfiles" in the status DB112 associated with the universal identifier). The example above from Table 8 shows a flow generator component along with its "hardware" versioning information and the currently installed "software" version of that component present on the patient device associated with the displayed identifier. Further records may also be kept in the status DB112 for different components of the device. For example, a Bluetooth module, a cellular module, a humidifier module, etc., may each have separate inputs. Each of these components is also associated with a universal identifier input ("'UniversalIdentifier':'6a7a2e7e-5d9d-4c87-b45e-faa3563f21a8'"), making it possible to look up all components of a given patient device. In a particular example, the universal identifier is the same for all components within the device. In certain cases, the universal identifier differs for several components within the same patient device (or linked to one within the device).

[0222] Next, in step 352, versioning information from the identification profiles of various components is processed via the rule manager module 108 (in accordance with the rules stored on the MMS system 106) to determine whether there are any available upgrade packages for the components of this patient device. If there are no available upgrades, the process terminates, and the MMS system 106 may respond to the request only with "None" (or a similar message indicating that there are no upgrades available at this time).

[0223] If there is one or more available upgrade packages, these upgrade packages are sent to the patient device in 354. If there are multiple upgrade packages, these packages may be applied sequentially from the patient device to the MMS system 106 via multiple different requests. In other words, the sequential application of rules by the rule manager module 108 (for example, in response to different cases where the same device checks in to the MMS system 106) can be used to determine further upgrades to be applied to a given patient device. Thus, the order in which these rules are processed by the rule manager module 108 can determine which upgrade packages to apply (from multiple possible upgrade packages). In certain examples, the method by which the MMS system 106 delivers upgrade packages to the device after a determination can enable the sequential and / or deterministic application of upgrades. For example, a device may meet multiple different preconditions (e.g., requiring the application of multiple upgrades). The MMS system 106 can favorably arbitrate such requests by determining which packages to deliver based on the order of segments in the upgrade specification. Therefore, instead of selecting preconditions that are satisfied, for example, the MMS system may select a first precondition within the upgrade specification (for example, assuming that the first preconditions are processed in order). This kind of exemplary approach makes it possible to construct the MMS system 106 (for example, a known and secure chain of upgrades for the requesting device).

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

[0225] In 358, the device status received in 356 is stored. For example, if a patient device transmits version information for a given component, this versioning information may be stored in the status DB112 (for example, overwriting the previously stored versioning information for that component). Alternatively, if the upgrade is unsuccessful, a record of the error may be stored and flagged for potential future follow-up.

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

[0227] Cloud service 400 may communicate with a separately provided request service 402 used for managing and generating requests. In a particular example, a request may be used to encapsulate an upgrade package (e.g., a request for a given device to apply an upgrade package). Generated requests may be stored in pending requests 114. In a particular example, 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. Request service 402 may interface with a queue 404 used to store pending requests (e.g., requests that have not yet been sent to a patient device and / or not yet completed by the patient device). Request service 402 may also communicate with an upgrade service 406. 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 shown in Figure 10B).

[0228] Returning to Figure 10A, an example of request retrieval involving (or undecided) broker involvement is shown according to a specific example. In Figures 10A to 10C, distributed services (e.g., 400, 402, 404, and 406) reside on separate computing resources, each providing a different function. In a specific example, each or any of these services may reside on a cloud computing environment. As described above, such services may collectively reside within the entire MMS system 106.

[0229] In 410, the patient device 102 transmits patient device identification data to the cloud service 400. This could be, for example, a cellular module universal identifier or another unique identifier used to uniquely identify the patient device 102. In a particular example, a MAC address may be used when requests from the patient device are transmitted via the patient device's network interface card, as opposed to a 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 transmitted identification data. In other words, this determines whether there is a current request associated with the provided ID. Then, at 414, the request service 402 accesses queue 404 to find the current request.

[0231] Subsequently, the request in queue 404 is sent back to request service 402 as a broker request at 416, and then request service 402 sends it back to cloud service 400 at 418. The broker request is then sent back to patient device 102 at 420. This type of architecture allows request functionality and upgrade services to be encapsulated by the cloud service (at least from the perspective of any checked-in patient devices).

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

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

[0234] Thus, a profile for the settings of a patient device can be delivered via a broker's request.

[0235] In certain exemplary embodiments, a broker's request delivered to a patient device may include items involving the participation of one or more brokers. In such instances, the items involving the participation of individual brokers in the overall request may be delivered to the patient device separately (and sequentially). In other words, the patient device requests the next BrokerItem after processing one BrokerItem. For example, each BrokerItem from Tables 5, 9, and 10 may be included in a single broker's request for a given patient device. Each BrokerItem can be delivered to the patient device according to the embodiments described herein. In a particular example, each request may include only a single BrokerItem, and multiple requests may be generated for a given patient device.

[0236] In a particular exemplary embodiment, when a broker request is received, each or any of the BrokerItems in the corresponding request may be parsed, and appropriate actions may be taken by the patient device 102. Next, for example, one or more files that may be displayed in the BrokerItem may be downloaded. In a particular exemplary embodiment, the patient device 102 may provide a report to the cloud service 400 indicating that the file download was successful. Next, this status may be attached to or adopted in requests that are currently undecided for a given patient device (e.g., requests stored in queue 404). After the files are downloaded, they may be applied to the patient device 102. Next, in a particular example, the patient device 102 may resume, and a device status message may be sent to the cloud service indicating that the upgrade components are now the upgraded version (e.g., an upgraded version number may be specified). In a particular example, the status message may include information indicating that the application of the upgrade to the patient device 102 was successful.

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

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

[0239] Refer to Figure 10B, which provides an example of a firmware upgrade request involving a broker. Here, at 500, identification data is sent from the patient device 102 to the cloud service 400. The cloud service 400 then requests a current broker request from the request service 402 at 502 based on the provided identification data. The request service 402 queries the queue 404 to find the current request at 504.

[0240] However, in this example there are no current requests, so an empty set is returned in 506. Next, the request service 402 submits a request to the upgrade service 406 to determine whether 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 the 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 a firmware (or other software upgrade, etc.) is available, details of the upgrade are sent back from the upgrade service 406 to the request service 402 in 510. Such details may be similar to those shown in Table 9, for example. For example, the location of the file(s) may be provided, the hash and size of these files, and the components of the patient device to which the files pertain.

[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 in 512. This may involve generating one or more BrokerItems for the broker request, as shown in the table above. The generated request or item is then added to queue 404 in 514 and subsequently returned in 516 (similar to the return of the request in 416 in Figure 1A, for example). This allows the system to track the progress of requests (including upgrades) that need to be processed for each individual patient device. The generated broker request (or BrokerItem) is then routed back to the cloud service 400 in 518 and subsequently communicated to the patient device 102 again in 520. Subsequent processing may be similar to that described above in relation to Figure 10A (where the upgrade may be verified and applied).

[0243] Figure 10C shows a detailed signal diagram of what happens when there is no broker request for patient device 102. At 600, patient device 102 submits identification data to cloud service 400. The cloud service then submits a request for broker requests to the request service at 602. The request service queries queue 404 at 604. Since there is nothing in queue 404, nothing is returned at 606. Next, the request service submits a request at 608 to upgrade service 406 to retrieve upgrade details. At 610, if the response is "nothing" or there is another similar response (for example, no applicable upgrades), the upgrade service 406 returns a message indicating that there are no upgrades for the displayed device. The "nothing" response is returned to cloud service 400 at 612, and cloud service 400 relays this response to patient device 102 at 614.

[0244] 5.10 Computing Devices Figure 11 is a block diagram of an exemplary computing device 1100 according to several embodiments (which may also be called, for example, “computer device,” “computer system,” or “computing system”). 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. Furthermore, in some embodiments, the computing device 1100 is connected to or includes one or more display devices 1112. Furthermore, 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) and are configured to perform a variety of different functions for computing device 1100 and / or a variety of different functions related to 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., which may be called 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-promable gate array (FPGA) circuit, or a system-on-a-chip (SOC) (e.g., an integrated circuit including a CPU, GPU and other hardware components (e.g., memory and / or memory controller (e.g., Northbridge), I / O controller (e.g., Southbridge), networking interface)). In some embodiments, each or any of the processors 1102 employs 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 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), hard disk, magneto-optical medium, optical medium, cache memory, registers (e.g., holding instruction items that can be executed by one or more of the processors 1102), or other types of devices that perform volatile or non-volatile storage of data and / or instruction items (e.g., software that runs on or is performed by the processors 1102). In some embodiments, each or any of the memory devices 1104 is removable from the computing device 1100 (e.g., USB flash drive, floppy disk, compact disk (CD), etc.). The memory devices 1104 are examples of non-temporary computer-readable storage units. As used herein, the term “non-temporary 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-temporary electronic data storage. The term “non-temporary computer-readable storage medium” does not include temporary, 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 performs one or more wired communication technologies (e.g., Ethernet (IEEE 802.3)) and / or wireless communication technologies (e.g., first layer, second layer and / or higher layer for Bluetooth, WiFi (IEEE 802.11), GSM, CDMA2000, UMTS, LTE, LTE Advanced (LTE-A) and / or other short-range, medium-range and / or long-range wireless communication technologies). The 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 for transmitting and receiving. In some embodiments, the transmitter and receiver of the transceiver may not share any common circuitry and / or may be located 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 processor 1102; generate corresponding image data based on the received data (e.g., via discrete GPU, integrated GPU, CPU performing graphical processing, etc.); and / or output image data to a display device 1112 (which displays the image data) via a high-resolution multimedia interface (HDMI), display port interface, video graphics array (VGA) interface, 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, video adapter, or graphics processing unit (GPU). In other words, each or any of the display interfaces 1108 may internally include a processor used for generating image data. The generation or such image 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 adapters 1110 is or includes one or more circuits. These circuits receive and process user input data from one or more user input devices 1114 (which are included in or attached to the computing device 1100 or otherwise communicate with it) and output data to the processor 1102 based on the received input data. Alternatively or additionally, in some embodiments, each or any of the user input adapters 1110 is or includes, for example, a PS / 2 interface, a USB interface, a touchscreen controller, and / or the user input adapters 1110 facilitate 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 where the display device 1112 is a component of the computing device 1100 (for example, the computing device and the display device are housed in an integrated housing), the display device 1112 may be a touchscreen display or a non-touchscreen display. In embodiments where the display device 1112 is connected to the computing device 1100 (for example, it is outside the computing device 1100 and communicates with the computing device 1100 via wired and / or wireless communication technology), 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 a machine and / or electronic device, or includes such a machine and / or electronic device, that generates a signal provided to a user input adapter (one or more) 1110 in response to a physical phenomenon. Examples of input devices 1114 include, for example, a keyboard, mouse, trackpad, touchscreen, button, joystick, sensor (e.g., accelerometer, gyroscope, temperature sensor, pressure sensor (e.g., one that measures gas pressure), flow sensor (e.g., one that measures the velocity of gas or liquid flow)), and microphone. In some examples, one or more input devices 1114 generate a signal provided in response to input provided by the user (e.g., by pressing a button, uttering a voice command, etc.). In other examples, one or more input devices generate a signal based on a sensed physical quantity (e.g., force, pressure, temperature). In some embodiments, each or any of the input devices 1114 are components of a computing device (for example, a button is provided on a housing that includes a processor 1102, a memory device 1104, a network interface device 1106, a display interface 1108, a user input adapter 1110, etc.).

[0252] In some embodiments, each or any of the external devices 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. Generally, the external devices 1116 may include devices that communicate with the computing device 1100 (e.g., electronically). For example, the computing device 1100 is a mobile device that communicates with a flow generator or a patient interface device or mask (e.g., an example of an external device 1116). Conversely, the computing device 1100 may be a flow generator that communicates with a server or cloud-based computer system, which is an example of an external device 1116 and provides data and / or software updates to the flow generator.

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

[0254] The computing device 1100 can be configured in numerous different ways in various embodiments. For example, the computing device 1100 may be configured such that the processor 1102 includes: a multi-core (or single-core) processor; a first network interface device (e.g., performing WiFi, Bluetooth, NFC, etc.); a second network interface device (e.g., performing one or more cellular communication technologies, such as 3G, 4G LTE, CDMA, etc.); and a memory or storage device (e.g., RAM, flash memory, or hard disk). The processor, the first network interface device, the second network interface device, and the memory device may be integrated as part of the same SOC (e.g., a single integrated circuit chip). In another example, the computing device 1100 may be configured 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 performing Ethernet and a second network interface device performing WiFi and / or Bluetooth; and the memory device 1104 includes RAM and flash memory or a hard disk. As another example, a computing device 5|00 may include an SoC along with: one or more processors 5|02, multiple network interface devices 5|06 (e.g., those for communication via cellular and Bluetooth connections), 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 a 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 stated above, whenever this document describes a software module or software process performing any action, that action is actually performed by the underlying hardware element in accordance with the instruction item, including the software module. Consistent with the above, in various embodiments, each or any combination of the cloud service 400, request service 402, queue 404, upgrade service 406, MMS system 106, rule manager module 108, rule 110, status database 112, upgrade package 116, and undecided request 114 will be referred to individually as “components” for clarity for the remainder of this paragraph and will be executed using the example of computing device 1100 in Figure 5. In such embodiments, the following applies to each component: (a) an element of the 1100 computing device 1100 shown in Figure 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 a suitable combination or subset thereof, comprising or not comprising one or more display devices 1112, one or more input devices 1114, and / or external devices 1116), is configured, adapted, and / or programmed to perform each or any combination of the actions, activities, or functions described herein, such as those performed by the component and / or by any software modules described herein as being contained within the component;(b) In some embodiments, to the extent described herein, one or more software modules are provided within the component, either alternatively or additionally, such software modules (and any data described herein that are handled and / or used by the software modules) are stored in the memory device 1104 (for example, in various embodiments, they are stored in a volatile memory device (e.g., RAM or instruction registers) and / or a non-volatile memory device (e.g., flash memory or hard disk)), and all actions described herein that are performed by the software modules are stored in other elements within the computing device 1100 and / or other elements connected to the computing device 1100 (e.g., network interface device 1106, display interface 1108, user input adapter 1110, display device(s) 1112, input device(s) 111 (c) Alternatively or additionally, to the extent described herein, component processes and / or others handle data, and in some embodiments, such data is stored in a memory device 1104 (e.g., in some embodiments, a volatile memory device (e.g., RAM) and / or a non-volatile memory device (e.g., flash memory or hard disk)) and / or processed / handled by the processor 1102 as appropriate, together with other elements in the computing device 1100 and / or other elements connected to the computing device 1100 (e.g., a network interface device 1106, a display interface 1108, a user input adapter 1110, a display device (e.g., one or more) 1112, an input device (e.g., one or more) 1114 and / or an external device (e.g., one or more) 1116);(d) Alternatively or additionally, in some embodiments, the memory device 1102 stores instructions. When executed by the processor 1102, these instructions cause the processor 1102 to perform, in conjunction as appropriate with other elements provided within and / or connected to the computing device 1100 (e.g., memory device 1104, 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), each or combinations of actions described herein: each action described herein as performed by a component and / or by any software module described herein as provided within a component;

[0256] The hardware configurations illustrated and described above in FIG. 11 are by way of example, and the content 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 using (a) individual hardware circuits, (b) application-specific integrated circuits (ASICs) configured in detail to perform the described function / action, (c) one or more digital signal processors (DSPs) configured in detail to perform the described function / action, (d) the hardware configuration described above with reference to FIG. 11, (e) through other hardware arrangements, architectures and configurations, and / or through combinations of the techniques described in (a)-(e).

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

[0258] 5.11.1 General Air: In certain forms of this technology, air may mean the atmosphere, and in other forms of this technology, air may mean a combination of other breathable gases (e.g., an oxygen-rich atmosphere).

[0259] Surroundings: In certain forms of this technology, the term “surroundings” should be understood to mean (i) outside the treatment system or patient, and (ii) directly surrounding the treatment system or patient.

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

[0261] In another example, ambient pressure could be pressure directly surrounding or outside the body.

[0262] In certain forms, ambient (e.g., acoustic) noise can be considered the background noise level in the patient's room, excluding noise originating from, for example, the RPT device or from the mask or patient interface. Ambient noise may 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. In some cases, when flow rate is mentioned, it refers to a scalar quantity (i.e., a quantity that has only magnitude). In other cases, when flow rate is mentioned, it refers to a vector quantity (i.e., a quantity that has both magnitude and direction). Flow rate may be denoted by the sign Q. Flow rate is sometimes simply called "flow" or "airflow."

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

[0265] Humidifier: The term "humidifier" is interpreted as a humidifying device that is constructed, positioned, or configured with a physical structure capable of providing a therapeutically beneficial amount of water (H2O) vapor into an airflow to improve a patient's medical respiratory illness.

[0266] Patient: A person who has or does not have a respiratory illness.

[0267] Respiratory pressure therapy (RPT): Addition of air supply to the airway inlet at therapeutic pressure, which is typically positive pressure relative to the atmosphere.

[0268] Ventilator: A mechanical device that provides pressure assistance to help a patient perform some or all of the breathing motion.

[0269] 5.12 Other Notes Some of the disclosures in this patent document include content that is protected by copyright. The copyright holder retains all copyrights to any other purpose, except that any reproduction of this patent document or this patent disclosure by fax by any person is permitted if it is included in the patent files or records of the Japan Patent Office.

[0270] Unless otherwise clearly indicated by the context or provided for a range of values, it is understood that 1 / 10 of the lower limit, the interval between the upper and lower limits of the range, and each intervention value for any other stated values ​​or intervention values ​​within the stated range are included in this technique. Even if the upper and lower limits of these intervention ranges, independently included within the intervention range, specifically exceed the limits within the stated range, they are also included in this technique. If the stated range includes one or both of these limits, the range exceeding either or both of these stated limits is also included in this technique.

[0271] Furthermore, where values ​​(one or more) are embodied in this specification as part of the Art, unless otherwise specified, it is understood that such values ​​may be approximated and used to any appropriate number of significant figures as permitted or required by the practical technical implementation.

[0272] Unless otherwise specified, all technical and scientific terms in this specification have the same meaning as those commonly understood by those skilled in the art. Any methods and materials similar to or equivalent to those described herein may be used in the practice or testing of this art, but only a limited number of exemplary methods and materials are described herein.

[0273] While certain materials are described as suitably used in constructing components, obvious alternative materials with similar properties may be used as substitutes. Furthermore, unless otherwise stated, any and all components described herein are understood to be manufacturable and therefore can be manufactured collectively or individually.

[0274] 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 indicates otherwise.

[0275] All published documents cited herein are used for disclosure and description of the methods and / or materials covered by those documents, and are incorporated for reference only. The published documents cited herein are provided solely for the purposes of their disclosure prior to the filing date of this application. Nothing in this specification should be construed as indicating that the present technology is not prior to such published documents for the purpose of prior patents. Furthermore, the dates of the published documents cited herein may differ from the actual dates of the published documents and may require individual verification.

[0276] The terms “comprises” and “comprising” should be interpreted as referring to elements, components, or steps in a non-exclusive sense, indicating that the elements, components, or steps described may exist, be used, or be combined with other elements, components, or steps not explicitly stated.

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

[0278] While the techniques described herein have been described with reference to specific examples, it should be understood that these examples are merely illustrative of the principles and applications of the techniques. In some cases, terms and symbols may indicate specific details that are not necessary for carrying out the techniques. For example, terms such as “first (first)” and “second (second)” (etc.) are used, but unless otherwise specified, these terms are not intended to indicate any arbitrary order and are used to distinguish separate elements. Furthermore, while descriptions or examples of process step 1 in the method may be given in order, such order is not necessary. Those skilled in the art will recognize that such order is changeable and / or that such modifications can be made simultaneously or even synchronously.

[0279] Therefore, it should be understood that numerous modifications are possible in the exemplary examples, and that other configurations may be devised, without deviating from the intent and scope of this technology.

Claims

1. A computer system for delivering changes to a remotely located patient device in a continuous positive air pressure (CPAP) system, A non-temporary computer-readable storage unit configured to store upgrade specifications, wherein the upgrade specifications include a plurality of upgrade segments, each containing at least one precondition and component upgrade data; A transceiver configured to communicate with at least a first patient device, wherein the first patient device includes an electronic memory configured to store firmware or software used to control the operation of the first patient device; and A processing system including at least one hardware processor, wherein the processing system is Processing an received electronic message via the transceiver, wherein the received electronic message is transmitted from the first patient device, and the electronic message includes identification data for the first patient device. Based on the identification data for the first patient device, a decision is made as to whether a brokered request exists in the queue. Based on the determination that there are no requests from the broker in the queue, access the upgrade specification, process it, and retrieve the first upgrade segment of the multiple upgrade segments. A computer system configured to retrieve a request from the broker from the queue and generate an upgrade message to be sent to the patient device via the first wireless transceiver, wherein the upgrade message is configured to be processed by the patient device, based on the retrieved first upgrade segment, to apply to the patient device an application of an upgrade file that modifies the firmware or software stored in the electronic memory of the patient device.

2. The processing system is The system is further configured to retrieve device profile data from a database based on the identification data transmitted by the first patient device, based on a determination that the broker's request is not in the queue, wherein the device profile data includes versioning data relating to one or more components associated with the first patient device. The computer system according to claim 1, wherein the extraction of the first upgrade segment is further based on the versioning data.

3. The computer system according to claim 1 or 2, wherein each of the multiple upgrade segments in the upgrade specification is processed sequentially until one of the preconditions in the upgrade segment matches the extracted versioning data of the device profile data of the first patient device.

4. The processing system is The system is further configured to generate a new broker request based on the first upgrade segment, and to add the new broker request to the queue, based on the retrieval of the first upgrade segment. The computer system according to any one of claims 1 to 3, wherein the broker's request is the new broker's request.

5. The computer system according to any one of claims 1 to 4, wherein the upgrade message includes an address to which the upgrade file should be obtained by the first patient device.

6. The first computing node; and The system further includes a second computing node configured to communicate with the first computing node via an electronic data communication network, The computer system according to any one of claims 1 to 5, wherein the first computing node makes a decision as to whether the broker's request is in the queue and whether the second computing node processes the upgrade specification.

7. The computer system according to any one of claims 1 to 6, wherein the versioning information of the software or firmware is not included in the received electronic message transmitted from the client.

8. A non-temporary computer-readable medium for storing computer-executable instructions, used in conjunction with a computer system that communicates with a patient device of a continuous positive pressure air (CPAP) system, the patient device including electronic memory storing firmware or software used to control the operation of the patient device, and the computer-executable instructions are transmitted to the computer system, The upgrade specification is stored in the computer storage of the computer system, wherein the upgrade specification includes a plurality of upgrade segments, each including at least one precondition and component upgrade data; Processing an received electronic message via the transceiver, wherein the received electronic message is transmitted from the first patient device, and the electronic message includes identification data for the first patient device; Based on the identification data for the first patient device, a determination is made as to whether a broker request exists in the queue; Based on the determination that there are no requests from the broker in the queue, access the upgrade specification, process it, and retrieve the first upgrade segment of the plurality of upgrade segments; and A non-temporary computer-readable medium comprising instructions configured to perform an operation including retrieving a request from the broker from the queue and generating an upgrade message to be transmitted to the patient device via the first wireless transceiver, wherein the upgrade message is configured to be processed by the patient device to apply to the patient device an application of an upgrade file that modifies the firmware or software stored in the electronic memory of the patient device, based on the retrieved first upgrade segment.

9. The aforementioned operation is, Based on a determination that the broker's request is not in the queue, the device profile data is retrieved from the database based on the identification data transmitted by the first patient device, the device profile data further includes versioning data relating to one or more components associated with the first patient device. The extraction of the first upgrade segment is further based on the versioning data, according to claim 8, for a non-temporary computer-readable medium.

10. The non-temporary computer-readable medium according to claim 8 or 9, wherein each of the multiple upgrade segments in the upgrade specification is processed sequentially until the precondition of one of the upgrade segments is consistent with the extracted versioning data of the device profile data of the first patient device.

11. The aforementioned operation is, The process further includes generating a new broker request based on the first upgrade segment based on the retrieval of the first upgrade segment, and adding the new broker request to the queue. The non-temporary computer-readable medium according to any one of claims 8 to 10, wherein the broker's request is the new broker's request.

12. The non-temporary computer-readable medium according to any one of claims 8 to 11, wherein the upgrade message includes an address to which the upgrade file should be obtained by the first patient device.

13. A non-temporary computer-readable medium according to any one of claims 8 to 12, wherein the first computing node of the computer system makes a decision as to whether the broker's request is in the queue and whether the second computing node of the computer system processes the upgrade specification.

14. The non-temporary computer-readable medium according to any one of claims 8 to 13, wherein the versioning information of the software or firmware is not included in the received electronic message transmitted from the client.

15. A method for delivering updates to a remotely located patient device in a continuous positive air pressure (CPAP) system, The upgrade specification is stored in the computer storage of the computer system, wherein the upgrade specification includes a plurality of upgrade segments, each including at least one precondition and component upgrade data; Processing an received electronic message via the transceiver, wherein the received electronic message is transmitted from the first patient device, and the electronic message includes identification data for the first patient device; Based on the identification data for the first patient device, a determination is made as to whether a broker request exists in the queue; Based on the determination that there are no requests from the broker in the queue, access the upgrade specification, process it, and retrieve the first upgrade segment of the plurality of upgrade segments; and A method comprising: retrieving a request from the broker from the queue and generating an upgrade message to be transmitted to the patient device via the first wireless transceiver, wherein the upgrade message is configured, based on the retrieved first upgrade segment, to be processed by the patient device to apply to the patient device an application of an upgrade file that modifies the firmware or software stored in the electronic memory of the patient device.

16. Based on a determination that the broker's request is not in the queue, the device profile data is retrieved from the database based on the identification data transmitted by the first patient device, the device profile data further includes versioning data relating to one or more components associated with the first patient device. The method of claim 15, wherein the extraction of the first upgrade segment is further based on the versioning data.

17. The method according to claim 15 or 16, wherein each of the multiple upgrade segments in the upgrade specification is processed sequentially until one of the preconditions in the upgrade segment matches the extracted versioning data of the device profile data of the first patient device.

18. The process further includes generating a new broker request based on the first upgrade segment based on the retrieval of the first upgrade segment, and adding the new broker request to the queue. The method according to any one of claims 15 to 17, wherein the broker's request is the new broker's request.

19. The method according to any one of claims 15 to 18, wherein the upgrade message includes an address to which the upgrade file should be obtained by the first patient device.

20. The method according to any one of claims 15 to 19, wherein the first computing node of the computer system makes a decision as to whether the broker's request is in the queue and whether the second computing node of the computer system processes the upgrade specification.

21. The method according to any one of claims 15 to 20, wherein the versioning information of the software or firmware is not included in the received electronic message transmitted from the client.

22. A patient device for a continuous positive pressure air (CPAP) system, the patient device comprising a first wireless transceiver and an electronic memory storing firmware or software used to control the operation of the patient device, wherein the first wireless transceiver is configured to transmit an electronic message containing identification data about the patient device, A server connected to a second transceiver and configured to receive the electronic message, wherein the server Based on the identification data that uniquely identifies the patient device, determine whether there are any applicable upgrades for the firmware or software stored in the patient's electronic memory; and A system including a server, configured to generate an upgrade message to be transmitted to the patient device via the first wireless transceiver in response to a decision that there is an upgrade to the firmware or software, wherein the upgrade message is configured to be processed by the patient device to cause the patient device to apply to the patient device an application of an upgrade file that modifies the firmware or software stored in the electronic memory of the patient device.

23. The system according to claim 22, wherein the server is further configured to retrieve device profile data by accessing a database using received identification data that uniquely identifies the patient device, the device profile data including versioning data relating to one or more components associated with the patient device.

24. The system according to claim 22 or 23, wherein the decision on whether there is an upgrade to the firmware or software is further based on the device profile data.

25. The system according to any one of claims 22 to 24, wherein the determination of whether there is an upgrade to the firmware or software is further based on a software or firmware version identifier included in the extracted device profile data.

26. The system according to any one of claims 22 to 25, wherein the firmware or software for the upgrade is associated with the components of the patient device.

27. The system according to any one of claims 22 to 26, wherein the versioning information of the software or firmware is not included in the electronic message containing identification data.

28. The patient device The system according to any one of claims 22 to 27, further configured to transmit the newly applied versioning data to the server based on the successful application of the upgrade file.

29. The patient device The system according to any one of claims 22 to 28, further configured to send an error message to the server based on an error that occurs when the upgrade file is applied.

30. The system according to any one of claims 22 to 29, wherein the upgrade message includes an address from which the upgrade file should be retrieved.

31. A method for remotely upgrading a patient device for a continuous positive air pressure (CPAP) system, Receiving an electronic message via a second transceiver of a computer system, wherein the electronic message is transmitted from the patient device, and the patient device includes a first transceiver and an electronic memory storing firmware or software used to control the operation of the patient device. Based on the identification data that uniquely identifies the patient device, determine whether there are any applicable upgrades for the firmware or software stored in the patient's electronic memory; and A method comprising, in response to the aforementioned decision, generating an upgrade message and transmitting the upgrade message to be processed by the patient device via the second transceiver of the computer system, thereby applying an application of an upgrade file that modifies the firmware or software stored in the electronic memory of the patient device to the patient device.

32. The method according to claim 31, further comprising retrieving device profile data by accessing a database using the received identification data that uniquely identifies the patient device, wherein the device profile data includes versioning data relating to one or more components associated with the patient device.

33. The method according to claim 31 or 32, wherein the determination of whether there is an upgrade to the firmware or software is further based on the device profile data.

34. The method according to any one of claims 31 to 33, wherein the determination of whether there is an upgrade to the firmware or software is further based on a software or firmware version identifier included in the extracted device profile data.

35. The method according to any one of claims 31 to 34, wherein the firmware or software for the upgrade is associated with the components of the patient device.

36. The method according to any one of claims 31 to 35, wherein the versioning information of the software or firmware is not included in the electronic message including identification data.

37. The method according to any one of claims 31 to 36, further comprising receiving another message from the patient device after sending the upgrade message, wherein the other message includes newly applied versioning data.

38. The method according to any one of claims 31 to 37, further comprising receiving an error message from the patient device after sending the upgrade message, wherein the error message includes data indicating that an error occurred when applying the upgrade file to the patient device.

39. The method according to any one of claims 31 to 38, wherein the upgrade message includes an address from which the upgrade file should be obtained.

Images