Display system for respiratory therapy device data

Abstract

Apparatus and methods, such as with processor(s), graphically display respiratory therapy data, in a system of server(s) (e.g., monitoring system (100)) and therapy device(s) (4000). A set of high-resolution samples of the data representing a therapy period may be received. A sample subset of the high-resolution set may be accessed in response to user activation of a user selectable graphic interface displaying samples of the high-resolution set. The accessed subset may be scaled for display in a window. The scaling may include, when the samples in the subset exceed a pixel dimension of the window for the data display, down-sampling the samples based on the pixel dimension. The scaling may include, when the samples in the subset are less than a pixel dimension of the window, increasing the number of samples of the subset based on the pixel dimension. The scaled subset may be then displayed in the window.

Description

RMDDHI 3.4-005 (21) DISPLAY SYSTEM FOR RESPIRATORY THERAPY DEVICE DATA 0. CROSS REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of United States Provisional Patent Application Nos. 63 / 812,467, filed May 27, 2025, and 63 / 681,509, filed August 9, 2024, the entire content of each of which is incorporated herein by reference. 1. BACKGROUND OF THE TECHNOLOGY 1.1. FIELD OF THE TECHNOLOGY

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

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

[0004] For example, for the purposes of treating sleep-related breathing disorders and other respiratory dysfunctions, many people utilize so-called respiratory therapy devices (RPTs) such as the examples described in more detail herein, or continuous positive airway pressure (CPAP) machines with their blower and respiratory interface such as an air circuit and mask. Such devices may be configured with sensors that generate data measurements during the operation of the RPTRPT. Moreover, the RPT may compute additional data related to such measured data. ForRMDDHI 3.4-005 (21) example, pressure, respiratory flow, and SpO2(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. Still further, to provide routine monitoring capabilities such as to support personnel (e.g., physicians, technicians and / or clinicians), such systems need to be designed to efficiently and repeatedly permit remote display for review of such data, which can require additional remote communications from such systems to reviewing devices such as on desktop computers, laptop computers, and smart devices (e.g., smart phones and tablets), which can be in addition to remoteRMDDHI 3.4-005 (21) communications that receive such data from the home medical equipment. For example, in the case of an example respiratory therapy device, it is believed that more than 8 million positive airway pressure (e.g., CPAP) devices are sold annually in the United States, with another 2.5 million globally. Daily use of so many of such devices can present a significant technical challenge for communication systems even with low-resolution data.

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

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

[0008] In view of the foregoing, there is a need for a cost effective, time-saving and reliable communications approach to effect remote data access from a home therapy device such as to support high-resolution data transmission to a remote system or server such as via wired and / or wireless devices, and simplify the process for exporting data to the remote system and / or enabling remote review of such data efficiently. 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.RMDDHI 3.4-005 (21) 2. BRIEF SUMMARY OF THE TECHNOLOGY

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

[0010] The technology relates to a therapy data system, such as including one or more servers, configured for receiving data, such as high-resolution data, from a plurality of therapy devices, 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 dynamically displaying high-resolution data or user selectable portions thereof, for remote clinical monitoring of therapy provided by the plurality of therapy devices.

[0011] Some implementations of the present technology may include a method of a processor for graphically displaying respiratory therapy data. The method may include receiving a set of sample, such as high-resolution samples, of respiratory therapy data representing a period of respiratory therapy. The method may include accessing a sample subset of the set of samples, such as the high- resolution samples, in response to a user activation of a user selectable graphic interface displaying samples of the set of samples, such as the high-resolution samples, on a display. The method may include scaling the accessed sample subset for display in a display time window. The scaling may include: (a) in a case that the number of samples in the sample subset exceeds a pixel dimension of the display time window in which the respiratory therapy data may be to be displayed, down- sampling the samples based on the pixel dimension. The scaling may include (b) in a case that the number of samples in the sample subset is less than a pixel dimension of the display time window, increasing the number of samples of the sample subset based on the pixel dimension. The method may include controlling displaying of the scaled sample subset in the display time window on the display.

[0012] In some implementations, the receiving may include accessing, by the processor, a data structure may include the set of high-resolution samples of respiratory therapy data. The data structure may have been transmitted from one or more servers to computing apparatus that includes the processor. The set of high-resolution samples of respiratory therapy data of the data structure may have been transmitted to the one or more servers over a network from a respiratory therapyRMDDHI 3.4-005 (21) apparatus. The down-sampling may include assigning samples of the sample subset to a chunk that includes an integer number of consecutive samples of the sample subset, and then selecting one or both of a minimum and a maximum of each chunk. The displaying the scaled sample subset in the display time window may include rendering a lower signal envelope of pixels. The lower signal envelope may correspond to a plurality of selected minimums that may include the minimum.

[0013] In some implementations, the displaying the scaled sample subset in the display time window may include rendering an upper signal envelope of pixels, wherein the upper signal envelope corresponds to a plurality of selected maximums may include the maximum. The displaying the scaled sample subset in the display time window may include filling one or more pixels between pixels representing the minimum and the maximum if the maximum and the minimum may be not equal. The method may further include determining a chunk size for the chunk based on factorizing widths of a plurality of different display time windows for displaying the sample subset. The method may further include determining a chunk size for the chunk based on bifurcation wherein each of a plurality of chunk sizes is a power of two. Increasing the samples of the sample subset may include generating samples by, according to a spline function, interpolating between samples of the sample subset. The spline function may include a cubic spline. Increasing the samples of the sample subset may further include padding null samples to the sample subset and filtering the padded sample subset. The interpolating with the spline function may generate samples between samples of the sample subset after the padding and filtering of the sample subset. Optionally, each of a number of the samples generated by the padding and filtering and a number of samples generated by the interpolating doubles the number of samples of the sample subset. The filtering may apply a finite impulse response filter.

[0014] In some implementations, the controlling the display may be performed in a first thread of the processor and the scaling may be performed in a second thread of the processor. The second thread may be configured to scale a plurality of differently scaled views of the sample subset by preprocessing the sample subset for each of the plurality of differently scaled views before displaying any one of the plurality of differently scaled views. The first thread may be a main thread and the second thread may be web worker. The scaling may be performed by a web worker in pre-processing for a plurality of different display time windows, The pre-processing may include determining, for a small-scale display time window that graphs a number of samples thatRMDDHI 3.4-005 (21) may be greater than a pixel dimension of the small-scale display time window, a first chunk size that may be an integer number of samples no greater than the number of graphed samples divided by the pixel dimension. The pre-processing may include determining, for each display time window that graphs more samples than the small-scale display time window, a further chunk size that may be a multiple of the first chunk size based on a number of samples graphed by that display time window. The down-sampling may include, for each display time window that graphs a number of samples that may be greater than the pixel dimension of that display time window, first assigning each included sample to a chunk of that display time window’s further chunk size, and next selecting a minimum and a maximum of each chunk. The determining the further chunk size for a given display time window may include factorizing the number of samples to be graphed by that display time window by the number of samples to be graphed by the small-scale display time window. The determining a further chunk size for a given display time window may include repeatedly doubling the chunk size to reach a number of samples that may be just greater than the number of covered samples for that display time window divided by the pixel dimension of that display time window.

[0015] In some implementations, the scaling may be performed by a web worker in pre-processing for a plurality of different display time windows. The pre-processing may include determining, for a large-scale display time window that has a pixel dimension larger than a number of samples to be covered by the large-scale display time window, a maximum multiple that may be an integer no less than the pixel dimension divided by the number of covered samples. The pre-processing may include up-sampling the covered samples with a filter that may be set to a filter frequency. The filter frequency may be no less than twice a sample rate of the covered samples and the filter frequency may be no more than the maximum multiple of the sample rate of the covered samples. The scaling may be performed by a web worker in pre-processing for a plurality of different display time windows. A rending process may then include fitting a cubic spline to the graphed samples. The cubic spline may be selected from a group consisting of: a Catmull-Rom spline, and a natural spline.

[0016] In some implementations, the receiving the set of high-resolution samples may further include decompressing a data structure may include a compressed version of the set of high- resolution samples.RMDDHI 3.4-005 (21)

[0017] Some implementations of the present technology may include a processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor, cause the processor to perform any of the aspects of the method of graphically displaying respiratory therapy data as described herein.

[0018] Some implementations of the present technology may include a processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor, cause the processor to graphically display respiratory therapy data. The processor- executable instructions may include instructions to receive a set of samples, such as high- resolution samples, of respiratory therapy data representing a period of respiratory therapy. The processor-executable instructions may include instructions to access a sample subset of the set of samples in response to a user activation of a user selectable graphic interface displaying samples of the set of samples, such as the high-resolution samples, on a display. The processor-executable instructions may include instructions to scale the accessed sample subset for display in a display time window. The scaling may include (a) in a case that the number of samples of the sample subset exceeds a pixel dimension of the display time window in which the respiratory therapy data may be to be displayed, down-sampling the samples based on the pixel dimension. The scaling may include (b) in a case that the number of samples in the sample subset may be less than a pixel dimension of the display time window, increasing the number of samples of the sample subset based on the pixel dimension. The processor-executable instructions may include instructions to control displaying of the scaled sample subset in the display time window on the display.

[0019] Some implementations of the present technology may include a server with access to an of the processor-readable mediums described herein, wherein the server may be configured to receive requests for downloading the processor-executable instructions of the processor-readable medium to a computing device over a network.

[0020] Some implementations of the present technology may include a computing device. The computing device may include one or more processors coupled with a display and (a) any of the processor-readable mediums described herein, or (b) wherein the computing device may be configured to access and execute the processor-executable instructions with any of the servers described herein. The computing device may be any one of a smart phone, a tablet, a laptop or a desktop computer.RMDDHI 3.4-005 (21)

[0021] Some implementations of the present technology may include a method of a server having access to any of the processor-readable mediums described herein. The method may include receiving, at the server, a request for downloading the processor-executable instructions of the processor-readable medium to a computing device over a network. The method may include transmitting the processor-executable instructions to the computing device in response to the request.

[0022] Some implementations of the present technology may include a method of a processor for graphically displaying respiratory therapy data, such as high-resolution respiratory therapy data. The method may include rendering and displaying a graphical user interface (GUI) for interacting with a respiratory therapy monitoring system. The GUI may include a first container and a second container, and the first container may include a first graphical control element for selecting a time period over which the respiratory therapy data, such as the high-resolution respiratory therapy data, was collected. The method may include, in response to a selection of a time period using the first graphical control element, dynamically updating content in the second container to include at least one graphical representation of a set of respiratory therapy data, such as high-resolution respiratory therapy data, that was collected over at least one respiratory therapy period that took place during the selected time period.

[0023] In some implementations, the at least one graphical representation of respiratory therapy data, such as high-resolution respiratory therapy data, may be a waveform graph, and the waveform graph may be a visual representation of a signal measured over the at least one respiratory therapy period. The first container may include respective graphical elements for each respiratory therapy period of a set of respiratory therapy periods, the selected time period may include a subset of respiratory therapy periods from among the set of respiratory therapy periods, and the subset of respiratory therapy periods may include the at least one respiratory therapy period and zero or more additional respiratory therapy periods. The first container may include a set of graphical data buffers, wherein each data buffer in the set of graphical data buffers graphically may represent an amount of data collected for a corresponding one of the set of respiratory therapy periods. The method may include, in response to detecting a pointer hovering over an individual data buffer in the set of data buffers for a predefined amount of time, displaying a tooltip within the GUI indicating an amount of data collected during a respiratory therapy period corresponding to the individual dataRMDDHI 3.4-005 (21) buffer. The GUI may further include a third container, and the method may include, in response to the selection of the time period using the first graphical control element, dynamically updating content in the third container to include a summary of the high-resolution respiratory therapy data that was collected during the selected time period.

[0024] In some implementations, the summary of the high-resolution respiratory therapy data that was collected during the selected time period may include at least one of: usage metrics related to usage of a respiratory therapy device from which the high-resolution respiratory therapy data was collected; therapy metrics related to respiratory therapy provided by the respiratory therapy device; and respiratory indices related to the provided respiratory therapy. The second container may include a set of therapy data panels, and each therapy data panel in the set of therapy data panels may correspond to a respiratory therapy period in the subset of respiratory therapy periods. Each therapy data panel may include a waveform graph, and the waveform graph of each therapy data panel may be a visual representation of a signal measured during the corresponding respiratory therapy period. At least one waveform graph of at least one therapy data panel in the set of therapy data panels may include a set of event markers, wherein each event marker in the set of event markers may correspond to a detected sleep-related event. Each event marker may be overlaid on the at least one waveform graph at respective time instants when the corresponding detected sleep- related event took place. Each therapy data panel may include a set of second graphical control elements, and each second graphical control element in the set of second graphical control elements may correspond to a signal type.

[0025] In some implementations, the method may include, in response to selection of an individual second graphical control element in the set of second graphical control elements of one therapy data panel in the set of therapy data panels, dynamically updating the one therapy data panel to display a waveform graph of the corresponding signal type. The set of second graphical control elements may include any one, more or all of a flow signal graphical control element corresponding to a flow signal type, a leak signal graphical control element corresponding to a leak signal type, and a pressure signal graphical control element corresponding to a pressure signal type. The second graphical control element may be a vertical menu of multiple different a signal types from which to select a desired signal type to be displayed in the waveform graph. Each therapy data panel mayRMDDHI 3.4-005 (21) include a respective third graphical control element for displaying a high resolution data interface for its corresponding therapy data panel.

[0026] In some implementations, the method may include, in response to selection of an individual third graphical control element of an individual therapy data panel in the set of therapy data panels, dynamically updating the second container to display a high resolution data interface corresponding to the individual therapy data panel. The high resolution data interface may include the high- resolution respiratory therapy data collected during an individual respiratory therapy period corresponding to the individual therapy data panel. The respective third graphical control element of each therapy data panel may be a button. The high resolution data interface may include a signal navigation panel, and the signal navigation panel may include the waveform graph of the individual therapy data panel and the set of second graphical control elements in the individual therapy data panel for displaying different waveform graphs. The waveform graph in the signal navigation panel may be a GUI element configured for interactive analysis of the high-resolution respiratory therapy data. The signal navigation panel may include a fourth graphical control element for displaying a set of event markers on the waveform graph in the signal navigation panel.

[0027] In some implementations, when the set of event markers are not overlaid on the waveform graph in the signal navigation panel, the method may include, in response to selection of the fourth graphical control element, dynamically updating the signal navigation panel to overlay the set of event markers on the waveform graph in the signal navigation panel. In some implementations, when the set of event markers are overlaid on the waveform graph in the signal navigation panel, the method may include, in response to selection of the fourth graphical control element, dynamically updating the signal navigation panel to remove the set of event markers from the waveform graph in the signal navigation panel. The fourth graphical control element may be a toggle switch. At least a subset of event markers in the set of event markers may correspond to respective respiratory therapy-related events detected by the respiratory therapy monitoring system. The method may further include, in response to detecting a pointer hovering over an individual event marker in the set of event markers for a predefined amount of time, displaying a tooltip indicating an event type of an event corresponding to the individual event marker and an amount of time that the event occurred. The signal navigation panel may include a fifth graphical control element for displaying an expanded events section.RMDDHI 3.4-005 (21)

[0028] In some implementations, when the expanded events section may be not displayed in the signal navigation panel, the method may include, in response to selection of the fifth graphical control element, dynamically updating the signal navigation panel to display the expanded events section. In some implementations, when the expanded events section may be displayed in the signal navigation panel, the method may include, in response to selection of the fifth graphical control element, dynamically updating the signal navigation panel to hide the expanded events section from being displayed in the signal navigation panel. The fifth graphical control element may be an accordion GUI element. The expanded events section, when displayed, may include another set of event markers arranged according to event type. Each other event marker in the other set of event markers may correspond to an event marker overlaid on the waveform graph in the signal navigation panel.

[0029] In some implementations, the method may include, in response to detecting a pointer hovering over an individual other event marker in the set of other event markers for a predefined amount of time, displaying a tooltip indicating an event type of an event corresponding to the individual other event marker and an amount of time that the event occurred. The waveform graph in the signal navigation panel may include a focused section bounded by a set of delimiter elements, wherein the set of delimiter elements may be overlaid on the waveform graph in the signal navigation panel. The focused section may span a time range within the individual respiratory therapy period. The high resolution data interface may include a plurality of signal panels, wherein the plurality of signal panels may include respective waveform graphs for a respective signal type. The plurality of signal panels may be arranged within the high resolution data interface such that the respective waveform graphs are aligned in time. The plurality of signal panels may include any one, more or all of, or at least one of: a flow signal panel including a flow signal waveform graph, a pressure signal panel including a pressure signal waveform graph, a leak signal panel including a leak signal waveform graph, an oxygen saturation (SpO2) signal panel including an SpO2 signal waveform graph, a respiration rate signal panel including a respiration rate signal waveform graph, and a minute ventilation signal panel including a minute ventilation signal waveform graph.

[0030] In some implementations, each signal panel may include a respective sixth graphical control element for displaying or hiding content in a corresponding signal panel. In some implementations, when content of an individual signal panel of the plurality of signal panels mayRMDDHI 3.4-005 (21) be displayed, the method may include, in response to selection of an individual sixth graphical control element of the individual signal panel, dynamically updating the GUI to hide the content of the individual signal panel. In some implementations, when the content of the individual signal panel may be hidden, the method may include, in response to selection of the individual sixth graphical control element, dynamically updating the GUI to expand the individual signal panel to display the content of the individual signal panel. The respective sixth graphical control element of each signal panel may be an accordion icon. The high resolution data interface may include a seventh graphical control element for displaying a set of event bands over the plurality of signal panels. In some implementations, when the set of event bands are not overlaid on the plurality of signal panels, the method may include, in response to selection of the seventh graphical control element, dynamically updating the high resolution data interface to display the set of event bands on the plurality of signal panels.

[0031] In some implementations, displaying the set of event bands may include overlaying the set of event bands on the plurality of signal panels such that the set of event bands extend through the respective waveform graphs. In some implementations, when the set of event bands are overlaid on the plurality of signal panels, the method may include, in response to selection of the seventh graphical control element, dynamically updating the high resolution data interface to not display the set of event bands such that the set of event bands are not overlaid on the plurality of signal panels. Each event band in the set of event bands may correspond to a respective event marker located within the focused section. A width of each event band may correspond to a timespan of a corresponding event represented by the respective event marker. Each event band in the set of event bands may include a corresponding tooltip indicating an event type of the corresponding event and the timespan of the corresponding event. The sixth graphical control element may be a toggle switch. The second graphical control element may be a vertical menu of multiple different time periods from which to select the time period. The first graphical control element may be a slider configured to be dragged over the selected time period.

[0032] In some implementations, the first graphical control element may include a set of delimiter elements that encompass the selected time period, and each delimiter element of the set of delimiter elements may be configured to be moved to encompass more or fewer respiratory therapy periods.RMDDHI 3.4-005 (21)

[0033] Some implementations of the present technology may include a processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor, cause the processor to perform any of the methods, of features of the methods described herein.

[0034] Some implementations of the present technology may include a computing device. The computing device may include any of the processor-readable mediums, with the processor- executable instructions, described herein. The computing device may include one or more processors coupled with a display device, wherein the one or more processors may be configured to execute the processor-executable instructions to render and display the GUI on the display device.

[0035] In some implementations, the computing device may include a communication interface coupled with the one or more processors, wherein the communication interface may be configured to obtain the processor-executable instructions from at least one server. The communication interface may be configured to access the high-resolution respiratory therapy data from the respiratory therapy monitoring system. The at least one server may be a server of the respiratory therapy monitoring system. The computing device may be any one of a smart phone, a tablet computer, a laptop computer, a desktop computer, or a respiratory therapy device.

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

[0037] 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 moreRMDDHI 3.4-005 (21) client devices). The server is configured to receive sensor data from each of the RPTs and store the sensor data in the database. The server is configured to provide, as part of a user interface, an organizational HDR button; to receive, via the internal interface, a click on the organizational HDR button; and, responsive to the click on the organizational HDR button, toggle a flag, state, or command signal for HDR sensor data collection (an “HDR state”) for each of the first group of RPTs. Each of the RPTs is configured to, after the end of a patient sleep session, communicate with the server to upload sensor data and to check for the HDR flag or command signal for that RPT; and, in response to the HDR command signal for that RPT being set, commence buffering, chunking, compressing, and communicating high-resolution data to the server.

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

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

[0040] Some implementations of the present technology may include a method of a processor for graphically displaying respiratory therapy data. The method may include receiving a set of high- resolution samples of respiratory therapy data representing a period of respiratory therapy. TheRMDDHI 3.4-005 (21) method may include accessing a sample subset of the set of high-resolution samples in response to a user activation of a user selectable graphic interface displaying samples of the set of high- resolution samples on a display. The accessing the sample subset may include generating the sample subset from the set of high-resolution samples of respiratory therapy data. The generating may include determining a reference value as a function of a user selected time span made with the user selectable graphic interface. The generating may include selecting samples from the set of high-resolution samples of respiratory therapy data according to sample position within a data structure of the set of high-resolution samples so that sample positions within the data structure of the selected samples are each an integer multiple of the reference value. The generating may include controlling displaying of the sample subset in the display time window on the display.

[0041] In some implementations, the reference value may be a function of the user selected time span and a minimum threshold. The function of the user selected time span and a minimum threshold may be a ratio. The method may further include rounding a result of division of the user selected time span and the minimum threshold. The method may further include determining the integer multiple of the reference value for a position of a sample of the selected samples as a function of the reference value and the position of the sample. The function of the reference value and the position of the sample may include a modulo function.

[0042] Some implementations of the present technology may include a graphic user interface for graphically displaying respiratory therapy data. The graphic user interface may include a calendar section including a visual set of respiratory therapy periods. The graphic user interface may include a graph section including a graphical data buffer element for each period of the visual set of respiratory therapy periods. Each graphical data buffer element may depict a visual quantity for one period of the set of respiratory therapy periods. Each of the graphical data buffer elements may be displayed in relation to a visual scale. The graphic user interface may include a graphical user activatable element that may be a scaling action element and may be configured to operate the graph section, wherein user activation of the graphical user activatable element modifies a range of the visual scale and visually adjusts each of the graphical data buffer elements in relation to the modified range of the visual scale.

[0043] In some implementations, the modified range of the visual scale may be a function of an accumulated therapy usage time of at least one graphical data buffer element of the graphical dataRMDDHI 3.4-005 (21) buffer elements. The accumulated therapy usage time may include a maximum accumulated therapy usage time of the graphical data buffer elements. The modified range of the visual scale may be a function of a period of each of the graphical data buffer elements.

[0044] Some implementations of the present technology may include a method for generating a graphic user interface for graphically displaying respiratory therapy data. The method may include displaying a calendar section including a visual set of respiratory therapy periods. The method may include displaying a graph section including a graphical data buffer element for each period of the visual set of respiratory therapy periods. Each graphical data buffer element may depict a visual quantity for one period of the set of respiratory therapy periods. Each of the graphical data buffer elements may be displayed in relation to a visual scale. The method may include displaying a graphical user activatable element that may be a scaling action element and may be configured to operate the graph section. The method may include, in response to user activation of the graphical user activatable element, modifying a range of the visual scale and visually adjusting each of the graphical data buffer elements in relation to the modified range of the visual scale.

[0045] Some implementations may include a processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor, cause the processor to perform any one or more of the aspects of the method for generating a graphic user interface for graphically displaying respiratory therapy data described herein. The achieved with the processor-readable medium may generate an of the graphic user interface(s) described herein.

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

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

[0048] 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-005 (21) 3.1. RESPIRATORY THERAPY MONITORING SYSTEMS

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

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

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

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

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

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

[0055]

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

[0057] 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.RMDDHI 3.4-005 (21)

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

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

[0060] 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 views 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.

[0061] FIG.8A illustrates a bifurcation down-sampling scheme such as for displaying data of the high-resolution data signals on display such as in the display view of any of FIGs.6A-8.

[0062] FIG.8B illustrates a stepwise spline interpolating real respiratory therapy data such as for displaying data of the high-resolution data signals on display such as in the display view of any of FIGs.6A-8.

[0063] FIG. 8C illustrates a linear spline interpolating real respiratory therapy data such as for displaying data of the high-resolution data signals on display such as in the display view of any of FIGs.6A-8.

[0064] FIG.8D illustrates a bump curve spline interpolating real respiratory therapy data such as for displaying data of the high-resolution data signals on display such as in the display view of any of FIGs.6A-8.

[0065] FIG.8E illustrates a monotone curve spline interpolating real respiratory therapy data such as for displaying data of the high-resolution data signals on display such as in the display view of any of Figs.6A-8.

[0066] FIG. 8F illustrates a basis spline interpolating real respiratory therapy data such as for displaying data of the high-resolution data signals on display such as in the display view of any of FIGs.6A-8.

[0067] FIG.8G illustrates a cardinal spline interpolating real respiratory therapy data such as for displaying data of the high-resolution data signals on display such as in the display view of any ofRMDDHI 3.4-005 (21) FIGs.6A-8.

[0068] FIG. 8H illustrates a natural spline interpolating real respiratory therapy data such as for displaying data of the high-resolution data signals on display such as in the display view of any of FIGs.6A-8.

[0069] FIG.8J illustrates a 21-tap finite impulse response (FIR) filter interpolating real respiratory therapy data such as for displaying data of the high-resolution data signals on display such as in the display view of any of Figs.6A-8.

[0070] FIG.8K shows a 307-tap FIR filter interpolating real respiratory therapy data such as for displaying data of the high-resolution data signals on display such as in the display view of any of FIGs.6A-8.

[0071] FIGs.11A, 11B, 11C, 11D, 11E, 11F, 11G, 11H, 11I, 11J, 11K, 11L, 11M, 11N, 11O, 12R and 12S, show different views of an example summary data GUI including 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.

[0072] FIGs.12A, 12B, 12C, 12D, 12E, 12F, 12G, 12H, 12I, 12J, 12K, 12L, 12M, 12N, 12O, 12P, 12Q, 12T, 12U, 12V and 12W show different views of an example high resolution data GUI including 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.

[0073] FIGs.13A, 13B, 13C and 13D, show views of example reorder charts GUIs that may be used to reorder panels within the high resolution data GUI of FIGs.12A to 12P or 12T, 12U, 12V and 12W. 3.2. RESPIRATORY THERAPY SYSTEMS

[0074] FIG.14A 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.

[0075] FIG.14B 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. AirRMDDHI 3.4-005 (21) from the RPT device is humidified in a humidifier 5000, and passes along an air circuit 4170 to the patient 1000.

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

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

[0078] FIG. 15B 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.

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

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

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

[0082] 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-005 (21) 4.1. COMMUNICATION ARCHITECTURE

[0083] 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 (e.g., 50 or 75 Hz) where the signals are produced by the sensors of the respiratory therapy device 104 (or other sensing device suitable for detecting respiratory and / or sleep related patient parameters) 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.

[0084] 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 overRMDDHI 3.4-005 (21) bandwidth usage. In this context, activation may initiate an immediate transfer of therapy data or may initiate one or more periodic transmissions of therapy data such as at the conclusion or shortly after a therapy session with a therapy device.

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

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

[0087] 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 requestRMDDHI 3.4-005 (21) may be a command signal that is sent to the therapy device(s) so that it may be acted upon by the therapy device(s). 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.

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

[0089] 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.RMDDHI 3.4-005 (21) In some implementations of the technology, each compressed chunk of high-resolution data may represent a similar length of time (e.g., 2 minutes), and be of similar size (e.g., up to 120 Kb), and may have a header that defines how to the data of the chunk was compressed or may be decompressed. 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.

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

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

[0092] 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) 110RMDDHI 3.4-005 (21) 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.

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

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

[0095] 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-005 (21) 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.

[0096] 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-005 (21) 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. 4.2. HDR TOGGLING

[0097] FIG. 2 illustrates some example processes that the server(s) 102 may implement in communicating one or more commands for the aforementioned high-resolution data processing such as for turning on and off the high-resolution data feed on a therapy device 104 in response to user actuation of an HDR control element (e.g., a toggle or a set of radio buttons) in one or more user interface that may be provided by the system 100. FIGs. 5A and 5B show example HDR controls 800, which may be part of a user interface 107, which provides a selection (e.g., three- button) 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.RMDDHI 3.4-005 (21) According to some implementations of the technology, the ECO database 208 may be a database that stores data associated with the respiratory therapy devices, and the data associated with at least one of the respiratory therapy devices includes a high-data-rate (HDR) state of that respiratory therapy device. In some implementations of the technology, there are no per-device HDR elements in the user interface 114. Instead, the organizational HDR toggle in the internal interface 106 sets the state of HDR for all devices that are associated with an organization in the ECO database 208.

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

[0099] 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,RMDDHI 3.4-005 (21) to determine if high-resolution functionality should be enabled (such as if not enabled) for further communications with the therapy device such as due to its organizational association with a plurality of therapy devices. If so, the handler service 206 may respond to the therapy device, such as via the messaging service(s) 202 / 204, with the aforementioned command to set the HDR state on the therapy device as previously described in relation to FIG.1. Once set, the HDR state of the therapy device may also be stored by the handler service in a database (e.g., shown as Mongo in FIG.2.) Moreover, once the therapy device RPT receives a command for setting its HDR state set to On, the therapy device will repeatedly take high-resolution data in an internal buffer during a defined period of time (e.g., during a therapy session with the therapy device), then compress the high-resolution data into chunks of data, thereby producing a sequence of discrete data chunks with compressed data. In some implementations of the technology, a therapy device (e.g., RPT) transmits compressed data chunks in a series of packets, each of which satisfies a cellular network’s upper limit on packet size. For example, each packet is no more than 120 Kb in size.

[0100] 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. 4.3. STREAMING ARCHITECTURE

[0101] 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, chunksRMDDHI 3.4-005 (21) in window batches for processing, by which the chunks may be orderly decompressed, joined and recompressed before passing back for forming a different data structure by the MDS service. The newly compressed data structure may be applied to multiple databases such by the streaming data service sending the converted data to a first database and to the MDS service, which in turn may send the data to an additional database.

[0102] 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). 4.4. GRAPHIC USER INTERFACE ARCHITECTURE

[0103] FIG.4 shows an architecture for producing a graphic user interface 114 with high resolution data that may be implemented with 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., via an API and / or the like). As described in more detail herein, 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.)RMDDHI 3.4-005 (21)

[0104] 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 (i.e., differently scaled views) of all or selected portions, such as by down-sampling, of the high- resolution data. The graphic user interface 114 may then present the chart display elements in response to user selections of data type, time window, etc., which may be made by selection elements on the graphic user interface, which may be visual elements in the chart components / sections. Example display related processes for such display generation may be considered in relation to FIGs.8A-8K, which are described in more detail herein.

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

[0106] 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 componentsRMDDHI 3.4-005 (21) 414 and a data service 416. Any one or more of these module may be implemented with the processes for such display generation as descried in relation to FIGs.8A-8K.

[0107] With regard to the example of FIG.4, in operation of the data charting tool, the data service 416 retrieves compressed raw signal, such a via network communications, from a service of the system (e.g., breath by breath gateway 418 to a high-resolution data store). The raw signal may be stored in a compressed data file format or other data structure such as an EDF data format. The compression library 406 implements a parsing module to decompress the data that the data service 416 retrieved. The data service 416 then passes the decompressed raw signal to the data filtering service 410, which hands off the signal to the data processing web worker 412, which may be in any suitable data structure or typed format. The web worker 412, or a plurality of web workers, 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). Thus, the web worker(s), such as in cooperation with any of the other modules, may implement any of the data processes described in relation to FIGs.8A-8K. 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, and such iterative display generations may be implemented without requiring further communications to the server system for additional data since the display can re-process the originally or previously received high-resolution data for display of different portions of the high-resolution data as selected and at different resolutions (zooms) as selected. This can consume a significant amount of processing so the methods should be chosen to be as quick and efficiently as possible to provide a suitable viewing experience for a user.

[0108] FIGs. 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 hours (hrs), Used days < 4 hrs, Days not used,RMDDHI 3.4-005 (21) 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.

[0109] FIGs. 6B and 8 show examples 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 SpO2 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), such as to present it as a high-resolution signal in another view.

[0110] 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. 4.5. DISPLAYING DATA IN THE INTERFACE

[0111] In some implementations, high-resolution data (“HDR data”), which may be data sampled at 25 Hz, may be compressed (e.g., losslessly or lossy) and stored at a lower sample rate (e.g., 6.25 Hz) such as for communication and / or storing purposes. The HDR data (e.g., after decompression when previously compressed), or portions thereof, can then be displayed within display time windows of varying duration (e.g., different durations), such as in a web browser. For example, in some implementations, the HDR data, or selected portions of the data, can be displayed at different zoom levels (e.g., 10 levels) ranging from 10 seconds to 24 hours according to user selection as previously mentioned. In an example where the high-resolution data comprises data sampled at 25 Hz, this means that anywhere from 250 up to 2.16 million pixels might be needed for a givenRMDDHI 3.4-005 (21) display time window to display all sample points as pixels. However, given that a typical display will utilize a different number of pixels to display a chosen set of samples, such as fewer pixels, e.g., from about 1000 up to about 2000 pixels, across a feasibly viewable window size, the process may need to adjust the number of samples for display to correspond with the available display width in pixels for displaying the selected data. That is, a pixel may represent a plurality of samples or a plurality of pixels may represent a sample. Typically, there are many times more samples than pixels. Thus, the adjustment of samples may be a decrease in samples, and the adjustment may be by, for example, down-sampling of the data sample points (e.g., for the small-scale display time windows on the order of 10 minutes or more). Alternatively, the adjustment of samples may be an increase in samples which may be by, for example, up-sampling of the data sample points (e.g., for a large-scale display time windows on the order of 1 minute or less). For example, a process for displaying data may include any of the following:

[0112] Calculate the number of samples per pixel at a zoom level (or each potential zoom level);

[0113] For each zoom level, split the sample data into sections (e.g., chunks) of that many samples;

[0114] Choose one or more points (e.g., a max and / or min) of each section; and

[0115] Convert every chosen point into pixels for rendering / displaying. 4.5.1. DOWN-SAMPLING DATA

[0116] In some implementations, such a process may include simple down-sampling of data that simply choses each point from the data at regular intervals. For example, to down-sample a 6.25 Hz data stream in order to obtain the right number of pixels for a 30-minute display time window that is 1000 pixels wide, one might divide the 11,250 points in a 30-minute piece of the data stream by the 1000 pixels in the window and pick every eleventh point for display. This can present a problem. Picking individual points from the signal can tend to introduce high levels of noise and can distort the signal beyond recognition. 4.5.1.1. Filtering

[0117] In some implementations that may be considered down-sampling, a process for displaying HDR data using a smaller number of pixels of a display area to display a higher number of samples for particular period of time, may involve filtering of samples. For example, a process may select a subset of the samples of a to-be-displayed period of HDR data and then display the selected subset. Such a filtering process may select the subset for display by omitting some samples of theRMDDHI 3.4-005 (21) samples of a to-be-displayed period. In some cases, the process of selecting specific subsets of data from the larger HDR data period may be based on one or more conditions. In some such examples, the subset may be produced by iterating through the larger HDR data period samples, and selecting, and / or omitting or skipping, samples based on the one or more conditions. The one or more conditions may include one or more functions of one or more parameters. Such parameter(s) may include a time span of a desired period of the HDR data to be displayed, such as a user selected time span. Another parameter may be a time threshold, such as a minimum time threshold. The minimum time threshold may represent a minimum such that below the threshold, no omitting or skipping occurs. The function(s) may serve to compare the parameters, such as by determining a ratio of the time span and the time threshold, which may be rounded. The function(s) may also compare the time position of a given sample to the comparison or ratio, such as by performing another ratio operation, such as division or modulus.

[0118] In some implementations, a display of a detail waveform of HDR data (such as display 890 of FIG.8, or display 2102a or 2102b of FIG.12A or display 989 of Fig.12 C, or display 2202a of FIG.12W) may be updated or reset upon user selection of a detail display period selector, such as a dropdown 1610 of FIG.12C or FIG.12T, for adjustment of the prior of the detail waveform display in a graph of a panel, such as graph 989a, 989b, 1289a or detail graph 1389a shown in FIG. 12T, 12U, 12V, and 12 W. For example, as illustrated in relation to FIGs. 12T, 12U, 12V and 12W, a user may select on the user interface, such as with operation of a pointer, the period selector (e.g., drop down 1610) to change a first display period to a second display period. Selection of the selector may offer the user a menu of period options, such as that shown on FIG.12U. Selection one of the period options by the user, such as by operating a pointer, then triggers an update of the detail display of graph 1309a with samples of the HDR data attributable to the selected period. This may then trigger operation of a process of selecting specific subsets of data from the larger HDR data period for rendering pixels in the graph based on one or more conditions associated with the selected period. In the illustrated example of FIG.12U, the user can select the time spans for display from the drop-down control where the time span (i.e., period options) options are time spans from 10 seconds to 24 hours. The selection of one effectively set the zoom level of the graph.RMDDHI 3.4-005 (21)

[0119] To update the graph with a rendered view attributable to the user selection, the graphs may be displayed with the filtering of samples as previously discussed. In some cases, a selection may result in the graph being rendered without filtering of the data points, such as when the selected period as at a minimum threshold (e.g., 1 hour). Such a threshold may be chosen so that there is at least one data point every time per rendered pixel and so that the performance is still adequate while navigating and scrolling through different time positions.

[0120] For example, an array data structure may be used to represent the HDR data such that a variable index to the array can be used to access a data point in a position of the array where the position is referenced by the variable index. A user selection of a period with the selector may trigger the following process to obtain a subset of samples from the array where the subset depends on the selected time span and the minimum threshold. In such an example, to determine which positions in the array are used with a variable index, an index reference value (indexToKeep) may be calculated using a function of the selected time span and the time threshold (1 hour) using the following code: indexToKeep = round (timeSpan / timeThreshold);

[0121] Where: timeSpan is the user selected time span as previously discussed, and the timeThreshold is a minimum threshold previously discussed. The ratio (e.g., division operation) may be rounded so that the result is an integer.

[0122] Once the index reference value is determined, the HDR data of the array can be filtered, such as by using a function with a condition that evaluates a further ratio (e.g., a division operation) for each position in the HDR dataset. In some implementations, a modulo operator may be used (%) for the division to produce the remainder to determine a condition when a particular position is an integer multiple of the reference (i.e., no remainder as a consequence of the division of the position and the reference). The condition of no remainder may be taken as a basis for displaying of a particular datapoint (i.e., sample) that is associated with its position in the array. (i.e., when the position divided by the reference has no remainer (i.e., the remainder is 0). Otherwise, if there is a non-zero remainder, the datapoint associated the position is not displayed in the display.

[0123] For example, such a process may be implemented with the following example javascript code that can create a smaller array of display samples from an array of HDR data samples. HDRsamples.filter ((sample, index) => index % indexToKeep === 0);RMDDHI 3.4-005 (21)

[0124] Where: HDRsamples is the HDR data samples in an array, index is a variable that iteratively points to each position in the array; sample is the datapoint in the array at position attributable to the index variable; % is a modulo operator; === is a test for equality; => indicates a function expression; filter is a method call for testing the elements of an array with a test implemented by the function expression. 4.5.1.2. Min / max sampling

[0125] Another approach to the sample adjustment, which in some implementations may be an alternative or in addition to the aforementioned regular interval point picking, can be to select certain points of sets (e.g., discrete sets) of the HDR data, such as a minimum and / or maximum of discrete sets or “chunks” of the HDR data. For example, to fit a time period of data comprising a 6.25 Hz samples into a 30-minute display time window that is 1000 pixels wide, the process may determine the maximum sample point and the minimum sample point from each of 1000 sets or sequences of the data where each set or sequence has 11 consecutive data points. The chunk then may be considered a point in time for the display window and the minimum and maximum may both be displayed as pixels for the same point in time and optionally, pixels at the same point in time between the minimum and maximum may also be displayed (e.g., vertically filling in pixels between the minimum and maximum corresponding pixels). In other words, the minimums of the chunks can be plotted as a lower envelope of the data and the maximums of the chunks can be plotted as an upper envelope of the data and the area between the envelopes can be filled in as a representation that simulates the HDR data signal. Such a display may be considered in relation to the signal 887 displayed in Fig. 8 in the display section between delimiter elements 888. As the resolution increases so that the minimum and the maximum for a given chunk become equals so that they can be represented by the one pixel, the HDR data display of the signal becomes effectively zoomed to a view sufficient to see the actual signal as a fine data line / curve. Such point selection and chunking can result in a very efficient display of information that can be anRMDDHI 3.4-005 (21) acceptable user experience as resolutions are changed in response to user selection. An example process for selection of minimum and maximums, in TypeScript coding, of the process is shown in the example below. Such a process can be undesirably slow, such as taking up to as much as 1.2 seconds to execute depending on data amounts and processor speed and can be slower on less powerful hardware. The example code may be: const minOut: number[][] = []; const maxOut: number[][] = []; for (const chunkSize of zoomLevels) { console.log(chunkSize); const zoomMin: number[] = []; const zoomMax: number[] = []; for (let i = 0; i < data.length; i += chunkSize) { const chunk = data.slice(i, i + chunkSize); let min = chunk[0]; let max = chunk[0]; for (let val of chunk) { min = Math.min(val, min); max = Math.max(val, max); } zoomMin.push(min); zoomMax.push(max); } minOut.push(zoomMin); maxOut.push(zoomMax); } 4.5.1.3. Factorization

[0126] Another approach to sample adjustment, which may be an alternative or in addition to the aforementioned adjustment methods, may be to also apply a factorization technique and may be implemented to increase speed of point selection, such as by reducing repeated minimum and / or maximum searching determinations for different display window sizes. This avoids duplicating work with dynamic programming by using the results of a previous iteration to speed up a subsequent iteration. Factorization may be applied for determining chunk size, and thereby the number of chunks, for splitting the sample data with respect to different zoom levels to avoid repeating a minimum and maximum selections from the HDR data.

[0127] For example, zoom levels may be implemented as simple factors of each other - 2 hours is 2x 1 hour, 1 hour is 2x 30 minutes, etc. This gets more complicated when accounting for samples per pixel. The samples per pixel of each zoom level can be calculated by multiplying the time period by the sample rate, and then dividing by the width of the graph in pixels. Chunks are an integer number of samples, the samples per pixel may be rounded down to get the chunk size. ThisRMDDHI 3.4-005 (21) means the process may have more than one chunk per pixel. For example, 1100 chunks might be used to display over 1000 pixels (width). In such cases, as there are more chunks than pixels, rendering will be consistent. Nevertheless, too many values can impact rendering performance. Using a real number of samples per pixel values factorise well, but rounded values may not. As a compromise, generating more chunks per pixel to reuse as much as possible by factorising. Below is an example table of factorizations for a 6.25 Hz data stream and a 1000 pixel window width. Target zoom Samples / Rounded / px Best Factorised / px level px chunk Factor chunk 5 minutes 1.875 1 1.875 1x raw data 1 1.875 10 minutes 3.75 3 1.25 3x raw data 3 1.25 30 minutes 11.25 11 1.023 3x 10 9 1.25 minutes 1 hour 22.5 22 1.023 2x 30 18 1.25 minutes 2 hours 45 45 1 2x 1 hour 36 1.25 5 hours 112.5 112 1 3x 2 hours 108 1.04 10 hours 225 225 1 2x 5 hours 216 1.04 12 hours 270 270 1 1x 10 hours 216 1.25 24 hours 540 540 1 2x 12 hours 432 1.25

[0128] The factorizing approach means that the process is much more likely to get more than one chunk per pixel, although not a huge amount more. It also significantly decreases the amount of processing. For example, rather than iterating over the sample data nine times, the factorized process can end up effectively iterating over it only three times. In general, we might expect this approach to be a little inconsistent - different combinations of target zoom levels, sample rates and resolutions may factorise better or worse.

[0129] As illustrated in the code below, an example approach to factorization may include: 1. Calculate the number of samples per pixel for each target zoom level; 2. Round the value of the smallest number of samples per pixel down to find the first chunk size; 3. For each increasing value of samples per pixel, factorise it with the previous chunk size by dividing and rounding down.

[0130] Although more coding steps are required, the factorizing implementation can be faster than a simple min / max approach without factorization – and can be nearly twice as fast on someRMDDHI 3.4-005 (21) platforms. Further optimizations may be implemented depending on platform such as by utilizing different data structures.

[0131] An example factorization implementation, in TypeScript code, is: interface Factor { index: number; / / index of output array to use for processing factor: number; / / chunk size in context of the processing array zoom: number; / / chunk size in context of raw data } const factors: Factor[] = []; const minOut: number[][] = []; const maxOut: number[][] = []; / / massage chunk levels to get factors zoomLevels.forEach((rawZoom, i) => { if (i === 0) { factors.push({ index: -1, factor: rawZoom, zoom: rawZoom }); } else { let newZoom = 0; let newFactor = 10; / / maximum allowed factor let newIndex = 0; factors.forEach((factor, j) => { if (rawZoom / factor.zoom < newFactor) { newFactor = Math.floor(rawZoom / factor.zoom); newIndex = j; newZoom = factor.zoom * newFactor; } }); if (newFactor > 1) { factors.push({ index: newIndex, factor: newFactor, zoom: newZoom }) } } }); for (const factor of factors) { console.log(factor.zoom); const zoomMin: number[] = []; const zoomMax: number[] = []; if (factor.index === -1) { / / iterate over raw data, same as naive algorithm for (let i = 0; i < data.length; i += factor.factor) { const chunk = data.slice(i, i + factor.factor); let min = chunk[0]; let max = chunk[0]; chunk.forEach(val => { min = val < min ? val : min; max = val > max ? val : max; }); zoomMin.push(min); zoomMax.push(max); } minOut.push(zoomMin); maxOut.push(zoomMax);RMDDHI 3.4-005 (21) } else { / / iterate over previous factor for (let i = 0; i < minOut[factor.index].length; i += factor. factor) { const chunk = minOut[factor.index].slice(i, i + factor.factor); let min = 0x8000; chunk.forEach(val => min = Math.min(val, min)); zoomMin.push(min); } for (let i = 0; i < maxOut[factor.index].length; i += factor. factor) { const chunk = maxOut[factor.index].slice(i, i + factor.factor); let max = 0x8000; chunk.forEach(val => max = Math.max(val, max)); zoomMax.push(max); } minOut.push(zoomMin); maxOut.push(zoomMax); } } 4.5.1.4. Bifurcation

[0132] Another optional modification to factorization is bifurcation. A lot of the complexity of factorisation comes from its variability – e.g., the factors may change depending on the data. In this regard, each zoom level’s “best” factor depends on several parameters. A lot of the variability could be eliminated by taking a stricter approach such as always hardcoding the factor (e.g., always choosing N, such as 2, as the factor). This can result in more chunks per pixel on average, of course - close to 2 in the worst case. This may be the result with any algorithm when the target (i.e., target zoom level) is just below 2 samples per pixel, but this approach can extend that situation to any zoom level. The table below shows the example chunk sizes that may be implemented with a fixed factorization approach (e.g., bifurcated) with regard to the same zoom levels as the previous table. Target zoom level Samples / px Best Factor Chunk size / px 5 minutes 1.875 1x raw data 1 1.88 10 minutes 3.75 2x raw data 2 1.5 30 minutes 11.25 4x 10 minutes 8 1.41 1 hour 22.5 2x 30 minutes 16 1.41 2 hours 45 2x 1 hour 32 1.41 5 hours 112.5 2x 2 hours 64 1.76 10 hours 225 2x 5 hours 128 1.76 12 hours 270 2x 10 hours 256 1.05 24 hours 540 2x 12 hours 512 1.05

[0133] This can result in more chunks per pixel on average, up to 1.76 for the two values which happen to be just below powers of two. This algorithm has some subtle differences to theRMDDHI 3.4-005 (21) factorisation algorithm. Instead of finding the min and max of an arbitrarily large chunk, the approach just compares two values every time. Instead of calculating each target’s best zoom level, the process keeps going until only a single value remains. However, a benefit of bifurcation over factorization is that the bifurcation process (such as with the example code implementation shown below) can guarantee an avoidance of repeating work. Every time the process compares two samples, it is the first and only time those two samples are compared. Such comparison minimalization is not guaranteed for plain factorization. For example, two target zoom levels may be different factors of the same earlier target. So even though the bifurcation process may generate more output data when compared to the factorisation algorithm / process, the bifurcation process can actually do less processing work on average to create the output data.

[0134] FIG. 8A illustrates a bifurcation down-sampling process, in which the entirety of a data chunk is at the top of the figure, and then pair-wise min / max down sampling reduces the chunk to a single pair of values (minimum and maximum of the entire chunk) at the bottom of the figure. In FIG.11A, each node contains the min and max of its two child nodes, each layer of the tree can be one of the arrays that can be displayed in the display time window, and the “leaves” at the top of the figure represent the raw samples of the HDR data.

[0135] An example bifurcation implementation, in TypeScript code, is: const minOut: number[][] = [Array.from(data.data)]; const maxOut: number[][] = [Array.from(data.data)]; for (let i = 1; i <= Math.ceil(Math.log2(data.data.length)); i++) { console.log(Math.pow(2, i)); const zoomMin: number[] = []; const zoomMax: number[] = []; / / compare pairs of data for (let j = 0; j < minOut[i-1].length; j += 2) { if (j === minOut[i-1].length - 1) { zoomMin.push(minOut[i-1][j]); zoomMax.push(maxOut[i-1][j]); } else { zoomMin.push(Math.min(minOut[i-1][j], minOut[i-1][j+1])); zoomMax.push(Math.max(maxOut[i-1][j], maxOut[i-1][j+1])); } } minOut.push(zoomMin); maxOut.push(zoomMax); }RMDDHI 3.4-005 (21)

[0136] This implementation can be achieved with much less code than a more general factorization process as previously described, and can perform better on average in terms of reduced processing time.

[0137] Such a bifurcation process as described herein can also allow the user interface (GUI) to be a lot more flexible. In this regard, if the user resizes their display application or window, such as a browser, or if arbitrary zoom level selection is enabled, the process can just display a best fitting array that is within an acceptable limit of chunks per pixel. Since the process evaluates the HDR data for the potential zoom levels very efficiently, it also has an advantage over other processes that would otherwise re-calculate on demand. 4.5.1.5. Performance Improvements

[0138] The quickest and easiest technique for coding of the data processing is to have the processor recalculate the needed samples for display on the fly. That is, every time the display time window changes, such as in response to a user selection, a data service takes the raw data, trims or crops it to a chart's domain such as by removing data or extracting portions of the data, and processes that data using a downsampling (e.g., the min, max of chunks), or upsampling, and optional filtering (e.g., lowpass filters). In such a case, the processed data does not need to be cached or saved, and all processing may be done using normal, synchronous functions. Performance results for such an approach can be acceptable, but can be improved by implementing parallel processing such by dividing the processing functionality using multiple threads. For example, the processing (e.g., down sampling) may be performed in its own thread, such as using a Web Worker or other similar software element / function. A Web Worker is a JavaScript script executed from an HTML page that runs in the background, independently of scripts that may also have been executed from the same HTML page. In such an implementation, the raw HDR data may be passed into a new thread, which runs the processing algorithm, and passes the processed data back to a main application thread. Another way to reduce the processing requirements of a main thread is to have the processing done before any animation (i.e., rendering) begins. Pre-processing the data can allow a graphic chart to simply access the already processed data on demand, and can avoid overhead introduced by multi-threading. These two strategies may be implemented together. For example, a web worker may be implemented to process one zoom level the first time a zoom level isRMDDHI 3.4-005 (21) requested, and a main thread may be implemented to cache that data and use that data from that point on.

[0139] Additional pre-processing steps may be taken to further improve the display efficiency. To pre-process the data, an array of raw samples may be converted into a processed data object for every zoom level, (e.g., ten in total or as needed). Each such object may have one or more arrays of data depending on processing (e.g., a min array, a max array, and / or a filtered array (e.g., lowpass data)) and, optionally the data's frequency. For lower zoom levels (i.e., higher resolution), each data array may be millions of samples long, so even though the algorithms being used are not that complex the amount of work may be substantial.

[0140] There are a number of different approaches that may be implemented to achieve this processing.

[0141] In some implementations, a loop may be run, when a page first loads. The loop may iterate over a set of zoom levels (such as the available zoom levels) and using the existing processing methods to generate the processed data. In some applications, helper functions or applications that provide parallel processing (e.g., additional threads), such as Web Workers, may be implemented for such pre-processing, which can reduce the delay of initialisation of a main thread. Optionally, several helper functions / applications (e.g., WebWorkers) can implement the pre-processing with each one pre-processing a different zoom level. Further efficiency improvements can be achieved with selection of data structures for the data that can minimize operations when sharing data between threads. In some implementations, to speed up the initial load time of a page, the page may be configured to render one zoom level as soon as the data is processed (e.g., a 24 hour data which may be selected since it has the shortest pre-processing time), while the remainder of the zoom levels are still in-process. 4.5.2. UP-SAMPLING DATA

[0142] As previously mentioned, when the number of samples available for display of the HDR data for a given display time window is less than the pixel width of a display window, additional points are generated so that the full pixel width may be utilized. Various up-sampling processes may be implemented to establish such additional points, such as by interpolation. Some example approaches may include a spline methodology and / or a filtering methodology.RMDDHI 3.4-005 (21) 4.5.2.1. Splines

[0143] One example approach to up-sampling is to generate points using a spline function. A spline is a piecewise polynomial equation that has coefficients for each piece that are chosen to fit the equation’s curve to the known samples between the end points of that piece. Various types of splines may be implemented. Typically, spline functions are zero, first, or third-degree according to the highest power of the polynomial (e.g., a third-order spline has a cubic term in each of its equations). Most splines are fitted precisely to the data, whereas some splines have a relaxed fit in that the equations do not perfectly match to the known points. Examples of splines include a zero- degree stepwise spline; a first-degree linear spline; and various third-degree splines such as bump curves, monotone curves, basis splines, cardinal splines, and natural splines (including Catmull- Rom splines).

[0144] FIG.8B shows a stepwise spline 11002 interpolating real respiratory therapy data 11000. The zero-degree spline just plots the constant value of the sample, and then instantly steps to the value of the next sample. The approach lacks a quality of “smoothness” that would make it attractive and therefore more desirable for interpolating data that is supposed to be continuous. Smoothness is a useful heuristic for assessing interpolation since it may be assumed that the original HDDR data is perfectly continuous.

[0145] FIG. 8C shows a linear spline 11004 interpolating the same real respiratory therapy data 11000. For real data, the edges of this spline are quite sharp around the peaks and troughs, but it produces a fair representation of the actual overall shape of the HDR data curve. However, higher- frequency signals are not handled so well. In this regard, this spline of Fig.8C has C0 continuity, which means that all the segments meet, but it has a jagged appearance because it lacks C1 continuity. This means that the derivative of the spline is not continuous.

[0146] Another type of spline is a cubic spline, which uses segments of the form y=ax3+bx2+cx+d. Cubic splines may be implemented so that C1 continuity is guaranteed. There are many ways to represent and compute cubic splines. For example, a cubic spline may be implemented with Bézier curves, which are a form natively supported by browser code. The shape of a Bézier curve is defined both by its end points, and by two control points that make the shape curve more or less and / or in different directions between the end points. For different types of cubic spline, the Bézier end points and control points are differently determined.RMDDHI 3.4-005 (21)

[0147] FIG. 8D shows a bump curve spline 11006 interpolating real respiratory therapy data 11000. The control points of a bump curve are set so that the tangent of the curve at each sample is horizontal (C1=0). This creates a sort of smoothed-out version of the step graph, with a flat section at each sample.

[0148] FIG.8E shows a monotone curve spline 11008 interpolating real respiratory therapy data 11000. A monotone curve always stays between its two end points - it will never create a turning point between two samples. This property was also true for the bump curve, and the monotone curve appears like a more smoothed out version of the bump curve.

[0149] FIG.8F shows a basis spline 11010 interpolating real respiratory therapy data 11000. Basis splines, or B-splines are a family of cubic splines which maximise continuity. They are excellent for producing very smooth curves, which make them very useful in animation and industrial design. Unfortunately, to have perfect smoothness, basis splines sacrifice accuracy: they don’t pass through the samples. A basis spline stays smooth by avoiding turning too sharply, which means that higher frequencies of the samples are removed.

[0150] FIG. 8G shows a cardinal spline 11012 interpolating real respiratory therapy data 11000. Cardinal splines set the tangents at each sample to a value based on a line between the two adjacent samples, multiplied by a “tension” constant. If that constant is set to zero, it would be a bump spline, but it’s most commonly set to 0.5, which is called a Catmull-Rom spline. On equally-spaced data, that tension of 0.5 produces a decent estimate of the derivative.

[0151] FIG. 8H shows a natural spline 11014 interpolating real respiratory therapy data 11000. The natural cubic spline is created by imposing restrictions on the shape: It provides C2 continuity (the second derivative is continuous), and also passes through all samples. These restrictions create a system of equations with one solution, which is the natural cubic spline. The result is a very smooth spline with no local control at all - changing one sample will change the entire curve to some extent. These are both true properties of typical respiratory therapy data, and the natural spline can provide a good approximation.

[0152] Any type of cubic spline is likely to be highly performant for rendering HDR data in a browser, because modern browsers render Bézier curves on-the-fly. However, it is possible to improve on the apparent accuracy of interpolation by enhancing the cubic spline with a prior stepRMDDHI 3.4-005 (21) of up-sampling such as by additionally applying a filter to the HDR data as discussed in more detail herein. 4.5.2.2. Filtering

[0153] For example, various filters can be used to interpolate the HDR data. Such a process may involve padding additional null or zero values into the HDR data signal and then filtering the padded HDR data signal to produce an up-sampled signal. One example filter that may be implemented in such a process may be a Finite Impulse Response (FIR) filter. This can be used to adjust or filter a curve’s shape particularly given the padded values. For example, a data signal (such as the output of a prior decompression), such as at a first sampling rate (e.g., 6.25 Hz) may be padded with values, such as between each sample point from the signal so that the resulting signal is at a desired data rate (e.g., 25 Hz). For example, by inserting three zeros between each sample of 6.25 Hz data, a 25 HZ data signal is produced. However, the zeros result in an HDR data signal with a spikey appearance that is not appropriate for display. By thereafter applying a filter to the signal, such as an FIR filter, the HDR data signal becomes more like the original respiratory device HDR data. In this regard, keeping the original samples preserves all the information in the original signal, and adding the zeros increases the sample rate but adds new high-frequency noise into the HDR signal. This noise is above the original signal’s Nyquist rate, which means it can be removed with a filter, such as a low-pass filter, without affecting the original signal. Such a low-pass filter, e.g., a FIR filter, may then produce the up-sampled data that is suitable for display.

[0154] A theoretical perfect low-pass filter would preserve all the low-frequency signals up to a certain point, and completely remove all frequencies above that point. Real low-pass filters will always introduce some noise and have a gradual drop off instead of a perfect cutoff at a particular frequency.

[0155] The impulse response of a filter is a measure of how much any individual sample transforms the output. A filter’s impulse response can be found by running two signals which differ by just one sample through the filter, and taking the difference between the two outputs. Filters with a finite impulse response will transform an area of the signal around the changed sample, but stop affecting it at all after a certain point. This is in contrast to infinite impulse response (IIR) filters, where the entire output will be affected by changing any sample.RMDDHI 3.4-005 (21)

[0156] In practice, a FIR filter is a list of samples of the impulse response, scaled so that all samples add up to 1. Since this impulse response represents how the surrounding samples affects the output, it can be applied by taking a weighted average of surrounding samples using the impulse response as a weighting. This is a mathematical operation called convolution.

[0157] For up-sampling, a FIR filter works out conveniently. All the zeros that are added to pad between the points of the original data stream will be essentially ignored, so the filter will just be applying the original samples. The output may be multiplied by a scaling factor to get a good approximation of the original signal at the new sample rate.

[0158] For example, a “21 tap” FIR filter has 21 samples of impulse response (coefficients). It may be applied to the signal data x using the equationx[n] is the input signal y[n] is the output signal N is 20 for this 21-tap, “20thorder” FIR filter, and b is the vector of floating-point coefficients, and may be defined, for example, as const b = [ -0.0000136266019965541612944974134147280153683823300526, 0.0003623537545148890356115634059364083441323600709438, 0.0006897516033274009002521087730031013052212074398994, -0.0004629595482407493313090074416038532945094630122185, -0.0039420043349947912758590717885454068891704082489014, -0.0043866499744409405414646840881687239743769168853760, 0.0119759284681171199876681399132394290063530206680298, 0.0579666209756930714269707038965862011536955833435059, 0.1289440906459027036401465693415957503020763397216797, 0.1965551468091850939590159441650030203163623809814453, 0.2246226964058655461986546697517042048275470733642578, 0.1965551468091850939590159441650030203163623809814453,RMDDHI 3.4-005 (21) 0.1289440906459027036401465693415957503020763397216797, 0.0579666209756930714269707038965862011536955833435059, 0.0119759284681171199876681399132394290063530206680298, -0.0043866499744409405414646840881687239743769168853760, -0.0039420043349947912758590717885454068891704082489014, -0.0004629595482407493313090074416038532945094630122185, 0.0006897516033274009002521087730031013052212074398994, 0.0003623537545148890356115634059364083441323600709438, -0.0000136266019965541612944974134147280153683823300526 ];

[0159] FIG. 8J shows a 21-tap finite impulse response (FIR) filter 11016 interpolating real respiratory therapy data 11000. The shape of the FIR filter output is very similar to the Catmull- Rom spline. Some jagged edges in the turning points may be visible depending on the sample resolution and the number of pixels for each sample.

[0160] Such a filter can be created to produce the desired appearance to mimic the original signal. For example, a tool, such as filter generation tool, can be used to generate arbitrary FIR filters based on selecting filter parameters as desired for producing suitably appearing output. Some filter tools may take inputs for the passband and stopband, which is the section of frequencies we want to allow and remove respectively. For example, a sampling rate of 25 Hz may be set and the passband may be set be 0 to 3.125 Hz with a 1db ripple. Ripple refers to how much distortion is introduced to these frequencies. In the example, the stopband may be set to -40db of ripple beginning at 3.25 Hz and above, which means these frequencies will be reduced to less than 1% of their original amplitudes. Setting the stopband to just .125 Hz above the passband gives the filter a relatively short falloff. The FIR filter produced by such a filter generation tool for these parameters may have 307 taps. As one might expect, it is computationally slower than the splines or the 21-tap filter.

[0161] With the lines overlaid, as in FIG.8K, this example filter 11018 can produce a signal that is practically indistinguishable from the original signal 11000. However, there can be a slight ripple in the filter output compared to the “actual” curve.

[0162] It is worthwhile to consider computational performance of the various up-sampling methods, as in practice the display should load within a user’s expected time. For data around 10RMDDHI 3.4-005 (21) hours long (225,000 samples), measured speed of several approaches are listed in the following table. Technique Time (ms) Linear spline 92 Catmull-Rom spline 293 Natural spline 320 21-tap FIR filter, 25 Hz 1545 693-tap FIR filter, 25 Hz 69466 348-tap FIR filter, 12.5 Hz 17720

[0163] In one or more implementations, it may be desirable to have a display refresh on a change of zoom in less than 100 ms. It may be acceptable to have a display refresh in a longer period of time if an attractive loading graphic is displayed. A refresh delay of up to about 2 seconds may be acceptable in some applications, particularly if interactivity is expressly limited during refresh (e.g., controls for zooming / panning are greyed out and inoperative).

[0164] Accordingly, in some implementations, a natural spline may be used to interpolate the data. In some implementations, a filter, such as a 21-tap 25 Hz FIR filter, may be combined with a natural spline, a Catmull-Rom spline, or other suitable spline to interpolate the data. Selection of such approaches may depend on desired speed as well as nature of the data to be upsampled (e.g., sample frequency, signal length, and / or display window width). For example, for displaying some data, a first stage of filtering may be applied (e.g., a four-stage upsampling filter) such as to increase the sample rate (e.g., by doubling) part of the way to a desired higher frequency resolution, and then that data may be rendered using a spline function (e.g., a natural spline) to achieve a sample rate at the desired higher frequency resolution.

[0165] In some implementations, upsampling, such as for zooming in to see a set of data points of any of the high-resolution signals previously described when the zooming to a given set of data points would, without upsampling, result in a plurality of pixels per available datapoint, may be achieved by implementing one or more transforms, such as using Fourier transforms. For example, the method may divide a set of samples, such as the samples of a high-resolution data signal that may be displayed as previously discussed, into sequential chunks. The number of samples in eachRMDDHI 3.4-005 (21) chunk may be a power of two (e.g., 512 etc.) The chunks may also overlap, such that a given chunk may overlap (at least in part) with a preceding chunk and may overlap (at least in part) with a succeeding chunk. For example, except for end chunks, the samples of a first half of each chunk may be the same samples as the samples of a second half of each preceding chunk. As such, the samples of a second half of each chunk may be the same samples as the samples of a first half of each succeeding chunk. These chunks may be applied to a smoothing or filtering operation, such as a windowing function (e.g., a Hann function). The chunks (e.g., smoothed chunks) may then each be applied to a transform function, such as a Fourier transform (e.g., a discrete Fourier transform). The signal represented by each transformed chunk may then be padded with values (such as zeros) to increase data resolution. For example, in the case of a Fourier transform, zero values may be applied (e.g., 512 data points etc.), such as at a spectral center of the transformed data, to each frequency domain chunk to effectively add data points (null frequency information) to the signal in the frequency domain without adding frequency information into the signal. Such addition of data points may, for example, double the length of the data of the transformed chunk. Each of the padded chunks may then be inversely transformed (e.g., by inverse Fourier transform back into the time domain). Such transformed chunks may then have more data points than prior to the transformation and padding. In the example case of the original chunks of 512 samples with padding of 512 zero valued samples, the re-transformed chunks may each then have double the original data points (e.g., 1024 samples in the time domain). The chunks may then be combined into a signal with a higher resolution from the originally chunked signal. Such combining may involve adding the overlapped portions of each of transformed chunks to produce the displayable datapoints of the higher resolution signal. Such a process may suitably permit upsampling of the signal. It may introduce some noise, but the resulting signal may be acceptable for the data viewing purposes described herein. Nevertheless, the method, in some cases, may be suitably faster than convolution with a FIR filter as previously described. Such an upsampling calculation process may be applied following transfer of the data from the aforementioned server system to the client device (e.g., at loading time) so that the data is readily available in the event of a user zoom operation is made on the user interface that demands the higher resolution signal. 4.6. EXAMPLES OF GRAPHICAL USER INTERFACES

[0166] As mentioned previously, the respiratory therapy monitoring system may provide orRMDDHI 3.4-005 (21) generate one or more graphical user interface(s) (GUI) for displaying provided respiratory therapy data, such as HDR data and low resolution data, according to various implementations of the present technology. The GUI may be displayed in / by a client-side application (app) operated by a client device, such as client device 109. In some implementations, the app may be a thin client app, such as a web browser, terminal emulator, virtual desktop infrastructure (VDI) client, remote desktop client, cloud access agent, and / or some other software application that relies on a server, such as server(s) 102, for a relatively large amount of processing, storage, and / or other computational resources. In other implementations, the app may be a thick client (or rich client) app, such as a special-purpose app, proprietary app, and / or some other software application that performs a relatively significant amount of processing on the client-side with little or no server- side resources. In either of these implementations, the app may be a mobile app specifically tailored to operate on a mobile device, such as a smartphone, tablet computer, and / or the like. Additionally or alternatively, the GUI may be a single page application (SPA), which is an app, such as a web app, that runs inside a single webpage or screen residing in the client app with all supporting content such as markup, style, and scripts retrieved during the initial page load. In an SPA, page content is manipulated behind the scenes using client-side scripts and / or other program code.

[0167] Example GUI’s are shown in FIGs.8-12W. Aspects of the examples GUI described herein may be formed using any suitable GUI elements such as general-purpose and / or custom-designed components and / or containers.

[0168] Such GUI elements may be implemented using any suitable GUI technologies, such as web development technologies (e.g., HTML CSS, ECMAScript or JavaScript, Angular, React, and the like), GUI frameworks and toolkits (e.g., Java Swing, JavaFX, windows presentation foundation (WPF) framework, Qt, GIMP toolkit (GTK), SwiftUI, Android SDK, Kotlin, and / or the like), and / or other software development tools and programming languages. 4.6.1. GRAPHICAL USER INTERFACE LAYOUT

[0169] FIGs.8-12Q show various views of a GUI instance 800. The GUI instance 800 includes a header section 801, a navigation section 802, and a body section 803. The header section 801 may include a set of patient data. For example, as shown by FIG.8, the set of patient data may include various information about the subject patient, for example, patient name (e.g., “J. Doe”), patientRMDDHI 3.4-005 (21) ID, date of birth, setup date, complaint(s), and / or the like. In some implementations of the present technology, each section 801, 802, 803 may be defined using respective sets of tags, such as division tags (“”), span tags (“”), inline frame tags (“<iframe>”), section tags (“<section>”), header tags (“<header>”), and / or the like, wherein such tags may include identifiers, attributes, and / or values used to define each section 801, 802, 803. Furthermore, any of the GUI sections, panels, components, and / or the like discussed herein may be defined using such tags. Such tags, and the content therein, may be dynamically manipulated using suitable scripting languages and / or other technologies. Such dynamic manipulations may be based on user interactions with the content within the GUI.

[0170] For example, the navigation section 802 includes a set of toggleable tabs. For example, as shown by FIGs. 11A and 11B, the set of tabs includes a charts tab, a “Nightly data”, a patient details tab, a prescription tab, a remote access tab, a notes tab, a logs tab, and a preferences tab. Additional or alternative tabs (or tab labels / names) and / or patient data 811 may be included in various implementations of the present technology. The navigation section 802 can include other types of navigation elements, such as an icon bar, expandable menu, vertical tabs, hover tabs, a navigation bar, fixed or responsive sidebars, pill navigation, and / or the like.

[0171] When a breath by breath (BBB) data feature is activated or turned on (see e.g., FIGs.5A and 5B), then the “Nightly data” tab may be present in the set of tabs 810. When the nightly data tab is activated (e.g., by clicking or tapping on the “Nightly data” tab), the body section 803 may display a BBB data interface. The BBB data interface allows a user to view high resolution and low resolution data for individual patients. In the examples of FIGs.11A to 13, the “Nightly data” tab is active unless explicitly stated otherwise. The BBB data interface may include a summary data interface and a high resolution data interface. An example of such a summary data interface is shown by FIGs. 11A-11O. An example of such a high resolution data interface is shown by FIGs.12A to 13. 4.6.2. SUMMARY DATA INTERFACE

[0172] FIGs.11A-11O show example views of a summary data interface. Referring to FIG.11A, the summary data interface may comprise panels or components such as three panels or components. These panels / components may include a calendar view panel 820, a therapy metrics panel 830, and / or a detailed view panel 840. The calendar view 820 includes calendar GUI elementRMDDHI 3.4-005 (21) 821. The calendar GUI element 821 includes a set of respiratory therapy periods 922, which may also be referred to as a set of sleep periods 922, during which data may (or may not) have been collected by a therapy device 104 for the patient (i.e., “J. Doe”). As shown by FIG.11B, the set of respiratory therapy periods 922 includes individual respiratory therapy periods 923, which may also be referred to as individual sleep periods 922. Note that not all respiratory therapy periods 923 are labeled in FIG. 11B in order to avoid obstructing the view depicted by FIG. 11B. Here, each respiratory therapy period 923 corresponds to a calendar date. For example, November 4, 2023 may correspond to a first respiratory therapy period 923, November 5, 2023 may correspond to a second respiratory therapy period 923, and so forth. Other implementations may include additional or alternative forms of categorizing or classifying respiratory therapy periods 923. Each respiratory therapy period 923 in calendar 821 includes a graphical representation of a data buffer 823. Each graphical data buffer 823 graphically represents an amount (or an estimated amount, within some standard deviation or margin of error) of data collected, or accumulated therapy usage time, for its corresponding respiratory therapy period 923. Note that not all of the data buffers 823 are labeled in FIG.11A.

[0173] In some implementations, color coding may be used to show whether a threshold amount of data is / was collected (or accumulated therapy usage time) for each respiratory therapy period 923. For example, a first color (e.g., red) may be used to show that the amount of data collected (or accumulated therapy usage time) for a specific respiratory therapy period 923 is below the threshold amount, such as is the case for buffer 823a. By way of another example, a second color (e.g., green) may be used to show that the amount of data collected (or accumulated therapy usage time) for a specific respiratory therapy period 923 is at or above the threshold amount, such as is the case for buffers 823b and 823c. By way of yet another example, a third color may be used to indicate that no data was collected (or there is no accumulated therapy usage time) on a specific respiratory therapy period 923, such as is the case with buffers 823d and 823e. The threshold amount of data can be expressed in a variety of ways. For example, the threshold amount of data can be expressed as an amount of time over which data was collected, such as 4 hours or the like. In another example, the threshold can be expressed as a number of samples collected, such as 360,000 data samples with a sampling rate of 25 Hz. In yet another example, the threshold can be expressed as an amount of used memory / storage space used to store the sampled data, such as XRMDDHI 3.4-005 (21) gigabytes (Gbs) (where X is a number) or the like. Additional or alternative threshold types and / or amounts / levels may be used in various implementations of the present technology.

[0174] A more detailed view of the amount of data collected for a specific respiratory therapy period 923 can be seen by hovering a pointer over its data buffer 823. For example, as shown by 11C, the user’s pointer may be hovered over buffer 823e, which causes a tooltip 1023 to be displayed. A tooltip is a small, contextual pop-up box that appears when the user hovers their pointer over a specific graphical element in the GUI 700a. The tooltip 1023 shows the amount of usage of a device 104 (a total amount) for that respiratory therapy period 923, which in this example, is 4 hours and 28 minutes.

[0175] The calendar view 820 includes a set of time period selection graphical elements 822. In the examples of FIGs.11A to 11O, the time period selection graphical elements 822 are embodied as a vertical menu. However, the time period selection graphical elements 822 can be formed using other GUI elements such as click dropdown menus, hamburger button menus, and / or the like. Each time period selection graphical elements in set 822 allows a user to select a desired time period 824 to be highlighted within the calendar view 820. Some of the time period selection graphical elements in the set 822 correspond to preset or default time periods, and a “custom” time period selection graphical elements in the set 822 allows the user to select a desired time period range. For example, as shown by FIGS.11A and 11B, the “7 days” time period graphical element in set 822 is shown as having been selected, and thus, the most recent seven days for which a therapy device 104 was used is highlighted in a time period section 824 of the calendar view 820. The “7 days” time period is also reflected by the “7 days” label in the time period section 824. By way of another example, FIG.11G shows a “Latest” time period graphical element in set 822 as having been selected, and thus, a most recent day (e.g., Sunday, December 2, 2023 in FIG.11G) that the therapy device 104 was used is highlighted in time period section 824. By way of yet another example, FIG.11H shows the “30 days” time period graphical element in set 822 as having been selected, and thus, the most recent 30 days that the therapy device 104 was used is highlighted in time period section 824. As shown by FIG.11I, selection of the “30 days” time period graphical element in set 822 may cause a date range selection window / pop-up GUI element 700c to be displayed. The GUI element 700c allows the user to select a desired 30 day time period to be highlighted in the time period section 824. Additionally, selection of the “Custom” time periodRMDDHI 3.4-005 (21) graphical element in set 822 may also cause the date range selection GUI element 700c to be displayed. Here, the GUI element 700c may allow the user to select a desired custom date range to be highlighted in the time period section 824. As discussed in more detail herein, the data collected during the highlighted time period can also displayed in more detail in the detailed view panel 840.

[0176] The time period section 824 includes a subset of respiratory therapy periods 923 that is / are highlighted or otherwise visually distinguished from other respiratory therapy periods 923 that may be displayed in the calendar GUI element 821. The time period visually distinguished by the time period section 824 is bounded by, or otherwise within, time period boundary graphical elements 924, which may also be referred to as “delimiter elements 924”. In some implementations, the desired time period to be reviewed can be expanded or shortened by dragging one or both of the boundary elements 924 to include or exclude specific respiratory therapy periods 923 within the time period section 824. For example, in FIG.11B, a first boundary element 924 may be dragged to the left to include Saturday, November 26, 2023. In another example, the first boundary element 924 may be dragged to the right to exclude Sunday, November 27, 2023 from consideration. Additionally or alternatively, the time period section 824 can be embodied as a sliding window or slider graphical control element (GCE) that may be dragged as a single unit to cover a desired time period. For example, the movement of the sliding window can be accomplished by clicking (or tapping) and holding an area between the boundary elements 924 and moving the pointer (or a finger / stylus) to cover a desired section of the calendar 821. In these implementations, the calendar GUI element 821 may be configured as a trough or track over which to move the slider time period section 824.

[0177] Selecting one of the graphical elements 822, or moving one or both of the boundary elements 924, causes the therapy metrics panel 830 to be dynamically updated to show various metrics for the selected time period of the time period section 824. The therapy metrics panel 830 provides a summary of the therapy usage for the selected time period. For example, as shown by FIGS. 11A and 11B, the “7 days” time period graphical element 822 is shown as having been selected, which causes the time period section 824 to include the most recent 7 days, and also causes the total usage metric in the therapy metrics panel 830 to show “7 days” of total usage.

[0178] The therapy metrics panel 830 also shows various usage metrics for a given therapy deviceRMDDHI 3.4-005 (21) 104, various therapy metrics, and various respiratory indices. The specific metrics displayed may be predefined or configurable. The user may also scroll through the therapy metrics panel 830 independently of the other panels / components of the BBB data interface, as is shown by FIG.11J. Additionally, the “Total usage”, “Therapy”, and “Respiratory indices (events per hour)” list items are configured as accordion or collapsable GCEs. Each accordion element can be expanded or collapsed to reveal or hide the content associated with that item. As shown by FIGs.11D to 11E, each of the accordions are in the expanded view showing the associated content. For example, the “Therapy” item, when expanded, shows “Leak – L / min” and “Pressure – cmH20” metrics. Each of the accordion list items may be collapsed to hide the associated data by, for example, clicking (or tapping) on the label or the corresponding triangle icon.

[0179] Referring now to FIG.11B, the detailed view panel 840 provides an overview of respective respiratory therapy periods 923 and the display may be dynamically limited to the data periods as selected in relation to time period section 824, such as with delimiters 924. Thus, the detailed view panel 840 may include a therapy data panel 902 for each respiratory therapy period 923 included in the time period section 824. For example, as shown by FIG.11B, when the time period section 824 is adjusted to include Sunday, November 27, 2023 through Saturday, December 2, 2023, the detailed view panel 840 includes respective graphical display panels for each. Here, the therapy data panel 902a corresponds to Saturday, December 2, 2023, and the therapy data panel 902b corresponds to Friday, December 1, 2023. The user may scroll through the detailed view panel 840 independently of the other panels / components of the BBB data interface, as is shown by FIGS. 11D through 11F such as to view each of the data panels 902 that is associated with a period of the time period section 824. It is noted some of such panels might not be displayed at this same time as others given limited display screen area but can be viewed by scrolling. For example, as shown by FIG.11D, the therapy data panel 902c corresponds to Thursday, November 31, 2023. As shown by FIG. 11E, the therapy data panel 902d corresponds to Tuesday, November 29, 2023, and the therapy data panel 902e corresponds to Monday, November 28, 2023. Furthermore, as shown by FIG.11F, the therapy data panel 902f corresponds to Sunday, November 27, 2023. Note that the therapy data panels 902c and 902f show that no data was collected for those days, which is also reflected by the graphical buffers 823d and 823e. It should also be noted that only a single therapy data panel 902a is shown by FIG. 11G because only a single day is selected for review.RMDDHI 3.4-005 (21) Furthermore, although FIG. 11H only shows a single therapy data panel 902a for a 30 day time period, it should be noted that multiple therapy data panels 902 may be displayed in the detailed view panel 840 and visibility of such data panels 902 may be limited by display screen area.

[0180] Each therapy data panel 902 may be a snapshot, or display of a waveform as discussed in more detail herein, for a period of therapy provided to a patient. Each therapy data panel 902 may include a set of measurement parameters / metrics for data of the corresponding therapy data panel 902. For example, in FIGS.11A to 11O, the measurement metrics include “start”, “end”, “usage”, “leak”, “AHI” (apnea hypopnea index), and “CSR” (Cheyne-Stokes respiration). Each therapy data panel 902 also includes a respective set of signal selection graphical elements 942. For example, in FIGS.11A, 11K, and 11L, therapy data panel 902a includes a set of signal selection graphical elements 942a and therapy data panel 902b includes a set of signal selection graphical elements 942b.

[0181] In the examples of FIGs. 11A-11O, each set of signal selection graphical elements 942 includes a flow signal graphical element, a leak signal graphical element, and a pressure signal graphical element, each of which may be derived from the previously discussed high resolution data, and which are associated with the time period of the particular therapy data panel. Additional or alternative graphical elements for additional or alternative signals can be included in individual selection sets 942. Selection of one of the signal selection graphical elements 942 causes a corresponding signal waveform to be displayed within a corresponding therapy data panel 902.

[0182] For example, as shown by FIG.11B, in therapy data panel 902a the flow signal graphical element in set 942a is shown as having been selected, and thus, a flow signal waveform graph 989a (also referred to as a “flow curve 989a”) is displayed in therapy data panel 902a. Additionally, in therapy data panel 902b the flow signal graphical element in set 942b is shown as having been selected in therapy data panel 902b, and thus, a flow signal waveform graph 989b is displayed.

[0183] By way of another example, as shown by FIG. 11K, in therapy data panel 902a the leak signal graphical element in set 942a is shown as having been selected, and thus, a leak signal waveform graph 1189a is displayed in therapy data panel 902a. By way of yet another example, as shown by FIG.11L, in therapy data panel 902a the pressure signal graphical element in set 942a is shown as having been selected, and thus, a pressure signal waveform graph 1289a is displayed in therapy data panel 902a. In both of the examples of FIGs.11L and 11L, the flow signal graphicalRMDDHI 3.4-005 (21) element in set 942b is shown as remaining selected, and thus, the flow signal waveform graph 989b is still displayed in corresponding therapy data panel 902b. Additional or alternative signals and corresponding signal selection graphical elements 942 may be included in various implementations of the present technology.

[0184] A signal waveform, such as in relation to the therapy data panel 902, is a visual representation of data, such as the previously discussed high resolution data, of a signal measured over a period of time, such as a respiratory therapy period 923. A waveform graph may include a set of event markers 988. In various implementations of the present technology, the event markers 988 may be vertical lines, bars or bands, that are overlaid on individual waveforms. The visible width of each marker may depend on the zoom level of the graph of the panel and the duration of time of the event that the marker represents. Note that not all event markers 988 are labeled in FIGS.11A-11O. The event markers 988 represent a detected sleep related event that was detected at a particular time instant or period within the signal. The detection of individual events may be performed by the respiratory therapy monitoring system 100, the therapy device 104, and / or by the client device 109 and may be by the event detection methods (e.g., apnea (obstructive or central), hypopnea (obstructive or central), respiratory effort-related arousal, Cheyne-stokes respiration, flow limitation, and / or snore, etc.) as discussed in more detail herein.

[0185] A more detailed view of individual events can be seen by hovering a pointer over an event marker 988, which causes a tooltip to be displayed. The tooltip shows the type of event that corresponds to the marker 988 and may include information about the event such as an amount of time for the event occurred. For example, as shown by FIG. 11M, the user’s pointer may be hovered over an event marker 988a, which causes a tooltip 1388 to be displayed. The tooltip 1388 shows that event marker 988a corresponds to a hypopnea event that occurred for 10.3 seconds. In another example, as shown by FIG.11N, the user’s pointer may be hovered over an event marker 988b, which causes a tooltip 1488 to be displayed. The tooltip 1488 shows that event marker 988b corresponds to a respiratory effort-related arousal (RERA) event that occurred for 7.9 seconds. By way of another example, as shown by FIG.11O, the user’s pointer may be hovered over an event marker 988c, which causes a tooltip 1588 to be displayed. The tooltip 1588 shows that event marker 988c corresponds to an obstructive event (e.g., apnea or flow limitation) that occurred for 16 seconds. In some implementations, color coding may be used to differentiate between differentRMDDHI 3.4-005 (21) types of events. For example, a first color (e.g., orange) may be used to show hypopnea events, such as is the case with event marker 988a, a second color (e.g., green) may be used to show RERA events, such as is the case with event marker 988b, a third color (e.g., purple) may be used to show obstructive apnea events, such as is the case with event marker 988c, and a fourth color (e.g., yellow) may be used to show desaturation (dSAT) events. Still further, a fifth color may indicate central events (e.g., central apnea). In these ways, the event markers and tooltips allow users to quickly view the specific events that occurred during the subject respiratory therapy period 923 without the need to pogo stick between different applications or different GUI instances.

[0186] Additional or alternative events may be detected and overlaid on the waveforms in various implementations of the present technology. For example, as more high and low resolution data is collected over time, and / or as insights, predictions, or inferences are generated based on the collected data, new events can be detected or identified and overlaid on the waveforms. 4.6.3. HIGH RESOLUTION DATA INTERFACE

[0187] Referring back to FIG.11B, each therapy data panel 902 includes its own view night button 945. For example, therapy data panel 902a includes a view night button 945a and therapy data panel 902b includes a view night button 945b. Selection of the view night button 945 in a particular therapy data panel 902 causes the GUI 700a to dynamically update the display area to show a high resolution data interface, such as the interface 1600 shown by FIGS.12A to 12Q, for interactively viewing high resolution data. In the example of FIGs. 12A to 12Q, the high resolution data interface 1600 corresponds to the therapy data panel 902a and shows a waveform including or derived from the high resolution data collected by a therapy device 104 on December 2, 2023. It should be noted that each therapy data panel 902 includes a respective view night button 945, which when selected, may cause the high resolution data interface to show the data corresponding to the respiratory therapy period 923 of that panel 902. Thus, the high resolution data interface may be a dynamic interface and / or include dynamic content that is updated based on user interactions with the GUI rather than requiring a page refresh or reload.

[0188] The view of the high resolution data interface shown by FIG. 12A provides a full respiratory therapy period summary of an entire respiratory therapy period 923. For example, therapy data panel 902a corresponds to a respiratory therapy period 923 of Saturday, December 2, 2023, and thus, selecting the view night button 945a dynamically updates the GUI to show theRMDDHI 3.4-005 (21) high resolution data interface for showing high resolution data collected on or during the respiratory therapy period 923 of Saturday, December 2, 2023. The high resolution data interface may also show usage metrics and high level metrics, such as “usage”, “leak”, “AHI”, and “CSR”, for that respiratory therapy period 923. The high resolution data interface may also include various content control elements, such as a hyperlink 1645, a dropdown menu 1610, a save to PDF icon 1611, a reorder charts icon 1612, and a details icon 1613. Selection of the hyperlink 1645 may navigate back to the summary data interface of FIGs.11A-11O. Selection of the save to PDF icon 1611 may export the high resolution data, as shown or in some other format, to a PDF document. The PDF document may then be saved in an electronic health record (HER) and / or be reviewed at a later time point. Selection of the reorder charts icon 1612 may allow the user to change the position and / or arrangement of the various waveform graphs 2189 within the high resolution data interface, as shown by FIGs.13A and 13B. Selection of the details icon 1613 may allow the user to display a device details panel, such as the device settings panel 900 of FIG.6C and / or the device details panel 2200 of FIGs.12H and 12I. The device details panel 2200 in FIGs.12H and 12I may be an off-canvas menu, collapsible side panel menu, collapsible sidebar menu, or the like. Activation of the details icon 1613 may expand or collapse the device details panel 2200. The device details panel 2200 is scrollable in a same or similar manner as the therapy metrics panel 830 discussed previously. Additionally, the device details panel 2200 includes a set of accordion / collapsible list items, such as “Device settings”, “Mask, tubing, humidifier”, “Total usage”, “Therapy”, and “Respiratory indices (events per hour)”. These accordion / collapsible list items may be expanded or collapsed in a same or similar manner as discussed previously.

[0189] The high resolution data interface includes a primary waveform panel 1602. In the examples depicted by FIGs. 12A to 12Q, the primary waveform panel 1602 corresponds to the selected therapy data panel 902a, and thus primary waveform panel 1602 includes the waveform graph 989a and the set of signal selection graphical elements 942a discussed previously. FIG.12A shows an example where the flow signal selection element in set 942a has been selected, and thus, the flow signal waveform graph 989a is displayed in the primary waveform panel 1602. However, it should be understood that selection of the leak signal selection element in set 942a or the pressure signal selection element in set 942a may cause display, in the primary waveform panel 1602, of the leak signal waveform graph 1189a or the pressure signal waveform graph 1289a, respectively.RMDDHI 3.4-005 (21)

[0190] The primary waveform panel 1602 may act as a signal navigation element or scrubber for analyzing the displayed signal / waveform. For example, as is discussed in more detail herein, the various GCEs in the primary waveform panel 1602 may be used to focus on different aspects of the displayed waveform, and can be used to dynamically change and / or update GUI elements in other parts of the GUI instance 700a. Thus, the primary waveform panel 1602 may also be referred to as a “navigation waveform panel”, a “scrubber waveform panel”, a “summary waveform panel”, and / or the like. Additionally, the waveform graph 989a displayed in the primary waveform panel 1602 may also be referred to as a “navigation waveform”, a “scrubber waveform”, a “summary waveform”, and / or the like.

[0191] The primary waveform panel 1602 also includes delimiter elements 1688 or user selectable delimiter elements as previously discussed, which allow a user to select a desired section of the waveform graph 989 to focus. In some implementations, the delimiter elements 1688 may be draggable in a same or similar manner as discussed previously with respect to the boundary elements 924, allowing the user to expand or reduce the focused section 1680 of the waveform graph 989, or move the focused section 1680 to a different portion of the waveform graph 989. Additionally or alternatively, the user may select a desired time period using the dropdown control element 1610. When selected, the dropdown control element 1610 may display a dropdown list 1710 as shown by FIG. 12B. The user may select a desired time period from the dropdown list 1710. Selection of a time period from the dropdown list 1710 causes the focused section 1680 to change its size to reflect the selected time period. For example, the user may select the “30 minutes” time period from the dropdown list 1710 as shown by FIG. 12B, which may cause the focused section 1680 to shrink or narrow to cover a 30 minute time period, as shown by FIG.12C.

[0192] The primary waveform panel 1602 also includes a waveform events toggle switch 1621, which gives the user the ability to display overlaid event markers 988 on the waveform graph 989. For example, as shown by FIG.12A, the toggle switch 1621 is in the “off” position, and thus, no event markers 988 are overlaid on the waveform graph 989 in FIG.12A. When the toggle switch 1621 is placed in the “on” position, the event markers 988 are overlaid on the waveform graph 989 as shown by FIG.12D. Note that not all event markers 988 are labeled in FIG.12D. Furthermore, the primary waveform panel 1602 can be collapsed by selecting the accordion icon 1647. Examples of the collapsed primary waveform panel 1602 are shown by FIGs.12O and 12P. FIG.12O showsRMDDHI 3.4-005 (21) an example of the collapsed primary waveform panel 1602 with the waveform events toggle switch 1645 in the “off” position, and therefore, the collapsed summary waveform depicted by FIG.12O does not include event markers. FIG.12P shows an example of the collapsed primary waveform panel 1602 with the waveform events toggle switch 1645 in the “on” position, and therefore, the collapsed summary waveform depicted by FIG.12P includes the overlaid event markers.

[0193] The primary waveform panel 1602 also includes an events accordion element 1643. In FIG. 12A, the events accordion 1643 is shown as being collapsed. Therefore, the events accordion 1643 is labeled as “Expand events”, indicating that the user may select the accordion 1643 to expand or activate the item to reveal the content associated with it, as shown by FIGs.12J to 12L. FIG.12J shows the expanded events element 2302. The delimiter elements 1688 extend into the expanded events section 2302 to highlight specific events that occurred within the focused section 1680.

[0194] The expanded events section 2302 lists multiple event classifications (or classes), such as with different types of events in discrete rows, such as “Central” which may represent central sleep apnea (CSA) events, “Obstructive” which may represent obstructive sleep apnea (OSA) events, “Hypopnea” which may represent hypopnea events, “RERA” which may represent RERA events, and “Unknown” which may represent unknown events that were detected. Each event class includes a set of event markers 2388. For example, the “Central” event class includes a set of CSA event markers 2388, the “Obstructive” event class includes a set of OSA event markers 2388, and so forth. The particular event types / classes to be displayed within the expanded events section 2302 can be predetermined or configured. In some implementations, a user or administrator can customize the GUI 700a to show desired events, e.g., one or more of the rows, within the expanded events section 2302. Additionally or alternatively, the expanded events section 2302 is populated with event classifications based on the capabilities of the therapy device 104 and / or the modes / settings in which the therapy device 104 operated during the respiratory therapy period 923. Thus, the specific event classes displayed in the expanded events section 2302 and in the summary waveform section 1602 may be device-specific and / or implementation-specific.

[0195] The event markers 2388 indicate points in time when a specific event was detected. For example, each CSA event marker 2388 may indicate a time when a CSA event was detected, each OSA event marker 2388 may indicate a time when a OSA event was detected, and so forth. Thus, the event markers 2388 are time-aligned with the summary waveform graph 989. Each eventRMDDHI 3.4-005 (21) marker 2388 is also aligned with a corresponding event marker 988 that is overlaid on the summary waveform graph 989. For example, CSA event marker 2388d corresponds to the event marker 988d in the summary waveform graph 989. By way of another example, OSA event marker 2388e corresponds to the event marker 988e in the summary waveform graph 989. By way of yet another example, hypopnea event marker 2388f corresponds to the event marker 988f in the summary waveform graph 989. By way of yet another example, unknown event marker 2388g corresponds to the event marker 988g in the summary waveform graph 989. By way of yet another example, RERA event marker 2388h corresponds to the event marker 988h in the summary waveform graph 989. Note that not all of the event markers 988, 2388 are labeled in FIG.12J. The event markers 2388 may be color coded in a same or similar manner as discussed previously with respect to the event markers 988.

[0196] Displaying the events according to event type or class, as is shown in the expanded events section 2302 of FIG.12J, may allow the user to more easily view specific types of events than may be possible with the primary waveform panel 1602 alone. For example, as shown by FIG. 12J, multiple events within the focused section 1680 occur relatively close to one another. This may result in the event markers 988d, 988e, and 988f being “crowded” in the summary waveform graph 989, such that event marker 988d or 988e may obstruct the view of event marker 988f. By displaying the event markers 2388d, 2388e, and 2388f according to event type / class, such as is shown by in FIG.12J, an unobstructed view of the individual events can be seen.

[0197] As mentioned previously, a more detailed view of individual events can be viewed by hovering a pointer over an event marker 988, which causes a corresponding tooltip to be displayed. Similarly, the user may hover their pointer over the event markers 988, 2388 to display a corresponding tooltip element. For example, as shown by FIG. 12K, the user’s pointer may be hovered over an event marker 988x, which causes a tooltip 2488 to be displayed. The tooltip 2488 shows that event marker 988x corresponds to a RERA event that occurred for 14 seconds. Also note that hovering over the event marker 988x also causes the corresponding event marker 2388x in the expanded events section 2302 to be highlighted. Additionally, a triangle icon may appear above the hovered-over event marker 988x and another triangle icon may appear above the hovered-over event marker 2388x to further highlight the subject event. By way of another example, as shown by FIG. 12L, the user’s pointer may be hovered over an event marker 2388yRMDDHI 3.4-005 (21) in the expanded events section 2302, which causes a tooltip 2588 to be displayed. The tooltip 2588 shows that event marker 2388y corresponds to a CSA event that occurred for 4.2 seconds. Hovering over the event marker 2388y also causes the corresponding event marker 988y in the summary waveform graph 989 to be highlighted. It should be noted that references to “hover” or “hovering” herein may also include performing a “long press” gesture, a “long tap” gesture, and / or other gesture(s) on the event marker 988 in a mobile device or other touchscreen context. Additionally, a triangle icon may appear above the hovered-over event marker 2388y and another triangle icon may appear above the hovered-over event marker 988y to further highlight the subject event. Other effects may additionally or alternatively be employed, such as bolding or increasing the thickness of the hovered-over event markers, and / or the like.

[0198] In the examples of FIGs. 12J to 12L, the event markers 988, 2388 may be automatically populated in the high resolution data interface based on events detected algorithmically by automated / computer processing. In some implementations, GCEs may be provided that allow the user to delete event markers 988, 2388, add or annotate the summary waveform graph to include additional or alternative event markers. For example, a medical professional may determine that the system incorrectly labeled an apnea event as a hypopnea event, and the medical professional may relabel the apnea event marker as a hypopnea event marker. By way of another example, the medical professional may identify a specific type of event within the waveform graph 989 that was not originally identified by the system. The medical professional may add a new event marker 988 for the identified event to the waveform graph 989 with appropriate annotations. Such annotations may include the event type or classification, as well as other relevant information. The addition and / or removal of event markers to / from the waveform graph may then be used by the system to retrain and / or fine tune the detection and classification algorithms used to automatically detect and classify events from various waveforms.

[0199] Additionally, the event markers 988, 2388 may be linked to corresponding events in one or more signal panels 2102. For instance, clicking on one of the event markers 988, 2388 may cause the pointer to jump to a corresponding event marker or location within a signal panel 2102, and / or may cause the high resolution data interface to refocus or reorientate around that location in the signal panel 2102. For example, clicking on the event marker 988d or 2388d in the summary flow waveform graph 989a may jump to a location in the flow signal waveform graph 2189a withinRMDDHI 3.4-005 (21) the flow signal panel 2102a that corresponds to the event marker 988d, 2388d. Furthermore, the event markers 988, 2388 may also correspond to event bands 2190 and event band tooltips 2191. For example, the event markers 988d, 2388d may correspond to event band 2190b and tooltip 2191b. By way of another example, the event markers 988e, 2388e may correspond to event band 2190a and tooltip 2191a. By way of yet another example, the event markers 988f, 2388f may correspond to event band 2190c and tooltip 2191c. The event bands 2190 and tooltips 2191 may be color coded in a same or similar manner as discussed previously with respect to the event markers 988, 2388.

[0200] The high resolution data interface also includes multiple signal panels 2102 for different measured signals, as shown by FIGs.12D to 12G. The views shown by FIGs.12D to 12G show views of the high resolution data interface as a user scrolls through the display or screen to view different signal panels 2102. Here, FIG.12D shows a view of a top of the display area, and each of FIGs.12E to 12G shows views of the screen / display as the user scrolls towards the bottom of the screen / display. Each signal panel 2102 includes a respective waveform graph 2189 for a specific type of signal. For example, as shown by FIGs. 12E to 12G, a flow signal panel 2102a includes a flow signal waveform graph 2189a, pressure signal panel 2102b includes a pressure signal waveform graph 2189b, leak signal panel 2102c includes a leak signal waveform graph 2189c, oxygen saturation (SpO2) signal panel 2102d includes a SpO2 signal waveform graph 2189d, respiration rate signal panel 2102e includes a respiration rate signal waveform graph 2189e, and minute ventilation (vent) signal panel 2102f includes a minute vent signal waveform graph 2189f. Additionally, each of the signal panels 2102 are collapsible, which allows the user to hide individual waveform graphs 2189. An example is shown by FIG. 12Q where the user collapsed the flow signal panel 2102a, pressure signal panel 2102b, and leak signal panel 2102c. In some implementations, a GCE can be included with each signal panel 2102 to allow the user to expand a desired signal panel 2102 or waveform graph 2189 to fill a portion or the entire width of the display area.

[0201] Each of the waveform graphs 2189 are dynamically updated to show a portion of their respective waveforms or signals in correspondence with adjustments to the focused section 1680 to provide a higher resolution or zoomed view associated with the focused section. For example, as shown by FIGs.12A and 12D to 12G, the focused section 1680 is user adjusted with the GUIRMDDHI 3.4-005 (21) to cover a one hour time period between 22:00 and 23:00, and thus, each of the waveform graphs 2189 includes a portion of a signal that was measured between 22:00 and 23:00. Similarly, in the example of FIGs.12T to 12W, the focused section 1680 is user adjusted with the GUI to change from covering twenty-four hours to an eight-hour time period, and thus, each of the waveform graph(s) 2189 is changed from including a portion of a signal that was measured in a twenty-four hour period to a portion of the signal in an eight hour time period as indicated by operation of the focused section 1680. By adjusting the size of the focused section 1680, the user is able to obtain a corresponding view of the different therapy metrics in each of the waveform graph(s) 2189 in greater detail, such as in as much detail as desired / user selected or otherwise achieve visibility over the received high resolution data.

[0202] The specific types of waveform graphs 2189 and signal panels 2102 to be displayed within the high resolution data interface can be predetermined or configured. In some implementations, the high resolution data interface is populated with specific signal panels 2102 and their waveform graphs 2189 based on the capabilities of the therapy device 104 and / or the modes / settings in which the therapy device 104 operated during the respiratory therapy period 923. Thus, the specific waveform graphs 2189 shown in the high resolution data interface may be device-specific and / or implementation-specific. In some examples, as a default, the high resolution data interface displays all of the different types of waveforms 2189 that a particular device 104 is capable of measuring.

[0203] The high resolution data interface may also include an events band toggle switch 1622, which allows the user to display one or more event bands 2190, which may be considered zoomed display versions of the event marker previously discussed. For example, as shown by FIG. 12A, the toggle switch 1622 is in the “on” position, and thus, the event bands 2190 are displayed. When the toggle switch 1622 is placed in the “off” position, the event bands 2190 are displayed are not displayed. When enabled, the event bands 2190 are overlaid on each of the waveform graphs 2189, as shown by FIGs.12A and 12D to 12G. The event bands 2190 may be semi-transparent so as not to obscure or obstruct the view of the underlying waveforms 2189. Each event band 2190 corresponds to an event marker 988 within the focused section 1680. For example, as shown by FIG. 12D, the event marker 988d may correspond to event band 2190b, the event marker 988e may correspond to event band 2190a, and the event marker 988f may correspond to event band 2190c. Additionally, the event bands 2190 may be color coded in the same manner as discussedRMDDHI 3.4-005 (21) previously with respect to the event markers 988. In this example, each event band 2190 has a same color as its corresponding event marker 988.

[0204] The event bands 2190 are overlaid on the waveform graphs 2189 at a position / location that corresponds to a time period at or during which the associated event took place. For example, as shown by FIG.12D, the hypopnea event associated with event marker 988f and event band 2190c began at approximately 22:09:55 and ended at approximately 22:10:05. Therefore, the event band 2190c is positioned over the waveform graphs 2198 that covers a timespan around the 22:10 time mark. Additionally, the thickness of each event band 2190 correlates to the amount of time the corresponding event was experienced. For example, as shown by FIG. 12D, the hypopnea event associated with event marker 988f and event band 2190c is 10.3 seconds in length, and thus, the thickness of the event band 2190c spans 10.3 seconds over the waveform graphs 2189. As such the common alignment of the event band with the waveforms permit the event of the band to be readily considered in relation to each of the different signals of the waveform graphs.

[0205] Furthermore, each event band 2190 includes a corresponding event band tooltip 2191. Similar to the tooltips 1388, 1488, 1588, 2488, 2588, the event band tooltips 2191 shows an event type of the corresponding event and an amount of time that the corresponding event took place. For example, as shown by FIGs. 12A, 12D, 12E, 12F, and 12J, tooltip 2191c shows that event band 2190c corresponds to a hypopnea event that occurred for 10.3 seconds.

[0206] The examples of FIGs. 12A, 12D, 12E, 12F, and 12J also show the tooltip 2191c being overlaid on tooltips 2191b and 2191a, and the tooltip 2191b being overlaid on tooltip 2191a. In some implementations, the content of tooltips 2191a and 2191b may be revealed by clicking on those tooltips 2191a, 2191b, as shown by FIGs.12M and 12N. FIG.12M shows a close-up view of the GUI instance 700a after the user clicks or taps on the tooltip 2191b to reveal the content of that tooltip 2191b. The tooltip 2191b shows that the corresponding event is a central (CSA) event that lasted 10.3 seconds. Additionally, after clicking on the tooltip 2191b, the tooltip 2191b is overlaid on top of tooltips 2191a and 2191c. FIG.12N shows a close-up view of the GUI instance 700a after the user clicks or taps on the tooltip 2191a to reveal the content of that tooltip 2191a. The tooltip 2191a shows that the corresponding event is an obstructive (OSA) event that lasted 10.3 seconds. Additionally, after clicking on the tooltip 2191a, the tooltip 2191a is overlaid on top of tooltips 2191b and 2191cRMDDHI 3.4-005 (21)

[0207] As shown by FIGs. 12E to 12G, the high resolution data interface also includes a tooltip 2193, which may be displayed based on the position of the bar 2194. The bar 2194 extends vertically through the waveform graphs 2189 and may be moved horizontally based on the movement of the pointer. In some implementations, the bar 2194 may be moved using a dragging gesture. In other implementations, the bar 2194 may be configured to move horizontally based on movement of the pointer when the pointer is moved over one of the signal panels 2102. As the user moves the pointer horizontally over one of the waveform graphs 2189, the tooltip 2193 displays measurements for the time instant that is covered by the bar 2194. The tooltip 2193 may display the time instant and the measurements / metrics that were measured at that time instant. For example, the tooltip 2193 may display a timestamp and “Flow”, “Pressure”, “Leak”, and “SpO2” measurements / metrics. Additional or alternative measurements and / or metrics may be displayed in the tooltip 2193. In some implementations, the specific metrics to be displayed within the tooltip 2193 can be configured or selected by the user or an administrator. Another version of the tooltip 2193 is illustrated in FIG.12V. The version in FIG.12V may display more comprehensive metrics associated with the position of the bar 2194, such as any one or more of inspiratory pressure, expiratory pressure, inspiratory time, leak, minute ventilation, respiratory rate, tidal volume, pressure high rate, alveolar ventilation, flow and Inspiratory:Expiratory ratio.

[0208] In the example graphic user interface shown in FIGs.12R and 12S, the GUI enables a user to selectively proportionally resize or scale information in dynamically scalable graph of calendar view 12820. In this regard, the view 12820 is similar to the view 820 of FIG.11A, 11B, and 11C as previously described. For example, the time period of the elements of the view 12820, like the view 820, may be set by one or more user activation elements of the GUI as previously described. However, the GUI of FIGs.12R and 12S additionally provide one or more user activatable elements 12827a, 12827b for dynamically resizing information (such as, for a period, accumulated usage information, maximum IPAP, 95th percentile IPAP, median IPAP, maximum EPAP, 95th percentile EPAP, median EPAP, etc.) associated with the time periods within the graph 12825 of the GUI. For example, as illustrated in FIG. 12R, the graph 12825 of the calendar view 12820 may include a scaling action element 12827a, such as the text label, that when activated by a user, such as by user selection with a pointer, changes a graphing view of the graph 12825 as shown in FIG.12R to another graphing view shown in FIG.12S. In this regard, the selection of the scalingRMDDHI 3.4-005 (21) action element 12827a activates a display scaling process to relatively adjust each graphical data buffer 823 so that the graphic element of each is proportionally displayed (such as with its visual representation of accumulated therapy usage time) on a common scale that is adjusted. In this regard, the common scale, such as its range, may be adjusted to be a function of one or more quantities of the buffer element(s) 823 displayed in the graph 12825. For example, the common scale may be a function of a quantity, such as a maximum quantity of the displayed buffer elements, such as a function of a maximum accumulated usage time of the usage times represented by the graphical data buffers 823. For example, the common scale may be a vertical axis VA of the graph 12820 and selection of the scaling action element 12827a may change the range of the scale to be at or near a maximum quantity, such as a maximum usage time, associated with one of the graphical data buffers 823 on the graph 12825. In this way, and with the visual adjustment to the range of the graph as a result of activation of the scaling action element 12827a, each of the graphical data buffers 823 then will be visually adjusted according to its value (e.g., accumulated usage time) with regard to the modified scale as illustrated in relation to the transition from the graph of the view of FIG.12R to the graph of the view of FIG.12S.

[0209] Additionally, in relation to FIG.12S, the GUI may additionally provide one or more user activatable elements 12827b for further resizing information associated with the time periods within the graph 12825 of the GUI. For example, as illustrated in FIG.12S, the graph 12825 of the calendar view 12820 may include a scaling action element 12827b, such as the text label, that when activated by a user, such as by user selection with a pointer, changes a graphing view of the graph 12825 as shown in FIG.12S to another graphing view shown in FIG.12R. In this regard, the selection of the scaling action element 12827b activates a display scaling process to relatively adjust each graphical data buffer 823 so that the graphic element of each is proportionally displayed (such as with its visual representation of accumulated therapy usage time) on a general scale. In this regard, the general scale, such as its range, may be adjusted to be a function of a period attributable to all of the displayed graphical data buffers 823 of the graph 12825. For example, the general scale may be a function of a period associated with each the displayed buffer elements 823, such as a function of a period represented by each of the graphical data buffers 823. For example, the general scale may be a vertical axis VA (e.g, a Y-axis) of the graph 12820 and selection of the scaling action element 12827b may change the range of the scale to be the timeRMDDHI 3.4-005 (21) associated with the period of each of the graphical data buffers 823 on the graph 12825. For example, when the each of the displayed buffer elements 823 collection period relates to a different calendar day, the general scale may be the amount of time of a day (e.g., 24 hours or 1440 minutes, or other time unit associated with the period etc.). In this way, and with the visual adjustment to the range of the graph as a result of activation of the scaling action element 12827b, each of the graphical data buffers 823 then will be visually adjusted according to its value (e.g., usage time) with regard to the modified scale as illustrated in relation to the transition from the graph of the view of FIG.12S to the graph of the view of FIG.12R. In this way, such as with activation of the user activatable elements, an improved display of information may be provided such as to improve the electronic display of a large quantity of electronic information.

[0210] As mentioned previously, selecting the reorder charts icon 1612 as shown in FIG.12A as well as FIG.12V (labelled “configure graphs” with a pencil icon), may allow a user to change the position and / or arrangement of the waveform graphs 2189 within the high resolution data interface. For example, selection of the reorder charts icon 1612 may cause a reorder charts (or graphs) window to be displayed, such as the reorder charts window 2600 shown by FIGs.13A and 13B or FIG. 13C. In FIG. 13A, the reorder charts window 2600 includes a list of chart elements 2601, 2602. The arrangement of the chart elements 2601, 2602 may indicate the current arrangement of the signal panels 2102 in the high resolution data interface. Each of the chart elements 2601, such as chart elements 2601a and 2601b, include a padlock icon to indicate that the user is not permitted to move the position of those charts / panels 2102. Each of the chart elements 2602, such as chart elements 2602a through 2602k, include a “grip” or “drag handle” icon, which may be formed as a grouping of dots, to indicate that the user is capable of moving the position of those chart elements 2602 so as to rearrange the charts / panels 2102 in the high resolution data interface. The user may drag one or more of the chart elements 2602 to a desired position in the list of chart elements 2601, 2602 to arrange the charts / panels 2102 as desired. For example, as shown by FIG.13B, the user is in the process of dragging the “Events” chart element 2602a to a new position in the list.

[0211] After arranging the chart elements 2602 in the desired order, the user may select the apply (or save) button 2615 to rearrange the charts / panels 2102 in the high resolution data interface to correspond with the order indicated by the user. After selecting the apply button 2615, the reorder charts window 2600 may automatically close, and the client-side app may dynamically rearrangeRMDDHI 3.4-005 (21) the corresponding charts / panels 2102 in the order made by the user. For example, if the user moved the “Leak” chart element 2602b to be above the “Pressure settings” chart element 2602d, activating the apply button 2615 may cause the client-side app to arrange the leak signal panel 2102c to be above, or on top of, the pressure signal panel 2102b. Alternatively, the user may select the reset button 2610 to reset the order of the chart elements 2602 back to a previous order or back to a default order. The user may also select the cancel button 2620 to exit or close the reorder charts window 2600.

[0212] Optionally, as illustrated in the example of FIGs. 13C and 13D, in addition to reordering of graphs or charts, each chart (or graph) element 2602 may include a toggle element, such as a check mark toggle, so that a user may toggle whether the related chart or graph will be displayed in the signal panel 2102. Moreover, as also illustrated in FIG.13C, the configuration window (or reorder charts window), may include one or more limit setting controls for some or each of the chart elements. For example, minimum or maximum values for the signal of the graph of the chart element 2602 may be set with the limit setting controls 2603. In the illustrated example, a limit setting control 2603 may permit user entry of a numeric value in a value entry window 2603w. Moreover, a limit setting control 2603 may include an increase icon 2603p and / or a decrease icon 2603m for adjusting a value of the value entry window 2603w such as by an increase increment or decrease decrement respectively. A scroll bar 2605 may be provided for enabling a user to drag a portion of the scroll bar for displaying additional chart elements 2602 that are configurable when all of the chart elements do not fit within the 2600 window at the same time, such as to change by scrolling from the view in FIG.13C to the view in FIG.13D, such as by dragging the scroll bar control icon 2605 using a user interface pointer. 4.7. RPT DEVICE

[0213] 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, such as apparatus similar to the device illustrated in Figs. 14A-15D. Referring to FIGS. 14A-14C, 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.

[0214] 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 moreRMDDHI 3.4-005 (21) 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.

[0215] 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 cmH2O, or at least 10cmH2O, or at least 20 cmH2O.

[0216] With respect to FIG.15A, 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.

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

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

[0219] As shown in FIG. 15C, 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.RMDDHI 3.4-005 (21) 4.7.1. RPT device mechanical & pneumatic components

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

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

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

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

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

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

[0226] 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. 4.7.4. Pressure generator

[0227] 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 cmH2O to about 20 cmH2O, or in other forms up to about 30 cmH2O when delivering respiratory pressure therapy. The blower may be as described in any one of the following patents or patent applications the contents of which are incorporated herein by reference in their entirety: U.S. Patent No.7,866,944; U.S. Patent No. 8,638,014; U.S. Patent No. 8,636,479; and PCT Patent Application Publication No. WO 2013 / 020167.RMDDHI 3.4-005 (21)

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

[0229] 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. 4.7.5. Transducer(s)

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

[0231] In one form of the present technology (see e.g., FIG.15B), 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.

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

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

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

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

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

[0237] In one form, a signal generated by the pressure sensor 4272 and representing a pressure is received by the central controller 4230.RMDDHI 3.4-005 (21) 4.7.5.3. Motor speed transducer

[0238] 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. 4.7.6. Anti-spill back valve

[0239] As shown in FIG.15B, 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. 4.7.7. RPT device electrical components 4.7.7.1. Power supply

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

[0241] 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. 4.7.7.2. Input devices

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

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

[0244] 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.RMDDHI 3.4-005 (21)

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

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

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

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

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

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

[0251] The RPT device 4000 may include a clock 4232 that is connected to the central controller 4230.RMDDHI 3.4-005 (21) 4.7.7.5. Therapy device controller

[0252] Referring to FIGs. 15C and 15D, 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.

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

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

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

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

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

[0258] 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. 4.7.7.8. Data communication systems

[0259] 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.15C). 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.RMDDHI 3.4-005 (21)

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

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

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

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

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

[0265] 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. 4.7.7.9.1. Display driver

[0266] 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. 4.7.7.9.2. Display

[0267] 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.RMDDHI 3.4-005 (21) 4.7.8. RPT device algorithms

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

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

[0270] 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. 4.7.8.1. Pre-processing module

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

[0272] 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 Ql.

[0273] 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.RMDDHI 3.4-005 (21) 4.7.8.1.1. Interface pressure estimation

[0274] 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 ΔP through the air circuit 4170. The dependence of the pressure drop ΔP on the total flow rate Qt may be modelled for the particular air circuit 4170 by a pressure drop characteristic ΔP(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 ΔP. 4.7.8.1.2. Vent flow rate estimation

[0275] 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). 4.7.8.1.3. Leak flow rate estimation

[0276] 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 Ql. In one form, the leak flow rate estimation algorithm estimates the leak flow rate Ql 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.

[0277] 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 Ql, by calculating a leak conductance, and determining a leak flow rate Ql 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, whereRMDDHI 3.4-005 (21) 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 Ql may be estimated as the product of leak conductance and a function of pressure, Pm. 4.7.8.1.4. Respiratory flow rate estimation

[0278] 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, Ql, and estimates a respiratory flow rate of air, Qr, to the patient, by subtracting the vent flow rate Qv and the leak flow rate Ql from the total flow rate Qt. 4.7.8.2. Therapy Engine Module

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

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

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

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

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

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

[0285] In some forms, known as discrete phase determination, the phase output ^ is a discrete variable. One implementation of discrete phase determination provides a bi-valued phase output with values of either inhalation or exhalation, for example represented as values of 0 and 0.5 revolutions respectively, upon detecting the start of spontaneous inhalation and exhalation respectively. RPT devices 4000 that “trigger” and “cycle” effectively perform discrete phaseRMDDHI 3.4-005 (21) 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 ^ equal to 0 (indicating inspiration) and 0.5 (indicating expiration) respectively.

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

[0287] In other forms, known as continuous phase determination, the phase output ^ is a continuous variable, for example varying from 0 to 1 revolutions, or 0 to 2^ 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 the 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 ^ is 0 revolutions. 2. If Qr is large positive and steady^ is 0.25 revolutions. 3. If Qr is zero and falling fast, then ^ is 0.5 revolutions. 4. If Qr is large negative and^ is 0.75 revolutions. 5. If Qr is zero and steady and the 5-second low-pass filtered absolute value of Qr is large then ^ is 0.9 revolutions. 6. Ifpositive and the phase is expiratory, then ^ is 0 revolutions. 7. If Qr is negative and the phase is inspiratory, then ^ is 0.5 revolutions.RMDDHI 3.4-005 (21) 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.

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

[0289] 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 ^ 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). 4.7.8.2.2. Waveform determination

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

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

[0292] In one form of the present technology, a waveform determination algorithm 4322 provides a waveform template ^(^) 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.

[0293] In one form, suitable for either discrete or continuously-valued phase, the waveform template ^(^) 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 ^(^) comprises two smoothly curved portions, namely a smoothly curved (e.g. raised cosine) rise from 0 to 1 for values of phaseRMDDHI 3.4-005 (21) 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 ^(^) 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.

[0294] In some forms of the present technology, the waveform determination algorithm 4322 selects a waveform template ^(^) from a library of waveform templates, dependent on a setting of the RPT device. Each waveform template ^(^) in the library may be provided as a lookup table of values ^ against phase values ^. In other forms, the waveform determination algorithm 4322 computes a waveform template ^(^) “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.

[0295] In some forms of the present technology, suitable for discrete bi-valued phase of either inhalation (^ = 0 revolutions) or exhalation (^ = 0.5 revolutions), the waveform determination algorithm 4322 computes a waveform template ^ “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 ^(^^ t) in two portions (inspiratory and expiratory) as follows: Π(Φ, ^^) = { Π^^(^^), Φ = 0

[0296] and expiratory portions of the waveform template ^(^, t). In one such form, the inspiratory portion ^i(t) of the waveform template is a smooth rise from 0 to 1 parametrised by a rise time, and the expiratory portion ^e(t) of the waveform template is a smooth fall from 1 to 0 parametrised by a fall time. 4.7.8.2.3. Ventilation determination

[0297] 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.RMDDHI 3.4-005 (21)

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

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

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

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

[0302] 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.RMDDHI 3.4-005 (21) 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.

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

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

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

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

[0307] 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.RMDDHI 3.4-005 (21)

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

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

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

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

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

[0313] 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. 4.7.8.2.7. Determination of airway patency

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

[0315] 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 ofRMDDHI 3.4-005 (21) 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.

[0316] 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 cmH2O.

[0317] 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. 4.7.8.2.8. Determination of target ventilation

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

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

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

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

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

[0323] 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 toRMDDHI 3.4-005 (21) 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. 4.7.8.2.9. Determination of therapy parameters

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

[0325] In one form of the present technology, the therapy parameter is an instantaneous treatment pressure Pt. In one implementation of this form, the therapy parameter determination algorithm 4329 determines the treatment pressure Pt using the equation ^^^^ = ^^Π(Φ, ^^) + ^^0 (1)

[0326] In equation 1, ^^ is the amplitude, Π(Φ, ^^) is the waveform template value (in the range 0to 1) at the current value ^ of phase and t of time, and P0is a base pressure.

[0327] If the waveform determination algorithm 4322 provides the waveform template ^(^^ t) as a lookup table of values ^ 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.

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

[0329] 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.RMDDHI 3.4-005 (21)

[0330] 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. 4.7.8.4. Detection of fault conditions

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

[0332] 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 incident 4.7.9. AIR CIRCUIT

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

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

[0335] 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 wireRMDDHI 3.4-005 (21) circuit is described in United States Patent 8,733,349, which is incorporated herewithin in its entirety by reference. 4.8. RESPIRATORY THERAPY MODES

[0336] 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. 5. GLOSSARY

[0337] 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. 5.1. General

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

[0339] 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. 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.In another example, ambient pressure may be the pressure immediately surrounding or external to the body. 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.

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

[0341] Continuous Positive Airway Pressure (CPAP) therapy: Respiratory pressure therapy in which the treatment pressure is approximately constant through a respiratory cycle of a patient. In some forms, the pressure at the entrance to the airways will be slightly higher during exhalation,RMDDHI 3.4-005 (21) 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.

[0342] 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’.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, Qt, is the flow rate of air and any supplementary gas reaching the patient interface via the air circuit. Vent flow rate, Qv, is the flow rate of air leaving a vent to allow washout of exhaled gases. Leak flow rate, Ql, 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.

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

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

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

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

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

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

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

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

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

[0352] Subject: An individual or entity that is being observed, tested, studied, discussed, or is otherwise under consideration for purposes of measuring, collecting, and / or gathering data or information related to one or more objectives. As examples, the individual or entity may refer to one, or a group of, users, patients, study participants, experimental units, components, devices, or systems.

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

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

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

[0356] Waveform: a graphical representation or visual depiction of a signal, which is a pattern of oscillations or fluctuations in a physical quantity over time and / or space. A waveform is typicallyRMDDHI 3.4-005 (21) represented as a graph with time (or another independent variable) on the horizontal axis and the amplitude (or another dependent variable) on the vertical axis. The waveform graph displays the behavior of the wave’s amplitude, frequency, phase, and other properties over time and / or space. The amplitude refers to the height or intensity of the waveform, and represents the strength or magnitude of the wave’s oscillations. The frequency refers to the number of complete cycles or oscillations of the wave per unit of time measured in hertz (Hz) or some other unit. The phase refers to the relative timing or alignment of a waveform with respect to a reference waveform, typically expressed in degrees or radians. The waveform’s shape refers to the overall pattern or form of the waveform, which may vary depending on the type of wave or signal that is depicted and its properties. 5.2. Respiratory cycle

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

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

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

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

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

[0362] 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.RMDDHI 3.4-005 (21)

[0363] Types of flow limited inspiratory waveforms include: (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.

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

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

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

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

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

[0369] Peak flow rate (Qpeak): The maximum value of flow rate during the inspiratory portion of the respiratory flow waveform.

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

[0371] 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) isRMDDHI 3.4-005 (21) 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 volume Ve.

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

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

[0374] Total Time (Ttot): 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.

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

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

[0377] 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. 5.3. Graphical User Interface

[0378] Graphical User Interface (GUI): A form of user interface that allows users to interact with electronic devices through graphical elements, such as windows, icons, text fields, canvases, menus, pointers, widgets, visual indicators, and the like. Actions in a GUI are typically performed through manipulation of the graphical elements.

[0379] Graphical control element: an element of interaction in a GUI. A graphical control element (GCE) can include any software component that a user interacts with through direct or indirect manipulation. Each GCE facilitates a specific type of user-computer interaction, and appears as aRMDDHI 3.4-005 (21) visible part of an application's GUI as defined by the theme and rendered by the rendering engine. GCEs are sometimes referred to as “widgets”, “interactive elements”, “GUI components”, and / or the like.

[0380] Accordion: A GUI component that allows a user to expand (reveal) and collapse (hide) sections of content within a limited space. An accordion is often used to manage and present hierarchical information or multiple categories of content in a compact and organized manner.

[0381] Button: a GCE that provides a user with a way to trigger an event. Typically, buttons have a rectangle or rounded rectangle shape, and include a descriptive caption indicating the type of action or event that can be triggered when activating the button.

[0382] Component: a reusable and self-contained unit of code that encapsulates a specific functionality, behavior, or user interface element. Multiple components can be combined and interrelated with other components to form a larger application, such as a web app. A component can exist autonomously from other components. A component may interact with other components via respective interfaces. Components may have an encapsulated presentation (e.g., markup), data state (e.g., attributes), logic (e.g., ECMAScript / JavaScript functions), and style (e.g., CSS rules). Components may be software package, web service, resource, or module that encapsulates a set of related functions and / or data. Components can be embodied or implemented as containers, GCEs, graphical representations of data (or data visualizations), logical elements, and / or the like.

[0383] Container: a GUI element or component that is used to hold and organize other GUI elements or components within an interface. Containers may provide a structured layout for arranging GUI elements such as buttons, text fields, labels, images, and other control elements. Examples of containers may include windows, tabs, panels, scroll panes, frames (or inline frames), sections, divisions, and / or the like.

[0384] Dynamic content: website elements or features that change or update automatically without requiring a webpage to be reloaded or refreshed. Examples of dynamic content can include real- time content updates, interactive elements such as GUI elements that respond to user input or interactions, data-driven content such as content populated dynamically from a database or external data source, and conditional display content where content is shown or hidden based on one or more conditions such as user preferences, login status, subscription status, permissions or authorizations, results of a calculation, and / or the like.RMDDHI 3.4-005 (21)

[0385] Hover: an action where a user moves their cursor or pointer over an interactive element, such as a button, link, icon, or menu item, causing the application, GUI, or client to detect the cursor’s or pointer’s presence within the boundaries of the interactive element. The term “hover” may refer to the state of the cursor or pointer when it is positioned over the element, where the user has not yet clicked or further interacted with that element.

[0386] Long press gesture: A gesture that involves pressing and holding a finger on the touchscreen for a certain duration, usually slightly longer than a normal tap or touch. A long press gesture may also be referred to as a “long tap” gesture.

[0387] Menu: a GUI element that presents a list of options or commands for a user to choose from. Examples of menus include dropdown menus, context menus, toolbar menus, hamburger menus, and modal menus.

[0388] Panel: a container or component that is used to group, organize, and layout other GUI elements within a window, frame, or another container. Panels are typically used in desktop applications, web applications, and software interfaces to create structured layouts, divide content into sections, and manage the presentation of GUI elements.

[0389] Scrollbar: an interaction technique, GCE, or widget in which continuous text, pictures, or any other content can be scrolled in a predetermined direction (e.g., up / down or left / right) on a computer display, window, or viewport so that all of the content can be viewed, even if only a fraction of the content can be seen on a device's screen at one time. Scrollbars usually appear on one or two sides of a viewing area as long rectangular areas containing a bar (or thumb) that can be dragged along a trough (or track) to move the body of the content or page. In some cases, a user may click on a point on the scrollbar to scroll through the displayed content or otherwise change the viewing area.

[0390] Slider: a GCE that allows a user to select or set a value, or range of values, by moving an indicator, such as by dragging the indicator along or through a trough or track bar or clicking on a point on the slider to change the setting or value (or range of values). Sliders are different from scrollbars in that sliders are not continuous, but are instead used to adjust a value without changing the format of the display or the other information on the screen.

[0391] Scrubber: a GUI element that allows a user to interactively adjust or scrub through a range of values, such as time, progress, volume, and / or the like.RMDDHI 3.4-005 (21)

[0392] Tab: a GUI element that allows a user to navigate between different sections, views, or pages of content within the same window, container, wrapper, or other interface. Tabs are typically represented as labeled rectangles or buttons arranged horizontally or vertically within a tab bar, ribbon, or strip. Each tab label displays a title or icon that describes the content or purpose of the tab. Each tab is associated with a specific set of content, such as a webpage, document, panel, form, GUI view or screen, and / or the like. When a user selects a tab, the corresponding content is displayed within the main window or interface area. Tabs are interactive elements that a user can click or tap to switch between sections. Clicking on a tab activates the associated content and updates the tab's visual state to indicate that it is active, and may also update a previous tab to indicate that it is inactive.

[0393] Toggle switch: a GCE that allows a user to make a choice between two mutually exclusive states, such as “on” and “off”.

[0394] Tooltip: a graphical element, such as a text box, that displays information about an element. Tooltips are typically displayed when a pointer hovers over a GUI element or component for some amount of time. A tooltip is sometimes referred to as a “hint”, a “hoverbox”, “hovercard”, an “infotip”, or a “mouseover”.

[0395] Window: a GUI or container within an operating system or application interface that displays content, GUI elements, and interactive controls. A window represents a visual area on the screen where graphical elements, such as text, images, buttons, menus, and other GUI components, are displayed. Windows typically include a title bar at the top of the window that displays the window's title, control buttons (e.g., minimize, maximize, and close), and sometimes additional options or menu items. The content area of a window contains the main display area where application content, documents, and / or GUI elements are presented. Windows may include toolbars, menus, and status bars that provide access to commands, options, and information relevant to the application or content within the window. A user can interact with interactive controls, such as buttons, checkboxes, radio buttons, text fields, sliders, and dropdown lists within a window to perform actions, input data, or adjust settings. Typically, windows can be moved around the screen or display area by dragging the title bar, and can be resized by dragging the edges or corners of the window frame. Windows typically include control buttons to minimize (iconify), maximize (expand to full screen), and close the window.RMDDHI 3.4-005 (21) 6. OTHER REMARKS

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

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

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

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

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

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

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

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

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

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

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

[0407] 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.RMDDHI 3.4-005 (21)

Claims

RMDDHI 3.4-005 (21) CLAIMS 1. A method of a processor for graphically displaying respiratory therapy data, the method comprising: receiving a set of high-resolution samples of respiratory therapy data representing a period of respiratory therapy; accessing a sample subset of the set of high-resolution samples in response to a user activation of a user selectable graphic interface displaying samples of the set of high-resolution samples on a display; scaling the accessed sample subset for display in a display time window, wherein the scaling includes: (a) in a case that the number of samples in the sample subset exceeds a pixel dimension of the display time window in which the respiratory therapy data is to be displayed, down-sampling the samples based on the pixel dimension; or (b) in a case that the number of samples in the sample subset is less than a pixel dimension of the display time window, increasing the number of samples of the sample subset based on the pixel dimension; and controlling displaying of the scaled sample subset in the display time window on the display.

2. The method as claimed in claim 1, wherein the receiving comprises accessing, by the processor, a data structure comprising the set of high-resolution samples of respiratory therapy data, wherein the data structure was transmitted from one or more servers to computing apparatus comprising the processor.

3. The method as claimed in claim 2, wherein the set of high-resolution samples of respiratory therapy data of the data structure was transmitted to the one or more servers over a network from a respiratory therapy apparatus.

4. The method as claimed in any one of claims 1 to 4, wherein the down-sampling comprises assigning samples of the sample subset to a chunk that includes an integer number of consecutiveRMDDHI 3.4-005 (21) samples of the sample subset, and then selecting one or both of a minimum and a maximum of each chunk.

5. The method as claimed in claim 4, wherein the displaying the scaled sample subset in the display time window comprises rendering a lower signal envelope of pixels, wherein the lower signal envelope corresponds to a plurality of selected minimums comprising the minimum.

6. The method as claimed in any one of claims 4 to 5, wherein the displaying the scaled sample subset in the display time window comprises rendering an upper signal envelope of pixels, wherein the upper signal envelope corresponds to a plurality of selected maximums comprising the maximum.

7. The method as claimed in any one of claims 4 to 6, wherein the displaying the scaled sample subset in the display time window comprises filling one or more pixels between pixels representing the minimum and the maximum if the maximum and the minimum are not equal.

8. The method as claimed in any one of claims 4 to 7, further comprising determining a chunk size for the chunk based on factorizing widths of a plurality of different display time windows for displaying the sample subset.

9. The method as claimed in in any one of claims 4 to 7, further comprising determining a chunk size for the chunk based on bifurcation wherein each of a plurality of chunk sizes is a power of two.

10. The method as claimed in any one of claims 1 to 9, wherein increasing the samples of the sample subset comprises generating samples by, according to a spline function, interpolating between samples of the sample subset.

11. The method as claimed in claim 10, wherein the spline function comprises a cubic spline.RMDDHI 3.4-005 (21) 12. The method as claimed in any one of claims 10 to 11, wherein increasing the samples of the sample subset further comprises padding null samples to the sample subset and filtering the padded sample subset.

13. The method as claimed in claim 12, wherein the interpolating with the spline function generates samples between samples of the sample subset after the padding and filtering of the sample subset.

14. The method as claimed in any one of claims 12 to 13, wherein each of a number of the samples generated by the padding and filtering and a number of samples generated by the interpolating doubles the number of samples of the sample subset.

15. The method as claimed in any one of claims 12 to 14, wherein the filtering applies a finite impulse response filter.

16. The method as claimed in any one of claims 1 to 15, wherein the controlling the display is performed in a first thread of the processor and the scaling is performed in a second thread of the processor.

17. The method of claim 16, wherein the second thread is configured to scale a plurality of differently scaled views of the sample subset by preprocessing the sample subset for each of the plurality of differently scaled views before displaying any one of the plurality of differently scaled views.

18. The method as claimed in any one of claims 16 to 17, wherein the first thread is a main thread and the second thread is web worker.

19. The method as claimed in any one of claims 1 to 3, wherein the scaling is performed by a web worker in pre-processing for a plurality of different display time windows, wherein the pre- processing comprises:RMDDHI 3.4-005 (21) determining, for a small-scale display time window that graphs a number of samples that is greater than a pixel dimension of the small-scale display time window, a first chunk size that is an integer number of samples no greater than the number of graphed samples divided by the pixel dimension; and determining, for each display time window that graphs more samples than the small-scale display time window, a further chunk size that is a multiple of the first chunk size based on a number of samples graphed by that display time window, wherein the down-sampling comprises, for each display time window that graphs a number of samples that is greater than the pixel dimension of that display time window, first assigning each included sample to a chunk of that display time window’s further chunk size, and next selecting a minimum and a maximum of each chunk.

20. The method as claimed in claim 19, wherein the determining the further chunk size for a given display time window comprises factorizing the number of samples to be graphed by that display time window by the number of samples to be graphed by the small-scale display time window.

21. The method as claimed in claim 19, wherein the determining a further chunk size for a given display time window comprises repeatedly doubling the chunk size to reach a number of samples that is just greater than the number of covered samples for that display time window divided by the pixel dimension of that display time window.

22. The method as claimed in any one of claims 1 to 3, wherein the scaling is performed by a web worker in pre-processing for a plurality of different display time windows, wherein the pre- processing comprises: determining, for a large-scale display time window that has a pixel dimension larger than a number of samples to be covered by the large-scale display time window, a maximum multiple that is an integer no less than the pixel dimension divided by the number of covered samples; andRMDDHI 3.4-005 (21) up-sampling the covered samples with a filter that is set to a filter frequency, wherein the filter frequency is no less than twice a sample rate of the covered samples and the filter frequency is no more than the maximum multiple of the sample rate of the covered samples.

23. The method as claimed in any one of claims 1 to 3 and claim 22, wherein the scaling is performed by a web worker in pre-processing for a plurality of different display time windows, and in a rendering process: fitting a cubic spline to the graphed samples, wherein the cubic spline is selected from a group consisting of: a Catmull-Rom spline, and a natural spline.

24. The method as claimed in any of claims 1 to 7, wherein the receiving the set of high- resolution samples further comprises decompressing a data structure comprising a compressed version of the set of high-resolution samples.

25. A processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor, cause the processor to perform a method of graphically displaying respiratory therapy data of any one of claims 1 to 24 and 91 to 96.

26. A processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor, cause the processor to graphically display respiratory therapy data, the processor-executable instructions comprising: instructions to receive a set of high-resolution samples of respiratory therapy data representing a period of respiratory therapy; instructions to access a sample subset of the set of samples in response to a user activation of a user selectable graphic interface displaying samples of the set of high-resolution samples on a display; and instructions to scale the accessed sample subset for display in a display time window, wherein the scaling includes: (a) in a case that the number of samples of the sample subset exceeds a pixel dimension of the display time window in which the respiratory therapy data is to beRMDDHI 3.4-005 (21) displayed, down-sampling the samples based on the pixel dimension; or (b) in a case that the number of samples in the sample subset is less than a pixel dimension of the display time window, increasing the number of samples of the sample subset based on the pixel dimension; instructions to control displaying of the scaled sample subset in the display time window on the display.

27. A server with access to the processor-readable medium of any one of claims 1 to 26, wherein the server is configured to receive requests for downloading the processor-executable instructions of the processor-readable medium to a computing device over a network.

28. A computing device comprising: one or more processors coupled with a display and (a) a processor-readable medium of any one of claims 1 to 26 or (b) wherein the computing device is configured to access and execute the processor-executable instructions with the server of claim 27.

29. The computing device of claim 28, wherein the computing device is any one of a smart phone, a tablet, a laptop or a desktop computer.

30. A method of a server having access to the processor-readable medium of any one of claims 1 to 26, the method comprising receiving, at the server, a request for downloading the processor- executable instructions of the processor-readable medium to a computing device over a network; and transmitting the processor-executable instructions to the computing device in response to the request.

31. A method of a processor for graphically displaying high-resolution respiratory therapy data, the method comprising: rendering and displaying a graphical user interface (GUI) for interacting with a respiratory therapy monitoring system, wherein the GUI includes a first container and a second container, and the first container includes a first graphical control element for selecting a time period over which high-resolution respiratory therapy data was collected; and in response to a selection of a time period using the first graphical control element, dynamically updating content in the second container to include at least one graphical representationRMDDHI 3.4-005 (21) of a set of high-resolution respiratory therapy data that was collected over at least one respiratory therapy period that took place during the selected time period.

32. The method of claim 31, wherein the at least one graphical representation of high-resolution respiratory therapy data is a waveform graph, and the waveform graph is a visual representation of a signal measured over the at least one respiratory therapy period.

33. The method of any one of claims 31 to 32, wherein the first container includes respective graphical elements for each respiratory therapy period of a set of respiratory therapy periods, the selected time period includes a subset of respiratory therapy periods from among the set of respiratory therapy periods, and the subset of respiratory therapy periods includes the at least one respiratory therapy period and zero or more additional respiratory therapy periods .

34. The method of claim 33, wherein the first container includes a set of graphical data buffers, wherein each data buffer in the set of graphical data buffers graphically represents an amount of data collected for a corresponding one of the set of respiratory therapy periods.

35. The method of claim 34, further comprising: in response to detecting a pointer hovering over an individual data buffer in the set of data buffers for a predefined amount of time, displaying a tooltip within the GUI indicating an amount of data collected during a respiratory therapy period corresponding to the individual data buffer.

36. The method of any one of claims 31 to 35, wherein the GUI further includes a third container, and the method comprises: in response to the selection of the time period using the first graphical control element, dynamically updating content in the third container to include a summary of the high-resolution respiratory therapy data that was collected during the selected time period 37. The method of claim 36, wherein the summary of the high-resolution respiratory therapy data that was collected during the selected time period includes at least one of:RMDDHI 3.4-005 (21) usage metrics related to usage of a respiratory therapy device from which the high-resolution respiratory therapy data was collected; therapy metrics related to respiratory therapy provided by the respiratory therapy device; or respiratory indices related to the provided respiratory therapy.

38. The method of any one of claims 33 to 37, wherein the second container includes a set of therapy data panels, and each therapy data panel in the set of therapy data panels corresponds to a respiratory therapy period in the subset of respiratory therapy periods.

39. The method of claim 38, wherein each therapy data panel includes a waveform graph, and the waveform graph of each therapy data panel is a visual representation of a signal measured during the corresponding respiratory therapy period.

40. The method of claim 39, wherein at least one waveform graph of at least one therapy data panel in the set of therapy data panels includes a set of event markers, wherein each event marker in the set of event markers corresponds to a detected sleep-related event.

41. The method of claim 40, wherein each event marker is overlaid on the at least one waveform graph at respective time instants when the corresponding detected sleep-related event took place.

42. The method of any one of claims 38 to 41, wherein each therapy data panel includes a set of second graphical control elements, and each second graphical control element in the set of second graphical control elements corresponds to a signal type.

43. The method of claim 42, further comprising: in response to selection of an individual second graphical control element in the set of second graphical control elements of one therapy data panel in the set of therapy data panels, dynamically updating the one therapy data panel to display a waveform graph of the corresponding signal type.RMDDHI 3.4-005 (21) 44. The method of any one of claims 42 to 43, wherein the set of second graphical control elements includes a flow signal graphical control element corresponding to a flow signal type, a leak signal graphical control element corresponding to a leak signal type, and a pressure signal graphical control element corresponding to a pressure signal type.

45. The method of any one of claims 42 to 44, wherein the second graphical control element is a vertical menu of multiple different a signal types from which to select a desired signal type to be displayed in the waveform graph.

46. The method of any one of claims 42 to 45, wherein each therapy data panel includes a respective third graphical control element for displaying a high resolution data interface for its corresponding therapy data panel.

47. The method of claim 46, further comprising: in response to selection of an individual third graphical control element of an individual therapy data panel in the set of therapy data panels, dynamically updating the second container to display a high resolution data interface corresponding to the individual therapy data panel.

48. The method of any one of claims 46 to 47, wherein the high resolution data interface includes the high-resolution respiratory therapy data collected during an individual respiratory therapy period corresponding to the individual therapy data panel.

49. The method of any one of claims 46 to 48, wherein the respective third graphical control element of each therapy data panel is a button.

50. The method of any one of claims 46 to 49, wherein the high resolution data interface includes a signal navigation panel, and the signal navigation panel includes the waveform graph of the individual therapy data panel and the set of second graphical control elements in the individual therapy data panel for displaying different waveform graphs.RMDDHI 3.4-005 (21) 51. The method of claim 50, wherein the waveform graph in the signal navigation panel is a GUI element configured for interactive analysis of the high-resolution respiratory therapy data.

52. The method of any one of claims 50 to 51, wherein the signal navigation panel includes a fourth graphical control element for displaying a set of event markers on the waveform graph in the signal navigation panel.

53. The method of claim 52, wherein, when the set of event markers are not overlaid on the waveform graph in the signal navigation panel, the method comprises: in response to selection of the fourth graphical control element, dynamically updating the signal navigation panel to overlay the set of event markers on the waveform graph in the signal navigation panel.

54. The method of any one of claims 52 to 53, wherein, when the set of event markers are overlaid on the waveform graph in the signal navigation panel, the method comprises: in response to selection of the fourth graphical control element, dynamically updating the signal navigation panel to remove the set of event markers from the waveform graph in the signal navigation panel.

55. The method of any one of claims 52 to 54, wherein the fourth graphical control element is a toggle switch.

56. The method of any one of claims 52 to 55, wherein at least a subset of event markers in the set of event markers correspond to respective respiratory therapy-related events detected by the respiratory therapy monitoring system.

57. The method of any one of claims 52 to 56, further comprising: in response to detecting a pointer hovering over an individual event marker in the set of event markers for a predefined amount of time, displaying a tooltip indicating an event type of an event corresponding to the individual event marker and an amount of time that the event occurred.RMDDHI 3.4-005 (21) 58. The method of any one of claims 52 to 57, wherein the signal navigation panel includes a fifth graphical control element for displaying an expanded events section.

59. The method of claim 58, wherein when the expanded events section is not displayed in the signal navigation panel, the method comprises: in response to selection of the fifth graphical control element, dynamically updating the signal navigation panel to display the expanded events section.

60. The method of any one of claims 58 or 59, wherein, when the expanded events section is displayed in the signal navigation panel, the method comprises: in response to selection of the fifth graphical control element, dynamically updating the signal navigation panel to hide the expanded events section from being displayed in the signal navigation panel.

61. The method of any one of claims 58 to 60, wherein the fifth graphical control element is an accordion GUI element.

62. The method of any one of claims 58 to 61, wherein the expanded events section, when displayed, includes another set of event markers arranged according to event type.

63. The method of any one of claims 58 to 62, wherein each other event marker in the other set of event markers corresponds to an event marker overlaid on the waveform graph in the signal navigation panel.

64. The method of any one of claims 52 to 63, further comprising: in response to detecting a pointer hovering over an individual other event marker in the set of other event markers for a predefined amount of time, displaying a tooltip indicating an event type of an event corresponding to the individual other event marker and an amount of time that the event occurred.RMDDHI 3.4-005 (21) 65. The method of any one of claims 50 to 64, wherein the waveform graph in the signal navigation panel includes a focused section bounded by a set of delimiter elements, wherein the set of delimiter elements are overlaid on the waveform graph in the signal navigation panel.

66. The method of claim 65, wherein the focused section spans a time range within the individual respiratory therapy period.

67. The method of claim 66, wherein the high resolution data interface includes a plurality of signal panels, wherein the plurality of signal panels include respective waveform graphs for a respective signal type.

68. The method of claim 67, wherein the plurality of signal panels are arranged within the high resolution data interface such that the respective waveform graphs are aligned in time.

69. The method of any one of claims 67 to 68, wherein the plurality of signal panels includes at least one of: a flow signal panel including a flow signal waveform graph, a pressure signal panel including a pressure signal waveform graph, a leak signal panel including a leak signal waveform graph, an oxygen saturation (SpO2) signal panel including an SpO2 signal waveform graph, a respiration rate signal panel including a respiration rate signal waveform graph, and a minute ventilation signal panel including a minute ventilation signal waveform graph.

70. The method of any one of claims 67 to 69, wherein each signal panel includes a respective sixth graphical control element for displaying or hiding content in a corresponding signal panel.

71. The method of claim 70, wherein, when content of an individual signal panel of the plurality of signal panels is displayed, the method comprises: in response to selection of an individual sixth graphical control element of the individualRMDDHI 3.4-005 (21) signal panel, dynamically updating the GUI to hide the content of the individual signal panel.

72. The method of claim 71, wherein, when the content of the individual signal panel is hidden, the method comprises: in response to selection of the individual sixth graphical control element, dynamically updating the GUI to expand the individual signal panel to display the content of the individual signal panel.

73. The method of any one of claims 70 to 72, wherein the respective sixth graphical control element of each signal panel is an accordion icon.

74. The method of any one of claims 67 to 73, wherein the high resolution data interface includes a seventh graphical control element for displaying a set of event bands over the plurality of signal panels.

75. The method of claim 74, wherein, when the set of event bands are not overlaid on the plurality of signal panels, the method comprises: in response to selection of the seventh graphical control element, dynamically updating the high resolution data interface to display the set of event bands on the plurality of signal panels.

76. The method of claim 75, wherein displaying the set of event bands comprises: overlaying the set of event bands on the plurality of signal panels such that the set of event bands extend through the respective waveform graphs.

77. The method of any one of claims 74 to 76, wherein, when the set of event bands are overlaid on the plurality of signal panels, the method comprises: in response to selection of the seventh graphical control element, dynamically updating the high resolution data interface to not display the set of event bands such that the set of event bands are not overlaid on the plurality of signal panels.RMDDHI 3.4-005 (21) 78. The method of any one of claims 75 to 77, wherein each event band in the set of event bands corresponds to a respective event marker located within the focused section.

79. The method of claim 48, wherein a width of each event band corresponds to a timespan of a corresponding event represented by the respective event marker.

80. The method of claim 79, wherein each event band in the set of event bands includes a corresponding tooltip indicating an event type of the corresponding event and the timespan of the corresponding event.

81. The method of any one of claims 74 to 80, wherein the sixth graphical control element is a toggle switch.

82. The method of any one of claims 31 to 81, wherein the second graphical control element is a vertical menu of multiple different time periods from which to select the time period.

83. The method of any one of claims 31 to 81, wherein the first graphical control element is a slider configured to be dragged over the selected time period.

84. The method of any one of claims 31 to 81, wherein the first graphical control element comprises a set of delimiter elements that encompass the selected time period, and each delimiter element of the set of delimiter elements are configured to be moved to encompass more or fewer respiratory therapy periods.

85. A processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 31 to 84.

86. A computing device comprising: the processor-readable medium of claim 85; and one or more processors coupled with a display device, wherein the one or more processorsRMDDHI 3.4-005 (21) are configured to execute the processor-executable instructions to render and display the GUI on the display device.

87. The computing device of claim 86, further comprising: a communication interface coupled with the one or more processors, wherein the communication interface is configured to obtain the processor-executable instructions from at least one server.

88. The computing device of claim 87, wherein the communication interface is configured to access the high-resolution respiratory therapy data from the respiratory therapy monitoring system.

89. The computing device of any one of claims 87 to 88, wherein the at least one server is a server in the respiratory therapy monitoring system.

90. The computing device of any one of claims 86 to 89, wherein the computing device is any one of a smart phone, a tablet computer, a laptop computer, a desktop computer, or a respiratory therapy device.

91. A method of a processor for graphically displaying respiratory therapy data, the method comprising: receiving a set of high-resolution samples of respiratory therapy data representing a period of respiratory therapy; accessing a sample subset of the set of high-resolution samples in response to a user activation of a user selectable graphic interface displaying samples of the set of high-resolution samples on a display, wherein accessing the sample subset comprises generating the sample subset from the set of high-resolution samples of respiratory therapy data by: determining a reference value as a function of a user selected time span made with the user selectable graphic interface; selecting samples from the set of high-resolution samples of respiratory therapy data according to sample position within a data structure of the set of high-resolutionRMDDHI 3.4-005 (21) samples so that sample positions within the data structure of the selected samples are each an integer multiple of the reference value; controlling displaying of the sample subset in the display time window on the display.

92. The method of claim 91, wherein the reference value is a function of the user selected time span and a minimum threshold.

93. The method of claim 92, wherein the function of the user selected time span and a minimum threshold is a ratio.

94. The method of claim 93, further comprising rounding a result of division of the user selected time span and the minimum threshold.

95. The method of any one of claims 91 to 94, further comprising determining the integer multiple of the reference value for a position of a sample of the selected samples as a function of the reference value and the position of the sample.

96. The method of claim 95, wherein the function of the reference value and the position of the sample comprises a modulo function.

97. A graphic user interface for graphically displaying respiratory therapy data, the user interface comprising: a calendar section including a visual set of respiratory therapy periods; a graph section including a graphical data buffer element for each period of the visual set of respiratory therapy periods; wherein each graphical data buffer element depicts a visual quantity for one period of the set of respiratory therapy periods, wherein each of the graphical data buffer elements are displayed in relation to a visual scale; and a graphical user activatable element comprising a scaling action element and configured to operate the graph section, wherein user activation of the graphical user activatable elementRMDDHI 3.4-005 (21) modifies a range of the visual scale and visually adjusts each of the graphical data buffer elements in relation to the modified range of the visual scale.

98. The graphic user interface of claim 97, wherein the modified range of the visual scale is a function of an accumulated therapy usage time of at least one graphical data buffer element of the graphical data buffer elements.

99. The graphic user interface of claim 98, wherein the accumulated therapy usage time comprises a maximum accumulated therapy usage time of the graphical data buffer elements.

100. The graphic user interface of claim 97, wherein the modified range of the visual scale is a function of a period of each of the graphical data buffer elements.

101. A method for generating a graphic user interface for graphically displaying respiratory therapy data, the method comprising: displaying a calendar section including a visual set of respiratory therapy periods; displaying a graph section including a graphical data buffer element for each period of the visual set of respiratory therapy periods; wherein each graphical data buffer element depicts a visual quantity for one period of the set of respiratory therapy periods, wherein each of the graphical data buffer elements are displayed in relation to a visual scale; and displaying a graphical user activatable element comprising a scaling action element and configured to operate the graph section, in response to user activation of the graphical user activatable element, modifying a range of the visual scale and visually adjusting each of the graphical data buffer elements in relation to the modified range of the visual scale.

102. A processor-readable medium, having stored thereon processor-executable instructions which, when executed by a processor, cause the processor to perform a method for generating a graphic user interface for graphically displaying respiratory therapy data according to claim 101.RMDDHI 3.4-005 (21) 103. The processor-readable medium of claim 102, wherein the method generates the graphic user interface of any one of claims 97 to 100.

Images