Communication system for respiratory therapy device data

Abstract

Systems, apparatus and methods provide management for enablement of data communications with therapy devices. In an example, a therapy device controller, such as of a respiratory therapy device, that is coupled to sensors and a communications device may be configured to receive and / or process sensor signals and store high-resolution data and low-resolution data from the received and / or processed one or more sensor signals and periodically transmit low-resolution data to an external server system for storage of the low-resolution data to a database. In response to a command signal, which may be received from the external server system, that requests activation of high-resolution data communications, the controller may initiate, or discontinue once initiated, periodic transmitting of the high-resolution data to a database of the server system.

Description

RMDDHI 3.4-002 (19)COMMUNICATION SYSTEM FOR RESPIRATORY THERAPY DEVICE DATACROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Patent Application No. 63 / 681,534, filed August 9, 2024, the entire content of which is incorporated herein by reference. BACKGROUND OF THE TECHNOLOGYFIELD OF THE TECHNOLOGY

[0002] The present technology relates to communications for remotely monitoring data related to therapy device use. In particular, the present technology relates to systems for obtaining high resolution data from remote medical equipment, such as a plurality of respiratory therapy devices, for remote monitoring of therapy.DESCRIPTION OF THE RELATED ART

[0003] Home-based therapy devices, such as respiratory therapy devices, allow patients to receive therapy remote from the personnel responsible for monitoring the therapy such as when the therapy device is used in the comfort of the patients’ home. To check for compliance or to monitor conditions of the patients and therapy progress, clinicians and / or physicians need to regularly review therapy data collected by the therapy devices. Such review of sensor data that was obtained during normal home therapy can benefit a therapy patient because such review enables, for example, the clinician / physician to adjust the patient’s course of treatment based on observation of the patient’s response to treatment, without having to bring the patient in to an office or other facility, such as a sleep lab for a sleep study. This means that the patient can sleep at home and still receive updates to their respiratory therapy, based on how they respond to the therapy.

[0004] For example, for the purposes of treating sleep-related breathing disorders and other respiratory dysfunctions, many people utilize so-called respiratory therapy devices (RPTs) such as the examples described in more detail herein, or continuous positive airway pressure (CPAP) machines with their blower and respiratory interface such as an air circuit and mask. Such devices may be configured with sensors that generate data measurements during the operation of the RPTRPT. Moreover, the RPT may compute additional data related to such measured data. ForRMDDHI 3.4-002 (19) example, pressure, respiratory flow, and SpC>2 (estimated blood oxygen saturation) can be obtained by sensors associated with an RPT, among others.

[0005] Some existing respiratory therapy devices implement a cellular modem to transfer therapy data to a remote database or server that is accessible by clinician. However, communication limitations such as due to quality or availability of such networks, the cellular modem is not always a reliable device for transferring data such as high-resolution data. For example, a respiratory therapy device may have collected an extensive quantity of pressure and flow data samples from one or more sensors over an eight-hour treatment session, which may be collected for weeks and months. If pressure sensors sample pressure values in a range of 100 to 250 Hertz (Hz) (which may be lower or higher), over the course of just one night of sleep (e.g., 8 hours), such a session could accumulate as much as 7,200,000 pressure samples. If additional sensors sample at similar rates, that number would multiply, such as double (e.g., a flow sensor), triple (e.g., a humidity sensor), quadruple (e.g., a temperature sensor), etc. Moreover, the devices may evaluate such signals and generate further data that characterizes such signals over time, such as by evaluating breathing conditions (e.g., sleep disordered breathing events) or device conditions (e.g., leak). Such computed parameters, including for example, tidal volume over time and other ventilation measures are described in more detail herein. With a low-quality cellular bandwidth limitation, the respiratory therapy device may be limited to transfer low-resolution data, limited to a summary or subset of the samples and / or computed parameters, as opposed to sending all or a substantial portion of the samples collected over even one seven or eight-hour treatment session or signals computed from such samples and having similar resolution (e.g., one night of sleep). In general, such devices are not enabled to transfer higher resolution data due to such bandwidth limitations. Indeed, the systems receiving such data may not be configured or organized for meeting the extensive communication demands of routinely receiving such quantities of high-resolution data from existing fleets of home medical equipment or therapy devices such as the respiratory therapy device. For example, in the case of an example respiratory therapy device, it is believed that more than 8 million positive airway pressure (e.g., CPAP) devices are sold annually in the United States, with another 2.5 million globally. Daily use of so many of such devices can present a significant technical challenge for communication systems even with low- resolution data.RMDDHI 3.4-002 (19)

[0006] Other existing respiratory therapy devices are not equipped with even a cellular modem. They may rely on a standard secure digital (SD) memory card to record therapy data. To export therapy data, a user or patient needs to manually pull the SD card out of the respiratory therapy device, physically carry the SD card to the clinician’s office and insert the card into a computer or terminal at a physician or clinician's office to permit transfer to the physician for review of the data. Such cards may limit the amount of data that may be transferred and do not present a convenient and reliable way to ensure remote clinical access to high-resolution data collected by the therapy devices.

[0007] While telemetry currently may be done for “low resolution” data (on the order of minute- by-minute summarized sensor pressure and flow data), it may be desirable to provide systems configured for telemetry of “high-resolution” data (in some implementations of the technology, such as on the order of 25 Hz sampling, or greater, of measurement signals and / or computed signals, such as pressure, flow, SpCh, leak, and more). Such high-resolution or high-data-rate or “HDR” telemetry need not be done in real time so long as it may be timely, e.g., accomplished within an hour to a few hours after a patient finishes a sleep session.

[0008] In view of the foregoing, there is a need for a cost effective, time-saving and reliable communications approach to effect remote data access from a home therapy device such as to support high-resolution data transmission to a remote system or server such as via wired and / or wireless devices, and simplify the process for exporting data to the remote system. The technology disclosed herein aims at providing technical systems and solutions that may permit communicating high resolution data with remote systems (e.g., to one or more server or database(s) from therapy devices and / or from one or more server or database(s) to clinician review devices), such as with minimal user intervention, and may do so with control elements to permit efficiencies in management of the communications and / or processing resources involved, given the extensive nature of the data loads. BRIEF SUMMARY OF THE TECHNOLOGY

[0009] The technology relates to a respiratory therapy data system, such as including one or more servers, in communication with therapy devices (e.g., respiratory therapy devices) and / or client computer devices, such as over one or more networks such as with wired and / or wireless communications.

[0010] The technology relates to a therapy data system, such as including one or more servers, configured for receiving data, such as high-resolution data, from a plurality of therapy devices, suchRMDDHI 3.4-002 (19) as over one or more networks such as with wired and / or wireless communications. The technology also relates to such therapy data system for providing remote access to such data, such as for displaying high-resolution data, for remote clinical monitoring of therapy provided by the plurality of therapy devices.

[0011] The present technology may include a respiratory therapy device. The respiratory therapy device may include a flow generator configured to couple with a respiratory patient interface and to provide a flow of breathable gas as a therapy to the respiratory patient interface. The respiratory therapy device may include one or more sensors, the one or more sensor configured to sense one or more characteristics of the flow of breathable gas and / or the therapy. The respiratory therapy device may include a communications device. The respiratory therapy device may include a controller that may include one or more processors and may be coupled to the one or more sensors and the communications device. The controller may be configured to receive and / or process one or more sensor signals from the one or more sensors and store high-resolution data and low-resolution data from the received and / or processed one or more sensor signals in a memory of the respiratory therapy device. The controller may be configured to periodically transmit the low-resolution data, with the communications device, to an external server system for storage of the low-resolution data to a database of the server system. The controller may be configured to receive via the communication device, a command signal requesting activation of high-resolution data communications. The controller may be configured to, in response to the received command, initiate periodic transmitting of the high-resolution data to a database of the server system.

[0012] In some implementations, the high-resolution data may include at least one of pressure data and flow rate. The high-resolution data may include samples collected at a rate no less than 25 Hertz. The low-resolution data may include samples collected at a rate in a range of one Hertz or less. The low-resolution data may include one or both of inspiratory pressure data and leak data. The one or more sensors may include one or both of a pressure sensor and a flow sensor. The respiratory therapy device may further include any one or more of a thermometer, a light sensor, a microphone, or a biomotion sensor, wherein the periodic transmitting of the high-resolution data includes data from any one or more of the thermometer, the light sensor, the microphone, or the biomotion sensor. The periodic transmitting may occur at a predetermined interval of time following a use of the respiratory therapy device such as when a respiratory therapy interface (e.g., mask) isRMDDHI 3.4-002 (19) removed by the user. The periodic transmitting may occur as in response to detection of a user ceasing a therapy session may include any of (a) a detection of removal of the respiratory patient interface or (b) a deactivation of a therapy session with the flow generator. The device may be configured to repeatedly collect the high-resolution data in an internal buffer during a defined period of time and then compresses the collected high-resolution data into a chunk of data, thereby producing a sequence of compressed data chunks. The device may be configured to transmit the compressed data chunks in a series of packets, according to a network packet size limit. In some implementations, each packet may be no more than (less than) 120 Kb in size. Each chunk may include no more than (less than) about two minutes of high-resolution data. The at least one of the chunks of data may include a header that describes a characteristic of data in that chunk. The respiratory therapy device may receive the command signal during a periodic communication between the respiratory therapy device and a server of the external server system. The respiratory therapy device may be configured to terminate the periodic transmitting of the high-resolution data to the database of the server system based on an engagement period. The respiratory therapy device may terminate the periodic transmitting of the high-resolution data to the database of the server system by detecting an end of the engagement period. The respiratory therapy device may terminate the periodic transmitting of the high -resolution data to the database of the server system upon receiving a follow-on command signal received from the server system when the server system detects an end of the engagement period.

[0013] The present technology may include one or more servers for monitoring respiratory therapy device over a network. The one or more servers may be configured to communicate with a plurality of respiratory therapy devices. The one or more servers may be configured to selectively activate at least one of the respiratory therapy devices to begin or cease a high -resolution data transfer protocol.

[0014] In some implementations, the one or more servers may include a machine control service that may be configured to communicate a command signal to activate at least one of the respiratory therapy devices to begin or cease the high-resolution data transfer protocol. The one or more servers may further include one or more databases configured to store data associated with the respiratory therapy devices, wherein the data associated with at least one of the respiratory therapy devices may include a high-data-rate state of that respiratory therapy device. The one or more servers may further include one or more services that may be configured to communicate with the respiratory therapyRMDDHI 3.4-002 (19) devices, to interact with the database, and / or to selectably manage low-resolution data and high- resolution data communications with the at least one of the respiratory therapy devices. The one or more services may be configured to select to communicate low-resolution data or high-resolution data from the at least one of the respiratory therapy devices in response to querying the database for a high-data-rate (HDR) state that may be associated with the at least one respiratory therapy device. When the one or more services may be communicating high-resolution data from the at least one of the respiratory therapy devices, a service of the one or more service may implement a streaming process that receives chunks of compressed high-resolution data in window batches for processing and decompresses, joins, and recompresses the high-resolution data into a data structure. At least one chunk of data may be compressed according to characteristics of the data in that chunk. The at least one chunk of data may include a header that describes a compression characteristic of the at least one chunk of data. Each chunk may include no more than (less than) about two minutes of high-resolution data.

[0015] In some implementations, the one or more services may be configured to set or clear the command signal for a given respiratory therapy device in response to querying the one or more databases for an HDR state of the given respiratory therapy device. The high-resolution data may include one or more of pressure data, flow data, and leak rate data. High -resolution data may be collected at a rate no less than (at or greater than) 25 Hz. The low-resolution data may include samples collected at a rate in a range of one Hertz or less. The low-resolution data may include one or both of inspiratory pressure data and leak data.

[0016] In some implementations, the one or more servers may be configured to generate a graphic user interface that may include a control with an element for selecting high-data-rate (HDR) communications for some or all of the respiratory therapy devices that may be associated with an organization. The one or more servers may be configured to, in response to activation of the element for selecting HDR communications, set or clear an HDR state for at least one of the plurality of respiratory therapy devices in a database that stores data associated with the plurality of respiratory therapy devices. The element may be a set of radio buttons.In some implementations, the one or more servers may be further configured to generate a graphic user interface. The one or more servers may be further configured to, in response to a user activation of the element for selecting HDR communications, enable in the graphic user interface a per-deviceRMDDHI 3.4-002 (19)HDR element for a plurality of devices associated with an organization. The one or more servers may be further configured to, in response to a user activation on the element for selecting HDR communications, display, via an external interface, a per-device HDR element for each device of the plurality of devices associated with the organization. One or more respiratory therapy devices of the plurality of respiratory therapy devices may be configured to terminate the high-resolution data transfer protocol based on an engagement period. The one or more respiratory therapy devices may terminate the high-resolution data transfer protocol by detecting an end of the engagement period. In some implementations, when the one or more servers detect an end of the engagement period, the one or more servers communicate a follow-on command signal to the one or more respiratory therapy devices to terminate the high -resolution data transfer protocol.

[0017] The present technology may include a respiratory therapy monitoring system. The respiratory therapy monitoring system may include one or more servers. The respiratory therapy monitoring system may include a plurality of respiratory therapy devices (RPTs). The RPTs ma be configured for communicating data with the one or more servers, wherein a first group of the RPTs may be associated with an organization. The one or more servers may be configured to serve a database and a graphic user interface. The one or more servers may be configured to receive sensor data from each of the RPTs and store the sensor data in the database. The one or more servers may be configured to provide the graphic user interface may include a control with an element for selecting high-data-rate (HDR) communications for some or all of the respiratory therapy devices that may be associated with an organization. The one or more servers may be configured to, in response to a user activation of the element for selecting HDR communications, set or clear an HDR state for at least one of the plurality of respiratory therapy devices in the database that stores data associated with the plurality of respiratory therapy devices. Each of the RPTs may be configured to after the end of a patient sleep session, check in with the server to upload sensor data and to check the HDR state for that RPT. Each of the RPTs may be configured to in response to the HDR state for that RPT being set, commence periodically transmitting high-resolution data to the server.

[0018] In some implementations, the server may be further configured to provide an graphic user interface. The server may be further configured to provide, as part of the graphic user interface, a per-device HDR element. The server may be further configured to receive, via the graphic user interface, an indication of activation of the per-device HDR element. The server may be furtherRMDDHI 3.4-002 (19) configured to, responsive to the indication of activation of the per-device HDR element, set or clear the HDR state for at least one of the RPTs. The high-resolution data may include at least one of pressure, flow, or leak rate data. The high-resolution data may be collected at a rate no less than 25 Hz. The one or more servers may be configured to receive low-resolution data from each of the RPTs and store the low-resolution data in the database. The low-resolution data may include samples collected at a rate in a range of one Hertz or less. The low-resolution data may include one or both of inspiratory pressure data and leak data. At least one of the RPTs may further include at least one of a pressure sensor, a flow sensor, a thermometer, a light sensor, a microphone, or a biomotion sensor. The periodic transmitting may occur at a regular interval of time, such as not less than hourly while the respiratory therapy system may be in use. The periodic transmitting may occur upon termination of a session of use with the RPT, such as each time the user removes a patient interface (e.g., a respiratory therapy mask). The RPT may repeatedly collect the high-resolution data in an internal buffer during a defined period of time and then may compress the collected high-resolution data into a chunk of data, thereby producing a sequence of compressed data chunks. The RPT may transmit the compressed data chunks in a series of packets, according to a communication network limit on packet size. Each packet may be no more than 120 Kb in size. Each chunk may include no more than about two minutes of high-resolution data. At least one chunk of data may be compressed by a customized algorithm that may be determined according to characteristics of the data in that chunk. The at least one chunk of data may include a header that describes a compression characteristic of the at least one chunk.

[0019] In some implementations, the one or more servers may be configured to provide a machine control service that may be configured to handle data related to respiratory therapy device identity and settings. The machine control service may be configured to generate a command signal that activates at least one of the RPTs to begin or cease a high-resolution data transfer protocol. The respiratory therapy monitoring system may further include a database that stores data associated with the respiratory therapy devices, wherein the data associated with at least one of the RPTs may include a high-data-rate state of that RPT. The respiratory therapy monitoring system may further include a machine data service that may be configured to communicate with the respiratory therapy devices, to interact with the database, and to selectably handle low-resolution data and high-resolution data related to use of the respiratory therapy devices. The machine data service may be configured toRMDDHI 3.4-002 (19) select to handle low-resolution data or high-resolution data from a given RPT in response to querying the database for a high-data-rate (HDR) state that may be associated with the given RPT. When the machine data service may be handling high-resolution data from a given RPT, a machine control service may implement data streaming that receives chunks of compressed high-resolution data in window batches for processing and decompresses, joins and recompresses the high-resolution data as data structure. At least one chunk of data may be compressed according to characteristics of the data in that chunk. The at least one chunk of data may include a header that describes a compression characteristic. Each chunk may be limited to include no more than about two minutes of high- resolution data. The machine control service may be configured to generate the command signal for a given respiratory therapy device in response to querying the database for an HDR state of the given respiratory therapy device. The element for selecting HDR communications may be a set of radio buttons.

[0020] The present technology may include a respiratory therapy monitoring system that may include one or more servers configured to communicate with a plurality of respiratory therapy devices (RPTs). The one or more servers may be configured to serve a database and a graphic user interface. The one or more servers may be configured to receive high-resolution sensor data from each of the RPTs and store the sensor data in the database. The one or more servers may be further configured to provide, as part of the graphic user interface, a display of data display elements, in which a display element of the display corresponds to a plurality of signals from the sensor data. The one or more servers may be further configured to receive, via the graphic user interface, a selection of a patient. The one or more servers may be further configured to responsive to the selection of the patient, retrieve from the database the sensor data that corresponds to the selected patient’s RPT. The one or more servers may be further configured to display, in a first view section of the graphic user interface, a low-resolution subset of points of the sensor data for a signal of the plurality of signals, wherein the low-resolution subset corresponds to the selected patient’s RPT. The low-resolution subset of points may be displayed in correspondence with event markers that correspond to identified events in the signal. The one or more servers may be further configured to receive, via the graphic interface, user input concerning the low-resolution subset of points of the sensor data with visual delimiter elements. The one or more servers may be further configured to responsive to the visual delimiter elements, display, in a second view section of the graphic user interface, high-resolution data of the signalRMDDHI 3.4-002 (19) corresponding to the visual delimiter elements. At least one of the RPTs further may include at least one of a pressure sensor, a flow sensor, a thermometer, a light sensor, a microphone, or a biomotion sensor. At least one of the display elements displays data may correspond to the at least one sensor of the at least one RPT. The first view section may display points that have been down-sampled from the high-resolution data that may be stored in the database. The one or more servers may be configured to provide a graphic user interface that may include a control with an element for selecting high-data-rate (HDR) communications for some or all of the respiratory therapy devices that may be associated with an organization. The one or more servers may be configured to, in response to a user activation of the element for selecting HDR communications, set or clear an HDR state for at least one of the plurality of respiratory therapy devices in a database that stores data associated with the plurality of respiratory therapy devices. Each of the plurality of respiratory therapy devices may be configured to after an end of a patient therapy session, communicate with the one or more servers to upload sensor data according to an HDR state for that RPT. Each of the plurality of respiratory therapy devices may be configured to in response to a change in the HDR state for that RPT being set, commence periodically transmitting high-resolution data to the one or more servers. The one or more servers may be configured to store the high-resolution data by receiving chunks of compressed high- resolution data from an RPT. The one or more servers may be configured to process, in streamed window batches, the chunks of compressed high -resolution data by decompression, joining, and recompression as a data structure for storing in the database.

[0021] In some implementations, HDR telemetry may be accomplished by collecting, buffering, chunking, compressing, and later communicating packets of high-resolution data from a respiratory therapy device (RPT) to a respiratory therapy data server. For example, two or three 120 Kb compressed data packets can be formed from the 25 Hz data produced by one patient’s sleep session. The packets can be transmitted by the RPT to the server, for example, during a brief window of time in the morning after the patient removes their sleep mask, or anytime the RPT detects that the user takes their mask off, such as by comparing measure pressure or flow to a threshold. At the same time, the RPT can check in with the server for, e.g., data rate instructions, other setting changes. If the server instructs the RPT to enter or exit HDR mode, the RPT will accordingly begin or cease buffering, chunking, compressing, and communicating high-resolution data. Moreover, according toRMDDHI 3.4-002 (19) such command, the RPT may send data of different types according to a commanded resolution, which may be data type specific.

[0022] According to an aspect of the technology, an exemplary respiratory therapy monitoring system may include a respiratory therapy data server and a plurality of respiratory therapy devices (RPTs), each of which is connected in communication with the server. A first group of the RPTs may be associated with an organization. The server is configured to serve a database and one or more user interfaces (e.g., graphic user interface data for presenting user controls in one or more client devices). The server is configured to receive sensor data from each of the RPTs and store the sensor data in the database. The server is configured to provide, as part of a user interface, an organizational HDR button; to receive, via the internal interface, a click on the organizational HDR button; and, responsive to the click on the organizational HDR button, toggle a flag, state, or command signal for HDR sensor data collection (an “HDR state”) for each of the first group of RPTs. Each of the RPTs is configured to, after the end of a patient sleep session, communicate with the server to upload sensor data and to check for the HDR flag or command signal for that RPT; and, in response to the HDR command signal forthat RPT being set, commence buffering, chunking, compressing, and communicating high- resolution data to the server.

[0023] In some implementations, the system may be further configured to provide a user interface; provide, as part of the external interface, a per-device HDR toggle; receive, via the external interface, a click on the per-device HDR toggle; and, responsive to the click on the per-device HDR toggle, instruct one of the RPTs to commence buffering, chunking, compressing, and communicating high- resolution data to the server.

[0024] According to another aspect, an exemplary respiratory therapy monitoring system may include a respiratory therapy data server and a plurality of respiratory therapy devices (RPTs), each of which is connected in communication with the server. The server is configured to serve a database and an external interface. The server is configured to receive sensor data from each of the RPTs and store the sensor data in the database. The server is configured to provide, as part of the external interface, a display of data display elements, in which a display element of the display corresponds to one of pressure, flow, and SpO2; receive, via the external interface, a selection of a patient; responsive to the selection of the patient, retrieve from the database the sensor data that corresponds to the selected patient’s RPT; display, via the external interface, the sensor data that corresponds toRMDDHI 3.4-002 (19) the selected patient’s RPT, along with event markers that correspond to identified events in the sensor data; receive, via the external interface, a click on an event marker; and, responsive to the click on the event marker, display, via the external interface, details of the corresponding event.

[0025] Of course, portions of the aspects may form sub-aspects of the present technology. Also, various ones of the sub-aspects and / or aspects may be combined in various manners and also constitute additional aspects or sub-aspects of the present technology.

[0026] Other features of the technology will be apparent from consideration of the information contained in the following detailed description, abstract, drawings and claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The present technology is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements including:RESPIRATORY THERAPY MONITORING SYSTEMS

[0028] FIG. 1 shows a diagram of an example architecture for a respiratory therapy monitoring system that comprises one or more servers, such as with various communication service(s) and data base(s), for communicating with a plurality of respiratory therapy devices (RPTs) 104 and / or client devices 109 such as computers or other smart devices (e g., smart phone, laptop, tablet etc.) each of which may be connected in communication with the system. A service may be an application (e.g., an application programming interface or API) running on computer apparatus acting as a server on a network.

[0029] FIG. 2 shows a diagram with service elements, such as for the aforementioned respiratory therapy monitoring system, for implanting data transfer services, such as to activate and / or deactivate high-resolution data services with one or more therapy devices, such as in response to user actuation of elements in user interfaces, such as one or more graphic user interfaces that may be generated with a server of the respiratory therapy monitoring system.

[0030] FIG. 3 illustrates an example streaming architecture that may be implemented by the respiratory therapy monitoring system.

[0031] FIG. 4 shows example modules for data charting in an interface that may be generated by the respiratory therapy monitoring system.RMDDHI 3.4-002 (19)

[0032] FIG. 5A shows an example user interface such as for implementing an HDR control that may be generated by the respiratory therapy monitoring system.

[0033] FIG. 5B shows another example user interface such as for implementing an HDR control that may be generated by the respiratory therapy monitoring system, such as on a display of a respiratory therapy device or a display of a client device of a server of the system.

[0034]

[0035] FIG. 6A shows an example user interface with a summary view that may be generated by the respiratory therapy monitoring system such as for presenting on a display such as on a client device.

[0036] FIG. 6B shows an example user interface with a nightly data view that may be generated by the respiratory therapy monitoring system such as for presenting on a display as an external interface such as on a client device.

[0037] FIG. 6C shows another example user interface with a device settings panel that may be generated by the respiratory therapy monitoring system such as for presenting on a display as an external interface such as on a client device.

[0038] FIG. 7 shows another example user interface with a nightly data view that may be generated by the respiratory therapy monitoring system such as for presenting on a display such as on a client device.

[0039] FIG. 8 shows an example user interface with a nightly data view that may be generated by the respiratory therapy monitoring system such as for presenting on a display as an external interface such as on a client device. This interface illustrates a display of one or more view of data based on, or including, one or more high-resolution data signals generated by a respiratory therapy device and reviewed a client device with one or more services of the system.

[0040] RESPIRATORY THERAPY SYSTEMS

[0041] FIG. 9A shows a system including a patient 1000 wearing a patient interface 3000, in the form of nasal pillows, receiving a supply of air at positive pressure from an RPT device 4000. Air from the RPT device 4000 is humidified in a humidifier 5000, and passes along an air circuit 4170 to the patient 1000. A bed partner 1100 is also shown. The patient is sleeping in a supine sleeping position.

[0042] FIG. 9B shows a system including a patient 1000 wearing a patient interface 3000, in the form of a nasal mask, receiving a supply of air at positive pressure from an RPT device 4000. Air from theRMDDHI 3.4-002 (19)RPT device is humidified in a humidifier 5000, and passes along an air circuit 4170 to the patient 1000.

[0043] FIG. 9C shows a system including a patient 1000 wearing a patient interface 3000, in the form of a full-face mask, receiving a supply of air at positive pressure from an RPT device 4000. Air from the RPT device is humidified in a humidifier 5000, and passes along an air circuit 4170 to the patient 1000. The patient is sleeping in a side sleeping position.RPT DEVICE

[0044] FIG. 10A shows an RPT device in accordance with one form of the present technology.

[0045] FIG. 10B is a schematic diagram of the pneumatic path of an RPT device in accordance with one form of the present technology. The directions of upstream and downstream are indicated with reference to the blower and the patient interface. The blower is defined to be upstream of the patient interface and the patient interface is defined to be downstream of the blower, regardless of the actual flow direction at any particular moment. Items which are located within the pneumatic path between the blower and the patient interface are downstream of the blower and upstream of the patient interface.

[0046] FIG. 10C is a schematic diagram of the electrical components of an RPT device in accordance with one form of the present technology.

[0047] FIG. 10D is a schematic of control algorithms that are implemented in an RPT device in accordance with one form of the present technology.DETAILED DESCRIPTION OF EXAMPLES OF THE TECHNOLOGY

[0048] Before the present technology is described in further detail, it is to be understood that the technology is not limited to the particular examples described herein, which may vary. It is also to be understood that the terminology used in this disclosure is for the purpose of describing only the particular examples discussed herein, and is not intended to be limiting.

[0049] The following description is provided in relation to various examples which may share one or more common characteristics and / or features. It is to be understood that one or more features of any one example may be combinable with one or more features of another example or other examples. In addition, any single feature or combination of features in any of the examples may constitute a further example.RMDDHI 3.4-002 (19)

[0050] FIG. 1 shows a diagram of a high-level architecture for a respiratory therapy monitoring system 100 that may include one or more servers, such as server(s) 102, that may be implemented with one or more services (e.g., software running on one or more processors of a server(s)) for managing and / or implementing the communications. The system may be configured for communicating with a plurality of therapy devices such as respiratory therapy devices (RPTs) 104, each of which may be connected in communication with the server(s), such as over one or more networks, with wired and / or wireless communications, for communicating therapy data, such as high- resolution therapy data. The system may also be configured for communicating with one or more client device(s) 109 such as over one or more networks APN, with wired and / or wireless communications, for communicating therapy data, such as high-resolution therapy data. Such communications may be implemented, in part, with wireless communications including, for example, cellular, wi-fi, Bluetooth, and / or other wireless communications protocol. Such one or more networks may include, for example, communications over Cellular, Wifi, Bluetooth and / or internet networks, such as the Internet. The system may be configured for receiving data (low resolution therapy data and / or high-resolution therapy data) from the therapy devices 104 for storage in one or more database(s), such as one or more databases for high-resolution data and one or more database(s) for low resolution data. The high-resolution data may be time dependent therapy data from a therapy session where the therapy data is represented by signal samples of the therapy session that are sampled on the order of 25 Hz data or more where the signals are produced by the sensors of the respiratory therapy device 104 or derived by processing of the respiratory therapy device from signals produced by the sensors. Such therapy data may be pressure data, flow rate data, leak data, acoustic noise data, etc. In some cases, the data sent may be of a lower resolution, such as where the therapy data is represented by signal samples of the therapy session data sampled in a range of one Hertz or less such as on the order of one hertz or 0.5 hertz. Such lower resolution data may be, for example, any of the aforementioned data such as leak data and / or inspiratory pressure. In some implementations, communication of data may be based on a control command, such as a resolution command that provides an indication of the resolution at which data should be sent. Such a control command or resolution command may be set on the RPT device (such as via a user input interface of the RPT) or the command may be provided or set remotely, such as from a server of the system. Moreover, such control command, or resolution command, may be data specific such that it may specify which typeRMDDHI 3.4-002 (19) of data should be sent according to a particular resolution. Thus, different data (e.g., pressure, flow, leak, etc.) may be sent at different resolutions, and such differences may be remotely controlled / commanded, such as by a server of the system.

[0051] As such, the system may be configured to enable a user, such as a clinical user, to selectively activate (such as remotely) one or more of the respiratory therapy devices for transmitting, for example, either one of high-resolution data or low-resolution data (e.g., summary data) to one or more servers of the system such as to activate or deactivate communications of the system for achieving communication of, or discontinuing communication, of the high-resolution data into one or more databases of the system when received from the respiratory therapy device(s). Thus, activation of high-resolution data communications, such as in accordance with the control command, in the system may be selectively made for organizing when therapy devices can begin such high-resolution communications or refrain from such communications to instead remain using low-resolution communications. Such activation control over transmitted data resolution can permit greater control over bandwidth usage. In this context, activation may initiate an immediate transfer of therapy data or may initiate one or more periodic transmissions of therapy data such as at the conclusion or shortly after a therapy session with a therapy device or multiple intervals within therapy such as after detected mask off events, which may be a temporary halt within a therapy session.

[0052] Moreover, in some implementations, the system may be configured with, or in response to, the control commands, or resolution commands, to activate such high-resolution communications for an engagement period, which is a temporary period of time such as a time period on the order of weeks or months such as a temporary period of time in a range of one week to three months, such as seven (7) days, thirty (30) days, sixty (60) days or ninety (90) days. Otherwise, the engagement period may be set to expire at a certain date. In this regard, a control command may activate one or more therapy devices to conduct high-resolution communications as described herein (such as periodically) for the length of the engagement period and, at or near the end of the engagement period, the one or more therapy devices may cease to conduct the high-resolution communications (such as by returning to the low-resolution transmissions). Thus, a control command for activation may have, or be enforced in association with, an engagement period. In some implementations, termination of the high-resolution communications at the conclusion of the engagement period may be enforced by any one or more components of the system (e.g., the one or more server(s) configured to communicateRMDDHI 3.4-002 (19) the control command(s) and / or the therapy device receiving the control commands). For example, the therapy devices may be configured with a scheduler and / or timer to determine a time period from activation or when the engagement period ends, and, in response to receiving of the control command or resolution command, may employ the high-resolution communications (e.g., periodically as previously discussed) during the length of the engagement period but then cease such high-resolution communications upon detecting the end of the activated engagement period. Similarly, the one or more servers may be configured with a scheduler and / or timer and be configured to, after transmission of a control command to initiate / activate high-resolution communications, to further automatically communicate a follow-on control command(s) at the end of the engagement period to disable the high-resolution communications. Examples of such communications management control may be considered in relation to the further examples described herein.

[0053] The high-level flow of interactions in an example architecture for such purposes may be considered in relation to the elements of FIG. 1. Such elements may include an activation service (labeled BBB in Fig. 1) which may be configured with a user interface 106 or graphic user interface, which may be implemented or generated / provided by the one or more servers of the system such as the server(s) 102. Such a service may be configured to generate the user interface, such as over a network to and on a display of a client device 109, for receiving user input, such as from the client device, that enables a user (such as a clinician) to select activation or deactivation of high-resolution data communication system functions described herein. Such a selection may also be stored in a database of the system such as in association with the identify of one or more therapy device affected by the activation.

[0054] For example, the activation service 106 may receive user input, such as a click, in relation to a high-data-rate (“HDR”) selection element of the user interface (e.g., a set of radio buttons as shown in FIG. 6; a sliding toggle element; a dropdown menu selection; a check box, etc) for activating high resolution data transmissions. For example, in response to the user input (e.g., a button click), at (1) the activation service 106 may then send, such as to an intermediary service (e.g., a machine control service 108) an HDR request (or other command) to activate or de-activate high-resolution data with respect to one or more of devices 104, such as a device 104.1.

[0055] In such an implementation of the technology, the machine control service 108 (labeled MCS in FIG. 1) (which may be implemented in one or more servers of the system such as the server 102)RMDDHI 3.4-002 (19) may be configured to, at an appropriate time, communicate at (2) the HDR request to the device 104.1. Such a communication may occur, such as a push notification, initiated from the server. Alternatively, or additionally, such a communication may occur, for example, when the therapy device periodically initiates a communication at (3) with the MCS service, such as when the therapy device periodically uploads data at (4) to the one or more servers, such as for storage of the data in any database of the one or more servers, via the MCS service. In certain implementations of the technology, the machine control service MCS 108 may be otherwise responsible for communications with the therapy device(s) concerning high resolution data such as in relation to transfer of metadata such as model, settings, and other usage or therapy data etc. The HDR request may be a command signal that is sent to the therapy device(s) so that it may be acted upon by the therapy device(s). In some implementations, such a command may designate a type or types of data and / or a resolution or resolutions for data for transmission. Thus, the MCS 108 may be configured to engage in network transmissions of data with respiratory therapy devices including, for example data regarding identity and settings, and usage and other therapy data. As such, the MCS service 108 communicates a command signal(s) to the therapy device(s), such as via one or more networks, that activates the respiratory therapy device(s) (RPTs) to begin, or cease, a high-resolution data transfer protocol, which may, for example, be enforced for an engagement period as previously discussed. For example, once the MCS service 108 communicates a command signal(s) to the therapy device(s), to activate a high- resolution data transfer protocol, the MCS service 108 may, optionally automatically, communicate a command signal(s) to the therapy device(s) to de-activate a high-resolution data transfer protocol, such as after conclusion of an engagement period associated with the command signal(s) that activated the high-resolution data transfer protocol. Such an automatic deactivation may, for example, occur at a time when the therapy device initiates a communication with the MCS service 108, such as after or near the end of the engagement period.

[0056] In some forms of the technology, in response to the command signal, the therapy device may store / set one or more settings concerning data resolution for transmission, such as, for example, an HDR setting in a memory of the therapy device 104. The therapy device (e.g., device 104.1) may optionally confirm to the MCS service that such a setting, like the HDR setting, has been affected on the therapy device(s), in response to the command signal. In this regard, the one or more settings concerning data resolution for transmission, herein referred to as an HDR setting, on the therapyRMDDHI 3.4-002 (19) device serves as a control parameter(s) at the therapy device for data transmissions. Thus, the HDR setting(s) may serve as a control parameter(s) on the therapy device to designate the type of data transfer (e.g., level(s) of resolution or type(s) of data at a specified level of resolution) that will be made when the therapy device transfers data, such as to the MCS service. Thus, the HDR setting can control the therapy device to send high-resolution data to MCS 108, when the therapy device otherwise communicates data to the MCS 108.

[0057] Such communications by the therapy device to the MCS service may be immediately in response to the command signal. Alternatively, such communication of high-resolution data may be made in response to a communication schedule of the therapy device, such as during its periodic transmissions of therapy data to the MCS 108. For example, the therapy device 104 may be configured to periodically send data to the MCS service, and the data may be high-resolution data depending on the HDR setting. For example, in some forms of the technology, the therapy device may periodically initiate or establish communications with the MCS service such as at the end or shortly after a sleep session with the therapy device, e.g., in the morning after a user removes their sleep mask or otherwise deactivates a therapy session. Optionally, in other forms of the technology, the device may more frequently, e.g., on an hourly basis or at another predetermined or defined time interval or after each detected removal of the user's patient interface (e.g., mask), communicate with the MCS service, or optionally, in real or near real time when such data is determined by the therapy device. In periodic communications, when the HDR setting is enabled, high-resolution data will be sent. Alternatively, when the HDR setting is not enabled only low resolution or summary data may be sent in the periodic communication. When high-resolution data is sent, such communications may optionally be implemented as a plurality of discrete (e.g., ~2min) transmissions such as compressed chunks, as further discussed below. In some implementations of the technology, each compressed chunk of high-resolution data may represent a similar length of time (e.g., 2 minutes), and be of similar size (e.g., up to 120 Kb), and may have a header that defines how to the data of the chunk was compressed or may be decompressed. However, other larger or smaller chunk sizes on the order of minutes may be implemented, such as for example, in a seconds range from 60 to 240, or 80 to 200, 80 to 180 etc. Moreover, other larger or smaller packet sizes may be implemented, such as for example, in a Kb range from 40 to 240, or 80 to 200, 80 to 180, etc. Such a header may also include an indication of how the chunk relates to the other chunks so that the collection of chunks correctlyRMDDHI 3.4-002 (19)(e.g., temporally) corresponds with the data of a therapy session that is represented by the high- resolution data.

[0058] Optionally, when the therapy device communicates with the MCS service (such as a scheduled or periodic communication), the therapy device may communicate a confirmation that the HDR setting has been made (i.e., stored) to the machine control service (MCS) 108. Similarly, the MCS service 108 may communicate with the activation service 106 to confirm that the high-resolution request has been made and / or completed such as at (4.1) or disabled such as in relation to expiration of an engagement period.

[0059] Thus, the command to set the HDR setting enables a control on the therapy device to begin (or cease) to make one or more periodic communications of high-resolution data (depending on the command) with the one or more servers of the system, such as server 102. For example, during its periodic communications, the therapy device may send high-resolution data when the HDR setting is enabled. Such communications may optionally also include low resolution data. Thus, at (4.2), the MCS 108 receives high-resolution data, and the service, or another service of the system, may optionally validate the received data such as when the high-resolution data is sent in a plurality of discrete transmissions such as chunks of the high-resolution data, which may each contain compressed data. Optionally, each chunk may have a header that includes information regarding the chunk, such as method of compression for that chunk and or the time period for the data of the chunk. Validation may involve confirmation of the received data such as in relation to parity checking or may involve ensuring that the plurality of discrete transmissions or compressed chunks that are received collectively correspond to an expected interval (e g., a period attributable to a sleep session for which the high resolution has been sent) of data transmitted data from the therapy device.

[0060] That received data may then be stored in a database of the one or more servers of the system. For example, at (5), the MCS service 108 may communicate the high-resolution data (e g., the compressed chunks) to another service such as the machine data service 110. The machine data service may operate with one or more servers to communicate with one or more databases so that the data may be sent to an appropriate database. For example, the machine data service (MDS) 110 may determine that the received data is high-resolution data and may then communicate with one or more specialized database(s) configured for storing the high-resolution data. In some implementations, the MDS service may be implemented to, such as with communications to additional service(s) such asRMDDHI 3.4-002 (19) the MCS service, reconstruct the sequence of data that represents a therapy session, such as a sleep session, from a plurality of chunks received from a therapy device, which might not be received in chronological order, so that the reconstructed sequence can be stored in the database. Such reconstruction may involve, for example, decompression of the chunk, such as in accordance with the method identified in the header, and chronological ordering the data of the chunks so that the data of the chunks may be converted to one or more data structures as one or more time series of signal samples respectively for storage within the database as chronological sequences of high-resolution data from a therapy session.

[0061] Once stored in such a database, the activation service 106, or another service of the system with access to the database(s) containing the data, may be configured to permit exami nation / review / access to the high-resolution data from the database(s), such as by providing / generating one or more user interfaces with the high-resolution data. Such user interfaces, as discussed in more detail herein in relation to the examples of Figs. 6-8, may be presented on a display of server of the activation service or the data may be communicated to a display of a client device 109 for viewing of the high-resolution data on the client device, such as with an application on the client device.

[0062] Although the aforementioned communications of therapy data from the therapy devices may be periodic as previously described, in other implementations, the high-resolution data may be sent by the therapy device 104 to the MCS service 108 in real time, or near real time such as within a one or two minutes the data is generated. Moreover, in some of the implementations and the data may or may not be compressed. For example, in some implementations, the transmission of high -resolution data, such as 25Hz data, may first involve down sampling to, for example, another resolution, such as 6.25Hz, before transmitting, and such data may be reconstructed to the original, e.g., 25 Hz data signal after transmission. In some implementations, the high-resolution data may be sent by the device 104 to the MCS 108 at regular intervals while the device 104 is in use; in such implementations, the high-resolution data may or may not be compressed and / or chunked.

[0063] Thus, as previously mentioned, in some implementations, such as in the example of FIG. 1, the one or more servers of the system may include a machine data service (MDS) 110. This service may be configured to receive, handle, and communicate with one or more databases for storing patient therapy data. This data may include data that are related to the patient’s breathing, on a breath-by-RMDDHI 3.4-002 (19) breath basis, that may include both the high-resolution data related to the breaths, and lower- resolution data such a summary data. The high-resolution data may include discrete data structures that each contain a time series of signal samples of different data concerning a therapy session (e.g., data samples representing breath-by-breath flow, pressure and / or leak signals). In some implementations of the technology, the MDS 110 may be configured to compile each time series of high-resolution data from real-time uploads sent by the therapy device 104.1 that may be received by the MDS 110 in communications with the MCS service 108. For example, the MDS 110 may receive a plurality of chunks of high -resolution data, which may be compressed, from the MCS service. The MDS 110 service may determine or ensure proper ordering of the data of the chunks, such as with communications to one or more additional services. The MDS 110 may also decompress the chunks (e.g., in a manner further discussed with reference to FIG. 4). At (6), in some implementations of the technology, the machine data service 110 may consolidate the data of the received chunks into a session-length, data structure (such as with metadata regarding the data structure), which may be compressed, for storage in one or more database(s), such as to produce a database of high-resolution data for a plurality of therapy devices, which may in turn be evaluated or processed such as for empirical study or pattern evaluation on a high-resolution basis for multitudes of patients. As previously mentioned, such stored data may then be accessed or used, such as with a user interface provided by the activation service 108 at (7). Examples of such user interfaces for examining data on a patient-by-patient basis may be considered in more detail herein in relation to the graphic user interface examples of FIGs. 6-8.

[0064] At the therapy device side, compression and chunking of the high-resolution data, for the uploading communications to the server(s), may be an ongoing process during a sleep session as long as the HDR setting has be set for high-resolution processing. According to some implementations of the technology, when a sleep session ends, the therapy device, according to the high-resolution command (e.g., the HDR toggle), accesses the chunks from the therapy session and communicates them to the MCS 109. In some implementations of the technology, the chunks may be communicated in several parts for better compatibility with the cellular network. For example, a communications network may be limited to packet sizes, such as packet sizes no greater than 120 Kb, whereas a full sleep session (a therapy session) may produce on the order of 300 Kb high-resolution data. Thus, in some implementations, the therapy device may partition the session into a plurality of chunks and aRMDDHI 3.4-002 (19) subset of those chunks may be applied to a packet for network communications, such that multiple packets, each with a plurality of chunks, may be required for transmission of the full data from the therapy session, such as after the end of the therapy session. Optionally, according to other implementations, the device may be configured to send packets of chunks, such as where each packet may include one or more chunks, at regular intervals, e.g., hourly, during a sleep session (i.e., while the device is in use). According to yet other implementations, the device may be configured to send uncompressed high-resolution data in real time, i.e. without intentional delay between acquisition of the data and transmission of the data to the MCS 109. In some implementations of the technology, periodic transmitting of data from an RPT 104 to the system, e.g., server 102, may occur at a regular interval of time (e g., not less than hourly) while the respiratory therapy system is in use. In other implementations of the technology, periodic transmitting occurs when a user (a) removes the respiratory patient interface or (b) deactivates the flow generator.

[0065] Thus, the RPT 104 may be configured or programmed with different transmission triggers for determining when to post the data to the server system. For example, the transmission trigger may indicate an on-demand or periodic, etc., transmission. As previously noted, in one example implementation, the trigger may indicate mask off event(s), e.g., each time a respiratory mask is taken off (no longer worn by user). However, other triggers may include transmission on powerup. Another may be a transmission upon detection of a particular event such as a therapy event, e.g., when an apena or other SDB event is detected, such as when CSR (Cheyne stokes respiration) is detected, or when some other disease state or event is detected, etc. Another trigger may be a network dependent trigger, such as, for example, a cellular or network window - e.g., during off-peak or peak usage times etc. Moreover, such transmission triggers may be remotely settable, such as by a server of the system. Furthermore, the server may be configured to change a transmission trigger depending on insights the server makes from reviewing data about the patient or device.

[0066] FIG. 2 illustrates some example processes that the server(s) 102 may implement in communicating one or more commands for the aforementioned high-resolution data processing such as for turning on and off the high-resolution data feed on a therapy device 104 in response to user actuation of an HDR control element (e.g., a toggle or a set of radio buttons) in one or more user interface that may be provided by the system 100. FIGs. 5A and 5B show example HDR controls 800, which may be part of a user interface 107, which provides a selection (e.g., three-button) elementRMDDHI 3.4-002 (19)802 for selecting whether HDR states will be enabled for all, some, or none of the patients associated with an organization. Optionally, other controls may also be provided (not shown) for enabling such HDR functions on a particular therapy device. For example, such a control 803 may be a selection element 802 for selecting (e.g., a toggle) whether HDR state will be enabled for a particular patient device as illustrated in FIG. 5B, which may be on a user interface 107 or may be generated on a display of the therapy device for directly changing the state in the therapy device. The interface 107 is configured to communicate, for storing an organizational HDR state, such as with ECO database 208. A patient service module 210 can look up the organizational HDR state in order to determine a status of the HDR state, such as for determining whether to command setting of a therapy device HDR state such as for therapy devices of the organization. According to some implementations of the technology, the ECO database 208 may be a database that stores data associated with the respiratory therapy devices, and the data associated with at least one of the respiratory therapy devices includes a high-data-rate (HDR) state of that respiratory therapy device. In some implementations of the technology, there are no per-device HDR elements in the user interface 114. Instead, the organizational HDR toggle in the internal interface 106 sets the state of HDR for all devices that are associated with an organization in the ECO database 208.

[0067] Referring again to FIG. 2, the therapy device 104 may be connected in communication with the server(s) 102 such as via a messaging service(s) 202 / 204 that may provide a message queuing or other communications functionality. This functionality may be for enabling communications between the server(s) 102 and therapy devices 104 such as for receiving data feed from the therapy device to the server(s) and for sending command(s) from the server(s) 102 to the therapy device(s) 104. Such a command may be received by the therapy device so that the therapy device may store settings 205 on the therapy device for controlling its data transmission operations (e.g., whether the device prepares and sends high resolution data at certain times or not) according to its HDR state or the organizational HDR state.

[0068] For example, the machine data server (MDS) 110 may access message service 202 and listen for messages from a therapy device. Such messages may be related to a data communication from the therapy device. In response, a handler service functionality such as of the MDS service 110 may determine whether the therapy device involved in the message is enabled for high-resolution data operations / communications, such as by accessing a database (e.g., Mongo) of the system at (13)RMDDHI 3.4-002 (19) that is used by the system to store the HDR state of therapy devices of the system. Such a data access may be taken to inform the handler service 206 that a data transfer associated with the message will require high-resolution communication functionalities of the MCS 108 (e.g., chunk handling and / or chunk validation) when the HDR state is enabled. Such communications may then be conducted as previously described in relation to the services of FIG. 1. Otherwise, if not, the data from the therapy device may be low resolution communications such that the MCS 108 is not required. In such an event, data from the therapy device may be applied to low resolution data structure(s) of a database(s) accessible to the MDS service by communication of the data from the therapy device to the MDS 110 service (shown in FIG. 2 at service 210.) Furthermore, the handler service 206, may access a database 208 of the system, such as via the MDS service 210, to determine if high-resolution functionality should be enabled (such as if not enabled) for further communications with the therapy device such as due to its organizational association with a plurality of therapy devices. If so, the handler service 206 may respond to the therapy device, such as via the messaging service(s) 202 / 204, with the aforementioned command to set the HDR state on the therapy device as previously described in relation to FIG. 1. Once set, the HDR state of the therapy device may also be stored by the handler service in a database (e.g., shown as Mongo in FIG. 2.) Moreover, once the therapy device RPT receives a command for setting its HDR state set to On, the therapy device will repeatedly take high- resolution data in an internal buffer during a defined period of time (e.g., during a therapy session with the therapy device), then compress the high-resolution data into chunks of data, thereby producing a sequence of discrete data chunks with compressed data. In some implementations of the technology, a therapy device (e.g., RPT) transmits compressed data chunks in a series of packets, each of which satisfies a cellular network’s upper limit on packet size. For example, each packet may be limited to no more than 120 Kb in size.

[0069] In some implementations, one or services of the system may implement data controls to prevent data flooding due to an excessive onslaught of high-resolution data such as in relation to messages of a queue of the messaging service 202 / 204. For example, a circuit breaker or message limit function may be implemented such as by any one or more of device handler service 206, MCS service 110 and / or the services 202 / 204, so that the system (e.g., MCS) does not get overburdened with too many message requests for communication of high-resolution data. If a limit is reached, the requests may be dropped, such as into a further queue to be processed at a later time.RMDDHI 3.4-002 (19)

[0070] FIG. 3 shows a streaming architecture 500 that may be implemented by the services of the system, such as with the MDS service and MCS service, including a streaming data service, such as to manage the chunking of the high-resolution data by the one or more servers (shown in FIG. 1). Thus, the architecture 500 may utilize a streaming service 502 to stream and process high-resolution data obtained in compressed chunks from devices 104. Thus, the MCS 109 may be part of a processing architecture with the MDS service 108, where streams of chunks are communicated and restored to a high-resolution data structure using a streaming data service. A streaming service (e.g., an application programming interface or API) for receiving, from the MCS service, chunks in window batches for processing, by which the chunks may be orderly decompressed, joined and recompressed before passing back for forming a different data structure by the MDS service. The newly compressed data structure may be applied to multiple databases such by the streaming data service sending the converted data to a first database and to the MDS service, which in turn may send the data to an additional database.

[0071] As previously mentioned, once high-resolution data is produced into a high-resolution data store (e.g., one or more databases) for such therapy devices, the data may be accessible to other devices, such one or more servers of the system or client devices that may access the system. For example, the system may communicate the high-resolution data from the database(s) to one or more client devices for clinical review of the high-resolution data such as in one or more user interface(s) or graphic user interface(s) of a client device. For example, a user interface generated by service of the system may be used for accessing a range of days of data for a given patient or therapy device or to fetch a specific session of high-resolution data signals as compressed file(s).

[0072] FIG. 4 shows an architecture for producing a graphic user interface 114 with high resolution data that may be implemented by the server(s) 102 of the system. Such functionality may be provided by the MDS service or the activation service or other database access service of the system. The user interface 114, 714, 814 may be presented on a graphical display such as by receiving request from a service (e.g., an API). The service and / or user interface may be configured to display the whole of a therapy session of the high-resolution therapy data and to selectively display subsections of such data. Such a service or user interface may produce or include visual component sections for displaying the high-resolution data (and / or summaries of the data) and may provide down-sampling functionality for efficiently displaying the data in various different visual component sections of the user interfaceRMDDHI 3.4-002 (19) so that the various sections may display different resolutions of the high-resolution data according to different user selections on the user interface. The service and / or user interface can further provide information on the graphic user interface about the therapy device and / or the therapy session such as the detected events (e.g., sleep disordered breathing events or AHI etc.)

[0073] Generating such a display may involve a data charting tool that acquires the received high resolution data and generates chart display elements or components that display the data as time series such as for each of a plurality of different signals or portions thereof. As part of the display element generation, the data charting tool may generate zoomed in and zoomed out views of all or selected portions, such as by down-sampling, of the high-resolution data. The graphic user interface 114 may then present the chart display elements in response to user selections of data type, time window, etc., which may be made by selection elements on the graphic user interface, which may be visual elements in the chart components / sections.

[0074] Generation such a display may also involve an event detection tool. Such a tool may optionally implement a machine learning model that has undergone supervised training, such as from high-resolution data of a population patients, to detect data trends that correspond to specified respiratory or other therapy related events (e.g., leak, apnea (central or obstructive), Cheyne-stokes respiration (CSR), as shown in FIGs. 6-8. In some implementations, the detection tool may mark the high-resolution data with one or more visual markers of such events such as by the bands or vertical lines, which may be color coded according to event type, on the time series data in a viewing section of a chart or in proximity to such a chart. (See, e.g., Figs. 7 and 8). Optionally, such a learning model may be any of a neural network, multilayer perceptron network, recurrent neural network, deep belief network, support vector machine, random forest, or decision tree. The event detection tool may then generate visual data with the interface 114 in relation to detected event. Other information regarding the patient, such as machine setting may also be displayed in the interface, and may be determined with a lookup tool which accesses a database(s) of the system.

[0075] FIG. 4 illustrates modules with processes for generating such a user interface. The modules, such as with processing instructions for an application(s) of a processor on a client device, may include a high-resolution charting library 402, a frontend 404 for communicating with the high- resolution database, and a compression library 406. The charting library 402 may include chart component 408 code for displaying data in any of the aforementioned charts, a data filtering serviceRMDDHI 3.4-002 (19)410, and a data processing web worker 412. The frontend 404 may include display components 414 and a data service 416.

[0076] With regard to the example of FIG. 4, in operation of the data charting tool, the data service 416 retrieves compressed raw signal, such a via network communications, from a service of the system (e.g., breath by breath gateway 418 to a high-resolution data store). The raw signal may be stored in a compressed data file format or other data structure such as an EDF data format. The compression library 406 implements a parsing module to decompress the data that the data service 416 retrieved. The data service 416 then passes the decompressed raw signal to the data filtering service 410, which hands off the signal to the data processing web worker 412, which may be in any suitable data structure or typed format. The web worker 412 processes the raw signal based on its sampling frequency and optionally a desired zoom level (which may be selected by the data filtering service in accordance with a user selection component of the user interface). The data filtering service accepts the processed data from the web worker and delivers to the chart component 408 a chunk of the data that matches a user-selected chart’s domain (e.g., a sub-section of a signal and / or desired zoom thereof). The chart component 408 then renders the chart display elements according to the data provided from the filtering service. The display components 414 render additional user interface elements (e.g., buttons, dropdowns, event markers) around the chart display elements. Since the graphic user interface with the data responds to user selections, such processing of the zoom level and / or sub-section selection may be iterative.

[0077] FIG. 6A and 7 show examples of a summary view 600 that may be presented by the graphic user interface 114, 714. The summary view 600 may be selectively activated by user input to display for a user Total usage, Used days >= 4 hrs, Used days < 4 hrs, Days not used, Median daily usage, Average daily usage, Leak rate, Pressure, Apnea index, Hypopnea index, and AHI. The user can select a 7 days, 30 days, or custom window of time for the summary.

[0078] FIG. 6B and 8 shows example of a nightly data view 700 that may be presented by the interface 114, 814. The nightly data view 700 informs a user of Usage, Leak, AHI, CSR, Flow, Pressure, and SpCh for a user-selected sleep session. Events display can be toggled on or off. When events are displayed, they are highlighted and annotated by type (e.g., Leak, Apnea). As illustrated in FIG. 8, the user interface may be activated by a user to select viewing of a particular signal from a plurality of high-resolution data signals (e.g., flow, leak and pressure as shown in FIG. 8.) as shownRMDDHI 3.4-002 (19) in Fig. 8, “flow” is selected and a chart component at view 889 shows the selected signal. The view 889 may be configured with user selectable delimiter elements 888 to permit user selection of a subset of data of the time series of the signal of the high-resolution data, such as when displayed in a down sampled format in view 889, for selection of a sub-set of the data. Such selection with the delimiter elements 888 then activates rendering of another high-resolution view 890 of the sub-set of the data signal so that that the user interface can show the samples of the selected signal (e g., flow leak or pressure) as a high-resolution signal in another view.

[0079] FIG. 6C shows a device settings panel 900 that may be presented by the external interface 114. The display 900 informs a user of Device type, Therapy mode, EPR, EPR level, EPR enable, EPR patient enable, Ramp enable, Ramp time, Essentials, Response, Min pressure, Max pressure settings for a given device.1 RPT DEVICE

[0080] In one form, each therapy device of the system may be an RPT device for treating a respiratory disorder, such as a positive airway pressure therapy device or a high flow therapy device. Referring to FIGS. 9A-9C, the RPT device 4000 may supply a flow of air to the patient 1000 via an air circuit 4170 and a patient interface 3000 or 3800.

[0081] The RPT device 4000 in accordance with one aspect of the present technology comprises mechanical, pneumatic, and / or electrical components and is configured to execute one or more algorithms 4300, such as any of the methods, in whole or in part, described herein. The RPT device 4000 may be configured to generate a flow of air for delivery to a patient’s airways, such as to treat one or more of the respiratory conditions described elsewhere in the present document. Such a device may provide a respiratory therapy, such a positive airway pressure therapy (e.g., CPAP, or bi-level CPAP, ventilator etc.) or high flow therapy, according to a flow control loop or pressure control loop.

[0082] In one form, the RPT device 4000 may be constructed and arranged to be capable of delivering a flow of air in a range of -20 L / min to +150 L / min while maintaining a positive pressure of at least 4 cmH20, or at least 10cmH2O, or at least 20 cmH20.

[0083] With respect to FIG. 10 A, the RPT device may have an external housing 4010, formed in two parts, an upper portion 4012 and a lower portion 4014. Furthermore, the external housing 4010 may include one or more panel(s) 4015. The RPT device 4000 comprises a chassis 4016 that supportsRMDDHI 3.4-002 (19) one or more internal components of the RPT device 4000. The RPT device 4000 may include a handle 4018.

[0084] The pneumatic path of the RPT device 4000 may comprise one or more air path items, e.g., an inlet air filter 4112, an inlet muffler 4122, a pressure generator 4140 capable of supplying air at positive pressure (e.g., a blower 4142), an outlet muffler 4124 and one or more transducers 4270, such as pressure sensors 4272 and flow rate sensors 4274.

[0085] One or more of the air path items may be located within a removable unitary structure which will be referred to as a pneumatic block 4020. The pneumatic block 4020 may be located within the external housing 4010. In one form a pneumatic block 4020 is supported by, or formed as part of the chassis 4016.

[0086] As shown in FIG. 10C, the RPT device 4000 may have an electrical power supply 4210, one or more input devices 4220, a central controller 4230, a therapy device controller 4240, a pressure generator 4140, one or more protection circuits 4250, memory 4260, transducers 4270, data communication interface 4280 and one or more output devices 4290. Electrical components 4200 may be mounted on a single Printed Circuit Board Assembly (PCBA) 4202. In an alternative form, the RPT device 4000 may include more than one PCBA 4202.2 RPT device mechanical & pneumatic components

[0087] An RPT device may comprise one or more of the following components in an integral unit. In an alternative form, one or more of the following components may be located as respective separate units.3 Air filter (s)

[0088] An RPT device in accordance with one form of the present technology may include an air filter 4110, or a plurality of air filters 4110.

[0089] In one form illustrated in FIG. 10B, an inlet air filter 4112 is located at the beginning of the pneumatic path upstream of a pressure generator 4140.

[0090] In one form illustrated in FIG. 10B, an outlet air filter 4114, for example an antibacterial filter, is located between an outlet of the pneumatic block 4020 and a patient interface 3000 or 3800.4 Muffler(s)

[0091] An RPT device in accordance with one form of the present technology may include a muffler 4120, or a plurality of mufflers 4120.RMDDHI 3.4-002 (19)

[0092] In one form of the present technology (see e.g., FIG. 10B), an inlet muffler 4122 is located in the pneumatic path upstream of a pressure generator 4140.

[0093] In one form of the present technology, an outlet muffler 4124 is located in the pneumatic path between the pressure generator 4140 and a patient interface 3000 or 3800.5 Pressure generator

[0094] In one form of the present technology, a pressure generator 4140 for producing a flow, or a supply, of air at positive pressure is a controllable blower 4142. For example, the blower 4142 may include a brushless DC motor 4144 with one or more impellers. The impellers may be located in a volute. The blower may be capable of delivering a supply of air, for example at a rate of up to about 120 litres / minute, at a positive pressure in a range from about 4 cmH20 to about 20 cmH20, or in other forms up to about 30 cmH20 when delivering;respiratory pressure therapy. The blower may be as described in any one of the following patents or patent applications the contents of which are incorporated herein by reference in their entirety: U.S. Patent No. 7,866,944; U.S. Patent No. 8,638,014; U.S. Patent No. 8,636,479; and PCT Patent Application Publication No. WO 2013 / 020167.

[0095] The pressure generator 4140 may be under the control of the therapy device controller 4240.

[0096] In other forms, a pressure generator 4140 may be a piston-driven pump, a pressure regulator connected to a high pressure source (e.g. compressed air reservoir), or a bellows.6 Transducer(s)

[0097] Transducers may be internal of the RPT device, or external of the RPT device. External transducers may be located for example on or form part of the air circuit, e.g., the patient interface. External transducers may be in the form of non-contact sensors such as a Doppler radar movement sensor that transmit or transfer data to the RPT device.

[0098] In one form of the present technology (see e.g., FIG. 10B), one or more transducers 4270 are located upstream and / or downstream of the pressure generator 4140. The one or more transducers 4270 may be constructed and arranged to generate signals representing properties of the flow of air such as a flow rate, a pressure or a temperature at that point in the pneumatic path.

[0099] In one form of the present technology, one or more transducers 4270 may be located proximate to the patient interface 3000 or 3800.RMDDHI 3.4-002 (19)

[0100] In one form, a signal from a transducer 4270 may be filtered, such as by low -pass, high- pass or band-pass filtering.7 Flow rate sensor

[0101] A flow rate sensor 4274 in accordance with the present technology may be based on a differential pressure transducer, for example, an SDP600 Series differential pressure transducer from SENSIRION.

[0102] In one form, a signal generated by the flow rate sensor 4274 and representing a flow rate is received by the central controller 4230.8 Pressure sensor

[0103] A pressure sensor 4272 in accordance with the present technology is located in fluid communication with the pneumatic path. An example of a suitable pressure sensor is a transducer from the HONEYWELL ASDX series. An alternative suitable pressure sensor is a transducer from the NPA Series from GENERAL ELECTRIC

[0104] In one form, a signal generated by the pressure sensor 4272 and representing a pressure is received by the central controller 4230.9 Motor speed transducer

[0105] In one form of the present technology a motor speed transducer 4276 is used to determine a rotational velocity of the motor 4144 and / or the blower 4142. A motor speed signal from the motor speed transducer 4276 may be provided to the therapy device controller 4240. The motor speed transducer 4276 may, for example, be a speed sensor, such as a Hall effect sensor.10 Anti-spill back valve

[0106] As shown in FIG. 10B, one form of the present technology, an anti-spill back valve 4160 is located between the humidifier 5000 and the pneumatic block 4020. The anti-spill back valve is constructed and arranged to reduce the risk that water will flow upstream from the humidifier 5000, for example to the motor 4144.11 RPT device electrical components12 Power supply

[0107] A power supply 4210 may be located internal or external of the external housing 4010 of the RPT device 4000.RMDDHI 3.4-002 (19)

[0108] In one form of the present technology, power supply 4210 provides electrical power to the RPT device 4000 only. In another form of the present technology, power supply 4210 provides electrical power to both RPT device 4000 and humidifier 5000.13 Input devices

[0109] In one form of the present technology, an RPT device 4000 includes one or more input devices 4220 in the form of buttons, switches or dials to allow a person to interact with the device. The buttons, switches or dials may be physical devices, or software devices accessible via a touch screen. The buttons, switches or dials may, in one form, be physically connected to the external housing 4010, or may, in another form, be in wireless communication with a receiver that is in electrical connection to the central controller 4230.

[0110] In one form, the input device 4220 may be constructed and arranged to allow a person to select a value and / or a menu option.14 Central controller

[0111] In one form of the present technology, the central controller 4230 is one or a plurality of processors suitable to control an RPT device 4000. The central controller 4230 is show in FIG. 10C.

[0112] Suitable processors may include an x86 INTEL processor, a processor based on ARM® Cortex®-M processor from ARM Holdings such as an STM32 series microcontroller from ST MICROELECTRONIC. In certain alternative forms of the present technology, a 32-bit RISC CPU, such as an STR9 series microcontroller from ST MICROELECTRONICS or a 16-bit RISC CPU such as a processor from the MSP430 family of microcontrollers, manufactured by TEXAS INSTRUMENTS may also be suitable.

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

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

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

[0116] The central controller 4230 may be configured to provide output signal(s) to one or more of an output device 4290, a pressure generator 4140, a therapy device controller 4240, a data communication interface 4280, and / or the humidifier 5000.RMDDHI 3.4-002 (19)

[0117] In some forms of the present technology, the central controller 4230 is configured to implement the one or more methodologies described herein, such as the one or more algorithms 4300 which may be implemented with processor-control instructions, expressed as computer programs stored in a non-transitory computer readable storage medium, such as memory 4260. In some forms of the present technology, the central controller 4230 may be integrated with an RPT device 4000. However, in some forms of the present technology, some methodologies may be performed by a remotely located device. For example, the remotely located device may determine control settings for a ventilator or detect respiratory related events by analysis of stored data such as from any of the sensors described herein.15 Clock

[0118] The RPT device 4000 may include a clock 4232 that is connected to the central controller 4230.16 Therapy device controller

[0119] Referring to FIG. 10D, in one form of the present technology, therapy device controller 4240 is a therapy control module 4330 that forms part of the algorithms 4300 executed by the central controller 4230.

[0120] In one form of the present technology, therapy device controller 4240 is a dedicated motor control integrated circuit. For example, in one form a MC33035 brushless DC motor controller, manufactured by ONSEMI is used.17 Protection circuits

[0121] The one or more protection circuits 4250 in accordance with the present technology may comprise an electrical protection circuit, a temperature and / or pressure safety circuit.18 Memory

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

[0123] Memory 4260 may be located on the PCBA 4202. Memory 4260 may be in the form of EEPROM, or NAND flash.

[0124] Additionally, or alternatively, RPT device 4000 includes a removable form of memory 4260, for example a memory card made in accordance with the Secure Digital (SD) standard.RMDDHI 3.4-002 (19)

[0125] In one form of the present technology, the memory 4260 acts as a non-transitory computer readable storage medium on which is stored computer program instructions expressing the one or more methodologies described herein, such as the one or more algorithms 4300.19 Data communication systems

[0126] In one form of the present technology, a data communication interface 4280 is provided, and is connected to the central controller 4230 (see e.g., FIG. 10C). 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.

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

[0128] In one form, remote external communication network 4282 is the Internet. The data communication interface 4280 may use wired communication (e.g., via Ethernet, or optical fibre) or a wireless protocol (e.g., CDMA, GSM, LTE) to connect to the Internet.

[0129] In one form, local external communication network 4284 utilises one or more communication standards, such as Bluetooth, or a consumer infrared protocol.

[0130] In one form, remote external device 4286 is one or more computers, for example a cluster of networked computers. In one form, remote external device 4286 may be virtual computers, rather than physical computers. In either case, such a remote external device 4286 may be accessible to an appropriately authorised person such as a clinician.

[0131] The local external device 4288 may be a personal computer, mobile phone, tablet or remote control.20 Output devices including optional display, alarms

[0132] An output device 4290 in accordance with the present technology may take the form of one or more of a visual, audio and haptic unit. A visual display may be a Liquid Crystal Display (LCD) or Light Emitting Diode (LED) display.RMDDHI 3.4-002 (19)21 Display driver

[0133] A display driver 4292 receives as an input the characters, symbols, or images intended for display on the display 4294, and converts them to commands that cause the display 4294 to display those characters, symbols, or images.22 Display

[0134] A 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 eight-segment display, in which case the display driver 4292 converts each character or symbol, such as the figure “0”, to eight logical signals indicating whether the eight respective segments are to be activated to display a particular character or symbol.23 RPT device algorithms

[0135] As mentioned above, in some forms of the present technology, the central controller 4230 may be configured to implement one or more algorithms 4300 expressed as computer programs stored in a non-transitory computer readable storage medium, such as memory 4260. The algorithms 4300 are generally grouped into groups referred to as modules.

[0136] In other forms of the present technology, some portion or all of the algorithms 4300 may be implemented by a controller of an external device such as the local external device 4288 or the remote external device 4286. In such forms, data representing the input signals and / or intermediate algorithm outputs necessary for the portion of the algorithms 4300 to be executed at the external device may be communicated to the external device via the local external communication network 4284 or the remote external communication network 4282. In such forms, the portion of the algorithms 4300 to be executed at the external device may be expressed as computer programs, such as with processor control instructions to be executed by one or more processor(s), stored in a non- transitory computer readable storage medium accessible to the controller of the external device. Such programs configure the controller of the external device to execute the portion of the algorithms 4300.

[0137] In such forms, the therapy parameters generated by the external device via the therapy engine module 4320 (if such forms part of the portion of the algorithms 4300 executed by the external device) may be communicated to the central controller 4230 to be passed to the therapy control module 4330.RMDDHI 3.4-002 (19)24 Pre-processing module

[0138] A pre-processing module 4310 in accordance with one form of the present technology receives as an input a signal from a transducer 4270, for example a flow rate sensor 4274 or pressure sensor 4272, and performs one or more process steps to calculate one or more output values that will be used as an input to another module, for example a therapy engine module 4320.

[0139] In one form of the present technology, the output values include the interface pressure Pm, the vent flow rate Qv, the respiratory flow rate Qr, and the leak flow rate QI.

[0140] In various forms of the present technology, the pre-processing module 4310 comprises one or more of the following algorithms: interface pressure estimation 4312, vent flow rate estimation 4314, leak flow rate estimation 4316, and respiratory flow rate estimation 4318.25 Interface pressure estimation

[0141] In one form of the present technology, an interface pressure estimation algorithm 4312 receives as inputs a signal from the pressure sensor 4272 indicative of the pressure in the pneumatic path proximal to an outlet of the pneumatic block (the device pressure Pd) and a signal from the flow rate sensor 4274 representative of the flow rate of the airflow leaving the RPT device 4000 (the device flow rate Qd). The device flow rate Qd, absent any supplementary gas 4180, may be used as the total flow rate Qt. The interface pressure algorithm 4312 estimates the pressure drop AP through the air circuit 4170. The dependence of the pressure drop AP on the total flow rate Qt may be modelled for the particular air circuit 4170 by a pressure drop characteristic AP(Q). The interface pressure estimation algorithm, 4312 then provides as an output an estimated pressure, Pm, in the patient interface 3000 or 3800. The pressure, Pm, in the patient interface 3000 or 3800 may be estimated as the device pressure Pd minus the air circuit pressure drop AP.26 Vent flow rate estimation

[0142] In one form of the present technology, a vent flow rate estimation algorithm 4314 receives as an input an estimated pressure, Pm, in the patient interface 3000 or 3800 from the interface pressure estimation algorithm 4312 and estimates a vent flow rate of air, Qv, from a vent 3400 in a patient interface 3000 or 3800. The dependence of the vent flow rate Qv on the interface pressure Pm for the particular vent 3400 in use may be modelled by a vent characteristic Qv(Pm).RMDDHI 3.4-002 (19)27 Leak flow rate estimation

[0143] In one form of the present technology, a leak flow rate estimation algorithm 4316 receives as an input a total flow rate, Qt, and a vent flow rate Qv, and provides as an output an estimate of the leak flow rate QI. In one form, the leak flow rate estimation algorithm estimates the leak flow rate QI by calculating an average of the difference between total flow rate Qt and vent flow rate Qv over a period sufficiently long to include several breathing cycles, e.g. about 10 seconds.

[0144] In one form, the leak flow rate estimation algorithm 4316 receives as an input a total flow rate Qt, a vent flow rate Qv, and an estimated pressure, Pm, in the patient interface 3000 or 3800, and provides as an output a leak flow rate QI, by calculating a leak conductance, and determining a leak flow rate QI to be a function of leak conductance and pressure, Pm. Leak conductance is calculated as the quotient of low pass filtered non-vent flow rate equal to the difference between total flow rate Qt and vent flow rate Qv, and low pass filtered square root of pressure Pm, where the low pass filter time constant has a value sufficiently long to include several breathing cycles, e.g. about 10 seconds. The leak flow rate QI may be estimated as the product of leak conductance and a function of pressure, Pm.28 Respiratory flow rate estimation

[0145] In one form of the present technology, a respiratory flow rate estimation algorithm 4318 receives as an input a total flow rate, Qt, a vent flow rate, Qv, and a leak flow rate, QI, and estimates a respiratory flow rate of air, Qr, to the patient, by subtracting the vent flow rate Qv and the leak flow rate QI from the total flow rate Qt.29 Therapy Engine Module

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

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

[0148] In one form of the present technology, therapy parameters are one or more of an amplitude of a pressure variation, a base pressure, and a target ventilation.

[0149] In various forms, the therapy engine module 4320 comprises one or more of the following algorithms: phase determination 4321, waveform determination 4322, ventilation determination 4323, inspiratory flow limitation determination 4324, apnea / hypopnea determination 4325, snoreRMDDHI 3.4-002 (19) determination 4326, airway patency determination 4327, target ventilation determination 4328, and therapy parameter determination 4329.30 Phase determination

[0150] In one form of the present technology, the RPT device 4000 does not determine phase.

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

[0152] In some forms, known as discrete phase determination, the phase output > is a discrete variable. One implementation of discrete phase determination provides a bi-valued phase output > with values of either inhalation or exhalation, for example represented as values of 0 and 0.5 revolutions respectively, upon detecting the start of spontaneous inhalation and exhalation respectively. RPT devices 4000 that “trigger” and “cycle” effectively perform discrete phase determination, since the trigger and cycle points are the instants at which the phase changes from exhalation to inhalation and from inhalation to exhalation, respectively. In one implementation of bivalued phase determination, the phase output cp is determined to have a discrete value of 0 (thereby “triggering” the RPT device 4000) when the respiratory flow rate Qr has a value that exceeds a positive threshold, and a discrete value of 0.5 revolutions (thereby “cycling” the RPT device 4000) when a respiratory flow rate Qr has a value that is more negative than a negative threshold. The inhalation time Ti and the exhalation time Te may be estimated as typical values over many respiratory cycles of the time spent with phase cp equal to 0 (indicating inspiration) and 0.5 (indicating expiration) respectively.

[0153] Another implementation of discrete phase determination provides a tri-valued phase output cp with a value of one of inhalation, mid-inspiratory pause, and exhalation.

[0154] In other forms, known as continuous phase determination, the phase output cp is a continuous variable, for example varying from 0 to 1 revolutions, or 0 to 211 radians. RPT devices 4000 that perform continuous phase determination may trigger and cycle when the continuous phase reaches 0 and 0.5 revolutions, respectively. In one implementation of continuous phase determination, a continuous value of phase cp is determined using a fuzzy logic analysis of the respiratory flow rate Qr. A continuous value of phase determined in this implementation is oftenRMDDHI 3.4-002 (19) referred to as “fuzzy phase”. In one implementation of a fuzzy phase determination algorithm 4321, the following rules are applied to the respiratory flow rate Qr:1. If Qr is zero and increasing fast then cp is 0 revolutions.2. If Qr is large positive and steady then cp is 0.25 revolutions.3. If Qr is zero and falling fast, then (p is 0.5 revolutions.4. If Qr is large negative and steady then cp is 0.75 revolutions.5. If Qr is zero and steady and the 5-second low-pass filtered absolute value of Qr is large then cp is 0.9 revolutions.6. If Qr is positive and the phase is expiratory, then cp is 0 revolutions.7. If Qr is negative and the phase is inspiratory, then (p is 0.5 revolutions.8. If the 5-second low-pass filtered absolute value of Qr is large, cp is increasing at a steady rate equal to the patient’s breathing rate, low-pass filtered with a time constant of 20 seconds.

[0155] The output of each rule may be represented as a vector whose phase is the result of the rule and whose magnitude is the fuzzy extent to which the rule is true. The fuzzy extent to which the respiratory flow rate is “large”, “steady”, etc. is determined with suitable membership functions. The results of the rules, represented as vectors, are then combined by some function such as taking the centroid. In such a combination, the rules may be equally weighted, or differently weighted.

[0156] In another implementation of continuous phase determination, the phase cp is first discretely estimated from the respiratory flow rate Qr as described above, as are the inhalation time Ti and the exhalation time Te. The continuous phase cp at any instant may be determined as the half the proportion of the inhalation time Ti that has elapsed since the previous trigger instant, or 0.5 revolutions plus half the proportion of the exhalation time Te that has elapsed since the previous cycle instant (whichever instant was more recent).31 Waveform determination

[0157] In one form of the present technology, the therapy parameter determination algorithm 4329 provides an approximately constant treatment pressure throughout a respiratory cycle of a patient.

[0158] In other forms of the present technology, the therapy control module 4330 controls the pressure generator 4140 to provide a treatment pressure Pt that varies as a function of phase cp of a respiratory cycle of a patient according to a waveform template II ((p).RMDDHI 3.4-002 (19)

[0159] In one form of the present technology, a waveform determination algorithm 4322 provides a waveform template IT(cp) with values in the range [0, 1] on the domain of phase values cp provided by the phase determination algorithm 4321 to be used by the therapy parameter determination algorithm 4329.

[0160] In one form, suitable for either discrete or continuously-valued phase, the waveform template II((p) is a square- wave template, having a value of 1 for values of phase up to and including 0.5 revolutions, and a value of 0 for values of phase above 0.5 revolutions. In one form, suitable for continuously -valued phase, the waveform template II((p) comprises two smoothly curved portions, namely a smoothly curved (e.g. raised cosine) rise from 0 to 1 for values of phase up to 0.5 revolutions, and a smoothly curved (e.g. exponential) decay from 1 to 0 for values of phase above 0.5 revolutions. In one form, suitable for continuously-valued phase, the waveform template n(cp) is based on a square wave, but with a smooth rise from 0 to 1 for values of phase up to a “rise time” that is less than 0.5 revolutions, and a smooth fall from 1 to 0 for values of phase within a “fall time” after 0.5 revolutions, with a “fall time” that is less than 0.5 revolutions.

[0161] In some forms of the present technology, the waveform determination algorithm 4322 selects a waveform template II(q>) from a library of waveform templates, dependent on a setting of the RPT device. Each waveform template TI(q>) in the library may be provided as a lookup table of values II against phase values cp . In other forms, the waveform determination algorithm 4322 computes a waveform template IT(cp) “on the fly” using a predetermined functional form, possibly parametrised by one or more parameters (e.g. time constant of an exponentially curved portion). The parameters of the functional form may be predetermined or dependent on a current state of the patient 1000.

[0162] In some forms of the present technology, suitable for discrete bi-valued phase of either inhalation (q> = 0 revolutions) or exhalation (cp = 0.5 revolutions), the waveform determination algorithm 4322 computes a waveform template II “on the fly” as a function of both discrete phase cp and time t measured since the most recent trigger instant. In one such form, the waveform determination algorithm 4322 computes the waveform template II((p, t) in two portions (inspiratory and expiratory) as follows: o = o0 = 0.5RMDDHI 3.4-002 (19)

[0163] where ni(t) and IIe(t) are inspiratory and expiratory portions of the waveform template II((p, t). In one such form, the inspiratory portion Ili(t) of the waveform template is a smooth rise from 0 to 1 parametrised by a rise time, and the expiratory portion Ile(t) of the waveform template is a smooth fall from 1 to 0 parametrised by a fall time.32 Ventilation determination

[0164] In one form of the present technology, a ventilation determination algorithm 4323 receives an input a respiratory flow rate Qr, and determines a measure indicative of current patient ventilation, Vent.

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

[0166] In other implementations, the ventilation determination algorithm 4323 determines a measure of ventilation Vent that is broadly proportional to actual patient ventilation. One such implementation estimates peak respiratory flow rate Qpeak over the inspiratory portion of the cycle. This and many other procedures involving sampling the respiratory flow rate Qr produce measures which are broadly proportional to ventilation, provided the flow rate waveform shape does not vary very much (here, the shape of two breaths is taken to be similar when the flow rate waveforms of the breaths normalised in time and amplitude are similar). Some simple examples include the median positive respiratory flow rate, the median of the absolute value of respiratory flow rate, and the standard deviation of flow rate. Arbitrary linear combinations of arbitrary order statistics of the absolute value of respiratory flow rate using positive coefficients, and even some using both positive and negative coefficients, are approximately proportional to ventilation. Another example is the mean of the respiratory flow rate in the middle K proportion (by time) of the inspiratory portion, where 0 < K < 1. There is an arbitrarily large number of measures that are exactly proportional to ventilation if the flow rate shape is constant.33 Determination of Inspiratory Flow Limitation

[0167] In one form of the present technology, the central controller 4230 executes an inspiratory flow limitation determination algorithm 4324 for the determination of the extent of inspiratory flow limitation.RMDDHI 3.4-002 (19)

[0168] In one form, the inspiratory flow limitation determination algorithm 4324 receives as an input a respiratory flow rate signal Qr and provides as an output a metric of the extent to which the inspiratory portion of the breath exhibits inspiratory flow limitation.

[0169] In one form of the present technology, the inspiratory portion of each breath is identified by a zero-crossing detector. A number of evenly spaced points (for example, sixty-five), representing points in time, are interpolated by an interpolator along the inspiratory flow rate-time curve for each breath. The curve described by the points is then scaled by a scalar to have unity length (duration / period) and unity area to remove the effects of changing breathing rate and depth. The scaled breaths are then compared in a comparator with a pre-stored template representing a normal unobstructed breath. Breaths deviating by more than a specified threshold (typically 1 scaled unit) at any time during the inspiration from this template, such as those due to coughs, sighs, swallows and hiccups, as determined by a test element, are rejected. For non-rejected data, a moving average of the first such scaled point is calculated by the central controller 4230 for the preceding several inspiratory events. This is repeated over the same inspiratory events for the second such point, and so on. Thus, for example, sixty-five scaled data points are generated by the central controller 4230, and represent a moving average of the preceding several inspiratory events, e.g., three events. The moving average of continuously updated values of the (e.g., sixty-five) points are hereinafter called the "scaled flow rate ", designated as Qs(t). Alternatively, a single inspiratory event can be utilised rather than a moving average.

[0170] From the scaled flow rate, two shape factors relating to the determination of partial obstruction may be calculated.

[0171] Shape factor 1 is the ratio of the mean of the middle (e.g. thirty-two) scaled flow rate points to the mean overall (e.g. sixty-five) scaled flow rate points. Where this ratio is in excess of unity, the breath will be taken to be normal. Where the ratio is unity or less, the breath will be taken to be obstructed. A ratio of about 1.17 is taken as a threshold between partially obstructed and unobstructed breathing, and equates to a degree of obstruction that would permit maintenance of adequate oxygenation in a typical patient.

[0172] Shape factor 2 is calculated as the RMS deviation from unit scaled flow rate, taken over the middle (e.g. thirty -two) points. An RMS deviation of about 0.2 units is taken to be normal. AnRMDDHI 3.4-002 (19)RMS deviation of zero is taken to be a totally flow-limited breath. The closer the RMS deviation to zero, the breath will be taken to be more flow limited.

[0173] Shape factors 1 and 2 may be used as alternatives, or in combination. In other forms of the present technology, the number of sampled points, breaths and middle points may differ from those described above. Furthermore, the threshold values can be other than those described.34 Determination of apneas and hypopneas

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

[0175] In one form, the apnea / hypopnea determination algorithm 4325 receives as an input a respiratory flow rate signal Qr and provides as an output a flag that indicates that an apnea or a hypopnea has been detected.

[0176] In one form, an apnea will be said to have been detected when a function of respiratory flow rate Qr falls below a flow rate threshold for a predetermined period of time. The function may determine a peak flow rate, a relatively short-term mean flow rate, or a flow rate intermediate of relatively short-term mean and peak flow rate, for example an RMS flow rate. The flow rate threshold may be a relatively long-term measure of flow rate.

[0177] In one form, a hypopnea will be said to have been detected when a function of respiratory flow rate Qr falls below a second flow rate threshold for a predetermined period of time. The function may determine a peak flow, a relatively short-term mean flow rate, or a flow rate intermediate of relatively short-term mean and peak flow rate, for example an RMS flow rate. The second flow rate threshold may be a relatively long-term measure of flow rate. The second flow rate threshold is greater than the flow rate threshold used to detect apneas.35 Determination of snore

[0178] In one form of the present technology, the central controller 4230 executes one or more snore determination algorithms 4326 for the determination of the extent of snore.

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

[0180] The snore determination algorithm 4326 may comprise the step of determining the intensity of the flow rate signal in the range of 30-300 Hz. Further, the snore determination algorithmRMDDHI 3.4-002 (19)4326 may comprise a step of filtering the respiratory flow rate signal Qr to reduce background noise, e.g., the sound of airflow in the system from the blower.36 Determination of airway patency

[0181] In one form of the present technology, the central controller 4230 executes one or more airway patency determination algorithms 4327 for the determination of the extent of airway patency.

[0182] In one form, the airway patency determination algorithm 4327 receives as an input a respiratory flow rate signal Qr, and determines the power of the signal in the frequency range of about 0.75 Hz and about 3 Hz. The presence of a peak in this frequency range is taken to indicate an open airway. The absence of a peak is taken to be an indication of a closed airway.

[0183] In one form, the frequency range within which the peak is sought is the frequency of a small forced oscillation in the treatment pressure Pt. In one implementation, the forced oscillation is of frequency 2 Hz with amplitude about 1 cmH20.

[0184] In one form, airway patency determination algorithm 4327 receives as an input a respiratory flow rate signal Qr, and determines the presence or absence of a cardiogenic signal. The absence of a cardiogenic signal is taken to be an indication of a closed airway.37 Determination of target ventilation

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

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

[0187] In other forms of the present technology, such as adaptive servo-ventilation (ASV), the target ventilation determination algorithm 4328 computes a target value Vtgt from a value Vtyp indicative of the typical recent ventilation of the patient.

[0188] In some forms of adaptive servo-ventilation, the target ventilation Vtgt is computed as a high proportion of, but less than, the typical recent ventilation Vtyp. The high proportion in such forms may be in the range (80%, 100%), or (85%, 95%), or (87%, 92%).

[0189] In other forms of adaptive servo-ventilation, the target ventilation Vtgt is computed as a slightly greater than unity multiple of the typical recent ventilation Vtyp.RMDDHI 3.4-002 (19)

[0190] The typical recent ventilation Vtyp is the value around which the distribution of the measure of current ventilation Vent over multiple time instants over some predetermined timescale tends to cluster, that is, a measure of the central tendency of the measure of current ventilation over recent history. In one implementation of the target ventilation determination algorithm 4328, the recent history is of the order of several minutes, but in any case should be longer than the timescale of Cheyne-Stokes waxing and waning cycles. The target ventilation determination algorithm 4328 may use any of the variety of well-known measures of central tendency to determine the typical recent ventilation Vtyp from the measure of current ventilation, Vent. One such measure is the output of a low-pass filter on the measure of current ventilation Vent, with time constant equal to one hundred seconds.38 Determination of therapy parameters

[0191] In some forms of the present technology, the central controller 4230 executes one or more therapy parameter determination algorithms 4329 for the determination of one or more therapy parameters using the values returned by one or more of the other algorithms in the therapy engine module 4320.

[0192] In one form of the present technology, the therapy parameter is an instantaneous treatment pressure Pt. In one implementation of this form, the therapy parameter determination algorithm 4329 determines the treatment pressure Pt using the equation ft = / tn(®. / )+7>0 ( 1 )[0193| where:• A is the amplitude,• II((p,t) is the waveform template value (in the range 0 to 1) at the current value (p of phase and t of time, and• P0 is a base pressure.

[0194] If the waveform determination algorithm 4322 provides the waveform template IT( ) ,t) as a lookup table of values II indexed by phase cp the therapy parameter determination algorithm 4329 applies equation (1) by locating the nearest lookup table entry to the current value (p of phase returned by the phase determination algorithm 4321, or by interpolation between the two entries straddling the current value cp of phase.RMDDHI 3.4-002 (19)

[0195] The values of the amplitude A and the base pressure P0 may be set by the therapy parameter determination algorithm 4329 depending on the chosen respiratory pressure therapy mode in the manner described below.39 Therapy Control module

[0196] The therapy control module 4330 in accordance with one aspect of the present technology receives as inputs the therapy parameters from the therapy parameter determination algorithm 4329 of the therapy engine module 4320, and controls the pressure generator 4140 to deliver a flow of air in accordance with the therapy parameters.

[0197] In one form of the present technology, the therapy parameter is a treatment pressure Pt, and the therapy control module 4330 controls the pressure generator 4140 to deliver a flow of air whose interface pressure Pm at the patient interface 3000 or 3800 is equal to the treatment pressure Pt.40 Detection of fault conditions

[0198] In one form of the present technology, the central controller 4230 executes one or more methods 4340 for the detection of fault conditions. The fault conditions detected by the one or more methods 4340 may include at least one of the following:• Power failure (no power, or insufficient power)• Transducer fault detection• Failure to detect the presence of a component• Operating parameters outside recommended ranges (e.g., pressure, flow rate, temperature, PaO2)• Failure of a test alarm to generate a detectable alarm signal.

[0199] Upon detection of the fault condition, the corresponding algorithm 4340 signals the presence of the fault by one or more of the following:• Initiation of an audible, visual & / or kinetic (e.g., vibrating) alarm• Sending a message to an external device• Logging of the incidentRMDDHI 3.4-002 (19)41 AIR CIRCUIT

[0200] An air circuit 4170 in accordance with an aspect of the present technology is a conduit or a tube constructed and arranged to allow, in use, a flow of air to travel between two components such as RPT device 4000 and the patient interface 3000 or 3800.

[0201] In particular, the air circuit 4170 may be in fluid connection with the outlet of the pneumatic block 4020 and the patient interface. The air circuit may be referred to as an air delivery tube. In some cases, there may be separate limbs of the circuit for inhalation and exhalation. In other cases, a single limb is used.

[0202] In some forms, the air circuit 4170 may comprise one or more heating elements configured to heat air in the air circuit, for example to maintain or raise the temperature of the air. The heating element may be in a form of a heated wire circuit, and may comprise one or more transducers, such as temperature sensors. In one form, the heated wire circuit may be helically wound around the axis of the air circuit 4170. The heating element may be in communication with a controller such as a central controller 4230. One example of an air circuit 4170 comprising a heated wire circuit is described in United States Patent 8,733,349, which is incorporated herewithin in its entirety by reference.42 RESPIRATORY THERAPY MODES

[0203] Various respiratory therapy modes may be implemented by the disclosed respiratory therapy system, including but not limited to, CPAP therapy, bi-level therapy and high flow therapy, among other possibilities.43 GLOSSARY

[0204] For the purposes of the present technology disclosure, in certain forms of the present technology, one or more of the following definitions may apply. In other forms of the present technology, alternative definitions may apply.44 General

[0205] Air. In certain forms of the present technology, air may be taken to mean atmospheric air, and in other forms of the present technology air may be taken to mean some other combination of breathable gases, e.g. oxygen enriched air.RMDDHI 3.4-002 (19)

[0206] Ambient. In certain forms of the present technology, the term ambient will be taken to mean (i) external of the treatment system or patient, and (ii) immediately surrounding the treatment system or patient.

[0207] For example, ambient humidity with respect to a humidifier may be the humidity of air immediately surrounding the humidifier, e.g. the humidity in the room where a patient is sleeping. Such ambient humidity may be different to the humidity outside the room where a patient is sleeping.

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

[0209] In certain forms, ambient (e.g., acoustic) noise may be considered to be the background noise level in the room where a patient is located, other than for example, noise generated by an RPT device or emanating from a mask or patient interface. Ambient noise may be generated by sources outside the room.

[0210] Automatic Positive Airway Pressure (APAP) therapy. CPAP therapy in which the treatment pressure is automatically adjustable, e.g. from breath to breath, between minimum and maximum limits, depending on the presence or absence of indications of SDB events.

[0211] Continuous Positive Airway Pressure (CPAP) therapy. Respiratory pressure therapy in which the treatment pressure is approximately constant through a respiratory cycle of a patient. In some forms, the pressure at the entrance to the airways will be slightly higher during exhalation, and slightly lower during inhalation. In some forms, the pressure will vary between different respiratory cycles of the patient, for example, being increased in response to detection of indications of partial upper airway obstruction, and decreased in the absence of indications of partial upper airway obstruction.

[0212] Flow rate '. The volume (or mass) of air delivered per unit time. Flow rate may refer to an instantaneous quantity. In some cases, a reference to flow rate will be a reference to a scalar quantity, namely a quantity having magnitude only. In other cases, a reference to flow rate will be a reference to a vector quantity, namely a quantity having both magnitude and direction. Flow rate may be given the symbol Q. ‘Flow rate’ is sometimes shortened to simply ‘flow’ or ‘airflow’.

[0213] In the example of patient respiration, a flow rate may be nominally positive for the inspiratory portion of a breathing cycle of a patient, and hence negative for the expiratory portion of the breathing cycle of a patient. Device flow rate, Qc is the flow rate of air leaving the RPT device.RMDDHI 3.4-002 (19)Total flow rate, Qt, is the flow rate of air and any supplementary gas reaching the patient interface via the air circuit. Vent flow rate, Qv, is the flow rate of air leaving a vent to allow washout of exhaled gases. Leak flow rate, QI, is the flow rate of leak from a patient interface system or elsewhere. Respiratory flow rate, Qr, is the flow rate of air that is received into the patient's respiratory system.

[0214] Flow therapy. Respiratory therapy comprising the delivery of a flow of air to an entrance to the airways at a controlled flow rate referred to as the treatment flow rate that is typically positive throughout the patient’s breathing cycle.

[0215] Humidifier'. The word humidifier will be taken to mean a humidifying apparatus constructed and arranged, or configured with a physical structure to be capable of providing a therapeutically beneficial amount of water (H2O) vapour to a flow of air to ameliorate a medical respiratory condition of a patient.

[0216] Leak. The word leak will be taken to be an unintended flow of air. In one example, leak may occur as the result of an incomplete seal between a mask and a patient's face. In another example leak may occur in a swivel elbow to the ambient.

[0217] Noise, conducted (acoustic)'. Conducted noise in the present document refers to noise which is carried to the patient by the pneumatic path, such as the air circuit and the patient interface as well as the air therein. In one form, conducted noise may be quantified by measuring sound pressure levels at the end of an air circuit.

[0218] Noise, radiated (acoustic) '. Radiated noise in the present document refers to noise which is carried to the patient by the ambient air. In one form, radiated noise may be quantified by measuring sound power / pressure levels of the object in question according to ISO 3744.

[0219] Noise, vent (acoustic)'. Vent noise in the present document refers to noise which is generated by the flow of air through any vents such as vent holes of the patient interface.

[0220] Oxygen enriched air . Air with a concentration of oxygen greater than that of atmospheric air (21%), for example at least about 50% oxygen, at least about 60% oxygen, at least about 70% oxygen, at least about 80% oxygen, at least about 90% oxygen, at least about 95% oxygen, at least about 98% oxygen, or at least about 99% oxygen. “Oxygen enriched air” is sometimes shortened to “oxygen”.

[0221] Medical Oxygen'. Medical oxygen is defined as oxygen enriched air with an oxygen concentration of 80% or greater.RMDDHI 3.4-002 (19)

[0222] Patient. A person, whether or not they are suffering from a respiratory condition.

[0223] Pressure: Force per unit area. Pressure may be expressed in a range of units, including cmFhO, g-f / cm2and hectopascal. 1 cmFEO is equal to 1 g-f / cm2and is approximately 0.98 hectopascal (1 hectopascal = 100 Pa = 100 N / m2= 1 millibar ~ 0.001 atm). In this specification, unless otherwise stated, pressure is given in units of cmFEO.

[0224] The pressure in the patient interface is given the symbol Pm, while the treatment pressure, which represents a target value to be achieved by the interface pressure Pm at the current instant of time, is given the symbol Pt.

[0225] Respiratory Pressure Therapy. The application of a supply of air to an entrance to the airways at a treatment pressure that is typically positive with respect to atmosphere.

[0226] Ventilator. A mechanical device that provides pressure support to a patient to perform some or all of the work of breathing.45 Respiratory cycle

[0227] Apnea: According to some definitions, an apnea is said to have occurred when flow falls below a predetermined threshold for a duration, e.g. 10 seconds. An obstructive apnea will be said to have occurred when, despite patient effort, some obstruction of the airway does not allow air to flow. A central apnea will be said to have occurred when an apnea is detected that is due to a reduction in breathing effort, or the absence of breathing effort, despite the airway being patent. A mixed apnea occurs when a reduction or absence of breathing effort coincides with an obstructed airway.

[0228] Breathing rate: The rate of spontaneous respiration of a patient, usually measured in breaths per minute.

[0229] Duty cycle: The ratio of inhalation time, Ti to total breath time, Ttot.

[0230] Effort (breathing): The work done by a spontaneously breathing person attempting to breathe.

[0231] Expiratory portion of a breathing cycle: The period from the start of expiratory flow to the start of inspiratory flow.

[0232] Flow limitation'. Flow limitation will be taken to be the state of affairs in a patient's respiration where an increase in effort by the patient does not give rise to a corresponding increase in flow. Where flow limitation occurs during an inspiratory portion of the breathing cycle it may beRMDDHI 3.4-002 (19) described as inspiratory flow limitation. Where flow limitation occurs during an expiratory portion of the breathing cycle it may be described as expiratory flow limitation.

[0233] Types of flow limited inspiratory waveforms:(i) Flattened: Having a rise followed by a relatively flat portion, followed by a fall.(ii) M-shaped: Having two local peaks, one at the leading edge, and one at the trailing edge, and a relatively flat portion between the two peaks.(iii) Chair-shaped: Having a single local peak, the peak being at the leading edge, followed by a relatively flat portion.(iv) Reverse-chair shaped: Having a relatively flat portion followed by single local peak, the peak being at the trailing edge.

[0234] Hypopnea. According to some definitions, a hypopnea is taken to be a reduction in flow, but not a cessation of flow. In one form, a hypopnea may be said to have occurred when there is a reduction in flow below a threshold rate for a duration. A central hypopnea will be said to have occurred when a hypopnea is detected that is due to a reduction in breathing effort. In one form in adults, either of the following may be regarded as being hypopneas:(i) a 30% reduction in patient breathing for at least 10 seconds plus an associated 4% desaturation; or(ii) a reduction in patient breathing (but less than 50%) for at least 10 seconds, with an associated desaturation of at least 3% or an arousal.

[0235] Hyperpnea'. An increase in flow to a level higher than normal.

[0236] Inspiratory portion of a breathing cycle: The period from the start of inspiratory flow to the start of expiratory flow will be taken to be the inspiratory portion of a breathing cycle.

[0237] Patency (airway): The degree of the airway being open, or the extent to which the airway is open. A patent airway is open. Airway patency may be quantified, for example with a value of one (1) being patent, and a value of zero (0), being closed (obstructed).

[0238] Positive End-Expiratory Pressure (PEEP) '. The pressure above atmosphere in the lungs that exists at the end of expiration.

[0239] Peak flow rate (Qpeak)'. The maximum value of flow rate during the inspiratory portion of the respiratory flow waveform.RMDDHI 3.4-002 (19)

[0240] Respiratory flow rate, patient airflow rate, respiratory airflow rate (Qr) '. These terms may be understood to refer to the RPT device’s estimate of respiratory flow rate, as opposed to “true respiratory flow rate” or “true respiratory flow rate”, which is the actual respiratory flow rate experienced by the patient, usually expressed in litres per minute.

[0241] Tidal volume (Vt): The volume of air inhaled or exhaled during normal breathing, when extra effort is not applied. In principle the inspiratory volume Vi (the volume of air inhaled) is equal to the expiratory volume Ve (the volume of air exhaled), and therefore a single tidal volume Vt may be defined as equal to either quantity. In practice the tidal volume Vt is estimated as some combination, e.g. the mean, of the inspiratory volume Vi and the expiratory volumeiVe.

[0242] Inhalation Time (Ti) : The duration of the inspiratory portion of the respiratory flow rate waveform.

[0243] Exhalation Time (Te): The duration of the expiratory portion of the respiratory flow rate waveform.

[0244] Total Time (Ttotf. The total duration between the start of one inspiratory portion of a respiratory flow rate waveform and the start of the following inspiratory portion of the respiratory flow rate waveform.

[0245] Typical recent ventilation'. The value of ventilation around which recent values of ventilation Vent over some predetermined timescale tend to cluster, that is, a measure of the central tendency of the recent values of ventilation.

[0246] Upper airway obstruction (UAO)'. includes both partial and total upper airway obstruction. This may be associated with a state of flow limitation, in which the flow rate increases only slightly or may even decrease as the pressure difference across the upper airway increases (Starling resistor behaviour).

[0247] Ventilation (Vent): A measure of a rate of gas being exchanged by the patient’s respiratory system. Measures of ventilation may include one or both of inspiratory and expiratory flow, per unit time. When expressed as a volume per minute, this quantity is often referred to as “minute ventilation”. Minute ventilation is sometimes given simply as a volume, understood to be the volume per minute.RMDDHI 3.4-002 (19)46 OTHER REMARKS

[0248] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in Patent Office patent files or records, but otherwise reserves all copyright rights whatsoever.

[0249] Unless the context clearly dictates otherwise and where a range of values is provided, it is understood that each intervening value, to the tenth of the unit of the lower limit, between the upper and lower limit of that range, and any other stated or intervening value in that stated range is encompassed within the technology. The upper and lower limits of these intervening ranges, which may be independently included in the intervening ranges, are also encompassed within the technology, subject to any specifically excluded limit in the stated range. Where the stated range includes one or both of the limits, ranges excluding either or both of those included limits are also included in the technology.

[0250] Furthermore, where a value or values are stated herein as being implemented as part of the technology, it is understood that such values may be approximated, unless otherwise stated, and such values may be utilized to any suitable significant digit to the extent that a practical technical implementation may permit or require it.

[0251] Furthermore, “approximately”, “substantially”, “about”, or any similar term used herein means + / - 5-10% of the recited value.

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

[0253] When a particular material is identified as being used to construct a component, obvious alternative materials with similar properties may be used as a substitute. Furthermore, unless specified to the contrary, any and all components herein described are understood to be capable of being manufactured and, as such, may be manufactured together or separately.RMDDHI 3.4-002 (19)

[0254] It must be noted that as used herein and in the appended claims, the singular forms "a", "an", “criterion” and "the" include their plural equivalents, unless the context clearly dictates otherwise.

[0255] All publications mentioned herein are incorporated herein by reference in their entirety to disclose and describe the methods and / or materials which are the subject of those publications. The publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present technology is not entitled to antedate such publication by virtue of prior disclosure. Further, the dates of publication provided may be different from the actual publication dates, which may need to be independently confirmed.

[0256] The terms "comprises" and "comprising" should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced.

[0257] The subject headings used in the detailed description are included only for the ease of reference of the reader and should not be used to limit the subject matter found throughout the disclosure or the claims. The subject headings should not be used in construing the scope of the claims or the claim limitations.

[0258] Although the technology herein has been described with reference to particular examples, it is to be understood that these examples are merely illustrative of the principles and applications of the technology. In some instances, the terminology and symbols may imply specific details that are not required to practice the technology. For example, although the terms "first" and "second" may be used, unless otherwise specified, they are not intended to indicate any order but may be utilised to distinguish between distinct elements. Furthermore, although process steps in the methodologies may be described or illustrated in an order, such an ordering is not required. Those skilled in the art will recognize that such ordering may be modified and / or aspects thereof may be conducted concurrently or even synchronously.

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

Claims

RMDDHI 3.4-002 (19)CLAIMS1. A respiratory therapy device comprising: a flow generator configured to couple with a respiratory patient interface and to provide a flow of breathable gas as a therapy to the respiratory patient interface; one or more sensors, the one or more sensor configured to sense one or more characteristics of the flow of breathable gas and / or the therapy; a communications device; a controller comprising one or more processors and coupled to the one or more sensors and the communications device, the controller configured to: receive and / or process one or more sensor signals from the one or more sensors and store high -resolution data and low-resolution data from the received and / or processed one or more sensor signals in a memory of the respiratory therapy device; periodically transmit the low-resolution data, with the communications device, to an external server system for storage of the low-resolution data to a database of the server system; receive via the communication device, a command signal requesting activation of high-resolution data communications; and in response to the received command, initiate periodic transmitting of the high- resolution data to a database of the server system.

2. A respiratory therapy device according to claim 1, wherein the high-resolution data comprises at least one of pressure data and flow rate, data.

3. A respiratory therapy device according to claims 1 or 2, wherein the high-resolution data comprises samples collected at a rate no less than 25 Hertz.

4. A respiratory therapy device according to any one of claims 1 to 3, wherein the low-resolution data comprises samples collected at a rate in a range of one Hertz or less.

5. A respiratory therapy device according to any one of claims 1 to 4, wherein the low -resolutionRMDDHI 3.4-002 (19) data comprise one or both of inspiratory pressure data and leak data.

6. A respiratory therapy device according to any one of claims 1 to 5, wherein the one or more sensors comprises one or both of a pressure sensor and a flow sensor.

7. A respiratory therapy device according to any one of claims 1 to 6, further comprising any one or more of a thermometer, a light sensor, a microphone, or a biomotion sensor, wherein the periodic transmitting of the high-resolution data includes data from any one or more of the thermometer, the light sensor, the microphone, or the biomotion sensor.

8. A respiratory therapy device according to any one of claims 1 to 6, wherein the periodic transmitting occurs at a predetermined interval of time following a use of the respiratory therapy device.

9. A respiratory therapy device according to any one of claims 1 to 7, wherein the periodic transmitting occurs as in response to detection of a user ceasing a therapy session comprising any of (a) a detection of removal of the respiratory patient interface or (b) a deactivation of a therapy session with the flow generator.

10. A respiratory therapy device according to any one of claims 1 to 9, wherein the device repeatedly collects the high-resolution data in an internal buffer during a defined period of time and then compresses the collected high-resolution data into a chunk of data, thereby producing a sequence of compressed data chunks.

11. A respiratory therapy device according to claim 10, wherein the device transmits the compressed data chunks in a series of packets, according to a network packet size limit.

12. A respiratory therapy device according to claim 11, wherein each packet is no more than 120 Kb in size.RMDDHI 3.4-002 (19)13. A respiratory therapy device according to any one of claims 10 to 12, wherein each chunk comprises no more than about two minutes of high-resolution data.

14. A respiratory therapy device according to any one of claims 10 to 13, wherein at least one of the chunks of data includes a header that describes a characteristic of data in that chunk.

15. A respiratory therapy device according to any one of claims 1 to 14, wherein the respiratory therapy device receives the command signal during a periodic communication between the respiratory therapy device and a server of the external server system.

16. The respiratory therapy device according to any one of claims 1 to 15, wherein the respiratory therapy device is configured to terminate the periodic transmitting of the high-resolution data to the database of the server system based on an engagement period.

17. The respiratory therapy device according to claim 16, wherein the respiratory therapy device terminates the periodic transmitting of the high-resolution data to the database of the server system by detecting an end of the engagement period.

18. The respiratory therapy device according to any one of claims 16 to 17, wherein the respiratory therapy device terminates the periodic transmitting of the high-resolution data to the database of the server system upon receiving a follow-on command signal received from the server system when the server system detects an end of the engagement period.

19. One or more servers for monitoring respiratory therapy device over a network, wherein the one or more servers are configured to: communicate with a plurality of respiratory therapy devices; and selectively activate at least one of the respiratory therapy devices to begin or cease a high- resolution data transfer protocol.

20. The one more servers according to claim 19, comprising:RMDDHI 3.4-002 (19) a machine control service that is configured to communicate a command signal to activate at least one of the respiratory therapy devices to begin or cease the high-resolution data transfer protocol.

21. The one or more servers according to claim 20, further comprising: one or more databases configured to store data associated with the respiratory therapy devices, wherein the data associated with at least one of the respiratory therapy devices comprises a high-data- rate state of that respiratory therapy device; and one or more services that are configured to communicate with the respiratory therapy devices, to interact with the database, and to selectably manage low-resolution data and high -resolution data communications with the at least one of the respiratory therapy devices, wherein the one or more services is configured to select to communicate low-resolution data or high-resolution data from the at least one of the respiratory therapy devices in response to querying the database for a high-data- rate (HDR) state that is associated with the at least one respiratory therapy device.

22. The one or more servers according to claim 21, wherein when the one or more services are communicating high-resolution data from the at least one of the respiratory therapy devices, a service of the one or more service implements a streaming process that receives chunks of compressed high- resolution data in window batches for processing and decompresses, joins, and recompresses the high-resolution data into a data structure.

23. The one or more servers according to claim 22, wherein at least one chunk of data is compressed according to characteristics of the data in that chunk.

24. The one or more servers according to claim 23, wherein the at least one chunk of data includes a header that describes a compression characteristic of the at least one chunk of data.

25. The one or more servers according to any one of claims 22 to 24, wherein each chunk comprises no more than about two minutes of high-resolution data.

26. The one or more servers according to claim 21, wherein the one or more services are configuredRMDDHI 3.4-002 (19) to set or clear the command signal for a given respiratory therapy device in response to querying the one or more databases for an HDR state of the given respiratory therapy device.

27. The one or more servers according to any one of claims 19 to 26, wherein the high-resolution data comprises one or more of pressure data and flow rate data.

28. The one or more servers according to any one of claims 19 to 27, wherein high-resolution data comprises samples collected at a rate no less than 25 Hz.

29. The one or more servers according to any one of claims 19 to 28, wherein the low-resolution data comprises samples collected at a rate in a range of one Hertz or less.

30. The one or more servers according to any one of claims 19 to 29, wherein the low-resolution data comprise one or both of inspiratory pressure data and leak data.

31. The one or more servers according to any one of claims 19 to 30, being further configured to: generate a graphic user interface that comprises a control with an element for selecting high- data-rate (HDR) communications for some or all of the respiratory therapy devices that are associated with an organization; and in response to activation of the element for selecting HDR communications, set or clear an HDR state for at least one of the plurality of respiratory therapy devices in a database that stores data associated with the plurality of respiratory therapy devices.

32. The one or more servers according to claim 31, wherein the element is a set of radio buttons.

33. The one or more servers according to any one of claims 31 to 32, being further configured to: generate a graphic user interface; and, in response to a user activation of the element for selecting HDR communications, enable in the graphic user interface a per-device HDR element for a plurality of devices associated with an organization.RMDDHI 3.4-002 (19)34. The one or more servers according to any one of claims 31 to 33, being further configured to: in response to a user activation on the element for selecting HDR communications, display, via an external interface, a per-device HDR element for each device of the plurality of devices associated with the organization.

35. The one or more servers according to any one of claims 19 to 34, wherein one or more respiratory therapy devices of the plurality of respiratory therapy devices are configured to terminate the high- resolution data transfer protocol based on an engagement period.

36. The one or more servers according to claim 35, wherein the one or more respiratory therapy devices terminate the high-resolution data transfer protocol by detecting an end of the engagement period.

37. The one or more servers according to any one of claims 35 to 36, wherein, when the one or more servers detect an end of the engagement period, the one or more servers communicate a follow-on command signal to the one or more respiratory therapy devices to terminate the high -resolution data transfer protocol.

38. A respiratory therapy monitoring system comprising: one or more servers; and a plurality of respiratory therapy devices (RPTs), each of which configured for communicating data with the one or more servers, wherein a first group of the RPTs are associated with an organization; wherein the one or more servers are configured to serve a database and a graphic user interface; wherein the one or more servers are configured to receive sensor data from each of the RPTs and store the sensor data in the database; wherein the one or more servers is configured to: provide the graphic user interface comprising a control with an element for selecting high-RMDDHI 3.4-002 (19) data-rate (HDR) communications for some or all of the respiratory therapy devices that are associated with an organization; and in response to a user activation of the element for selecting HDR communications, set or clear an HDR state for at least one of the plurality of respiratory therapy devices in the database that stores data associated with the plurality of respiratory therapy devices; wherein each of the RPTs is configured to: after the end of a patient sleep session, check in with the server to upload sensor data and to check the HDR state for that RPT; and in response to the HDR state for that RPT being set, commence periodically transmitting high-resolution data to the server.

39. The respiratory therapy monitoring system of claim 38, wherein the server is further configured to: provide an graphic user interface; provide, as part of the graphic user interface, a per-device HDR element; receive, via the graphic user interface, an indication of activation of the per-device HDR element; and, responsive to the indication of activation of the per-device HDR element, set or clear the HDR state for at least one of the RPTs.

40. A respiratory therapy monitoring system according to any one of claims 38 to 39, wherein the high-resolution data comprises at least one of pressure, flow, or leak rate data.

41. A respiratory therapy monitoring system according to any one of claims 38 to 40, wherein the high-resolution data comprise samples collected at a rate no less than 25 Hz.

42. A respiratory therapy monitoring system according to any one of claims 38 to 41, wherein the one or more servers are configured to receive low-resolution data from each of the RPTs and store the low-resolution data in the database, wherein the low-resolution data comprises samples collected at a rate in a range of one Hertz or less.RMDDHI 3.4-002 (19)43. A respiratory therapy monitoring system according to any one of claims 38 to 42, wherein the low-resolution data comprise one or both of inspiratory pressure data and leak data.

44. A respiratory therapy monitoring system according to any one of claims 38 to 43, wherein at least one of the RPTs further comprises at least one of a pressure sensor, a flow sensor, a thermometer, a light sensor, a microphone, or a biomotion sensor.

45. A respiratory therapy monitoring system according to any one of claims 38 to 44, wherein periodic transmitting occurs at a regular interval of time not less than hourly while the respiratory therapy system is in use.

46. A respiratory therapy monitoring system according to any one of claims 38 to 44, wherein periodic transmitting occurs upon termination of a session of use with the RPT.

47. A respiratory therapy monitoring system according to any one of claims 38 to 46, wherein the RPT repeatedly collects the high-resolution data in an internal buffer during a defined period of time and then compresses the collected high-resolution data into a chunk of data, thereby producing a sequence of compressed data chunks.

48. A respiratory therapy monitoring system according to claim 47, wherein the RPT transmits the compressed data chunks in a series of packets, according to a communication network limit on packet size.

49. A respiratory therapy monitoring system according to claim 48, wherein each packet is no more than 120 Kb in size.

50. A respiratory therapy monitoring system according to any one of claims 47 to 49, wherein each chunk comprises no more than about two minutes of high-resolution data.RMDDHI 3.4-002 (19)51. A respiratory therapy monitoring system according to any one of claims 47 to 50, wherein at least one chunk of data is compressed by a customized algorithm that is determined according to characteristics of the data in that chunk.

52. A respiratory therapy monitoring system according to claim 51, wherein the at least one chunk of data includes a header that describes a compression characteristic of the at least one chunk.

53. A respiratory therapy monitoring system according to any one of claims 38 to 52, wherein the one or more servers are configured to provide: a machine control service that is configured to handle data related to respiratory therapy device identity and settings, wherein the machine control service generates a command signal that activates at least one of the RPTs to begin or cease a high -resolution data transfer protocol.

54. A respiratory therapy monitoring system according to any one of claims 38 to 53, further comprising: a database that stores data associated with the respiratory therapy devices, wherein the data associated with at least one of the RPTs comprises a high-data-rate state of that RPT; and a machine data service that is configured to communicate with the respiratory therapy devices, to interact with the database, and to selectably handle low-resolution data and high-resolution data related to use of the respiratory therapy devices, wherein the machine data service selects to handle low-resolution data or high-resolution data from a given RPT in response to querying the database for a high-data-rate (HDR) state that is associated with the given RPT.

55. A respiratory therapy monitoring system according to claim 54, wherein when the machine data service is handling high-resolution data from a given RPT, a machine control service implements data streaming that receives chunks of compressed high-resolution data in window batches for processing and decompresses, joins and recompresses the high-resolution data as data structure.

56. A respiratory therapy monitoring system according to claim 55, wherein at least one chunk ofRMDDHI 3.4-002 (19) data is compressed according to characteristics of the data in that chunk.

57. A respiratory therapy monitoring system according to claim 56, wherein the at least one chunk of data includes a header that describes a compression characteristic.

58. A respiratory therapy monitoring system according to any one of claims 55 to 57, wherein each chunk comprises no more than about two minutes of high-resolution data.

59. A respiratory therapy monitoring system according to claim 53, wherein the machine control service generates the command signal for a given respiratory therapy device in response to querying the database for an HDR state of the given respiratory therapy device.

60. A respiratory therapy monitoring system according to any one of claims 38 to 59, wherein the element for selecting HDR communications is a set of radio buttons.

61. A respiratory therapy monitoring system that comprises: a one or more servers configured to communicate with a plurality of respiratory therapy devices (RPTs); wherein the one or more servers is configured to serve a database and a graphic user interface; wherein the one or more servers are configured to receive high-resolution sensor data from each of the RPTs and store the sensor data in the database; wherein the one or more servers are further configured to: provide, as part of the graphic user interface, a display of data display elements, in which a display element of the display corresponds to a plurality of signals from the sensor data; receive, via the graphic user interface, a selection of a patient; responsive to the selection of the patient, retrieve from the database the sensor data that corresponds to the selected patient’s RPT; display, in a first view section of the graphic user interface, a low-resolution subset of points of the sensor data for a signal of the plurality of signals, wherein the low-resolution subsetRMDDHI 3.4-002 (19) corresponds to the selected patient’s RPT, and wherein the low-resolution subset of points is displayed in correspondence with event markers that correspond to identified events in the signal; receive, via the graphic interface, user input concerning the low-resolution subset of points of the sensor data with visual delimiter elements; and responsive to the visual delimiter elements, display, in a second view section of the graphic user interface, high-resolution data of the signal corresponding to the visual delimiter elements.

62. The respiratory therapy monitoring system according to claim 61, wherein at least one of the RPTs further comprises at least one of a pressure sensor, a flow sensor, a thermometer, a light sensor, a microphone, or a biomotion sensor, and at least one of the display elements displays data corresponding to the at least one sensor of the at least one RPT.

63. The respiratory therapy monitoring system according to any one of claims 61 to 62, wherein the first view section displays points that have been down-sampled from the high-resolution data that is stored in the database.

64. The respiratory therapy monitoring system according to any one of claims 64 to 66, wherein the one or more servers are configured to: provide a graphic user interface that comprises a control with an element for selecting high- data-rate (HDR) communications for some or all of the respiratory therapy devices that are associated with an organization; and in response to a user activation of the element for selecting HDR communications, set or clear an HDR state for at least one of the plurality of respiratory therapy devices in a database that stores data associated with the plurality of respiratory therapy devices; wherein each of the plurality of respiratory therapy devices is configured to: after an end of a patient therapy session, communicate with the one or more servers to upload sensor data according to an HDR state for that RPT; and, in response to a change in the HDR state for that RPT being set, commence periodically transmitting high-resolution data to the one or more servers.RMDDHI 3.4-002 (19)65. The respiratory therapy monitoring system according to claim 64, wherein the one or more servers is configured to store the high-resolution data by receiving chunks of compressed high-resolution data from an RPT.

66. The respiratory therapy monitoring system according to claim 65, wherein the one or more servers are configured to process, in streamed window batches, the chunks of compressed high- resolution data by decompression, joining, and recompression as a data structure for storing in the database.

Images