This application claims priority from U.S. provisional application No. 61/148,666, filed on 30/1/2009, the disclosure of which is incorporated herein by reference.
Detailed Description
The present invention provides a system and method for reporting operational data of a respiratory gas delivery system, such as a bi-level respiratory gas machine or CPAP machine, that will display compliance with prescribed user operational instructions in a manner that prevents tampering with the data by the patient or by a person receiving the data from the patient.
The invention includes a respiratory gas delivery system that monitors and stores selected system parameters and collected operational data. The data accumulates over time and can be retrieved via a display on the device. The data is encoded and the encoded data is subsequently displayed prior to displaying the data. The device user then passes the encoded data to another party, such as a sleep clinic or doctor (hereinafter referred to as the "provider"). The encoded data includes system parameters and operational data to inform a provider of whether a breathing apparatus user is compliant with prescribed instructions for use. The encoded data will appear as readable ASCII characters that can be easily read by the user from the display and transferred to the provider. The encoding of the data simplifies the data reporting process and is not potentially manipulated by the device user, since the user is unaware of the encoding scheme being used to encode the data. Thus, the user does not know what data the provider is collecting.
Fig. 2 is a block diagram of the apparatus of the present invention. Similar to the prior art breathing gas delivery system 12 shown in FIG. 1, the device is connected by a flexible tube (not shown) to a mask (also not shown) that is adapted to be strapped to the user's face. The device includes a user interface panel 32 mounted on an outer surface of the unit. The user interface panel 32 includes an alphanumeric display 50 and one or more control buttons 52, 54, 56, 58, 59, and 62. One or more LED-type indicators 60 may also be included. It should be appreciated that the actual configuration, as well as the number and type of buttons included on the user interface panel 32 may vary from embodiment to embodiment and may depend on the operational characteristics of a particular unit.
The microprocessor 34 and the non-volatile memory 36 control the functions of the unit. The non-volatile memory 36 may be broken down as shown in FIG. 3 and includes an algorithm 36a, a user interface control 36b, an encoder 36c, and a storage device 36d for operating parameters and collected data. As will be appreciated by those skilled in the art, many configurations may be used for the structure of the non-volatile memory. In one possible alternative embodiment, the unit may be provided with a separate microprocessor or Application Specific Integrated Circuit (ASIC) (not shown) dedicated to collecting, storing and manipulating system parameters and selected operational data. Such dedicated components may use raw memory hardware 36 or a separate dedicated memory to store data. The memory used to store the operating algorithms and collected data may include any type of memory known in the art, including non-volatile RAM, flash media, and hard drives, any of which may be internal or external to the device.
Operating algorithm 36a controls the change in pressure in flow element 42 based on monitoring of the user's breathing pattern as sensed by pressure sensor 44 and flow sensor 46. The actual algorithm will vary from unit to unit and in some cases be separately patented or protected as a trade secret.
The interface control 36b receives input from the user interface panel 32 and controls the display 50. The display 50 is used to display all data input to or output from the unit, including the encoded operating parameters and the collected data. The encoder 35c contains algorithms for encoding the operating parameters, while the data storage 36d stores the unencoded operating parameters and collected data.
The microprocessor 34 may also include a clock that provides timing data stored in the non-volatile memory 36 d. In addition to tracking usage of the breathing gas delivery system, the timing data is also used to calculate selected operational performance data from raw data obtained from the motor current, gas pressure sensor 44, and flow sensor 46. The unit may also include an algorithm at 36a for determining when a sleep session begins and ends.
Microprocessor 34 is electrically connected to motor control circuit 38, which is in turn electrically connected to blower 40. Insufflator 40 provides pressurized breathing gas to a flexible tube (not shown) via flow element 42. Motor control circuit 38 is operable to control the speed of blower 40 and, thus, the pressure and flow rate of the air forced into flow element 42.
A pressure sensor 44 and a flow sensor 46 are provided to monitor the pressure and flow rate, respectively, of the air flowing through the flow element 42. Feedback voltage, air pressure and air flow rate representative of blower motor current are provided by motor control circuit 38, pressure sensor 44 and flow sensor 46, respectively, to analog-to-digital converter 48 which converts the data to a digital format for use by operating algorithm 36a and for storage in data storage memory 36 d. As shown in fig. 2, analog-to-digital converter 48 is included in microprocessor 32, however, the present invention may also be implemented with an analog-to-digital converter (not shown) that is separate from microprocessor 32.
As shown in fig. 2, the microprocessor 34 is connected to the user interface panel 32. In a preferred embodiment, the user interface panel 32 includes a backlit display 50, preferably a Liquid Crystal Display (LCD), that displays selected, encoded system operating parameters and data related to the use of the breathing gas delivery system. Although a 16x2 display having two rows of 16 alphanumeric characters is shown in fig. 3, it will be understood that the present invention may also be practiced with displays having different sizes and different types.
In one embodiment of the present invention, the reverse and forward buttons, respectively designated 52 and 54, are mounted immediately below the LCD display 50. The forward and reverse buttons 52 and 54 carry arrow indicia and are used to rank the display 50 by displaying a series of displays of various settings or menus for controlling the machine, one of which is a display of encoded operational data. The forward button 54 is operable to advance the display and the reverse button 52 is operable to move the display in the opposite direction. The up button 59 and the down button 58 are operable to make selections within a setting or menu selected using the left button 52 and the right button 54, respectively. When the buttons 52 and/or 54 are used to advance the display to a display showing encoded operational data, the up button 59 and the down button 58 may be used to display different ASCII character strings representing the respective sets of encoded operational data. By way of example, the first string displayed may represent operational data for the current session, and pressing the up or down arrow keys may advance the display to a different string representing 7, 30, or 90 days of operational data.
A button 56 on the left side of the operating panel 32 turns the control unit 30 on or off and thereby turns the breathing gas delivery system on or off. Light emitting diodes or other types of indicators 60 located below the buttons 58 and 59, when illuminated, indicate that the heater is on. A button 62 on the right side of the operator panel 32 may be used to initiate a system delay that causes the initial air flow to be supplied at a reduced pressure. The air pressure is then gradually increased to the operating pressure over a period of time.
The arrows in fig. 2 indicate the direction of data flow between the operator panel 32 and the microprocessor 34. Thus, the signals generated by operation of the buttons are communicated from the user interface panel 32 to the microprocessor 34 via line 64. The backlighting of the panel and display 50 is controlled by line 66. The heater LEDs 60 are controlled by line 68 and selected system operating parameter data is communicated between the microprocessor 34 and the display 50 via line 70.
It will be appreciated that fig. 2 is a schematic diagram and that although one line is shown, multiple electrical connections may be used to communicate data between the various components illustrated in the figure.
The present invention utilizes an ASCII encoding scheme to display stored operating parameters and data to a system user. The microprocessor 34 includes algorithms stored in the non-volatile memory 36c for converting the operating parameters and data stored in the non-volatile memory 36d into an encoded data string comprised of ASCII characters that can be read from the display 50 and communicated by voice from the patient to the provider. The encoded data includes the following features:
·code identificationEach encoded data string itself contains an identification of the code type and the therapy device type. The code identification is checked in a report generator as described below to ensure that it is the code requested from the user or patient to help identify whether a transcription error has occurred in the reading or recording of the code.
·Check byte(s)-the encoded data string contains one or more characters for assisting in identifying whether there is an error in the transcription of the data. During preparation of the encoded data string, a Cyclic Redundancy Check (CRC) operation is performed on the encoded data string and a comparison is made with one or more check characters within the encoded data string as the code is received.
·Device identification (Serial number)At least one of the encoded data strings further contains a check character based on the device-specific identifier, e.g.The serial number of the device. The identifier is subjected to a CRC calculation and the result is converted into a character and included with one of the encoded data strings. Alternatively the entire identifier or a portion thereof may be encoded and included in its own encoded string or as part of another encoded data string.
·Compression-compressing the operating parameters and data by using the full range of possible values for containing the data and adjusting the resolution of each reported parameter. So, for example, a parameter such as the mean pressure has a value of 0.5cmH2O, but AHl is 0.25, although it should be appreciated that any resolution may be used.
·Encoding/blurring-blurring the operational parameters and data in the encoded data string by encoding in a format that is difficult to interpret by a typical patient. This allows the patient to report information from the device by reading the code without knowing the interpretation of the information contained in the code.
·Real time-recording daily summary data in a non-volatile memory in the device, said data including the data of the latest day being used.
(a) "real-time" generation of code-the encoded data string is preferably generated by reading the recorded data and calculating the average of 7 days, 30 days, 90 days and cumulative usage, although any time period for averaging the data may be used.
(b) The current session that is reporting in progress-the last day-is also reported and accurate even though the device is in use and the current "session" is still in progress.
The present invention also contemplates an application with a provider interface and supporting software for decoding the encoded data string and generating a report from the operating parameters and data. Consider that the application used by the system is hosted on a web server and accessible using a standard web browser via a Uniform Resource Locator (URL). Alternatively, the application may be based on a mainframe or personal computer local to the provider.
A flow diagram illustrating provider interaction with an application is shown in fig. 4. The application is entered by contacting a provider of a user of the breathing gas delivery system (e.g., a sleep clinic or a doctor), via block 80. Contact with the user may be via telephone, for example, but may also be accomplished in other ways, such as via a website, email, SMS message, or any other method that facilitates communication of the encoded data string from the user to the provider. Applications where the user would typically access decoding the encoded data string or generating a report are not considered.
At block 82, the provider requests a particular code and the user repeatedly presses the up arrow button 59 on the user interface panel 32 until the desired code is displayed on the display 50. If the user passes the desired code, the down button 58 may be used to reverse the display direction and access the encoded data string that appears earlier in the display sequence. Pressing the up or down arrow button also initiates the encoder 36c to calculate the selected, encoded data string, which also occurs in block 82. The present invention considers five reported encoded data strings, namely:
a last date code representing the most recent operating parameters and data;
a 7-day code representing the average of the operating parameters and data for the last 7 days;
a 30-day code representing the average of the operating parameters and data for the last 30 days;
a 90-day code representing the average of the operating parameters and data for the last 90 days; and
cumulative usage code representing the average of the operating parameters and data for all days taken after the memory is reset to zero.
It will be appreciated that the invention may also be practiced to provide more or fewer encoded data strings than listed above and that the encoded data strings may be programmed for other time periods than those described above and may contain different operating parameters and data. In addition, the present invention may be used with other types of devices, such as blood monitors, blood glucose level monitors, and the like, as well as other non-medical devices.
Three exemplary displays are illustrated in fig. 5 and show the encoded data strings for one day, seven days, and 30 days, respectively. In a preferred embodiment, the code may be a code representing a display of operating parameters and data for the last 1, 7, 30 and 90 days, and a running average of each operating parameter and data.
It should be noted that the first line of the display preferably provides an unencoded identification of the data (i.e., "1 day"), as shown in FIG. 5, while the second line of the display is an encoded ASCII string that actually represents the operating parameters and data to be presented. Although ten characters are shown in the second line of the code shown in FIG. 5, the code may include more or fewer characters. In addition, a larger display may be used that is capable of displaying more than one code at a time.
As described above, the data is obfuscated using a set of translation tables, each having as an index a set or subset of characters that includes readable ASCII characters. Certain letters and numbers may be omitted to avoid confusion, for example "S" and "5" may be easily confused when reading on an electronic display, as may "I" and "1", "O" and "0", and "V" and "U". Accordingly, the total number of characters that can be displayed may be less than the total number of ASCII characters. Preferably, the characters will be grouped into groups of 3-5 characters separated by dashes or other separator characters to make the display easy to read and transfer.
In one embodiment of the invention, the encoded ASCII string may be derived as follows. The displayed characters are indices to a table of possible values for various parameters or particular types of operational data. The values in the table will have a range and will be scaled according to a resolution that depends on the type of data being represented, with each ASCII character representing a particular value or range of values within the total possible range of values for a particular parameter.
The particular parameter for which the value of the character representation is used depends on the location within the encoded ASCII string displayed on the cell. For example, in a preferred embodiment, the encoded ASCII string representing the activity for the current day may include characters representing the following information:
decoding information and low usage threshold;
the length of the most recent day;
90% pressure;
pressure plateau time percentage;
the% of treatment time for which a leak is detected;
hourly apnea/hypopnea event index;
an hourly non-response event index;
expiratory wheezing index;
miscellaneous information (which may be a bit field);
an 8-bit CRC based on the element sequence number;
an 8-bit CRC based on the encoded alphanumeric string.
Thus, the third character in the string may be an index to a table of pressure readings expressed in a predefined range as a predefined step. Preferably, when used as an index to a table of possible values for each parameter, the characters will not be arranged in order, but will be arranged in random order to provide greater ambiguity in the value being encoded. Each character is also assigned a numerical value that may be useful if a particular character position within the string represents a bitfield.
Alternatively, the data may be encrypted (not shown) using any of a number of well-known data encryption algorithms.
It will be appreciated that the use of the unencoded title string shown on the first row of the display of fig. 5 is intended to be exemplary, and that the invention may also be practiced with other displays, for example, representing other ranges of data. Naturally, other implementations, including machines other than CPAP machines, will have different parameters expressed.
The encoded data string is prepared by the microprocessor 34 according to an encoding algorithm 36c stored in the non-volatile memory 36. A flow chart illustrating the algorithm is shown in fig. 8. The algorithm is entered when the user presses the forward button 52 or the reverse button 54 or the up arrow button 59 or the down arrow button 58 to select the requested encoded data string, via box 110. The algorithm proceeds to a function block 112 where a data template is selected for the currently requested encoded data string. In a function block 114, data for the selected template is read from the operating parameters and data stored in the non-volatile memory 36d and manipulated as necessary in a function block 116 to generate data elements for inclusion in the encoded data string.
During data operations in functional block 116, desired parameters are calculated from the stored operational data. For example, the expiratory wheeze index (EPI) may be calculated from data representing the raw respiratory air pressure and flow stored in the non-volatile memory 36. Alternatively, the desired data may be calculated and the results stored in the non-volatile memory 36d after each operating session of the breathing gas delivery system. Further, for encoded data strings representing multiple days, for example, encoded data strings representing the last 7 days, the average of each daily value is calculated in block 116.
Function block 118-124 describes the establishment of the requested encoded data string. At functional block 118, an identifier corresponding to the requested encoded data string is stored. This identifier is used to check the encoded data string in decision block 88 of the application shown in figure 4. Next, at block 120, a data parameter is scaled to a desired range and resolution. In block 122, the data elements are encoded using the ASCII character index of the above-described value table, with each possible character representing the value of the scaled parameter. Alternatively, other data encryption means may be used. Next, in function block 124, the encoded data element is added to the encoded data string. In decision block 125, if more parameters have been added to the encoded data string, control returns to block 120 and the process is repeated until all desired parameters have been added to the encoded data string.
Next, at function block 126, the algorithm calculates a CRC for the device specific identifier. In a preferred embodiment, the serial number of the device may be used. The identifier CRC is used in an optional decision block 92 of the application shown in figure 4 to check the identifier entered by the provider. The identifier CRC is then encoded and added to the new encoded data string in function block 128.
The algorithm then proceeds to function block 130, where a CRC for the new encoded data string is generated as a whole. The CRC for the new encoded data string is used in decision block 90 of the application shown in figure 4 to verify that the user correctly read the requested code. The CRC for the encoded data string is encoded and added to the encoded data in functional block 132.
The encoding in function block 132 also effectively compresses the data. The new encoded data string is then displayed on the display 50 in function block 134 and the algorithm exits through block 136. If more than one encoded data string is needed, the algorithm is re-entered, via block 110. It will be appreciated that the composition of the encoded data string may be arranged in any desired order other than that described above.
The present invention also contemplates using the described approach to provide feedback that allows settings adjustments made to a particular breathing gas delivery system to be communicated in an audible format from a remote control system to the system (not shown). Such audible formats may include via DTMF, voice or other protocols suitable for the limitations of audio bandwidth communication devices. In alternative embodiments, the device may be provided with an ASCII keyboard or a connector for connecting to a standard computer keyboard may be provided to allow entry of specific codes provided via voice on the phone. This may be accomplished by encoding the settings update command and communicating it to the treatment device in a manner much like the method described above for encoding operating parameters and data for communication to the provider. A variety of protocols may be used including synthesized voice, DTMF, or even the common modem protocol. The breathing gas delivery system will then make a setting adjustment. The system will "listen" for the correct interface handshake and command. The handshaking protocol will preferably include response feedback to ensure safety in communication with the correct breathing gas delivery system, to ensure verification that the settings delivery values are not compromised, and to ensure that the correct settings have been applied to the system after the settings adjustments are made.
Fig. 4 is a flow chart representing a process for requesting and decoding an encoded data string by a provider. As previously described, there is an application into which the provider can enter the code obtained from the user's device, which will decode and verify the encoded data string and generate a report based on the received data.
Referring to fig. 4, at block 80 the provider contacts the user. At block 82, the provider requests a particular encoded data string, which the user may select by repeatedly pressing arrow buttons 52 and 54 and/or up and down arrow buttons 59 and 58, as desired and as previously described. The application then proceeds to decision block 84 where the user reads the encoded data string shown in display 50, which is repeated to the provider over the telephone connection. At block 86, the provider enters the encoded data string into a report generation application, an example of which is shown in FIG. 6, via an interface (e.g., a computer screen and keyboard).
There are two main elements for the provider interface that are combined into the decoder and report generation applications; namely, a data input screen and a data output screen. Consider first a data entry screen displayed on a computer screen and comprising the following data:
a) healthcare data entry
i) Device provider information;
ii) physician information;
iii) patient information; and
iv) device information;
b) an encoded data string input consisting of a location into each encoded data string; and
c) verification feedback
i) Cyclic Redundancy Check (CRC) code error checking
ii) code ID error checking
iii) device Serial number verification
The software user, typically a healthcare provider, fills the form shown in fig. 6 with healthcare data and then enters the encoded data string received over the phone from the breathing gas delivery system user. The provider types the encoded data string into the corresponding box on the screen and the application then applies three checks to the data.
In decision block 88, a code ID error check ensures that the correct code requested by the healthcare provider has been read by the patient. Code ID error checking includes counting the number of days, hours of use, or other criteria that exceed a minimum threshold. Thus, if the healthcare provider requests a 7 day code, but the user incorrectly reads the 30 day code, the error will be flagged to the healthcare provider and a second verification box to the right of the corresponding input box will indicate the error and the application returns to decision block 82, where the provider again requests the user to read the encoded data string. If no error is detected, the first verification box will turn green and the application proceeds to decision block 90.
At decision block 90 of fig. 4, the CRC code error check helps ensure that the encoded data string character has been correctly read by the patient and correctly entered by the healthcare provider. CRC code error checking utilizes bytes to detect errors in characters that may occur when a user speaks the letter "C" on a telephone line, but is heard by the provider as the letter "E". If an error is detected, the first verification box to the right of the respective box will indicate an error, for example by reddening, and the application returns to function box 82, where the provider again requests the user to read the same encoded data string. If no error is detected, the second verification block will provide an indication, for example by turning green, and the application proceeds to decision block 92.
In decision block 92, a breathing gas delivery system serial number check is optionally performed. To select this option, the healthcare provider enters the system serial number in the data entry screen. As described above, a CRC calculated based on the serial number information is embedded in each encoded data string and this information is compared to the calculation of the serial number CRC performed based on the serial number entered into the decoding application by the healthcare provider. If there is a mismatch, the error is flagged to the healthcare provider and a third verification box to the right of the corresponding data entry box will indicate an error. The application then returns to block 82 where the provider may request that the user verify the serial number. If no error is detected, the third verification block will indicate a success status and the application enters decision block 94. The application will continue only if no verification box indicates an error.
In decision block 94, the provider is asked whether another encoded data string is desired. If the user wishes to enter another encoded data string, flow returns to block 82 and the provider requests that the user operate button 52, 54, 58 or 59 to display the next desired encoded data string. Once all desired encoded data strings have been entered, the application proceeds to a function block 96, where the provider may add or change other information on the screen. The application then continues to functional block 98 where the provider clicks the "Generate Report" button to decode the input encoded data string and Generate a Report based on the decoded operating parameters and data. The generated report is displayed as a data output screen and includes:
a) healthcare data from the input screen; and
b) decoded data from the encoded data string.
A typical data output screen is illustrated in fig. 7. The data output screen may also be printed, communicated to another user, and/or stored. The application then exits through block 100.
As described above, the system collects and stores data for one day, seven days, 30 days, 90 days, and cumulative time periods. Data for multiple days and cumulative time periods were averaged for reporting. The encoded data string of the one-day session contains data collected from the most recent session used by the respiratory device. The data is fresh such that when the session data is being compiled, the data is updated in the encoded data string. This allows the user to read the code immediately after waking up without waiting for an unused period of time during which the respiratory system stops the session. As shown in fig. 5, in the preferred embodiment, the encoded data string consists of 10 alphanumeric characters divided into three groups of three, three and four characters, respectively; however, as described above, the encoded data string may be comprised of any number of characters.
In a preferred embodiment of the present invention, the first character of the encoded data string represents information about the system identification and the encoded data string to allow the decoding and reporting software to automatically detect the code type. The next eight characters contain operating parameters and data. The tenth character is a serial number CRC character, the detection of which is optional. The last character is a CRC check character used to validate the encoded data string.
It should be noted that any of a number of well-known polynomials can be used to generate the CRC code, but in a preferred embodiment, the form x is used8+x5+x4A CRC 8 th order polynomial of + 1.
The present invention also contemplates alternative means of using data transmission to the provider. The present invention thus contemplates that data may be transmitted by means other than the patient reading the encoded data string via a telephone link. Such methods of transferring data may be user-initiated, device-initiated, or provider-initiated. To use such a method, the device may be provided with a telephone line connection, a satellite connection or an internet connection, or may use a separate device, such as a modem, which may be connected to the device via a data link. These methods may include, but are not limited to:
(a) encoding and transmission in audible format, such as DTMF (dual tone multi frequency);
(b) frequency or similar methods, where the device will "play" the encoded information to the telephone recipient;
(c) synthesized speech or other protocol suitable for the limitations of audio bandwidth communication equipment where the device will "speak" the encoded information to the telephone recipient; and
(d) an email, an SMS message, or any other method known in the art for transmitting an ASCII string.
The system may also include a feedback modulation mode for tone or DTMF signaling. An audible link increases the likelihood of artificial forgery and interference when presented within a communication scheme. Maintaining a sufficient signal-to-noise ratio for the receiving party to distinguish the information from the background noise is a considerable challenge. The signal can easily be too small to be detected or too loud to cause distortion. Several modulation techniques can be used to improve the likelihood of successful transmission, namely:
(a) each tone is modulated individually (faded from minimum to maximum) with the amplitude of each tone fading in amplitude from low to high levels. As the tone increases to a sufficient amplitude above background, the receiving party will detect it, and as the amplitude continues to increase, it may reach a maximum level that causes distortion, yet it has been successfully detected. This allows for successful transmission of single-burst sounds over the system with a variety of audio links.
(b) Each sequence is modulated as a whole, with the transmission of each sequence of tones starting at a lower level and repeating over the entire sequence with higher and higher amplitudes until successful reception is confirmed.
(c) The "test" sequence is modulated from a low level to a high level until it is successfully detected.
The amplitude is then increased to provide some additional margin and the horizontal transmission code is used.
The device may also include a session detection feature that requires the breathing apparatus to be powered in the "off" state and includes the following phases:
(1) start session-detected after a predetermined period of continuous use (e.g., half an hour);
(2) starting from a half-hour period the trip timer counts while the user is breathing; and
(3) stop session-detect a predefined period of unused time (e.g., four hours).
The system also adds any time to the trip timer that stops the afternoon nap period within 24 hours of the session.
In an alternative embodiment of the respiratory gas delivery system control unit, the monitoring module may be attached by a technician to the rear of the control unit, into which a removable memory card may be inserted. The monitoring module is operable to record the selected operational data. However, rather than requiring the device user to transmit encoded data to the provider, a technician periodically accesses the user and collects the memory card, or the user sends the memory card to the provider and is provided with a replacement. Alternatively, the user may use an application on the local computer to read the card and transmit the data to the provider. Thus, the user does not need to participate in the data collection process. After removing the memory card, the technician may insert a new memory card for further data collection or, if monitoring is complete, remove the monitoring module. When returning to the clinic or doctor's office, the technician will download the contents of the memory card onto the computer and then log into the report generation service or application to decode the data and generate a report as described above.
The invention and the main modes of operation have been explained and illustrated in the preferred embodiments of the invention. However, it must be understood that this invention may be practiced otherwise than as specifically explained and illustrated without departing from its spirit or scope. Thus, the present invention also contemplates that other or additional features (e.g., alternative operating parameters) may be monitored and provided as output data. For example, a humidity sensor (not shown) may be incorporated into the device to provide monitoring and storage of data regarding the humidity of the breathing gas delivered by the system. Moreover, as previously mentioned, the present invention is not limited to use with CPAP or breathing gas delivery systems, but may be used with other medical-related or non-medical devices.