Patent Description:
Oxygen is normally supplied to portable ventilators by high flow oxygen concentrators with constant oxygen flow, compressed gas cylinders, or fixed medical oxygen plumbing systems. The oxygen is mixed with air within the ventilator to supply a desired fraction of inspired oxygen (FIO2) to the patient so as to efficiently treat a medical condition. When such high-pressure sources are unavailable or limited in capacity, low pressure, low flow oxygen is supplied to ventilators using oxygen concentrators, which typically delivers <NUM>-<NUM> LPM oxygen by mixing air and oxygen at either the input or the outlet of the blower or compressor.

In the past, oxygen has been added to the inspiratory limb of the patient's breathing circuit prior to the inspiration cycle. The oxygen-rich gas stored in the inspiratory limb is preferentially delivered to the patient when a breath is delivered by the ventilator. The inspiratory limb's proximal location in the ventilator circuit results in an elevated fraction of inspired oxygen within the alveolar space of the patient's lungs. In all cases, the current state of the art ventilators uses only low, continuous flow settings of oxygen from the concentrator or other oxygen delivery device. This method can only be used with continues flow concentrators and cannot be used with triggered oxygen concentrators.

A concentrator has been connected to the inlet of the ventilator's compressor. This volume of oxygen, plus the air delivered by the ventilator, combines to make a homogenous mixture which is then delivered to a patient to yield a fraction of inspired oxygen within the patient's lungs. In this type of configuration, the ventilator cannot trigger a concentrator and can only use a fix flow concentrator.

Portable oxygen concentrators, compressed gas cylinders, and liquid oxygen storage devices are also used to provide supplemental oxygen to respiratory patients via nasal cannula for the purposes of increasing the fraction of inspired oxygen. In these cases, oxygen delivery is either a low continuous flow or a pulsed flow triggered by a decrease in pressure in the cannula as the patient inhales. This method does not provide any mechanical ventilation to the patient.

Taken alone, these prior art methods are capable of producing fractions of inspired oxygen for the patient sufficient enough to treat some medical conditions while the patient is at home or near a high oxygen flow source. When traditional high-pressure or high-flow sources of oxygen are not available, not economical, or need to be conserved, there is a need for systems and techniques that improve FIO2 values while conserving oxygen and energy beyond the methods that are currently available.

Prior art methods can produce fractions of inspired oxygen from a pulse concentrator by modifying the concentrator to accept a signal from the ventilator. However, there is a need for a portable ventilator to be used with all unmodified concentrators and still be able to deliver the oxygen to the nasal pillows interface needed to increase the FIO2 of the patient.

Prior art methods are capable of producing FIO2 from a pulse concentrator by modifying the patient circuit to include a Venturi valve or Venturi tube to generate a negative pressure that triggers the oxygen concentrator. These methods require a higher pressure and/or flow from the portable ventilator so that the Venturi can generate the negative pressure needed to trigger the concentrator. Portable ventilators have low pressure and low flow, so they cannot be used with Venturi which requires higher pressure and/or flow to be able to generate negative pressure. Also, the Venturi will leak air at low pressure and/or flow which will reduce the flow and/or pressure to the patient. Using these methods, FIO2 will be low since the oxygen pulse is mixed with the flow of the ventilator and some of this mixed flow will leak at the patient interface. There is a need for portable ventilators to be used with all unmodified pulse concentrators and still be able to deliver higher FIO2 to the patient by bypassing the leak of the patient circuit and the patient interface.

These prior art methods are not effective when used for portable ventilator with a portable pulse concentrator. Portable ventilators are limited in pressure and/or flow and they implement a high level of leaks at the interface, therefore the fractions of inspired oxygen will not be effective when portable pulse concentrators are used. There is a need for a portable ventilator that can trigger any pulse oxygen concentrator and deliver the oxygen pulse to the patient interface directly and bypass the leak ports in the patient interface and circuit.

The invention possesses numerous benefits and advantages over known portable ventilators. In particular, the invention utilizes a method to trigger any portable oxygen concentrator that uses triggered pulse delivery mechanism. Moreover, the oxygen pulse is delivered directly to the patient interface and bypasses any leaks in the patient circuit or patient interface. Because of this invention, patients who require lighter equipment can be outside for an extended time while being portable and receiving higher FIO2. From the United States patent application publication <CIT> a medical device is known, supplying oxygen and a drug from respective supply tanks through a multiple lumen nasal cannula. A patient a breathing assistance apparatus including multiple lumen nasal patient interface is know from the he United States patent application publication <CIT>. further, from the international patent application publication <CIT> a medical device for delivering an aerosol is known. From the international patent application publication <CIT> a ventilator is known including an oxygen concentrator. It is an object of the invention to create a ventilator delivering sufficiently strong oxygen pulses and avoiding leakage on the path of the oxygen to the patient interface. This is achieved by the features of independent claim <NUM>. Advantageous further embodiments are claimed in the dependent claims.

The foregoing, together with other features and advantages of the present invention, will become more apparent when referring to the following specification, claims, and accompanying drawings.

For a more complete understanding of the present invention, reference is now made to the following detailed description of the embodiments illustrated in the accompanying drawings, wherein:.

The subject matter described herein is taught by way of example implementations. Various details have been omitted for the sake of clarity and to avoid obscuring the subject matter. The examples shown below are directed to devices, apparatus and methods for increasing the fraction of inspired oxygen (FIO2) to a patient. Other features and advantages of the subject matter should be apparent from the following description.

After reading this description it will become apparent to one skilled in the art how to implement the invention in various alternative embodiments and alternative applications. However, all the various embodiments of the present invention will not be described herein. It is understood that the embodiments presented here are presented by way of an example only, and not limitation.

The terminology used herein is for describing particular embodiments only and is not intended to be limiting of the invention. As such, this detailed description of various alternative embodiments should not be construed to limit the scope or breadth of the present invention.

A system and method for increasing the fraction of inspired oxygen (FIO2) to a patient or user (e.g., spontaneously breathing patient, non-spontaneously breathing patient) in a medical ventilator that uses pulse flow rather than continuous flow of oxygen from low pressure oxygen sources such as the oxygen concentrators described. Other oxygen sources such as oxygen concentrators, compressed oxygen tanks, membrane oxygen generators, chemical oxygen generators, liquid oxygen systems, or any oxygen delivery system that requires patient effort to initiate the delivery of the oxygen pulse and/or flow could be used in the same manner.

<FIG> illustrates a typical prior art medical ventilator <NUM>. The medical ventilator <NUM> includes a positive pressure source <NUM>, patient circuit <NUM> for supplying mixed oxygen and air to a user and pillows user interface <NUM> and portable oxygen source <NUM>.

Conditions of the medical ventilator <NUM> such as flow rate, oxygen concentration level, etc. may be constant for the system, may be manually controllable, and/or may be automatically controllable. For example, the medical ventilator <NUM> may include a user interface that allows the user, provider, doctor, etc. to enter information, e.g., prescription oxygen level, flow rate, etc. to control the oxygen output of the ventilator system <NUM>. A flow of oxygen mixed with air is distributed from the medical ventilator <NUM> to the patient during each breath via breathing or user circuit <NUM> in the inspiration phase, and the flow is discontinued during the exhalation phase. It should be noted that some ventilators have a small flow rate during exhalation phase used to maintain a positive pressure during exhalation so in those instances flow is not completely discontinued during the exhalation phase. A small continuous flow rate of oxygen can be added during this phase too.

The control module of the ventilator <NUM> may take any well-known form in the art and includes a central microprocessor or CPU that communicates with the components of the ventilator <NUM> described herein via one or more interfaces, controllers, or other electrical circuit elements for controlling and managing the medical ventilator <NUM>. The ventilator system <NUM> may include a user interface as a part of the control module <NUM> or coupled to the control module for allowing the user, provider, doctor, etc. to enter information, e.g., prescription oxygen level, flow rate, activity level, etc., to control the ventilator.

<FIG> illustrates a prior art medical ventilator system including an oxygen source (e.g., oxygen concentrator/conserving device) <NUM>, a medical ventilator <NUM> and a breathing circuit <NUM> between the ventilator <NUM> and a patient <NUM>. In one embodiment, the oxygen concentrator <NUM> includes a controller/control module (e.g., controller that processed one or more modules stored in memory perform the function(s) described herein) that is configured to generate a trigger signal <NUM> to initiate the distribution of pulses of oxygen (or a pulse bolus of oxygen) from the oxygen concentrator <NUM>. In some embodiments, a conserving device may be used in conjunction with the oxygen concentrator <NUM> to control the distribution of oxygen to the breathing circuit <NUM>. In other embodiments, the conserving device can be independent of the oxygen concentrator <NUM>. The controller module for generating a trigger signal to initiate the distribution of pulses of oxygen from the oxygen concentrator <NUM> can be incorporated in the oxygen concentrator <NUM> and/or the conserving device. In this prior art, the oxygen concentrator needs to be modified to accept a triggering signal from the ventilator.

<FIG> illustrates a prior art medical ventilator system including an oxygen source (e.g., oxygen concentrator/conserving device) <NUM>, a medical ventilator <NUM> and a breathing circuit <NUM> between the ventilator <NUM> and a patient <NUM>. In one embodiment, the oxygen concentrator <NUM> connects to the negative port of a Venturi <NUM> which is located in the breathing circuit <NUM>. The Venturi <NUM> is configured to generate a negative pressure which is connected to the concentrator to initiate the distribution of a pulse of oxygen (or a pulse bolus of oxygen) from the oxygen concentrator <NUM>. The patient circuit need to be modified to include the Venturi <NUM>. The Venturi <NUM> requires higher pressure and/or flow than pressures and/or flows generated by a potable ventilator. One pulse can be delivered by the concentrator using this method which will reduce the FIO2. When using a BI-Level ventilation method or PEEP during exhalation, the Venturi will generate a negative pressure during the inhalation and exhalation cycles which will cause the concentrator to miss triggering and therefore reduce the FIO2 to the patient.

With reference to <FIG>, an embodiment of a medical ventilator <NUM> will be described. The medical ventilator <NUM> includes a positive pressure source <NUM> to generate air flow that creates positive pressure at the patient and negative pressure source <NUM> to generate a negative pressure that triggers an oxygen source (e.g., oxygen concentrator) <NUM>. The medical ventilator <NUM> is connected to a patient/breathing circuit <NUM> with multi-tubes or multi-lumen tube. The multi-lumen tube contains three lumens, one for the ventilator pressurized air, one for the oxygen flow and one for pressure sensing. The breathing circuit <NUM> is connected to pillows interface <NUM> which is connected to the patient <NUM>. The ventilator <NUM> can be used with any oxygen concentrators <NUM> currently used to provide oxygen to ambulatory patients via a nasal cannula. The triggering of the pulses of the oxygen by the oxygen concentrator <NUM> is controlled by the negative pressure device within the ventilator <NUM>. The negative pressure can be generated to start the oxygen pulse or pulses during the inspiration cycle and/or during exhalation cycle.

The patient/breathing circuit <NUM> includes a special connector to the medical ventilator. The breathing circuit <NUM> includes three tubes or a three-lumen tube: <NUM>) an air pressurized gas, <NUM>) an oxygen flow and/or pulses, and <NUM>) a pressure sensing line. The three tubes or the three-lumen tube are connected to the nasal pillows interface <NUM>.

The negative pressure device <NUM> generates negative pressure in the ventilator <NUM> which triggers the concentrator <NUM> to deliver a pulse of oxygen to the ventilator oxygen inlet. The pulse of oxygen will be delivered directly to the oxygen cannula in the nasal pillows interface <NUM> through the patient/breathing circuit <NUM>.

In another embodiment, a small continuous flow of oxygen may also be supplied when a pulse is not being delivered to aid in elevating FIO2.

In one embodiment, the oxygen concentrator <NUM> supplies pulse flow to the ventilator <NUM> to gain higher FIO2 values. The medical ventilator <NUM> may include one or more output sensors to sense one or more conditions of the user <NUM>, pressure, flow, leak, respiratory rate, activity environment, etc. to monitor the patient while ventilated.

<FIG> illustrates one example of a waveform graph identifying the patient pressure signal <NUM> and air flow <NUM> and one oxygen pulse <NUM> delivered by the concentrator to the ventilator <NUM>. The x-axis represents the time in seconds in the patient or breathing circuit and the y-axis represents pressure in cm H2O <NUM>. In one embodiment, the ventilator air flow <NUM> is shown, and one oxygen pulse is shown in the same graph <NUM>.

<FIG> illustrates one example of a waveform graph identifying the patient pressure signal <NUM> and air flow <NUM> and multiple oxygen pulses <NUM> delivered by the ventilator. The x-axis represents the time in seconds in the patient or breathing circuit <NUM> and the y-axis represents pressure in cmH2O <NUM>. In one embodiment, the ventilator air flow <NUM>, and two oxygen pulses <NUM> are shown in the same graph.

With reference to <FIG>, an embodiment of a control unit <NUM> may take any well-known form in the art and includes a central microprocessor or CPU <NUM> in communication with the components of the system described herein via one or more interfaces, controllers, or other electrical circuit elements for controlling and managing the system. The system may include a user interface as part of the control unit or coupled to the control unit for allowing the user, provider, doctor, etc. to enter information, e.g., number of oxygen pulses, inspiratory positive air pressure, expiratory positive air pressure, flow rate, activity level, etc., to control the system.

With reference to <FIG>, an embodiment of a pillows nasal interface <NUM> worn by a patient will be described. The interface <NUM> contains an oxygen cannula <NUM> integrated into the interface to deliver a pulse and/or pulses of oxygen to the patient to increase FIO2. Feeding tubes <NUM> contains a connector <NUM> to connect the interface to the patient/breathing circuit <NUM>. The feed tubing <NUM> may be a thin flexible tube made of an inert material such as polyurethane, silicone, or another material known in the art. It will be noted that all components of the interface may be made of medical grade biocompatible materials. The medical ventilator <NUM> forces a gas such as air and/or oxygen through the tubing <NUM>. The medical ventilator <NUM> may provide volume and/or pressure type of therapy delivered through the interface to the patient.

With reference to <FIG> and <FIG>, an embodiment of the pillows interface <NUM> will be described in greater detail. Pressurized air from air delivery lumen <NUM> (from the ventilator <NUM>) and oxygen gas from oxygen cannula/oxygen deliver lumens <NUM>, <NUM> are mixed in a mixing chamber <NUM> of pillows <NUM>. Lumen <NUM> is a triggering lumen. In an alternative embodiment, the oxygen cannula/oxygen deliver lumen <NUM> may be an opening in the tube and not extend all the way into the chamber <NUM> of the pillows <NUM>. The pillows <NUM> seal at nostrils <NUM> of patient <NUM> and deliver the mixed gases from the chamber <NUM> of the pillows <NUM> to the patient <NUM>.

<FIG> illustrates an example system <NUM> that may be used, for example, but not by way of limitation, for control and/or communication of/with the control unit <NUM> of the ventilator <NUM>, according to an embodiment. The infrastructure may comprise a platform <NUM> (e.g., one or more servers) which hosts and/or executes one or more of the various functions, processes, methods, and/or software modules described herein. Platform <NUM> may comprise dedicated servers, or may instead comprise cloud instances, which utilize shared resources of one or more servers. These servers or cloud instances may be collocated and/or geographically distributed. Platform <NUM> may also comprise or be communicatively connected to a server application <NUM> and/or one or more databases <NUM>. In addition, platform <NUM> may be communicatively connected to one or more user systems <NUM> via one or more networks <NUM>. Platform <NUM> may also be communicatively connected to one or more external systems <NUM> (e.g., other platforms, websites, etc.) via one or more networks <NUM>.

Network(s) <NUM> may comprise the Internet, and platform <NUM> may communicate with user system(s) <NUM> through the Internet using standard transmission protocols, such as HyperText Transfer Protocol (HTTP), HTTP Secure (HTTPS), File Transfer Protocol (FTP), FTP Secure (FTPS), Secure Shell FTP (SFTP), and the like, as well as proprietary protocols. While platform <NUM> is illustrated as being connected to various systems through a single set of network(s) <NUM>, it should be understood that platform <NUM> may be connected to the various systems via different sets of one or more networks. For example, platform <NUM> may be connected to a subset of user systems <NUM> and/or external systems <NUM> via the Internet, but may be connected to one or more other user systems <NUM> and/or external systems <NUM> via an intranet. Furthermore, while only a few user systems <NUM> and external systems <NUM>, one server application <NUM>, and one set of database(s) <NUM> are illustrated, it should be understood that the infrastructure may comprise any number of user systems, external systems, server applications, and databases.

User system(s) <NUM> may comprise any type or types of computing devices capable of wired and/or wireless communication, including without limitation, desktop computers, laptop computers, tablet computers, smart phones or other mobile phones, servers, game consoles, televisions, set-top boxes, electronic kiosks, point-of-sale terminals, Automated Teller Machines, and/or the like.

Platform <NUM> may comprise web servers which host one or more websites and/or web services. In embodiments in which a website is provided, the website may comprise a graphical user interface, including, for example, one or more screens (e.g., webpages) generated in HyperText Markup Language (HTML) or other language. Platform <NUM> transmits or serves one or more screens of the graphical user interface in response to requests from user system(s) <NUM>. In some embodiments, these screens may be served in the form of a wizard, in which case two or more screens may be served in a sequential manner, and one or more of the sequential screens may depend on an interaction of the user or user system <NUM> with one or more preceding screens. The requests to platform <NUM> and the responses from platform <NUM>, including the screens of the graphical user interface, may both be communicated through network(s) <NUM>, which may include the Internet, using standard communication protocols (e.g., HTTP, HTTPS, etc.). These screens (e.g., webpages) may comprise a combination of content and elements, such as text, images, videos, animations, references (e.g., hyperlinks), frames, inputs (e.g., textboxes, text areas, checkboxes, radio buttons, drop-down menus, buttons, forms, etc.), scripts (e.g., JavaScript), and the like, including elements comprising or derived from data stored in one or more databases (e.g., database(s) <NUM>) that are locally and/or remotely accessible to platform <NUM>. Platform <NUM> may also respond to other requests from user system(s) <NUM>.

Platform <NUM> may further comprise, be communicatively coupled with, or otherwise have access to one or more database(s) <NUM>. For example, platform <NUM> may comprise one or more database servers which manage one or more databases <NUM>. A user system <NUM> or server application <NUM> executing on platform <NUM> may submit data (e.g., user data, form data, etc.) to be stored in database(s) <NUM>, and/or request access to data stored in database(s) <NUM>. Any suitable database may be utilized, including without limitation MySQL™, Oracle™, IBM™, Microsoft SQL™, Access™, and the like, including cloud-based databases and proprietary databases. Data may be sent to platform <NUM>, for instance, using the well-known POST request supported by HTTP, via FTP, and/or the like. This data, as well as other requests, may be handled, for example, by server-side web technology, such as a servlet or other software module (e.g., comprised in server application <NUM>), executed by platform <NUM>.

In embodiments in which a web service is provided, platform <NUM> may receive requests from external system(s) <NUM>, and provide responses in eXtensible Markup Language (XML), JavaScript Object Notation (JSON), and/or any other suitable or desired format. In such embodiments, platform <NUM> may provide an application programming interface (API) which defines the manner in which user system(s) <NUM> and/or external system(s) <NUM> may interact with the web service. Thus, user system(s) <NUM> and/or external system(s) <NUM> (which may themselves be servers), can define their own user interfaces, and rely on the web service to implement or otherwise provide the backend processes, methods, functionality, storage, and/or the like, described herein. For example, in such an embodiment, a client application <NUM> executing on one or more user system(s) <NUM> may interact with a server application <NUM> executing on platform <NUM> to execute one or more or a portion of one or more of the various functions, processes, methods, and/or software modules described herein. Client application <NUM> may be "thin," in which case processing is primarily carried out server-side by server application <NUM> on platform <NUM>. A basic example of a thin client application is a browser application, which simply requests, receives, and renders webpages at user system(s) <NUM>, while the server application on platform <NUM> is responsible for generating the webpages and managing database functions. Alternatively, the client application may be "thick," in which case processing is primarily carried out client-side by user system(s) <NUM>. It should be understood that client application <NUM> may perform an amount of processing, relative to server application <NUM> on platform <NUM>, at any point along this spectrum between "thin" and "thick," depending on the design goals of the particular implementation. In any case, the application described herein, which may wholly reside on either platform <NUM> (e.g., in which case server application <NUM> performs all processing) or user system(s) <NUM> (e.g., in which case client application <NUM> performs all processing) or be distributed between platform <NUM> and user system(s) <NUM> (e.g., in which case server application <NUM> and client application <NUM> both perform processing), can comprise one or more executable software modules that implement one or more of the functions, processes, or methods of the application described herein.

<FIG> is a block diagram illustrating an example wired or wireless system <NUM> that may be used in connection with various embodiments described herein such as, but not by way of limitation, the control unit <NUM> of the ventilator <NUM>. For example, system <NUM> may be used as or in conjunction with one or more of the functions, processes, or methods (e.g., to store and/or execute the application or one or more software modules of the application) described herein, and may represent components of platform <NUM>, user system(s) <NUM>, external system(s) <NUM>, and/or other processing devices described herein. System <NUM> can be a server or any conventional personal computer, or any other processor-enabled device that is capable of wired or wireless data communication. Other computer systems and/or architectures may be also used, as will be clear to those skilled in the art.

System <NUM> preferably includes one or more processors, such as processor <NUM>. Additional processors may be provided, such as an auxiliary processor to manage input/output, an auxiliary processor to perform floating-point mathematical operations, a special-purpose microprocessor having an architecture suitable for fast execution of signal-processing algorithms (e.g., digital-signal processor), a slave processor subordinate to the main processing system (e.g., back-end processor), an additional microprocessor or controller for dual or multiple processor systems, and/or a coprocessor. Such auxiliary processors may be discrete processors or may be integrated with processor <NUM>. Examples of processors which may be used with system <NUM> include, without limitation, the Pentium® processor, Core i7® processor, and Xeon® processor, all of which are available from Intel Corporation of Santa Clara, California.

Processor <NUM> is preferably connected to a communication bus <NUM>. Communication bus <NUM> may include a data channel for facilitating information transfer between storage and other peripheral components of system <NUM>. Furthermore, communication bus <NUM> may provide a set of signals used for communication with processor <NUM>, including a data bus, address bus, and/or control bus (not shown). Communication bus <NUM> may comprise any standard or non-standard bus architecture such as, for example, bus architectures compliant with industry standard architecture (ISA), extended industry standard architecture (EISA), Micro Channel Architecture (MCA), peripheral component interconnect (PCI) local bus, standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE) including IEEE <NUM> general-purpose interface bus (GPIB), IEEE <NUM>/S-<NUM>, and/or the like.

System <NUM> preferably includes a main memory <NUM> and may also include a secondary memory <NUM>. Main memory <NUM> provides storage of instructions and data for programs executing on processor <NUM>, such as one or more of the functions and/or modules discussed herein. It should be understood that programs stored in the memory and executed by processor <NUM> may be written and/or compiled according to any suitable language, including without limitation C/C++, Java, JavaScript, Perl, Visual Basic,. NET, and the like. Main memory <NUM> is typically semiconductor-based memory such as dynamic random access memory (DRAM) and/or static random access memory (SRAM). Other semiconductor-based memory types include, for example, synchronous dynamic random access memory (SDRAM), Rambus dynamic random access memory (RDRAM), ferroelectric random access memory (FRAM), and the like, including read only memory (ROM).

Secondary memory <NUM> may optionally include an internal medium <NUM> and/or a removable medium <NUM>. Removable medium <NUM> is read from and/or written to in any well-known manner. Removable storage medium <NUM> may be, for example, a magnetic tape drive, a compact disc (CD) drive, a digital versatile disc (DVD) drive, other optical drive, a flash memory drive, and/or the like.

Secondary memory <NUM> is a non-transitory computer-readable medium having computer-executable code (e.g., disclosed software modules) and/or other data stored thereon. The computer software or data stored on secondary memory <NUM> is read into main memory <NUM> for execution by processor <NUM>.

In alternative embodiments, secondary memory <NUM> may include other similar means for allowing computer programs or other data or instructions to be loaded into system <NUM>. Such means may include, for example, a communication interface <NUM>, which allows software and data to be transferred from external storage medium <NUM> to system <NUM>. Examples of external storage medium <NUM> may include an external hard disk drive, an external optical drive, an external magneto-optical drive, and/or the like. Other examples of secondary memory <NUM> may include semiconductor-based memory, such as programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), and flash memory (block-oriented memory similar to EEPROM).

As mentioned above, system <NUM> may include a communication interface <NUM>. Communication interface <NUM> allows software and data to be transferred between system <NUM> and external devices (e.g. printers), networks, or other information sources. For example, computer software or executable code may be transferred to system <NUM> from a network server (e.g., platform <NUM>) via communication interface <NUM>. Examples of communication interface <NUM> include a built-in network adapter, network interface card (NIC), Personal Computer Memory Card International Association (PCMCIA) network card, card bus network adapter, wireless network adapter, Universal Serial Bus (USB) network adapter, modem, a wireless data card, a communications port, an infrared interface, an IEEE <NUM> fire-wire, and any other device capable of interfacing system <NUM> with a network (e.g., network(s) <NUM>) or another computing device. Communication interface <NUM> preferably implements industry-promulgated protocol standards, such as Ethernet IEEE <NUM> standards, Fiber Channel, digital subscriber line (DSL), asynchronous digital subscriber line (ADSL), frame relay, asynchronous transfer mode (ATM), integrated digital services network (ISDN), personal communications services (PCS), transmission control protocol/Internet protocol (TCP/IP), serial line Internet protocol/point to point protocol (SLIP/PPP), and so on, but may also implement customized or non-standard interface protocols as well.

Software and data transferred via communication interface <NUM> are generally in the form of electrical communication signals <NUM>. These signals <NUM> may be provided to communication interface <NUM> via a communication channel <NUM>. In an embodiment, communication channel <NUM> may be a wired or wireless network (e.g., network(s) <NUM>), or any variety of other communication links. Communication channel <NUM> carries signals <NUM> and can be implemented using a variety of wired or wireless communication means including wire or cable, fiber optics, conventional phone line, cellular phone link, wireless data communication link, radio frequency ("RF") link, or infrared link, just to name a few.

Computer-executable code (e.g., computer programs, such as the disclosed application, or software modules) is stored in main memory <NUM> and/or secondary memory <NUM>. Computer programs can also be received via communication interface <NUM> and stored in main memory <NUM> and/or secondary memory <NUM>. Such computer programs, when executed, enable system <NUM> to perform the various functions of the disclosed embodiments as described elsewhere herein.

In this description, the term "computer-readable medium" is used to refer to any non-transitory computer-readable storage media used to provide computer-executable code and/or other data to or within system <NUM>. Examples of such media include main memory <NUM>, secondary memory <NUM> (including internal memory <NUM>, removable medium <NUM>, and external storage medium <NUM>), and any peripheral device communicatively coupled with communication interface <NUM> (including a network information server or other network device). These non-transitory computer-readable media are means for providing executable code, programming instructions, software, and/or other data to system <NUM>.

In an embodiment that is implemented using software, the software may be stored on a computer-readable medium and loaded into system <NUM> by way of removable medium <NUM>, I/O interface <NUM>, or communication interface <NUM>. In such an embodiment, the software is loaded into system <NUM> in the form of electrical communication signals <NUM>. The software, when executed by processor <NUM>, preferably causes processor <NUM> to perform one or more of the processes and functions described elsewhere herein.

In an embodiment, I/O interface <NUM> provides an interface between one or more components of system <NUM> and one or more input and/or output devices. Example input devices include, without limitation, sensors, keyboards, touch screens or other touch-sensitive devices, biometric sensing devices, computer mice, trackballs, pen-based pointing devices, and/or the like. Examples of output devices include, without limitation, other processing devices, cathode ray tubes (CRTs), plasma displays, light-emitting diode (LED) displays, liquid crystal displays (LCDs), printers, vacuum fluorescent displays (VFDs), surface-conduction electron-emitter displays (SEDs), field emission displays (FEDs), and/or the like. In some cases, an input and output device may be combined, such as in the case of a touch panel display (e.g., in a smartphone, tablet, or other mobile device).

System <NUM> may also include one or more optional wireless communication components that facilitate wireless communication over a voice network and/or a data network (e.g., in the case of user system <NUM>). The wireless communication components comprise an antenna system <NUM>, a radio system <NUM>, and a baseband system <NUM>. In system <NUM>, radio frequency (RF) signals are transmitted and received over the air by antenna system <NUM> under the management of radio system <NUM>.

In an embodiment, antenna system <NUM> may comprise one or more antennae and one or more multiplexors (not shown) that perform a switching function to provide antenna system <NUM> with transmit and receive signal paths. In the receive path, received RF signals can be coupled from a multiplexor to a low noise amplifier (not shown) that amplifies the received RF signal and sends the amplified signal to radio system <NUM>.

In an alternative embodiment, radio system <NUM> may comprise one or more radios that are configured to communicate over various frequencies. In an embodiment, radio system <NUM> may combine a demodulator (not shown) and modulator (not shown) in one integrated circuit (IC). The demodulator and modulator can also be separate components. In the incoming path, the demodulator strips away the RF carrier signal leaving a baseband receive audio signal, which is sent from radio system <NUM> to baseband system <NUM>.

If the received signal contains audio information, then baseband system <NUM> decodes the signal and converts it to an analog signal. Then the signal is amplified and sent to a speaker. Baseband system <NUM> also receives analog audio signals from a microphone. These analog audio signals are converted to digital signals and encoded by baseband system <NUM>. Baseband system <NUM> also encodes the digital signals for transmission and generates a baseband transmit audio signal that is routed to the modulator portion of radio system <NUM>. The modulator mixes the baseband transmit audio signal with an RF carrier signal, generating an RF transmit signal that is routed to antenna system <NUM> and may pass through a power amplifier (not shown). The power amplifier amplifies the RF transmit signal and routes it to antenna system <NUM>, where the signal is switched to the antenna port for transmission.

Baseband system <NUM> is also communicatively coupled with processor <NUM>, which may be a central processing unit (CPU). Processor <NUM> has access to data storage areas <NUM> and <NUM>. Processor <NUM> is preferably configured to execute instructions (i.e., computer programs, such as the disclosed application, or software modules) that can be stored in main memory <NUM> or secondary memory <NUM>. Computer programs can also be received from baseband processor <NUM> and stored in main memory <NUM> or in secondary memory <NUM>, or executed upon receipt. Such computer programs, when executed, enable system <NUM> to perform the various functions of the disclosed embodiments.

Claim 1:
A medical ventilator (<NUM>) for delivering a pressurized breath to a patient (<NUM>, <NUM>) and to trigger an oxygen source (<NUM>) to increase FiO2 delivered to the patient (<NUM>, <NUM>), comprising:
a ventilation delivery interface (<NUM>) including one or more mixing chambers (<NUM>);
a ventilator circuit (<NUM>) for connecting the ventilator (<NUM>) to the ventilation delivery interface (<NUM>), the ventilator circuit (<NUM>) including a multiple lumen circuit to deliver pressurized air and pulsed oxygen upon triggering of the pressurized breath, wherein
the ventilation delivery interface (<NUM>) includes a first lumen and a second lumen, the first lumen being an air delivery lumen (<NUM>) to deliver air to the one or more mixing chambers (<NUM>), and the second lumen being an oxygen delivery lumen (<NUM>, <NUM>) to deliver oxygen to the one or more mixing chambers (<NUM>) to mix with the air just prior to delivery to the patient (<NUM>, <NUM>) and bypassing any interface leaks without mixing previously in the ventilator (<NUM>) nor the ventilator circuit (<NUM>);
characterized in that
the oxygen source (<NUM>) is a pulsed oxygen concentrator that delivers pulses (<NUM>, <NUM>) of a bolus of oxygen to the ventilator (<NUM>);
the medical ventilator (<NUM>) comprises a positive pressure source (<NUM>); and
the medical ventilator (<NUM>) comprises a negative pressure source (<NUM>) that is configured to generate a negative pressure in the ventilator (<NUM>) which triggers the oxygen concentrator (<NUM>) to deliver a pulse of oxygen to the ventilator oxygen inlet.