Data compression for respiratory therapy device data

Abstract

Methods and apparatus prepare medical or therapy data, such as respiratory therapy data for electronic communication to a server system, such as a monitoring system (100). The data may be accessed. Low-pass data may be generated by applying an anti-aliasing filter to the data. Low-rate data may be generated by applying a down-sampling filter to the low-pass data. Encoded data may be generated by performing one or more of intermediate floating-point interpolation, simple linear predictive delta encoding, and / or Rice-Golomb encoding on the low-rate data. The encoded data may be packaged as compressed data with a compression header.

Description

RMDDHI 3.4-004 (20)DATA COMPRESSION FOR RESPIRATORY THERAPY DEVICE DATA1. CROSS REFERENCE TO RELATED APPLICATIONSThis application claims the benefit of United States Provisional Patent Application No. 63 / 681,520, filed August 9, 2024, the entire content of which is incorporated herein by reference.2. BACKGROUND OF THE TECHNOLOGY2.1. FIELD OF THE TECHNOLOGY

[0002] The present technology relates to communications for remotely monitoring data related to medical device or therapy device use such as with compressed therapy data. In particular, the present technology relates to systems for obtaining and compressing data for transmissions from remote medical equipment, such as a plurality of medical monitoring devices, a plurality of therapy devices such as respiratory therapy devices, for remote monitoring of therapy and / or patient health.2.2. DESCRIPTION OF THE RELATED ART

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

[0004] For example, for the purposes of diagnosing, managing and / or 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 positive airway pressure PAP (e.g., continuous positive airway pressure (CPAP), bi-level therapy, Bi-PAP etc.) machines with their blower and respiratory interface such as an air circuit and mask. Such devicesRMDDHI 3.4-004 (20) may be configured with sensors that generate data measurements during the operation of the RPT. Moreover, the RPT may compute additional data related to such measured data. For example, pressure, respiratory flow, and SpC (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 canRMDDHI 3.4-004 (20) present a significant technical challenge for communication systems even with low-resolution data.

[0006] Other known respiratory therapy devices might not be 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 clinical management efficiencies or even 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, on the order of 25 Hz sampling 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, such as a therapy 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.3. 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.RMDDHI 3.4-004 (20)

[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, such 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] Some implementations of the present technology may include a method for preparing medical data, such as respiratory therapy data, for electronic communication to a server system. The method may include accessing the data. The method may include generating low-pass data by applying an anti-aliasing filter to the data. The method may include generating low-rate data by applying a down-sampling filter to the low-pass data. The method may include generating encoded data by performing one or more of intermediate floating-point interpolation, simple linear predictive delta encoding, and / or Rice-Golomb encoding on the low-rate data. The method may include packaging the encoded data as compressed data with a compression header.

[0012] In some implementations, the anti-aliasing filter may be a Bessel filter. The anti-aliasing filter may be a sixth order Bessel filter. The anti-aliasing filter may have a 2 Hz cut-off frequency. The anti-aliasing filter may have a 3.125 Hz cut-off frequency. The respiratory therapy data may include high-resolution data. The down-sampling filter may take every nth point of the respiratory therapy data. The compression header may include a compression algorithm identifier. The compression header may include one or more compression parameters. The one or more compression parameters may include one or more of a step size value, a minimum data value, a maximum data value, and a Golomb divider value. The method may further include transmitting the packaged compression header and compressed data in a data message to the server system. The one or more steps for generating the encoded data and / or for generating the low-rate data may be selected based on a received command from the server system. The one or more steps for generating the encoded data and / or for generating the low-rate data may be selected based on a resolution of the respiratory therapy data.

[0013] In some implementations, one or more compression parameters for the generating the encoded data may be chosen to ensure enabling clinical visualization in a user interface of a display after compression and decompression of any one or more signs of treatment anomalies. The oneRMDDHI 3.4-004 (20) or more signs of treatment anomalies may include: missed trigger, double triggering, auto triggering, upper airway instability and / or collapse, presence of cardiogenic flow, presence of arousals, forced oscillation, snore like breathing, waning and waxing breathing.

[0014] Some implementations of the present technology may include a processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor of a medical device, such as a respiratory therapy device, cause the processor to prepare medical data, such as respiratory therapy data, for electronic communication to a server system. The processor-executable instructions may include instructions to access the data. The processorexecutable instructions may include instructions to generate low-pass data by applying an antialiasing filter to the data or respiratory therapy data. The processor-executable instructions may include instructions to generate low-rate data by applying a down-sampling filter to the low-pass data. The processor-executable instructions may include instructions to generate encoded data by performing one or more of intermediate floating-point interpolation, simple linear predictive delta encoding, and / or Rice-Golomb encoding on the low-rate data. The processor-executable instructions may include instructions to generate package the encoded data as compressed data with a compression header.

[0015] In some implementations, the anti-aliasing filter may be a Bessel filter. The anti-aliasing filter may be a sixth order Bessel filter. The anti-aliasing filter may have a 2 Hz cut-off frequency. The anti-aliasing filter may have a 3.125 Hz cut-off frequency. The respiratory therapy data may include high-resolution data. The down-sampling filter may take every nth point of the respiratory therapy data. The compression header may include a compression algorithm identifier. The compression header may include one or more compression parameters. The one or more compression parameters may include one or more of a step size value, a minimum data value, a maximum data value, and a Golomb divider value.

[0016] In some implementations, the processor-executable instructions may include instructions to transmit the packaged compression header and compressed data in a data message to the server system. The processor-executable instructions may be configured to control the processor of the respiratory therapy device to select one or more steps for generating the encoded data and / or for generating the low-rate data based on a received command from the server system. The processor executable instructions may be configured to control the processor of the respiratoryRMDDHI 3.4-004 (20) therapy device to select one or more steps for generating the encoded data and / or for generating the low-rate data based on a resolution of the respiratory therapy data. The processor executable instructions comprise one or more compression parameters for the generating the encoded data that may be chosen to ensure enabling clinical visualization in a user interface of a display after compression and decompression of any one or more signs of treatment anomalies. The treatment anomalies may include: missed trigger, double triggering, auto triggering, upper airway instability and / or collapse, presence of cardiogenic flow, presence of arousals, forced oscillation, snore like breathing, waning and waxing breathing.

[0017] Some implementations of the present technology may include respiratory therapy device for preparing respiratory therapy data for electronic communication to a server system. The respiratory therapy device may include a pressure device configured to deliver a flow of pressurised air to a patient interface that is, in use, connected to a patient airway. The respiratory therapy device may include a communications device for communicating compressed data to the server system via a network. The respiratory therapy device may include one or more sensors to monitor one or more characteristics of the pressurised air. The respiratory therapy device may include a controller. The controller may include may include one or more processors. The controller and / or the one or more processors may be configured to (a) control the pressure device to deliver the flow of pressurised air to the patient interface. The controller and / or the one or more processors may be configured to generate, with the one or more sensors, respiratory therapy data. The controller and / or the one or more processors may be configured to generate low-pass data by applying an anti-aliasing filter to the respiratory therapy data. The controller and / or the one or more processors may be configured to generate low-rate data by applying a down-sampling filter to the low-pass data. The controller and / or the one or more processors may be configured to generate encoded data by performing one or more of intermediate floating-point interpolation, simple linear predictive delta encoding, and / or Rice-Golomb encoding on the low-rate data. The controller and / or the one or more processors may be configured to package the encoded data as compressed data with a compression header. The controller and / or the one or more processors may be configured to communicate the compressed data with the compression header via the communications device to the server system via the network.RMDDHI 3.4-004 (20)

[0018] In some implementations, the respiratory therapy device may include any of the processor-readable medium described herein with any of the processor control instructions. The one or more processors may be configured to execute the processor-executable instructions of the processor-readable medium.

[0019] Use of such high resolution data, with the benefit of such compression techniques, that is made available in a remote way may allow for more informative reporting. Such data may be overlayed with patient feedback over detailed data of the therapy to allow for greater clinical insights.

[0020] 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 during a brief window of time in the morning after the patient removes their sleep mask. 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.

[0021] 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 thatRMDDHI 3.4-004 (20)RPT; and, in response to the HDR command signal for that RPT being set, commence buffering, chunking, compressing, and communicating high-resolution data to the server.

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

[0023] 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 to 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.

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

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

[0026] 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:RMDDHI 3.4-004 (20)4.1. RESPIRATORY THERAPY MONITORING SYSTEMS

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

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

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

[0030] FIG. 4 shows example modules for data charting in an interface that may be generated by the respiratory therapy monitoring system.

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

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

[0033] 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.RMDDHI 3.4-004 (20)

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

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

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

[0037] 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.4.2. RESPIRATORY THERAPY SYSTEMS

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

[0039] 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 the RPT device is humidified in a humidifier 5000, and passes along an air circuit 4170 to the patient 1000.

[0040] 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 deviceRMDDHI 3.4-004 (20)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.4.3. RPT DEVICE

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

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

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

[0044] FIG. 10D is a schematic of control algorithms that are implemented in an RPT device in accordance with one form of the present technology.4.4. COMPRESSION OF DATA

[0045] FIG. 11 is a schematic of an example algorithm for compressing HDR respiratory therapy data for transmission from an RPT device to a respiratory therapy monitoring system.5. DETAILED DESCRIPTION OF EXAMPLES OF THE TECHNOLOGY

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

[0047] 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-004 (20)5.1. COMMUNICATION ARCHITECTURE

[0048] 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, with wired and / or wireless communications, for communicating therapy data, such as high-resolution therapy data. 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.

[0049] The system may be configured to enable a user, such as a clinical user, to selectively activate one or more of the respiratory therapy devices for transmitting 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 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 can permit greater control over bandwidth usage. In this context, activation may initiate an immediate transfer of therapy data orRMDDHI 3.4-004 (20) 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.

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

[0051] 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 to activate or de-activate high-resolution data with respect to one or more of devices 104, such as a device 104.1.

[0052] 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) may be configured to, at an appropriate time, communicate at (2) the HDR request to the device 104.1. 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 theRMDDHI 3.4-004 (20) therapy device(s). 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 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.

[0053] In some forms of the technology, in response to the command signal, the therapy device may store / set 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 the HDR setting has been affected on the therapy device(s), in response to the command signal. In this regard, an HDR setting on the therapy device serves as a control parameter at the therapy device for data transmissions. Thus, the HDR setting serves as a control parameter on the therapy device to designate the type of data transfer 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.

[0054] 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, communicate with the MCS service. In such 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 (~2min) transmission such as compressed chunks, as further discussed below. In some implementations of the technology, each compressed chunk of high-RMDDHI 3.4-004 (20) 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. Such a header may also include an indication of how the chunk relates to the other chunks so that the collection of chunks correctly (e.g., temporally) corresponds with the data of a therapy session that is represented by the high-resolution data.

[0055] 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).

[0056] Thus, the command to set the HDR setting enables a control on the therapy device to begin to make one or more periodic communications of high-resolution data 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.

[0057] 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)RMDDHI 3.4-004 (20)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 as 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.

[0058] 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 examination / 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.

[0059] 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. Moreover, in some of the implementations and the data may or may not be compressed. In other 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.

[0060] 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,RMDDHI 3.4-004 (20) on a breath-by-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.

[0061] 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 sessionRMDDHI 3.4-004 (20) into a plurality of chunks and a 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.5.2. COMPRESSION

[0062] As previously mentioned, devices of the system (e.g., processor(s) of the RPT and / or servers) may employ compression and / or decompression, such as with optimal compression parameters, that are suitable for the RPT device signals such as pressure and flow signals sampled at high-resolution (e.g., rates about 25 Hertz or greater) and suitable for implementation by such devices (e.g., processing of an RPT device). In some implementations, the RPT device may be configured to selectively vary compression techniques (e.g., algorithm steps and / or parameters) depending on the type of signal (e.g., resoluation) to be transmitted from the RPT device and / or depending on a command signal (such as the previously described signal) that is sent to the therapy device(s) from a server of the system. In this manner, the RPT may implement an optimal compression technique for particular data. For example, based on the command received by the RPT and / or the type of data to be sent by the RPT (e.g., high-resolution data or low-resolution data), the RPT may utilize different compression techniques to provide optimal compression under particular signal use goals.

[0063] Optimal compression means finding compression parameters that allow maintaining sufficient signal fidelity for human visual analysis of the transmitted data in relation to visual review goals, while providing a significant data compression for minimizing communicationsRMDDHI 3.4-004 (20)(e.g., transfer times) between devices. In clinical practice, the visualization goal of high-resolution signals (e.g., 25Hz signals) is an evaluation of root cause of some treatment anomalies as depicted in the signal(s). Typically, a user would look at the signal(s) on a display over a period of a few hours or a night, visually assessing the data traces (most commonly, patient a flow rate trace and a mask pressure trace are reviewed together, but also, for example, snore, respiratory rate, etc.) looking for particular breathing related signs and / or treatment anomalies such as:

[0064] -triggering issues (missed trigger, double triggering, auto triggering);

[0065] -upper airway instability, flow limitation and / or collapse;

[0066] -presence of cardiogenic flow;

[0067] -presence of arousals or irregular breathing patterns (breathing loop gain or waning and waxing breathing);

[0068] - Forced Oscillation;

[0069] - Normal breathing

[0070] - Snore like breathing

[0071] - Unknown disturbances

[0072] But also, a clinician may, for example, review for the sake of checking that the therapy response algorithm is working as expected (e.g., an appropriate response (e.g., pressure) to, for example, flow limitations and / or apnoea, which may be observed in a flow rate signal)

[0073] In implementations in which the high-resolution data is compressed, the data compression algorithm may use a range of techniques or steps such as any of converting data representation, downsampling, linear predictive delta encoding and / or Rice-Golomb encoding. Generally, the data compression algorithm may employ any of the following steps:

[0074] • Filtering of an integer stream representing the signal, such as using the anti-aliasing filter

[0075] • Down sampling the integer stream, such as from 25Hz to 6.25Hz

[0076] • Compressing linearly the range of integer stream, for example, by interpolation, such as to 1 byte, using, for example, intermediate floating-point interpolation with data range reduction;RMDDHI 3.4-004 (20)

[0077] • Applying one or more encoding schemes, such as simple linear predictive delta encoding; and / or encoding the resulting integer stream, such as a Rice-Golomb code with interleaving (e.g., M=8).

[0078] Moreover, the compression parameters may be chosen to ensure enabling clinical visualization (e.g., in a user interface of a display) after compression and decompression of any one, more or all of the aforementioned breathing related signs and / or signs of treatment anomalies.

[0079] FIG. 11 depicts an example algorithm 11000 for implementing compression as discussed herein. For example, at 11002, a raw data stream of high-resolution respiratory therapy data (e.g., pressure, flow, leak) may be received or accessed, such as by a processor of the RPT. At 11004, a fdter, such as an anti-aliasing filter, may be applied. For example, a Bessel filter may be used, i.e. a linear polynomial that samples sequences of consecutive values from the data stream. In some implementations, the Bessel filter may be a sixth order filter, i.e., one that samples six consecutive values at a time, where “y” is the output of the filter, “x” are the sampled values, “P” and “Q” are equal to 6 (for a sixth order filter), and “a” and “b” may be polynomial coefficients chosen as compression parameters for enabling visualization as previously discussed, such as the example values shown below:a= [1 . 00000000000000000000000000000000000000000000000000000000000000000 -2 . 57861311167301998636958160204812884330749511718750000000000000000 3 . 09368825168031769123899721307680010795593261718750000000000000000 -2 . 13735063908556721656850641011260449886322021484375000000000000000 0 . 88175180586089674239502755881403572857379913330078125000000000000 - 0 . 20366076962491561075374590927822282537817955017089843750000000000 0 . 02041291345353737907153401920368196442723274230957031250000000000 ] ; b= [0 . 00119106954080076560958945108836815052200108766555786132812500000 0 . 00714641724480459365753670653020890313200652599334716796875000000 0 . 01786604311201148501120350431392580503597855567932128906250000000 0 . 02382139081601531219178902176736301044002175331115722656250000000RMDDHI 3.4-004 (20)0 . 01786604311201148501120350431392580503597855567932128906250000000 0 . 00714641724480459365753670653020890313200652599334716796875000000 0 . 00119106954080076560958945108836815052200108766555786132812500000 ]

[0080] In some implementations, the filter or Bessel filter may have a cut-off frequency, such as a chosen cut-off frequency that is between 1 Hz and 5 Hz. In some implementations, 2 Hz or 3.125 Hz may be suitable example values in certain implementations of the technology. The filter or Bessel filter may be one of a class of filters known as Infinite Impulse Response (HR) filters, but other filters of this class may be suitable for anti-aliasing purposes. HR filters are known for a property that changing any single value of the input stream affects all subsequent values of the output stream, due to including previous “y” values in the calculation of each subsequent “y” value.

[0081] At 11006, optionally, signal down-sampling may be implemented, such as from 25 Hz data to 6.25 Hz. This may be accomplished, for example, by picking every nth (e.g., fourth) consecutive value from the data stream.

[0082] At 11008, optionally, the data representation of the integer stream may be compressed to a desired size or bit size (e g., one byte) by interpolation. In some implementations, this may be done by using an interpolation technique such as an intermediate floating-point interpolation. This step is only needed when the data representation of the data stream is greater than a desired bit size. Thus, the step may be conditional based on an evaluation of data stream size. In order to do this, there may be several different methods:1. Reduce the data range, use the same data step size.2. Use the same data range, increase the data step size with unified step size.3. Use the same data range, increase the data step size with non-unified step size.A goal of this step is to reduce the space required to represent a particular value in the data stream. This is essentially a loss in "resolution", however we want to choose carefully how this resolution loss takes place depending on the signal and intended use of this data. The process gives us some control in where we want to lose resolution or fidelity per signal, rather than it be generic across the board for all signal types. This may be implemented by allowing parametrization of how this linear compression takes place. Affectively, the control may be via two key parameters:RMDDHI 3.4-004 (20)1. The scaling of the data. This is effectively a simple divider of the original value with us accepting a resolution loss depending on how large the scaling factor is. (This corresponds to step size).2. The range of the values. We can then potentially shift this range around, and given a known starting point, use a smaller amount of space to represent larger numbers or ranges. It also allows a way by which some number representations (such as negative numbers) which typically require more bits of data to represent, to be represented more efficiently.

[0083] An appropriate method is determined by input parameters that may be applied to a function implementing the algorithm (e.g., min, max, decimal and step).

[0084] Optionally, at 11010, encoding may be applied such as to further compress the data. For example, a first encoding scheme may be employed. This may be a simple encoding scheme such as simple linear predictive delta encoding. Such encoding may use two consecutive samples to predict the next sample by a straight line fit, where the difference or delta from the predicted value of a sample to an actual value of the sample is chosen as the result value for the compressed data.

[0085] At 11012, encoding may be employed, such as a second encoding. Such encoding may be, for example, a variant of a Golomb coding such as Rice-Golomb coding. The encoding may be based on the parameter M to divide an input value A into two parts:1. Quotient: The quotient is defined in unary coding where a non-negative integer, n, is represented in n ones followed by one zero.2. Remainder: The remainder is defined in truncated binary encoding where is parameterized by an alphabet with total size of number, t. If t is a power of two then the encoding is just a simple binary code, otherwise let k = floor(log2(Z)) such that 2- < 1 < 2‘ ' and let u =2*+1- 1. Truncated binary encoding assigns the first u symbols codewords of length k and then assigns the remaining t - u symbols the last t - u codewords of length k + 1

[0086] For example, the Rice-Golomb coding for a set of positive integers, i.e. 0, 1, 2, 3, 4, 5, 6, 7, and M = 2 may be:RMDDHI 3.4-004 (20)

[0087] For a set of negative integers, an overlap and interleave scheme is needed to reassign those number in a unique and reversible way. The sequence begins: 0, -1, 1, -2, 2, -3, 3, -4, 4 ... The nth negative value (i.e., -n) is mapped to the nth odd number (2n-l), and the mth positive value is mapped to the m* even number (2m).

[0088] For example, for a set of negative integers, i.e. 0, -1, 1, -2, 2, -3, 3, and M = 4, then the interleaving may be:5.3. COMPRESSION FORMATS

[0089] As previously noted, compressed data (e.g., chunks) may be communicated as discrete messages between devices of the system where each is packaged with a header, or compression header. Such a header may include compression information, such as parameters in one or more field, to facilitate decompression, such as when compression is performed dynamically in the system using different parameters, techniques, and / or steps as needed as previously discussed. The header may take a format as described herein. The header format thus encodes the compression parameters with the compressed data in the form of a header. The format may address any of the following goals:Streamline the introduction of new algorithms without requiring MDA changes or breaking compatibility;Reduce the overhead for storing and transmitting compression parameters; and / or Use standard encoding mechanisms for simplicityRMDDHI 3.4-004 (20)

[0090] The generalised form of the header format may be as follows:

[0091] Algorithm ID is a fixed 4-byte value allocated for identification purposes. This field includes a compression identifier that may be represented as a plain text ASCII string, such as “AID1” in the example below. The fields may be variable length with the length determined by the content of the field itself. Each compression identifier may represent different sets of compression related steps that were applied to the data stream to form the compressed data to thereby inform a receiving system of how decompression may be accomplished. For example, the following different Algorithm IDs may be associated with different compression algorithm steps as follows:

[0092] The Algorithm Specific Parameters may be input parameters from the compression algorithm of the algorithm ID, and thus, may be used as input parameters for the decompressionRMDDHI 3.4-004 (20) algorithm. For example, the algorithm specific compression parameters of an example of algorithm 11000 can give the following example header format:

[0093] As such, some algorithm specific parameters may be fractional values, such as step size, minimum and maximum parameters for a particular compression algorithm, such as AUDI. Thus, in some implementations, some of the algorithm specific parameters may be converted for transfer in the header, such as by converting some or all to interger form. For example, rather than including floating point values for the step size in the header, the actual step size used for the compression encoding may be converted, such as to a coefficient and a base 10 exponent. Similarly, the minimum and / or maximum may be the compression related actual values but converted to integer multiples of the step size. Such conversions may be as follows:

[0094] Note that there are multiple ways of encoding the same step size value. However, an implementation can choose the largest exponent possible to accurately represent a value. An error may occur if the minimum or maximum are not a multiple of the step size. An example is shown below:RMDDHI 3.4-004 (20)

[0095] This may be considered a flexible way of transmitting the step size as a combination of cofficient and exponent. Floating point numbers in machine format are sometimes inaccurate with minor error, and take up significant space to transmit. By changing the way we transmit these into two integers (the co-efficient and exponent), we get a more exact representation, as well as a reduction in size of transmission if the integer values are small. For the typical use case contemplated herein, these values are almost always small.

[0096] Once converted into integer forms the step size, minimum and maximum are encoded as an integer fields. With regard to other parameters, such as the Golomb divider, they can be positive integers, such as a positive integer value greater than 1 in the case of the Golomb divider parameter.

[0097] In some implementations, the integer fields of the header may be signed and encoded using variable length quantity (VLQ) zig-zag encoding.5.4. DECOMPRESSION

[0098] Decompression is the reverse of the compression sequence using, as input, the compressed data stream rather than the data stream, which may be based on evaluation / reading of the header. As such, in some implementations, server(s) of the system will perform the decompression. However, in some implementations, the data decompression algorithm may also be implemented in the RPT device if necessary. For example, in relation to the example of Fig. 11 , a data decompression algorithm may, for example, include:1. Reversing a Rice-Golomb code based on the coefficient M.2. Reversing a simple linear predictive delta encoding.3. Linearly expanding the range of integer stream to the original range using floating point interpolation.RMDDHI 3.4-004 (20)4. Optionally, for some signals, such as a range of original sampling rates (e.g., for a range of about 6.25 Hz up to about 25 Hz output), feed the floating-point stream into an up- sampling filter. Prior to such filtering, each sample may be padded with zeros (e.g., 3) to increase the sampling rate (e.g., to 25Hz).5. Optionally, for certain high-resolution signals, e.g., 25 Hz), scale the resulting floatingpoint stream up by a factor (e.g., four).6. Optionally, for certain high-resolution signals, e.g., 25 Hz), erase some initial samples, (e.g., the first 10 samples of the resulting floating-point stream) to account for a delay created by filtering (e.g., a 20 tap FIR filter).

[0099] In some implementations, the up-sampling filter may be a Nth order floating-point finite impulse response (FIR) filter that is selected for converting the stream from a low resolution to a high resolution (e.g. ,.25 Hz to 25 Hz), as follows:where:

[0100] x[n] is the input signal,

[0101] y[n] is the output signal,

[0102] N may be 20 when implementing a 20th order FIR filter, and

[0103] b is the floating-point coefficient and may be defined, for example, as b= [- 0 . 0000136266019965541612944974134147280153683823300526 0 . 0003623537545148890356115634059364083441323600709438 0 . 0006897516033274009002521087730031013052212074398994 - 0 . 0004629595482407493313090074416038532945094630122185 - 0 . 0039420043349947912758590717885454068891704082489014 - 0 . 0043866499744409405414646840881687239743769168853760 0 . 0119759284681171199876681399132394290063530206680298 0 . 0579666209756930714269707038965862011536955833435059 0 . 1289440906459027036401465693415957503020763397216797 0 . 1965551468091850939590159441650030203163623809814453RMDDHI 3.4-004 (20)0 . 2246226964058655461986546697517042048275470733642578 0 . 1965551468091850939590159441650030203163623809814453 0 . 1289440906459027036401465693415957503020763397216797 0 . 0579666209756930714269707038965862011536955833435059 0 . 0119759284681171199876681399132394290063530206680298 - 0 . 0043866499744409405414646840881687239743769168853760 - 0 . 0039420043349947912758590717885454068891704082489014 - 0 . 0004629595482407493313090074416038532945094630122185 0 . 0006897516033274009002521087730031013052212074398994 0 . 0003623537545148890356115634059364083441323600709438 - 0 . 00001362660199655416129449741341 7280153683823300526 ] ;5.5. HDR TOGGLING[0104J 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. 5 A and 5B show example HDR controls 800, which may be part of a user interface 107, which provides a selection (e.g., three- button) element 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 noRMDDHI 3.4-004 (20) 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.

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

[0106] 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) 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, suchRMDDHI 3.4-004 (20) 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 is no more than 120 Kb in size.

[0107] 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.5.6. STREAMING ARCHITECTURE

[0108] 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 dataRMDDHI 3.4-004 (20) 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.

[0109] 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).5.7. GRAPHIC USER INTERFACE

[0110] 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 interface 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.) and other respiratory parameters.

[0111] 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 userRMDDHI 3.4-004 (20) 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.

[0112] Generation of such a display may also involve an event detection tool or trend detection tool. Such a detection 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.

[0113] 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 service 410, and a data processing web worker 412. The frontend 404 may include display components 414 and a data service 416.

[0114] 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 dataRMDDHI 3.4-004 (20) 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.

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

[0116] 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 shown 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.RMDDHI 3.4-004 (20)

[0117] 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.5.8. RPT DEVICE

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

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

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

[0121] With respect to FIG. 10A, 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 supports one or more internal components of the RPT device 4000. The RPT device 4000 may include a handle 4018.

[0122] 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.RMDDHI 3.4-004 (20)

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

[0124] 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.5.8.1. RPT device mechanical & pneumatic components

[0125] 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.5.8.2. Air filter(s)

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

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

[0128] 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.5.8.3. Muffler(s)

[0129] An RPT device in accordance with one form of the present technology may include a muffler 4120, or a plurality of mufflers 4120.

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

[0131] 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.RMDDHI 3.4-004 (20)5.8.4. Pressure generator

[0132] 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 whenpressure 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.

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

[0134] 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.5.8.5. Transducer(s)

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

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

[0137] In one form of the present technology, one or more transducers 4270 may be located proximate to the patient interface 3000 or 3800.

[0138] In one form, a signal from a transducer 4270 may be filtered, such as by low-pass, high-pass or band-pass filtering.RMDDHI 3.4-004 (20)5.8.5.1. Flow rate sensor

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

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

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

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

[0143] 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.5.8.6. Anti-spill back valve

[0144] 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.5.8.7. RPT device electrical components5.8.7.1. Power supply

[0145] A power supply 4210 may be located internal or external of the external housing 4010 of the RPT device 4000.

[0146] 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.RMDDHI 3.4-004 (20)5.8.7.2. Input devices

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

[0148] 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.5.8.7.3. Central controller

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

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

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

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

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

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

[0155] 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 algorithmsRMDDHI 3.4-004 (20)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.5.8.7.4. Clock

[0156] The RPT device 4000 may include a clock 4232 that is connected to the central controller 4230.5.8.7.5. Therapy device controller

[0157] Referring to FIG. 7D, 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.

[0158] 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.5.8.7.6. Protection circuits

[0159] 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.5.8.7.7. Memory

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

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

[0162] 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-004 (20)

[0163] 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.5.8.7.8. Data communication systems

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

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

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

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

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

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

[0170] 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-004 (20)5.8.7.9.1. Display driver

[0171] 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.5.8.7.9.2. Display

[0172] 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.5.8.8. RPT device algorithms

[0173] As mentioned above, in some forms of the present technology, the central controller4230 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.

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

[0175] 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-004 (20)5.8.8.1. Pre-processing module

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

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

[0178] 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.5.8.8.1.1. Interface pressure estimation

[0179] 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.5.8.8.1.2. Vent flow rate estimation

[0180] 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-004 (20)5.8.8.1.3. Leak flow rate estimation

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

[0182] 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.5.8.8.1 4. Respi ratory fl ow rate esti m ati on

[0183] 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.5.8.8.2. Therapy Engine Module

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

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

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

[0187] In various forms, the therapy engine module 4320 comprises one or more of the following algorithms: phase determination 4321, waveform determination 4322, ventilationRMDDHI 3.4-004 (20) determination 4323, inspiratory flow limitation determination 4324, apnea / hypopnea determination 4325, snore determination 4326, airway patency determination 4327, target ventilation determination 4328, and therapy parameter determination 4329.5.8.8.2.1. Phase determination

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

[0189] 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 of a current breathing cycle of a patient 1000.

[0190] In some forms, known as discrete phase determination, the phase output O 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 bi-valued phase determination, the phase output 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 O equal to 0 (indicating inspiration) and 0.5 (indicating expiration) respectively.

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

[0192] In other forms, known as continuous phase determination, the phase output O is a continuous variable, for example varying from 0 to 1 revolutions, or 0 to 2n 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 is determined using a fuzzy logic analysis of theRMDDHI 3.4-004 (20) respiratory flow rate Qr. A continuous value of phase determined in this implementation is often 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 O is 0 revolutions.2. If Qr is large positive and steady thenis 0.25 revolutions.3. If Qr is zero and falling fast, then is 0.5 revolutions.4. If Qr is large negative and steady then O is 0.75 revolutions.5. If Qr is zero and steady and the 5-second low-pass filtered absolute value of Qr is large then0.9 revolutions.6. If Qr is positive and the phase is expiratory, then Q is 0 revolutions.7. If Qr is negative and the phase is inspiratory, then is 0.5 revolutions.8. If the 5-second low-pass filtered absolute value of Qr is large, is increasing at a steady rate equal to the patient’s breathing rate, low-pass filtered with a time constant of 20 seconds.

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

[0194] In another implementation of continuous phase determination, the phase 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 O 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).RMDDHI 3.4-004 (20)5.8.8.2.2. Waveform determination

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

[0196] 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 of a respiratory cycle of a patient according to a waveform template fl(Q).

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

[0198] In one form, suitable for either discrete or continuously-valued phase, the waveform template 11(0) 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 11( ) 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 fl(<h) 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.

[0199] In some forms of the present technology, the waveform determination algorithm 4322 selects a waveform template fl(<b) from a library of waveform templates, dependent on a setting of the RPT device. Each waveform template EI() in the library may be provided as a lookup table of values II against phase values . In other forms, the waveform determination algorithm 4322 computes a waveform template n(d ) “on the fly” using a predetermined functional form, possibly parameterised 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.RMDDHI 3.4-004 (20)

[0200] In some forms of the present technology, suitable for discrete bi-valued phase of either inhalation (0 = 0 revolutions) or exhalation (O = 0.5 revolutions), the waveform determination algorithm 4322 computes a waveform template fl “on the fly” as a function of both discrete phase and time t measured since the most recent trigger instant. In one such form, the waveform determination algorithm 4322 computes the waveform template 11( , t) in two portions (inspiratory and expiratory) as follows: 0 = 00 = 0.5

[0201] where Hi(t) and He(t) are inspiratory and expiratory portions of the waveform template H(O, t). In one such form, the inspiratory portion ni(t) of the waveform template is a smooth rise from 0 to 1 parametrised by a rise time, and the expiratory portion He(t) of the waveform template is a smooth fall from 1 to 0 parametrised by a fall time.5.8.8.2.3. Ventilation determination

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

[0203] 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 comer frequency of 0.11 Hz.

[0204] 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 orderRMDDHI 3.4-004 (20) 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.5.8.8.2.4. Determination of Inspiratory Flow Limitation

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

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

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

[0208] From the scaled flow rate, two shape factors relating to the determination of partial obstruction may be calculated.RMDDHI 3.4-004 (20)

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

[0210] 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. An 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.

[0211] 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.5.8.8.2.5. Determination of apneas and hypopneas

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

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

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

[0215] 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.RMDDHI 3.4-004 (20)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.5.8.8.2.6. Determination of snore

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

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

[0218] 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 algorithm 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.5.8.8.2.7. Determination of airway patency

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

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

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

[0222] 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.5.8.8.2.8. Determination of target ventilation

[0223] 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.RMDDHI 3.4-004 (20)

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

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

[0226] 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%).

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

[0228] 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.5.8.8.2.9. Determination of therapy parameters

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

[0230] 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 equationRMDDHI 3.4-004 (20)PI - m («,<)+ / ;( 1 )

[0231] where:• A IS THE AMPLITUDE,• n(<D, T) IS THE WAVEFORM TEMPLATE VALUE (IN THE RANGE 0 TO 1 ) AT THE CURRENT VALUE <D OF PHASE AND T OF TIME, AND• PoIS A BASE PRESSURE.

[0232] If the waveform determination algorithm 4322 provides the waveform template n(Q, t) as a lookup table of values n indexed by phase , the therapy parameter determination algorithm 4329 applies equation (1) by locating the nearest lookup table entry to the current value of phase returned by the phase determination algorithm 4321, or by interpolation between the two entries straddling the current value of phase.

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

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

[0235] 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.5.8.8.4. Detection of fault conditions

[0236] 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:RMDDHI 3.4-004 (20)• 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.

[0237] 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 incident5.8.9. AIR CIRCUIT

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

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

[0240] 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.RMDDHI 3.4-004 (20)5.9. RESPIRATORY THERAPY MODES

[0241] 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.6. GLOSSARY

[0242] 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.6.1. General

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

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

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

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

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

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

[0249] Continuous Positive Airway Pressure (CPAP) therapy. Respiratory pressure therapy in which the treatment pressure is approximately constant through a respiratory cycle of a patient.RMDDHI 3.4-004 (20)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.

[0250] 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’.

[0251] 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, Qd, is the flow rate of air leaving the RPT device. Total flow rate, Qi, 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.

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

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

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

[0255] 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 interfaceRMDDHI 3.4-004 (20) 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.

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

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

[0258] 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”.

[0259] Medical Oxygen'. Medical oxygen is defined as oxygen enriched air with an oxygen concentration of 80% or greater.

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

[0261] Pressure: Force per unit area. Pressure may be expressed in a range of units, including cmFFO, g-f / cm2and hectopascal. 1 cmFFO 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 cmbhO.

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

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

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

[0265] 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, such that, for example, it may determine that there is no flow. An obstructive apnea will be said to have occurred when,RMDDHI 3.4-004 (20) 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.

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

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

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

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

[0270] 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 be 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.

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

[0272] 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:RMDDHI 3.4-004 (20)(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.

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

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

[0275] 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).

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

[0277] Peak flow rate (Qpeakfl. The maximum value of flow rate during the inspiratory portion of the respiratory flow waveform.

[0278] Respiratory flow rate, patient airflow rate, respiratory airflow rate (Qrfl. 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.

[0279] 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 volumefVe.

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

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

[0282] Total Time (Ttotfl. 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.RMDDHI 3.4-004 (20)

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

[0284] 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).

[0285] 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.7. OTHER REMARKS

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

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

[0288] 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.RMDDHI 3.4-004 (20)

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

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

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

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

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

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

[0295] 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.RMDDHI 3.4-004 (20)

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

[0297] 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-004 (20)CLAIMS1. A method for preparing respiratory therapy data for electronic communication to a server system, the method comprising: accessing the respiratory therapy data; generating low-pass data by applying an anti-aliasing filter to the respiratory therapy data; generating low-rate data by applying a down-sampling filter to the low-pass data; generating encoded data by performing one or more of intermediate floating-point interpolation, simple linear predictive delta encoding, and / or Rice-Golomb encoding on the low- rate data; and packaging the encoded data as compressed data with a compression header.

2. The method as claimed in claim 1, wherein the anti-aliasing filter is a Bessel filter.

3. The method as claimed in claim 2, wherein the anti-aliasing filter is a sixth order Bessel filter.

4. The method as claimed in any of claims 1 to 3, wherein the anti-aliasing filter has a 2 Hz cut-off frequency.

5. The method as claimed in any of claims 1 to 3, wherein the anti-aliasing filter has a 3.125 Hz cut-off frequency.

6. The method as claimed in any of claims 1 to 5, wherein the respiratory therapy data comprises high-resolution data.

7. The method as claimed in any of claims 1 to 6, wherein the down-sampling filter takes every nth point of the respiratory therapy data.

8. The method as claimed in any of claims 1 to 7, wherein the compression header comprises a compression algorithm identifier.RMDDHI 3.4-004 (20)9. The method as claimed in any of claims 1 to 7, wherein the compression header comprises one or more compression parameters.

10. The method as claimed in claim 9, wherein the one or more compression parameters comprises one or more of a step size value, a minimum data value, a maximum data value, and a Golomb divider value.

11. The method as claimed in any one of claims 1 to 10, further comprising transmitting the packaged compression header and compressed data in a data message to the server system.

12. The method as claimed in any one of claims 1 to 11, wherein one or more steps for generating the encoded data and / or for generating the low-rate data are selected based on a received command from the server system.

13. The method as claimed in any one of claims 1 to 12, wherein one or more steps for generating the encoded data and / or for generating the low-rate data are selected based on a resolution of the respiratory therapy data.

14. The method as claimed in any one of claims 1 to 13, wherein one or more compression parameters for the generating the encoded data are chosen to ensure enabling clinical visualization in a user interface of a display after compression and decompression of any one or more signs of treatment anomalies comprising: missed trigger, double triggering, auto triggering, upper airway instability and / or collapse, presence of cardiogenic flow, presence of arousals, forced oscillation, snore like breathing, waning and waxing breathing.

15. A processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor of a respiratory therapy device, cause the processor to prepare respiratory therapy data for electronic communication to a server system, the processorexecutable instructions comprising:RMDDHI 3.4-004 (20) instructions to access the respiratory therapy data; instructions to generate low-pass data by applying an anti-aliasing filter to the respiratory therapy data; instructions to generate low-rate data by applying a down-sampling filter to the low-pass data; instructions to generate encoded data by performing one or more of intermediate floatingpoint interpolation, simple linear predictive delta encoding, and / or Rice-Golomb encoding on the low-rate data; and instructions to generate package the encoded data as compressed data with a compression header.

16. The processor-readable medium as claimed in claim 15, wherein the anti-aliasing filter is a Bessel filter.

17. The processor-readable medium as claimed in claim 16, wherein the anti-aliasing filter is a sixth order Bessel filter.

18. The processor-readable medium as claimed in any of claims 15 to 17, wherein the antialiasing filter has a 2 Hz cut-off frequency.

19. The processor-readable medium as claimed in any of claims 15 to 17, wherein the antialiasing filter has a 3. 125 Hz cut-off frequency.

20. The processor-readable medium as claimed in any of claims 15 to 19, wherein the respiratory therapy data comprises high-resolution data.

21. The processor-readable medium as claimed in any of claims 15 to 20, wherein the downsampling filter takes every nth point of the respiratory therapy data.

22. The processor-readable medium as claimed in any of claims 15 to 21, wherein theRMDDHI 3.4-004 (20) compression header comprises a compression algorithm identifier.

23. The processor-readable medium as claimed in any of claims 15 to 22, wherein the compression header comprises one or more compression parameters.

24. The processor-readable medium as claimed in claim 23, wherein the one or more compression parameters comprises one or more of a step size value, a minimum data value, a maximum data value, and a Golomb divider value.

25. The processor-readable medium as claimed in any one of claims 15 to 24, further comprising instructions to transmit the packaged compression header and compressed data in a data message to the server system.

26. The processor-readable medium as claimed in any one of claims 15 to 25, wherein the processor-executable instructions are configured to control the processor of the respiratory therapy device to select one or more steps for generating the encoded data and / or for generating the low- rate data based on a received command from the server system.

27. The processor-readable medium as claimed in any one of claims 15 to 26, wherein the processor executable instructions are configured to control the processor of the respiratory therapy device to select one or more steps for generating the encoded data and / or for generating the low- rate data based on a resolution of the respiratory therapy data.

28. The processor-readable medium as claimed in any one of claims 15 to 27, wherein the processor executable instructions comprise one or more compression parameters for the generating the encoded data that are chosen to ensure enabling clinical visualization in a user interface of a display after compression and decompression of any one or more signs of treatment anomalies comprising: missed trigger, double triggering, auto triggering, upper airway instability and / or collapse, presence of cardiogenic flow, presence of arousals, forced oscillation, snore like breathing, waning and waxing breathing.RMDDHI 3.4-004 (20)29. A respiratory therapy device for preparing respiratory therapy data for electronic communication to a server system, the respiratory therapy device comprising: a pressure device configured to deliver a flow of pressurised air to a patient interface that is, in use, connected to a patient airway; a communications device for communicating compressed data to the server system via a network; one or more sensors to monitor one or more characteristics of the pressurised air; and a controller comprising one or more processors configured to:(a) control the pressure device to deliver the flow of pressurised air to the patient interface;(b) generate, with the one or more sensors, respiratory therapy data;(c) generate low-pass data by applying an anti-aliasing filter to the respiratory therapy data;(d) generate low-rate data by applying a down-sampling filter to the low-pass data; generating encoded data by performing one or more of intermediate floating-point interpolation, simple linear predictive delta encoding, and / or Rice-Golomb encoding on the low- rate data; and(e) package the encoded data as compressed data with a compression header.

30. The respiratory therapy device as claimed in claim 29 and further comprising the processor- readable medium as claimed in any one of claims 15 to 28, wherein the one or more processors are configured to execute the processor-executable instructions of the processor-readable medium.

Images