CN116547028A

CN116547028A - Respiratory distress management device, system and method

Info

Publication number: CN116547028A
Application number: CN202180081645.0A
Authority: CN
Inventors: G·贝克; B·P·哈维; D·R·艾扎德哈赫; D·莱克罗伊; 加里·A·弗里曼
Original assignee: Zoll Medical Corp
Current assignee: Zoll Medical Corp
Priority date: 2020-10-05
Filing date: 2021-10-05
Publication date: 2023-08-04

Abstract

Respiratory distress devices, systems, and methods are described. An example respiratory distress management device includes a housing and also has a mechanical ventilation device and a controller within the housing. The controller may include a processor and a memory. The controller may be configured to determine whether a failure mode condition exists at a particular time. If it is determined that a failure mode condition does not exist, the controller may be configured to enable control of the mechanical ventilation device of the respiratory distress management apparatus by the source to deliver mechanical ventilation to the patient via a signal received by the controller from the source. If a failure mode condition is determined to exist, the controller may be configured to control the mechanical ventilation device of the respiratory distress management apparatus to deliver mechanical ventilation to the patient.

Description

Respiratory distress management device, system and method

Priority application

The present application claims priority from U.S. provisional application No.63/198,234 entitled "RESPIRATORY DISTRESS MANAGEMENT APPARATUS, SYSTEM, AND METHOD" filed on 5 th 10 th 2020 and U.S. provisional application No.63/168,398 entitled "RESPIRATORY DISTRESS MANAGEMENT APPARATUS, SYSTEM, AND METHOD" filed on 31 rd 2021.

Background

Respiratory distress is a common patient complaint that may sometimes be indicative of a medical emergency. Respiratory distress is a major complaint in about 12% of EMS calls, based on several statistics. In an associated emergency response, many complex but critical patient care related challenges may be presented to the responders.

Response care providers may face a wide variety of response settings, including pre-hospital and off-hospital settings, ranging from common indoor and outdoor public and private spaces to off-hospital settings that may even include battlefield or large scale injury event settings. Other response settings may include ambulance or other traffic scenarios, hospital or emergency room arrivals, handover and transition scenarios, or other hospitalization or emergency room settings. In such an arrangement, the responsive care provider sometimes must provide life-saving care, which may include providing mechanical ventilation for a substantial period of time. Sometimes a response care provider with relatively limited training or experience in such settings may face emergency care for patients experiencing medical crisis. Furthermore, they may need to do so using equipment that is taken or carried, and may need to be immediately operatively integrated with other care providers and their devices. The scope or effectiveness of the intervention of these care providers may be limited based on the equipment they can carry with them to the site. Still further, in some cases, multiple care providers, each having different equipment and sometimes arriving at different times, may be required on site. This may present further challenges related to integration and control of, for example, communications, physiological signal collection, data, devices, interventions, and overall patient care.

Once on site, the response care provider may need emergency determination and provide effective patient intervention, where the selected intervention and the rate of delivery to the patient may be a life-to-death problem. This in turn may require emergency patient-related assessment (such as related to the nature and extent of a particular dysfunction or problem, etc.) potentially in a challenging pre-hospital setting. Assessment may become more difficult because the etiology that causes respiratory distress in a patient may be difficult to determine and may be associated with root causes across any of a range of patient systems (such as respiratory, cardiac, endocrine, or other, etc.). The care provider may be faced with using available patient medical history and may not be able to explicitly or individually clearly target physiological signals of a particular etiology to make or obtain patient assessment. Furthermore, care providers may face additional challenges during the provision of care. These challenges may include, for example, care provider distraction or multitasking, physical instability in the field, limited or intermittent communication or network availability and associated device integration or isolation problems, and constantly changing or evolving patient conditions (conditions) or etiologies. Such conditions may require continuous monitoring and assessment, as well as the determination and implementation of modified interventions or associated operating parameters during the provision of care.

The responding emergency care provider faces these and other problems and challenges that the health or life of the patient is likely to depend on in various contexts, possibly including patients experiencing RD.

Disclosure of Invention

One example of an apparatus for treating a patient experiencing respiratory distress includes: a respiratory distress management device, comprising: a housing; a mechanical ventilation device disposed within the housing for providing mechanical ventilation to a patient, the mechanical ventilation device comprising: a gas flow generator disposed within the housing, and a gas delivery device disposed at least partially within the housing, coupled with the gas flow generator, the gas delivery device comprising a patient circuit extending from the housing and configured to be at least partially connected with a patient to deliver gas to the patient; and a controller disposed within the housing, the controller including a processor and a memory, the controller configured to: determining whether a failure mode condition exists at a particular time; in the event that the failure mode condition is determined to be absent, enabling control of the mechanical ventilation device of the respiratory distress management apparatus by at least one source to deliver mechanical ventilation to a patient via a signal received by the controller from the at least one source, and in the event that the failure mode condition is determined to be present, controlling the mechanical ventilation device of the respiratory distress management apparatus to deliver mechanical ventilation to a patient.

In some examples, the controller controls the mechanical ventilation device of the respiratory distress management apparatus to deliver mechanical ventilation to a patient in accordance with previously stored ventilation control parameter values if it is determined that the failure mode condition exists at the particular time. In some examples, the controller controls the mechanical ventilation device of the respiratory distress management apparatus to deliver mechanical ventilation to a patient in accordance with a last received valid ventilation control parameter value previously stored if it is determined that the failure mode condition exists at the particular time. In some examples, the controller is configured to: determining whether the failure mode condition exists, wherein the failure mode condition is associated with the respiratory distress management device, and wherein the at least one source is separate from the respiratory distress management device.

In some examples, the controller is configured to: determining whether a fault mode condition exists at a particular time, wherein the particular time is a first predetermined time; enabling control of the mechanical ventilator of the respiratory distress management device by at least one source to deliver mechanical ventilation to a patient upon determining that the failure mode condition does not exist for the first predetermined time via a signal received by the controller from the at least one source; and controlling the mechanical ventilation device of the respiratory distress management apparatus to deliver mechanical ventilation to a patient if it is determined that the failure mode condition exists for the first predetermined time.

In some examples, the controller is configured to: determining whether a fault mode condition exists at a second predetermined time, wherein the second predetermined time is a time after a predetermined period of time has elapsed after the first predetermined time; enabling control of the mechanical ventilator of the respiratory distress management device by at least one source to deliver mechanical ventilation to a patient upon determining that the failure mode condition does not exist for the second predetermined time via a signal received by the controller from the at least one source; and controlling the mechanical ventilation device of the respiratory distress management apparatus to deliver mechanical ventilation to a patient if it is determined that the failure mode condition exists for the second predetermined time.

In some examples, the controller is configured such that the predetermined period of time is set prior to use of the respiratory distress management device. In some examples, the controller is configured such that the predetermined period of time is set to 1 second. In some examples, the controller is configured such that the predetermined period of time is set to between 0.1 seconds and 1 second. In some examples, the controller is configured such that the predetermined period of time is set to between 1 second and 10 seconds. In some examples, the controller is configured such that the predetermined period of time is set by a user of the respiratory distress management device.

In some examples, the mechanical ventilation device comprises: at least one pressure sensor disposed within the mechanical ventilation device configured to sense a signal representative of a flow of gas within the gas delivery device; and wherein the controller is configured to: the method includes receiving a signal representative of the flow of gas, generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received signal representative of the flow of gas, and transmitting the respiratory parameter data to a second device coupled to the respiratory distress management device, the respiratory parameter data being used to determine a respiratory condition of the patient.

In some examples, the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying data related to the breathing condition of the patient on a graphical user interface of a display of the second device. In some examples, the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of the patient.

In some examples, the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of the patient, the context-sensitive guide including treatment recommendations provided to a user of the second device and relating to treatment delivered to the patient by the respiratory distress management device at least in part upon user selection of the treatment recommendation. In some examples, the controller is configured to transmit the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of the patient, the context-sensitive guide including a therapy recommendation provided to a user of the second device and related to a therapy delivered to the patient by the respiratory distress management device at least in part upon user selection of the therapy recommendation, wherein the therapy includes mechanical ventilation.

In some examples, the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter includes forced vital capacity, FVC, and forced expiratory volume, FEV.

In some examples, the respiratory distress management device, the at least one source, and the second device are different devices and separate from but coupled to the respiratory distress management device. In some examples, the at least one source and the second device are the same and separate from but coupled to the respiratory distress management device. In some examples, the mechanical ventilation device includes at least one spirometer. In some examples, the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation device. In some examples, the respiratory distress management device includes a bronchodilator. In some examples, the controller uses one or more algorithms stored in a memory of the controller and executed by a processor of the controller to determine whether the fault mode condition exists. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a portable computing device. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a tablet. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a critical care monitor. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a defibrillator. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises one or more aspects of a cloud-based computing system.

In some examples, the controller is configured to enable control by the at least one source, wherein control by the at least one source comprises closed-loop ventilation control utilizing oxygen concentration measurements based on blood of the patient, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a critical care monitor, and wherein the at least one oxygen saturation sensor is part of a pulse oximeter of the critical care monitor. In some examples, the controller is configured to switch from enabling control of the mechanical ventilation by the at least one source to the controller controlling the mechanical ventilation if the failure mode condition is determined to be present.

In some examples, the failure mode condition indicates that control by the at least one source will be insufficiently secure. In some examples, the failure mode condition indicates that control by the at least one source will not be reliable enough for the controller of the respiratory distress management system to receive mechanical ventilation control data from the at least one source. In some examples, the failure mode condition indicates that the treatment with respect to the patient will be suboptimal with respect to control by the controller, control by the at least one source. In some examples, the failure mode condition is related to one or more unsafe patient physiological parameters. In some examples, the failure mode condition indicates that ventilation control data received by the controller from the at least one source is invalid.

In some examples, the failure mode condition indicates that ventilation control data received by the controller from the at least one source is corrupted. In some examples, the failure mode condition indicates that two or more items of ventilation control data received by the controller from the at least one source are inconsistent with one another. In some examples, the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation to operate in accordance with at least one ventilation parameter value that exceeds at least one range. In some examples, the at least one range includes a range associated with sufficient patient safety. In some examples, the at least one range includes a range of flow rates. In some examples, the at least one range includes a pressure range. In some examples, the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation to operate in accordance with values of two parameters, wherein a combination of the values will exceed a range of allowed combinations of values of the at least two parameters. In some examples, the values include a value of flow rate and a value of pressure. In some examples, the range of allowed value combinations is associated with sufficient patient safety.

In some examples, the respiratory distress management device is configured such that upon resetting the controller after a controller process that occurs during control by the at least one source, the controller enables control by the at least one source, including control according to current ventilation control data from the at least one source, in the presence of communication capability between the respiratory distress management device and the at least one source. In some examples, the respiratory distress management device is configured such that upon resetting the controller after a controller process that occurs during control of the at least one source, the controller controls the mechanical ventilation in accordance with one or more backup ventilation control parameter values stored in a memory of the controller in the absence of communication capability between the respiratory distress management device and the at least one source.

In some examples, the controller is configured to perform a cyclic redundancy check on mechanical ventilation control data received from the at least one source. In some examples, the controller is configured to utilize task priorities in optimization of controller processing operations. In some examples, the controller is configured to process with data sampling protection. In some examples, the controller is configured to utilize one or more histograms in data processing to minimize data noise. In some examples, the controller is configured to process with a single threaded configuration. In some examples, the controller is configured to utilize a thread-safe operating system object for processing. In some examples, the controller is configured to process using a polling software process design to minimize processing delay. In some examples, the controller is configured to perform a token count check on ventilation control data received from the at least one source.

In some examples, the controller is configured to disable software processing interrupts under one or more conditions. In some examples, the controller is configured to process with priority regarding one or more aspects of communication with the at least one source. In some examples, the controller is configured to conduct one or more checks related to ventilation control data reception rate from the at least one source. In some examples, the controller is configured to process to maintain a minimum portion of unused memory to prevent potential data storage overload. In some examples, the controller is configured to process with at least one of an acknowledgement, ACK, and a negative acknowledgement, NACK, scheme to ensure that ventilation control data is received from the at least one source. In some examples, the controller is configured to automatically reset if the software process is in a frozen or deadlocked condition. In some examples, continuous communication between the respiratory distress management device and the at least one source is utilized to continuously correct any data reception errors. In some examples, the controller is configured to check that the at least one source is properly configured for communication with the respiratory distress management device.

In some examples, the controller is configured to generate a user alert associated with a particular detection condition. In some examples, the user alert includes an alert to provide an early warning regarding a potentially unsafe ventilation condition. In some examples, the user alert includes an alert to provide an alert related to a potentially unsafe breathing parameter value of the patient. In some examples, the user alert includes an alert indication for display to a user of the respiratory distress management device on a graphical user interface separate from the respiratory distress management device. In some examples, the user alert includes an alert related to a ventilation parameter value. In some examples, the user alert includes an alert related to a ventilation parameter value related to control by the at least one source. In some examples, the user alert includes an alert related to a physiological parameter of the patient. In some examples, the alarms related to the patient physiological parameter include one or more alarms related to a high respiratory rate of the patient. In some examples, the alarms related to the patient physiological parameter include one or more alarms related to an incomplete exhalation condition of the patient.

One example of a system for treating a patient experiencing respiratory distress includes: a respiratory distress management system, comprising: a mechanical ventilation system for providing mechanical ventilation to a patient, the mechanical ventilation system comprising at least one pressure sensor configured to sense a signal representative of an airflow within the mechanical ventilation system; and a controller including a processor and a memory, the controller configured to: determining whether a failure mode condition exists at a particular time, enabling control of the mechanical ventilation system of the respiratory distress management system by at least one source to deliver mechanical ventilation to a patient, via a signal received by the controller from at least one source if the failure mode condition is determined to not exist, and controlling the mechanical ventilation system of the respiratory distress management system to deliver mechanical ventilation to a patient if the failure mode condition is determined to exist.

In some examples, the controller is configured to: determining whether the failure mode condition exists, wherein the failure mode condition is associated with the respiratory distress management system, and wherein the at least one source is separate from the respiratory distress management system.

In some examples, the controller is configured to: the method may include receiving a signal representative of the flow of gas, generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received signal representative of the flow of gas, and transmitting the respiratory parameter data to a device coupled to the respiratory distress management system, the respiratory parameter data being used to determine a respiratory condition of the patient.

In some examples, the controller is configured to transmit the breathing parameter data to the apparatus for use by the apparatus in displaying data relating to the breathing condition of the patient on a graphical user interface of a display of the apparatus. In some examples, the controller is configured to transmit the breathing parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guide related to treatment of a patient. In some examples, the controller is configured to transmit the respiratory parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including treatment recommendations provided to a user of the apparatus and related to a treatment to be delivered by the respiratory distress management system at least in part when the user selects the treatment recommendation. In some examples, the controller is configured to transmit the respiratory parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a treatment recommendation provided to a user of the apparatus and related to a treatment to be delivered by the respiratory distress management system when the user selects the treatment recommendation, wherein the treatment includes mechanical ventilation.

In some examples, the respiratory distress management system, the at least one source, and the apparatus are separate from one another. In some examples, the at least one source and the device are the same and separate from the respiratory distress management system but coupled to the respiratory distress management device. In some examples, the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation system. In some examples, the controller uses one or more algorithms stored in a memory of the controller and executed by a processor of the controller to determine whether the fault mode condition exists. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a portable computing device. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a critical care monitor. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a defibrillator. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises one or more aspects of a cloud-based computing system.

In some examples, the controller is configured to enable control by the at least one source, wherein control by the at least one source comprises closed-loop ventilation control utilizing oxygen concentration measurements based on blood of the patient, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a critical care monitor, and wherein the at least one oxygen saturation sensor is part of a pulse oximeter of the critical care monitor. In some examples, the controller is configured to switch from enabling control of the mechanical ventilation by the at least one source to the controller controlling the mechanical ventilation if the failure mode condition is determined to be present. In some examples, the failure mode condition indicates that control by the at least one source will be insufficiently secure.

In some examples, the failure mode condition indicates that control by the at least one source will not be reliable enough for the controller of the respiratory distress management system to receive mechanical ventilation control data from the at least one source. In some examples, the failure mode condition indicates that the treatment with respect to the patient will be suboptimal with respect to control by the controller, control by the at least one source. In some examples, the failure mode condition indicates that ventilation control data received by the controller from the at least one source is invalid. In some examples, the failure mode condition indicates that ventilation control data received by the controller from the at least one source is corrupted. In some examples, the failure mode condition indicates that two or more items of ventilation control data received by the controller from the at least one source are inconsistent with one another.

In some examples, the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation system to operate in accordance with at least one ventilation parameter value that exceeds at least one range. In some examples, the at least one range includes a range associated with sufficient patient safety. In some examples, the at least one range includes a range of flow rates. In some examples, the at least one range includes a pressure range. In some examples, the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation system to operate in accordance with values of at least two parameters, wherein a combination of the values will exceed a range of allowable combinations of values of the two parameters. In some examples, the values include a value of flow rate and a value of pressure. In some examples, the range of allowed value combinations is associated with sufficient patient safety.

In some examples, the respiratory distress management system is configured such that upon resetting the controller after a controller process that occurs during control by the at least one source, the controller enables control by the at least one source, including control according to current ventilation control data from the at least one source, in the presence of communication capability between the respiratory distress management system and the at least one source. In some examples, the respiratory distress management system is configured such that upon resetting the controller after a controller process that occurs during control of the at least one source, the controller controls the mechanical ventilation in accordance with one or more backup ventilation control parameter values stored in a memory of the controller in the absence of communication capability between the respiratory distress management system and the at least one source. In some examples, the controller is configured to perform a cyclic redundancy check on mechanical ventilation control data received from the at least one source. In some examples, the controller is configured to utilize task priorities in optimization of controller processing operations.

In some examples, the controller is configured to process with data sampling protection. In some examples, the controller is configured to utilize one or more histograms in data processing to minimize data noise. In some examples, the controller is configured to process with a single threaded configuration. In some examples, the controller is configured to utilize a thread-safe operating system object for processing. In some examples, the controller is configured to process using a polling software process design to minimize processing delay. In some examples, the controller is configured to perform a token count check on ventilation control data received from the at least one source. In some examples, the controller is configured to disable software processing interrupts under one or more conditions. In some examples, the controller is configured to process with priority regarding one or more aspects of communication with the at least one source. In some examples, the controller is configured to conduct one or more checks related to ventilation control data reception rate from the at least one source. In some examples, the controller is configured to process to maintain a minimum portion of unused memory to prevent potential data storage overload.

In some examples, the controller is configured to process with at least one of an acknowledgement, ACK, and a negative acknowledgement, NACK, scheme to ensure that ventilation control data is received from the at least one source. In some examples, the controller is configured to automatically reset if the software process is in a frozen or deadlocked condition. In some examples, continuous communication between the respiratory distress management system and the at least one source is utilized to continuously correct any data reception errors. In some examples, the controller is configured to check that the at least one source is properly configured for communication with the respiratory distress management system.

In some examples, the controller is configured to generate a user alert associated with a particular detection condition. In some examples, the user alert includes an alert to provide an early warning regarding a potentially unsafe ventilation condition. In some examples, the user alert includes an alert to provide an alert related to a potentially unsafe breathing parameter value of the patient. In some examples, the user alert includes an alert indication for display to a user of the respiratory distress management system on a graphical user interface separate from the respiratory distress management system. In some examples, the user alert includes an alert related to a ventilation parameter value related to control by the at least one source. In some examples, the user alert includes an alert related to a ventilation parameter value related to control by the at least one source. In some examples, the user alert includes an alert related to a physiological parameter of the patient. In some examples, the alarms related to the patient physiological parameter include one or more alarms related to a high respiratory rate of the patient. In some examples, the alarms related to the patient physiological parameter include one or more alarms related to an incomplete exhalation condition of the patient.

One example of a computer-implemented method for treating a patient experiencing respiratory distress includes: a controller disposed within the respiratory distress management device determining whether a failure mode condition exists at a particular time, the controller comprising a processor and a memory, the failure mode condition being associated with the respiratory distress management device and at least one source separate from the respiratory distress management device; in the event that the failure mode condition is determined to not be present, the controller enables control of a mechanical ventilation system of the respiratory distress management device by the at least one source to deliver mechanical ventilation to a patient via signals received by the controller from the at least one source; and in the event that the failure mode condition is determined to exist, the controller controls the mechanical ventilation system of the respiratory distress management device to deliver mechanical ventilation to a patient.

Some examples include: the controller determines whether the failure mode condition exists, wherein the mechanical ventilation system comprises: at least one pressure sensor disposed within a gas delivery system of the mechanical ventilation system configured to sense a signal representative of a flow of gas within the gas delivery system; and wherein the controller: the method includes receiving a signal representative of the flow of gas, generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received signal representative of the flow of gas, and transmitting the respiratory parameter data to a second device coupled to the respiratory distress management device, the respiratory parameter data being used to determine a respiratory condition of the patient.

Some examples include: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying data related to the respiratory condition of the patient on a graphical user interface of a display of the second device. Some examples include: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient. Some examples include: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including treatment recommendations provided to a user of the second device and relating to a treatment to be delivered by the respiratory distress management device at least in part upon user selection of the treatment recommendation. Some examples include: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a treatment recommendation provided to a user of the second device and related to a treatment to be delivered by the respiratory distress management device when the user selects the treatment recommendation, wherein the treatment includes mechanical ventilation.

Some examples include: the controller determines whether the failure mode condition exists, wherein the respiratory distress management device, the at least one source, and the second device are different devices and separate from but coupled to the respiratory distress management device. Some examples include: the controller determines whether the failure mode condition exists, wherein the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation system. Some examples include: the controller uses one or more algorithms stored in a memory of the controller and executed by a processor of the controller to determine whether the fault mode condition exists.

In some examples, the controller enables control by the at least one source, wherein the at least one source comprises a portable computing device. In some examples, the controller enables control by the at least one source, wherein the at least one source includes a critical care monitor. In some examples, the controller enables control by the at least one source, wherein the at least one source comprises a defibrillator. In some examples, the controller enables control by the at least one source, wherein the at least one source comprises one or more aspects of a cloud-based computing system.

In some examples, the controller enables control by the at least one source, wherein control by the at least one source comprises closed-loop ventilation control utilizing oxygen concentration measurements based on blood of the patient, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

In some examples, the controller enables control by the at least one source, wherein the at least one source comprises a critical care monitor, and wherein the at least one oxygen saturation sensor is part of a pulse oximeter of the critical care monitor. In some examples, the controller switches from enabling control of the mechanical ventilation by the at least one source to the controller controlling the mechanical ventilation if the failure mode condition is determined to be present.

Some examples include: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that control by the at least one source will be insufficiently secure. Some examples include: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that control by the at least one source will be unreliable with respect to receipt of mechanical ventilation control data by the controller of the respiratory distress management device from the at least one source. Some examples include: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that the control by the at least one source will be suboptimal with respect to the control by the controller regarding the treatment of the patient. Some examples include: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that ventilation control data received by the controller from the at least one source is invalid. Some examples include: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that ventilation control data received by the controller from the at least one source is corrupted. Some examples include: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that two or more items of ventilation control data received by the controller from the at least one source are inconsistent with one another. Some examples include: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation system to operate in accordance with at least one ventilation parameter value that exceeds at least one range.

Some examples include: the controller determines whether the failure mode condition exists, wherein the at least one range includes a range associated with sufficient patient safety. Some examples include: the controller determines whether the failure mode condition exists, wherein the at least one range includes a range of flow rates. Some examples include: the controller determines whether the fault mode condition exists, wherein the at least one range includes a pressure range. Some examples include: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation system to operate in accordance with values of at least two parameters, wherein a combination of the values will exceed a range of allowable combinations of values of the two parameters. Some examples include: the controller determines whether the fault mode condition exists, wherein the values include a value of a flow rate and a value of a pressure. Some examples include: the controller determines whether the failure mode condition exists, wherein the range of allowed value combinations is associated with sufficient patient safety.

In some examples, the controller enables control by the at least one source when communication capability exists between the respiratory distress management device and the at least one source when the controller is reset after a controller process that occurs during control by the at least one source has frozen, the control by the at least one source including control according to current ventilation control data from the at least one source. In some examples, upon resetting the controller after a controller process that occurs during control of the at least one source has frozen, the controller controls the mechanical ventilation in accordance with one or more backup ventilation control parameter values stored in a memory of the controller in the absence of communication capability between the respiratory distress management device and the at least one source.

In some examples, the controller performs a cyclic redundancy check on mechanical ventilation control data received from the at least one source. In some examples, the controller utilizes task priorities in optimization of controller processing operations. In some examples, the controller utilizes data sampling protection for processing. In some examples, the controller utilizes one or more histograms in data processing to minimize data noise. In some examples, the controller utilizes a single threaded configuration for processing. In some examples, the controller utilizes thread-safe operating system objects for processing. In some examples, the controller utilizes a polling software processing design to process to minimize processing delay. In some examples, the controller performs a token count check on ventilation control data received from the at least one source. In some examples, the controller with C170 disables the software process interrupt under one or more conditions.

In some examples, the controller processes with priority regarding one or more aspects of communication with the at least one source. In some examples, the controller performs one or more checks related to ventilation control data reception rate from the at least one source. In some examples, the controller processes to maintain a minimum portion of unused memory to prevent potential data storage overload. In some examples, the controller processes with at least one of an acknowledgement, ACK, and a negative acknowledgement, NACK, scheme to ensure that ventilation control data is received from the at least one source. In some examples, the controller automatically resets if the software handles a freeze or deadlock condition. In some examples, continuous communication between the respiratory distress management device and the at least one source is utilized to continuously correct any data reception errors. In some examples, the controller checks that the at least one source is properly configured for communication with the respiratory distress management device.

In some examples, the controller generates a user alert related to a particular detection condition. In some examples, the controller generates the user alert, wherein the user alert comprises an alert to provide an early warning regarding a potentially unsafe ventilation condition. In some examples, the controller generates the user alert, wherein the user alert includes an alert to provide an early warning regarding potentially unsafe respiratory parameter values for the patient. In some examples, the controller generates the user alert, wherein the user alert includes an alert indication for display to a user of the respiratory distress management device on a graphical user interface separate from the respiratory distress management device. In some examples, the controller generates the user alert, wherein the user alert comprises an alert related to a ventilation parameter value related to control by the at least one source. In some examples, the controller generates the user alert, wherein the user alert comprises an alert related to a ventilation parameter value related to control by the at least one source. In some examples, the controller generates the user alert, wherein the user alert comprises an alert related to a physiological parameter of the patient. In some examples, the controller generates the user alert, wherein the alert related to the patient physiological parameter includes one or more alerts related to a high respiratory rate of the patient. In some examples, the controller generates the user alert, wherein the alert related to the patient physiological parameter includes one or more alerts related to an incomplete exhalation condition of the patient.

One example of an apparatus for treating a patient experiencing respiratory distress includes: an dynamic respiratory distress management device, comprising: a housing; a mechanical ventilation device disposed within the housing for providing mechanical ventilation to a patient, the mechanical ventilation device comprising: a gas flow generator disposed within the housing, and a gas delivery device disposed at least partially within the housing, coupled with the gas flow generator, the gas delivery device including a patient circuit extending from the housing and configured to be at least partially connected with a patient to deliver gas to the patient, at least one pressure sensor disposed within the mechanical ventilation device configured to sense a signal representative of a gas flow within the gas delivery device, and a controller disposed within the housing configured to: the method includes receiving a signal representative of the airflow, generating respiratory parameter data corresponding to at least one respiratory parameter of a patient based at least in part on the received signal representative of the airflow, and transmitting the respiratory parameter data to a second device coupled to the respiratory distress management device, the respiratory parameter data being used to determine a respiratory condition of the patient, wherein the controller is configured to enable control of the mechanical ventilation device by at least one source separate from the respiratory distress management device to deliver mechanical ventilation to the patient.

In some examples, the controller is configured such that: the controller determining whether a failure mode condition exists at a particular time, the failure mode condition being associated with the respiratory distress management device and the at least one source separate from the respiratory distress management device; in the event that it is determined that the failure mode condition is not present at the particular time, the controller enables control of the mechanical ventilator of the respiratory distress management device by the at least one source to deliver mechanical ventilation to a patient via signals received by the controller from the at least one source; and in the event that it is determined that the failure mode condition exists at the particular time, the controller controls the mechanical ventilation device of the respiratory distress management apparatus to deliver mechanical ventilation to a patient.

In some examples, the controller is configured to enable control by the at least one source, wherein control by the at least one source comprises utilizing closed-loop ventilation control based on oxygen concentration measurements of blood of the patient, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

In some examples, the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying data related to the breathing condition of the patient on a graphical user interface of a display of the second device. In some examples, the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of the patient. In some examples, the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of the patient, the context-sensitive guide including a treatment recommendation provided to a user of the second device and relating to a treatment to be delivered by the respiratory distress management device at least in part upon user selection of the treatment recommendation. In some examples, the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a therapy recommendation provided to a user of the second device and related to a therapy to be delivered by the respiratory distress management device when the user selects the therapy recommendation, wherein the therapy includes mechanical ventilation.

In some examples, the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter includes forced vital capacity, FVC, and forced expiratory volume, FEV. In some examples, the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation device. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a device having a graphical user interface configured to allow user input related to adjusting one or more ventilation control parameters. In some examples, the respiratory distress management device is configured to enable control of the mechanical ventilation apparatus in accordance with signals received by the controller of the respiratory distress management device from outside the respiratory distress management device. In some examples, the controller is configured to determine whether to control the mechanical ventilation device at a particular time based on signals received by the controller from outside of the respiratory distress management device.

In some examples, the controller is configured to determine whether to control the mechanical ventilator at the particular time based on signals received by the controller from the at least one source from outside of the respiratory distress management device. In some examples, the controller is configured to determine whether to control the mechanical ventilation device at the particular time based on signals received by the controller of the respiratory distress management device from the at least one source external to the respiratory distress management device, wherein the at least one source is a critical care monitor. In some examples, the controller is configured to determine whether to control the mechanical ventilator device at the particular time based on signals received by the controller of the respiratory distress management device from the at least one source external to the respiratory distress management device, wherein the at least one source is a defibrillator. In some examples, the controller is configured to determine whether to control the mechanical ventilator device at the particular time based on signals received by the controller of the respiratory distress management device from the at least one source external to the respiratory distress management device, wherein the at least one source is a tablet. In some examples, the controller is configured to determine whether to control the mechanical ventilator at the particular time based at least in part on a signal received by the controller of the respiratory distress management device from the at least one source from outside the respiratory distress management device based on whether communication capability exists between the respiratory distress management device and a control source at the particular time.

In some examples, the controller includes software stored in memory configured to enable control of the mechanical ventilation device in accordance with signals received by the controller of the respiratory distress management device from outside the respiratory distress management device. In some examples, the respiratory distress management device is configured to be coupled with at least one critical care monitor, and wherein the controller is configured to: receiving a signal from the critical care monitor representative of at least one physiological parameter of a patient; and generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received signals. In some examples, the controller is configured to receive signals from the critical care monitor representative of at least one physiological parameter of the patient, including receiving signals from a defibrillator representative of at least one physiological parameter of the patient. In some examples, the controller is configured to receive signals from the critical care monitor representative of at least one physiological parameter of the patient, including signals obtained at least in part via oximetry. In some examples, the controller is configured to receive signals from the critical care monitor representative of at least one physiological parameter of the patient, including signals obtained at least in part via capnography. In some examples, the respiratory distress management device is configured to operate in a first mode that does not include delivering mechanical ventilation to the patient or in a second mode that includes delivering mechanical ventilation to the patient.

In some examples, the airflow generator includes a blower. In some examples, the blower is operable to produce between 40 and 70 decibels of sound at one meter. In some examples, the airflow generator includes a turbine. In some examples, the airflow generator includes a compressor. In some examples, the housing of the respiratory distress management device has a volume of between 0.125 and 27L (such as between 5.0 and 27L, between 1.0 and 5.0L, between 0.5 and 1.0L, between 0.15 and 0.5L, or between 0.125 and 0.15L, etc.). In some examples, the respiratory distress management device has a weight of between 0.2 and 5.0kg (such as between 2.0 and 5.0kg, between 1.0 and 2.0kg, between 0.3 and 1.0kg, or between 0.2 and 0.3kg, etc.). In some examples, the respiratory distress management device is sized such that the respiratory distress management device has a length, height, and width that are no greater than 300mm, no greater than 150mm, no greater than 100mm, or no greater than 60mm.

In some examples, the respiratory distress management device is configured to be portable. In some examples, the respiratory distress management device is configured for patient treatment within a vehicle. In some examples, the respiratory distress management device is configured for off-hospital patient treatment. In some examples, the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter includes at least one of breathing compliance and breathing resistance.

In some examples, the respiratory distress management device is configured to deliver non-invasive mechanical ventilation to a patient. In some examples, the respiratory distress management device is configured to deliver non-invasive mechanical ventilation including continuous positive airway pressure, CPAP, ventilation to the patient. In some examples, the respiratory distress management device is configured to deliver non-invasive mechanical ventilation including bi-level ventilation to a patient. In some examples, the respiratory distress management device is configured to deliver non-invasive mechanical ventilation to the patient including high flow nasal cannula ventilation, HFNC ventilation. In some examples, the respiratory distress management device is configured to deliver invasive mechanical ventilation to a patient. In some examples, the respiratory distress management device is configured to deliver invasive mechanical ventilation to the patient including assisted control ventilation, AC ventilation. In some examples, the respiratory distress management device is configured to deliver invasive mechanical ventilation to the patient including synchronous intermittent forced ventilation, SIMV. In some examples, the respiratory distress management device is configured to deliver to the patient an invasive mechanical ventilation including ventilation synchronized with cardiopulmonary resuscitation chest compressions, CPR chest compressions, being delivered to the patient. In some examples, the respiratory distress management device is coupled with an oxygen source for delivering gas to a patient.

In one example, a system for treating a patient experiencing respiratory distress includes: a respiratory distress management system, comprising: a mechanical ventilation system for providing mechanical ventilation to a patient, the mechanical ventilation system comprising at least one pressure sensor configured to sense a signal representative of an airflow within the mechanical ventilation system; and a controller including a processor and a memory, the controller configured to: the method includes receiving a signal representative of the flow of gas, generating respiratory parameter data corresponding to at least one respiratory parameter of a patient based at least in part on the received signal representative of the flow of gas, and transmitting the respiratory parameter data to a device coupled to the respiratory distress management system, the respiratory parameter data being used to determine a respiratory condition of the patient, wherein the controller is configured to enable control of the mechanical ventilation system by at least one source separate from the respiratory distress management system to deliver mechanical ventilation to the patient.

In some examples, the controller is configured such that: the controller determining whether a failure mode condition exists at a particular time, the failure mode condition being associated with the respiratory distress management system and the at least one source separate from the respiratory distress management system; in the event that it is determined that the failure mode condition is not present at the particular time, the controller enables control of the mechanical ventilation system of the respiratory distress management system by the at least one source to deliver mechanical ventilation to a patient via signals received by the controller from the at least one source; and in the event that it is determined that the failure mode condition exists at the particular time, the controller controls the mechanical ventilation system of the respiratory distress management system to deliver mechanical ventilation to a patient.

In some examples, the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within a gas delivery system of the mechanical ventilation system. In some examples, the controller is configured to enable control by the at least one source, wherein the at least one source comprises a device having a graphical user interface configured to allow user input related to adjusting one or more ventilation control parameters. In some examples, the respiratory distress management system is configured to enable control of the mechanical ventilation system in accordance with signals received by the controller of the respiratory distress management system from outside the respiratory distress management system. In some examples, the controller is configured to determine whether to control the mechanical ventilation system at a particular time based on signals received by the controller from outside of the respiratory distress management system. In some examples, the controller is configured to determine whether to control the mechanical ventilation system at a particular time based on signals received by the controller from the at least one source from outside the respiratory distress management system. In some examples, the controller is configured to determine whether to control the mechanical ventilation system at the particular time based on signals received by the controller of the respiratory distress management system from the at least one source external to the respiratory distress management system, wherein the at least one source is a critical care monitor.

In some examples, the controller is configured to determine whether to control the mechanical ventilation system at the particular time based on signals received by the controller of the respiratory distress management system from the at least one source external to the respiratory distress management system, wherein the at least one source is a defibrillator. In some examples, the controller is configured to determine whether to control the mechanical ventilation system at the particular time based on signals received by the controller of the respiratory distress management system from the at least one source external to the respiratory distress management system, wherein the at least one source is a tablet. In some examples, the controller is configured to determine whether to control the mechanical ventilation system at the particular time based at least in part on a signal received by the controller of the respiratory distress management system from the at least one source from outside the respiratory distress management system based on whether communication capabilities exist between the respiratory distress management system and the at least one source at the particular time.

In some examples, the controller includes software stored in the memory, the software configured to enable control of the mechanical ventilation system in accordance with signals received by the controller of the respiratory distress management system from outside the respiratory distress management system. In some examples, the respiratory distress management system is configured to be coupled with at least one critical care monitor, and wherein the controller is configured to: receiving a signal from the critical care monitor representative of at least one physiological parameter of a patient; and generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received signals. In some examples, receiving a signal from the critical care monitor representative of at least one physiological parameter of the patient comprises: a signal representative of at least one physiological parameter of a patient is received from a defibrillator. In some examples, receiving a signal from the critical care monitor representative of at least one physiological parameter of the patient comprises: a signal obtained at least in part via oximetry is received. In some examples, receiving a signal from the critical care monitor representative of at least one physiological parameter of the patient comprises: a signal obtained at least in part via capnography is received. In some examples, the respiratory distress management system is configured to operate in a first mode that does not include delivering mechanical ventilation to the patient or in a second mode that includes delivering mechanical ventilation to the patient.

In some examples, the airflow generator includes a blower. In some examples, the blower is operable to produce between 40 and 70 decibels of sound at one meter. In some examples, the airflow generator includes a turbine. In some examples, the airflow generator includes a compressor. In some examples, the respiratory distress management system has a volume between 0.125 and 27L (such as between 5.0 and 27L, between 1.0 and 5.0L, between 0.5 and 1.0L, between 0.15 and 0.5L, or between 0.125 and 0.15L, etc.). In some examples, the respiratory distress management system has a weight between 0.2 and 5.0kg (such as between 2.0 and 5.0kg, between 1.0 and 2.0kg, between 0.3 and 1.0kg, or between 0.2 and 0.3kg, etc.).

In some examples, the respiratory distress management system is configured to be portable.

In some examples, the respiratory distress management system is configured for patient treatment within a vehicle. In some examples, the respiratory distress management system is configured for off-hospital patient treatment. In some examples, the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter includes at least one of breathing compliance and breathing resistance.

In some examples, the respiratory distress management system is configured to deliver non-invasive mechanical ventilation to a patient. In some examples, the respiratory distress management system is configured to deliver non-invasive mechanical ventilation including continuous positive airway pressure, CPAP, ventilation to the patient. In some examples, the respiratory distress management system is configured to deliver non-invasive mechanical ventilation including bi-level ventilation to a patient. In some examples, the respiratory distress management system is configured to deliver non-invasive mechanical ventilation to the patient including high flow nasal cannula ventilation, HFNC ventilation. In some examples, the respiratory distress management system is configured to deliver invasive mechanical ventilation to a patient. In some examples, the respiratory distress management system is configured to deliver invasive mechanical ventilation to a patient including assisted control ventilation, AC ventilation. In some examples, the respiratory distress management system is configured to deliver invasive mechanical ventilation to a patient including synchronous intermittent forced ventilation, or SIMV. In some examples, the respiratory distress management system is configured to deliver to the patient an invasive mechanical ventilation including ventilation synchronized with cardiopulmonary resuscitation chest compressions, CPR chest compressions, being delivered to the patient. In some examples, the respiratory distress management system is coupled with an oxygen source for delivering gas to a patient.

In one example, a computer-implemented method for treating a patient experiencing respiratory distress includes: a controller including a processor and a memory disposed within a respiratory distress management device, the respiratory distress management device including a mechanical ventilation system for providing mechanical ventilation to a patient and including at least one pressure sensor configured to sense a signal representative of airflow within the mechanical ventilation system: the method includes receiving a signal representative of the flow of gas, generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received signal representative of the flow of gas, and transmitting the respiratory parameter data to a second device coupled to the respiratory distress management device, the respiratory parameter data being used to determine a respiratory condition of the patient, wherein the controller is capable of enabling control of the mechanical ventilation system by at least one source separate from the respiratory distress management device to deliver mechanical ventilation to the patient.

In some examples, the controller enables control by the at least one source, wherein control by the at least one source comprises: closed-loop ventilation control utilizing oxygen concentration measurements based on blood of a patient, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

Some examples include: altering the controller at C290+4 to determine whether a failure mode condition exists at a particular time, the failure mode condition being associated with the respiratory distress management device and the at least one source separate from the respiratory distress management device; in the event that it is determined that the failure mode condition is not present at the particular time, the controller enables control of the mechanical ventilation system of the respiratory distress management device by the at least one source to deliver mechanical ventilation to a patient via signals received by the controller from the at least one source; and in the event that it is determined that the failure mode condition exists at the particular time, the controller controls the mechanical ventilation system of the respiratory distress management device to deliver mechanical ventilation to a patient.

Some examples include: the controller receives a signal representative of the flow of gas, wherein the at least one pressure sensor is coupled to or part of at least one pneumotach disposed within a gas delivery device of the mechanical ventilation system. Some examples include: the controller allows control of the mechanical ventilation system of the respiratory distress management device to deliver ventilation to a patient in accordance with signals received by the respiratory distress management device from the at least one source separate from the respiratory distress management device. Some examples include: determining whether communication capability exists between the respiratory distress management device and the at least one source separate from the respiratory distress management device at a particular time to allow control of the mechanical ventilation system by the at least one source; in the event that it is determined that the communication capability exists at the particular time, the controller allows control of the mechanical ventilation system by the at least one source; and in the event that it is determined that the communication capability is not present at the particular time, the controller controls the mechanical ventilation system.

Some examples include: the controller allows control of the mechanical ventilation system by the at least one source if it is determined that the communication capability is present at the particular time, wherein control by the at least one source includes utilizing one or more algorithms stored at least in part on the at least one source. Some examples include: in the event that it is determined that the communication capability is present at the particular time, the controller allows control of the mechanical ventilation system by the at least one source, the control by the at least one source having no user input. Some examples include: in the event that it is determined that the communication capability is not present at the particular time, the controller controls the mechanical ventilation system using one or more algorithms stored at least in part on the controller. Some examples include: in the event that it is determined that the communication capability is not present at the particular time, the controller controls the mechanical ventilation system without user input. Some examples include: the controller allows control of the mechanical ventilation system by the at least one source, where the at least one source includes a portable computing device, if it is determined that the communication capability exists at the particular time.

Some examples include: the controller allows control of the mechanical ventilation system by the at least one source, wherein the at least one source comprises a tablet computer, if it is determined that the communication capability is present at the particular time. Some examples include: the controller allows control of the mechanical ventilation system by the at least one source, where the at least one source includes a critical care monitor, if the communication capability is determined to be present at the particular time. Some examples include: the controller allows control of the mechanical ventilation system by the at least one source, wherein the at least one source comprises a defibrillator, if it is determined that the communication capability exists at the particular time.

Some examples include: the respiratory distress management device is coupled with a critical care monitor, wherein the controller generates the respiratory parameter data based at least in part on signals received from the critical care monitor.

In one example, an apparatus for treating a patient experiencing respiratory distress includes: a respiratory distress management device, comprising: a housing; a mechanical ventilation device disposed within the housing for providing mechanical ventilation to a patient, the mechanical ventilation device comprising: a gas flow generator disposed within the housing, and a gas delivery device disposed at least partially within the housing, coupled with the gas flow generator, the gas delivery device comprising a patient circuit extending from the housing and configured to be at least partially connected with a patient to deliver gas to the patient; and a controller disposed within the housing, the controller including a processor and a memory, the controller configured to: determining whether a communication capability exists between the respiratory distress management device and at least one source separate from the respiratory distress management device at a particular time to allow control of the gas delivery device of the mechanical ventilation device by the at least one source to deliver mechanical ventilation to a patient, enabling control of the gas delivery device of the mechanical ventilation device by the at least one source to deliver mechanical ventilation to a patient if the communication capability is determined to exist, and controlling the gas delivery device of the mechanical ventilation device to deliver mechanical ventilation to a patient if the communication capability is determined to not exist.

In some examples, allowing control by the at least one source includes allowing closed-loop ventilation control based on oxygen concentration measurements of the patient's blood, wherein the closed-loop ventilation control includes: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor coupled to the patient, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

In some examples, the mechanical ventilation device comprises: at least one pressure sensor disposed within the gas delivery device of the mechanical ventilation device configured to sense a signal representative of a flow of gas within the gas delivery device; and wherein the controller is configured to: the method includes receiving a signal representative of the flow of gas, generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received signal representative of the flow of gas, and transmitting the respiratory parameter data to a second device coupled to the respiratory distress management device, the respiratory parameter data being used to determine a respiratory condition of the patient.

In some examples, the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter includes a forced vital capacity parameter, FVC, parameter and a forced expiratory volume parameter, FEV, parameter. In some examples, the respiratory distress management device, the at least one source, and the second device are different devices and separate from each other but coupled to each other. In some examples, the mechanical ventilation device includes at least one spirometer. In some examples, the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation device.

In one example, a system for treating a patient experiencing respiratory distress, the system comprising: a respiratory distress management system, comprising: a mechanical ventilation system for providing mechanical ventilation to a patient, and a controller comprising a processor and a memory, the controller configured to: determining whether a communication capability exists between the respiratory distress management system and at least one source separate from the respiratory distress management system at a particular time to allow control of the mechanical ventilation system by the at least one source to deliver mechanical ventilation to a patient, enabling control of the mechanical ventilation system by the at least one source to deliver mechanical ventilation to a patient if the communication capability is determined to exist at the particular time, and controlling a gas delivery device of the mechanical ventilation system to deliver mechanical ventilation to a patient if the communication capability is determined to not exist at the particular time; wherein allowing control by the at least one source comprises allowing closed-loop ventilation control based on oxygen concentration measurements of the patient's blood, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor coupled to the patient, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

In some examples, the mechanical ventilation system of C318 includes: at least one pressure sensor disposed within a gas delivery system of the mechanical ventilation system configured to sense a signal representative of a flow of gas within the gas delivery system; and wherein the controller is configured to: the method may include receiving a signal representative of the flow of gas, generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received signal representative of the flow of gas, and transmitting the respiratory parameter data to a device coupled to the respiratory distress management system, the respiratory parameter data being used to determine a respiratory condition of the patient.

In some examples, the respiratory distress management system, the at least one source, and the device are different devices and separate from each other but coupled to each other. In some examples, the at least one source and the apparatus are the same and separate from, but coupled to, the respiratory distress management system. In some examples, the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation system.

In one example, a computer-implemented method for treating a patient experiencing respiratory distress includes: a controller including a processor and a memory disposed within a respiratory distress management device including a mechanical ventilation system for providing mechanical ventilation to a patient determines whether a communication capability exists between the respiratory distress management device and at least one source separate from the respiratory distress management device at a particular time to allow control of the mechanical ventilation system by the at least one source to deliver mechanical ventilation to the patient; in the event that it is determined that the communication capability is present at the particular time, the controller allows control of the mechanical ventilation system by the at least one source to deliver mechanical ventilation to the patient; in the event that it is determined that the communication capability is not present at the particular time, the controller controls a gas delivery device of the mechanical ventilation system to deliver mechanical ventilation to the patient, wherein allowing control by the at least one source comprises allowing closed-loop ventilation control based on oxygen concentration measurements of the patient's blood, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor coupled to the patient, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

In some examples, the mechanical ventilation system includes: at least one pressure sensor disposed within a gas delivery system of the mechanical ventilation system configured to sense a first signal representative of a flow of gas within the gas delivery system, and the method includes the controller: the method includes receiving a first signal representative of the airflow, generating respiratory parameter data corresponding to at least one respiratory parameter of a patient based at least in part on the received first signal representative of the airflow, and transmitting the respiratory parameter data to a second device coupled to the respiratory distress management device, the respiratory parameter data being used to determine a respiratory condition of the patient. In some examples, the controller transmits the breathing parameter data to the second device for use by the second device in displaying data related to the breathing condition of the patient on a graphical user interface of a display of the second device. In some examples, the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient.

Some examples include: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including treatment recommendations provided to a user of the second device and relating to a treatment to be delivered by the respiratory distress management device at least in part upon user selection of the treatment recommendation. Some examples include: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a treatment recommendation provided to a user of the second device and related to a treatment to be delivered by the respiratory distress management device when the user selects the treatment recommendation, wherein the treatment includes mechanical ventilation. Some examples include: the controller allows control by the at least one source, wherein the respiratory distress management device, the at least one source, and the device are different devices and separate from each other but coupled to each other.

Some examples include: the controller receives a signal representative of the flow of gas, wherein the at least one pressure sensor is coupled to or part of at least one pneumotach disposed within the mechanical ventilation system. Some examples include: the controller performs the following operations: receiving a second signal from the critical care monitor representative of at least one physiological parameter of the patient; and generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received first signal and the received second signal.

Some examples include: the controller receives the second signal from the intensive care monitor, wherein the intensive care monitor is a defibrillator. Some examples include: the controller receives a second signal representative of at least one physiological parameter of the patient, wherein the at least one physiological parameter includes an blood oxygen concentration parameter. Some examples include: the controller receives a second signal representative of at least one physiological parameter of the patient, wherein the at least one physiological parameter is obtained using oximetry. Some examples include: the controller receives a second signal representative of at least one physiological parameter of the patient, wherein the at least one physiological parameter is obtained using capnography.

Some examples include: the controller transmits the breathing parameter data to the second device, the breathing parameter data being used to determine a breathing condition of the patient, wherein the breathing condition is for display on a graphical user interface of the second device. Some examples include: the controller transmits the respiratory parameter data to the second device, wherein the second device includes a critical care monitor. Some examples include: the controller transmits the breathing parameter data to the second device, wherein the second device comprises a tablet computer. Some examples include: the controller transmits the respiratory parameter data to the second device, wherein the second device comprises an aspect of a cloud-based computing system.

Drawings

Various aspects of embodiments of the invention are discussed below with reference to the accompanying drawings, which are not intended to be drawn to scale. These figures are included for illustrative purposes and for further understanding of various aspects and examples. The accompanying drawings are incorporated in and constitute a part of this specification and are not intended to limit the scope of the invention. In the drawings, identical or nearly identical components that are illustrated in various figures are represented by like numerals. For purposes of clarity, not every component may be labeled in every drawing.

Fig. 1 illustrates an example emergency care environment including a respiratory distress ventilator, CCM, and a tablet computer.

Fig. 2 illustrates an example emergency care environment including a respiratory distress ventilator, CCM, tablet computer, and offsite monitor.

Fig. 3 illustrates an example emergency care environment including a respiratory distress ventilator and tablet computer.

Fig. 4 illustrates an example emergency care environment including a respiratory distress ventilator, a tablet computer, and an offsite monitor.

Fig. 5 illustrates an example emergency care environment including a respiratory distress ventilator and CCM.

Fig. 6 illustrates an example emergency care environment including a respiratory distress ventilator, CCM, and offsite monitor.

Fig. 7 illustrates an example emergency care environment including a respiratory distress ventilator, CCM/defibrillator, and tablet computer.

Fig. 8 illustrates an example modular system including a respiratory distress ventilator, CCM/defibrillator, and tablet computer.

Fig. 9 illustrates an example environment for utilizing multiple devices within a medical treatment system to provide and monitor patient treatment.

Fig. 10 illustrates an example respiratory distress ventilator.

Fig. 11 illustrates example emergency care settings including a respiratory distress ventilator that may be remotely controlled.

Fig. 12 illustrates an example of the types of signaling related to a Ventilation Control Director (VCD) utilizing failure mode condition analysis.

Fig. 13 illustrates an example of a method related to failure mode condition analysis implemented by a VCD.

Fig. 14 illustrates an example of an emergency care environment including a VCD of a respiratory distress ventilator controller enabling control of respiratory distress ventilator mechanical ventilation by a remote control source.

Fig. 15 illustrates an example of an emergency care environment including a VCD of a respiratory distress ventilator controller controlling respiratory distress ventilator mechanical ventilation due to detection of a failure mode condition.

Fig. 16 illustrates an example of an emergency care environment including a VCD of a respiratory distress ventilator controller controlling respiratory distress ventilator mechanical ventilation due to detection of a no communication failure mode condition.

Fig. 17 illustrates an example of an emergency care environment including remote control of a respiratory distress ventilator through an offsite source.

Fig. 17A illustrates an example of a non-hospital emergency care environment including a respiratory distress ventilator and a plurality of other devices.

Fig. 17B illustrates an example of a portion of the non-hospital emergency care environment depicted in fig. 17A showing remote control by one of the other devices.

Fig. 18 illustrates example communication-related failure mode conditions.

FIG. 19 illustrates example data integrity related failure mode conditions.

Fig. 20 illustrates an example ventilator setting-related failure mode condition.

FIG. 21 illustrates example alert related fault mode conditions.

FIG. 22 illustrates an example method related to failure mode condition analysis implemented by a VCD, including control utilizing the VCD.

Fig. 23 illustrates an example method associated with failure mode condition analysis implemented by a VCD that includes details associated with failure mode condition analysis associated with communications.

FIG. 24 illustrates an example method related to failure mode condition analysis implemented by a VCD, including details related to failure mode condition analysis related to data integrity.

FIG. 25 illustrates an example method related to failure mode condition analysis implemented by a VCD, including details related to failure mode condition analysis related to ventilation settings.

Fig. 26 illustrates an example respiratory distress ventilator with non-ventilation and ventilation modes.

Fig. 27 illustrates an example of respiratory distress ventilator ventilation capability.

Fig. 28A illustrates an example front portion of a respiratory distress ventilator including controls including a power switch and a communication light.

Fig. 28B illustrates an example front portion of a respiratory distress ventilator including controls including a power switch, a remote control light, and a smaller display.

Fig. 28C illustrates an example front portion of a respiratory distress ventilator including controls including a power switch, a remote control light, and a larger display.

Fig. 29 illustrates an example of ventilation control software including CLC capability.

Fig. 30 illustrates an example emergency care environment that provides Context Sensitive Guidance (CSG).

Fig. 31 illustrates an example of components of a system for providing CSG.

Fig. 32A to 32C illustrate an example method for providing a CSG.

Fig. 33 illustrates an example of a companion device configured to provide a device view.

Fig. 34 illustrates an example of a combined ventilation system/patient monitor-defibrillator device view user interface at a companion device.

Fig. 35 illustrates an example of a medical device data screen.

Fig. 36 illustrates aspects of an example of a mechanical ventilation device for use with a ventilation system, such as a respiratory distress ventilator.

FIG. 37 illustrates aspects of an example pneumatic system that may be used with a portable ventilator.

Fig. 38 illustrates aspects of an example external gas supply system that may be used with a portable ventilator.

Fig. 39 illustrates aspects of an example patient circuit that may be used with a portable ventilator.

Fig. 40 illustrates examples of components of the various devices described with reference to fig. 1-39.

Detailed Description

The description set forth below in connection with the appended drawings is intended as a description of various exemplary embodiments of the disclosed subject matter. Specific features and functions are described in connection with the exemplary embodiments; however, it will be apparent to those skilled in the art that the disclosed embodiments may be practiced without each of these specific features and functions.

Reference throughout this specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the subject matter disclosed. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. Further, embodiments of the disclosed subject matter are intended to cover modifications and variations thereof.

It must be noted that, as used in the specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. That is, as used herein, the words "a," "an," and "the" etc. have the meaning of "one or more than one," unless specifically indicated otherwise. In addition, it is to be understood that terms such as "left", "right", "top", "bottom", "front", "back", "side", "height", "length", "width", "upper", "lower", "inner", "outer", "inner" and "outer", etc., as may be used herein, describe only points of reference and do not necessarily limit embodiments of the invention to any particular orientation or configuration. Moreover, terms such as "first," "second," "third," etc. identify only one of a plurality of portions, components, steps, operations, functions, and/or reference points as disclosed herein, and as such, do not necessarily limit embodiments of the invention to any particular configuration or orientation.

Furthermore, the terms "generally," "about," "near," "minor variation," and similar terms generally refer to ranges of identification values that are included within a margin of 20%, 10%, or preferably 5% in some embodiments, as well as any value in between these ranges.

All functions described in connection with one embodiment are intended to be applicable to such additional embodiments, unless explicitly stated or unless the features or functions are incompatible with the additional embodiments described below. For example, where a given feature or function is described explicitly in connection with one embodiment but not explicitly mentioned in connection with an alternative embodiment, it is to be understood that the inventors contemplate that the feature or function may be deployed, utilized, or implemented in connection with an alternative embodiment unless the feature or function is incompatible with the alternative embodiment.

In some instances, variants of terms that may refer to the same or similar concepts may be utilized, and certain terms may have meanings that are notified by a particular context. In general, the sending, receiving, or transmitting of data may include through wired and/or wireless connections, and/or within one or more wired or wireless networks. Further, sending from the first entity to the second entity or to be received by the second entity may include sending from the first entity to the second entity or to be received by the second entity, directly from the first entity to the second entity, or indirectly via one or more intermediate entities.

Respiratory distress may include, for example, any form of dyspnea, injury, or problem (including respiratory failure). The breathing parameter data may comprise data relating to breathing, lung or lung related parameters, as may be associated with breathing, lung or lung related characteristics, properties or functions, for example. The breathing parameter data may include, for example, data related to pressure, flow, volume, or volume related parameters associated with the lungs, including parameters that may be measured using one or more flow sensors, pneumotachs, or spirometers. The breathing parameter data may include, for example, data related to respiratory mechanics, such as respiratory compliance (Crs), respiratory elasticity (E), and respiratory resistance (Rrs), etc. The breathing parameter data may also include parameters such as, for example: vital Capacity (VC), forced Vital Capacity (FVC), forced Expiratory Volume (FEV) at timed intervals (e.g., between 0.5 and 10 seconds, less than 0.5 seconds, 1.0 seconds, or FEV1, 2.0, 3.0 seconds, 4.0 seconds, or 5.0 seconds), forced Expiratory Flow (FEF) at e.g., 10% to 90% capacity (such as 25% to 75% or FEF25 to 75, etc.), peak expiratory flow rate (PEF or PEFR), and maximum respiratory capacity (sometimes referred to as maximum spontaneous ventilation or MVV). The breathing parameter data may be presented in a variety of different manners or forms, such as may include, for example, in raw terms (such as liters or liters/second, etc.) or as a percentage, etc. The breathing parameter data may also be presented as "predicted" values, such as a prediction percentage, for example, which may include percentage values related to a reference, average, or other "predicted" value, for example. In some cases, a "predicted" value may be associated with one or more patients or hypothetical patients of similar characteristics.

The respiratory condition may, for example, relate to, identify or indicate the presence or absence of one or more respiratory, pulmonary or lung-related conditions, and may include RD. The condition may include a state, disease or problem, or several thereof, or a type, group or category thereof. Respiratory conditions may include etiologies associated with respiratory conditions or non-respiratory conditions (e.g., respiratory distress associated with acute heart failure). The non-respiratory condition may be associated with one or more non-respiratory systems (e.g., heart, endocrine, exocrine, circulatory, immune, lymphoid, neural, muscular, renal, skeletal, or otherwise), for example. In addition, the respiratory condition may include one or more of a determined, assessed, estimated, likely, or a determined, assessed, likely, or likely, associated etiology. The respiratory condition may also include data associated with any of the foregoing, which may be referred to as respiratory condition data.

A ventilator may include, for example, any device or system capable of delivering ventilation, whether such delivered ventilation is controlled internally, remotely, or by both aspects.

Various ventilation parameter related terms or abbreviations (including inhaled oxygen concentration Fraction (FiO) ₂ ) Positive End Expiratory Pressure (PEEP) and others) may refer to ventilation-related settings, although the word "settings" may or may not be stated. Furthermore, reference to ventilation parameters or parameter settingsThe generation may be used to refer to a parameter in the conceptual or definition sense, or a value associated with a particular setting (e.g., "5cm H ₂ PEEP "of O). The user may include an individual operating, supervising, or fully or partially responsible for the operation of the device, such as a respiratory distress ventilator, even though the user may not interact with the device during a particular period of time when the device is operating.

The pre-warning or alert may be presented (such as by being presented visually or audibly, such as via a display, graphical User Interface (GUI), or speaker of the device) to draw the attention of the user, and may or may not be included in a context-sensitive guide (CSG). However, the pre-warning or alarm may also include pre-warning or alarm conditions that are algorithmically identified, discerned or determined by the computerized device and do not have to be presented or displayed. The term optimization may include, for example, improvements or improved operation in one or more aspects relative to an actual, potential, or hypothetical less optimal situation or less optimal operation. The term adjustment may include changing as well as not changing or remaining unchanged, as the case may be. The determined parameter values may include a determined estimate or a determined approximation to the parameter. The term monitoring may refer to or include, for example, monitoring or tracking by computerized means utilizing one or more algorithms, rather than by a person or user, or monitoring by a person or user, or both. The term continuous may include, for example, periodic (having the same or different periods), frequent, repeated, or cyclical, among other things.

Some embodiments of the invention provide, include or comprise the use of: devices, systems, and methods for caring for patients experiencing or having undergone respiratory distress, such as may include a respiratory distress ventilator, and the like. In various embodiments or modes of operation, the respiratory distress ventilator may include, for example, a device that may control itself, or may be remotely controlled, such as by a remote control device or system, or may include aspects of both.

In some embodiments, the controller of the respiratory distress ventilator internally signals the mechanical ventilation system (or device) of the respiratory distress ventilator to enable control thereof, whether such internal signaling enables internal control or remote control. The internal control includes the controller of the respiratory distress ventilator internally signaling the mechanical ventilation system of the respiratory distress ventilator to effect control in accordance with a setting (or more than one setting) determined by the controller, even if the determined setting is determined based at least in part on the received requested/commanded setting. The remote control includes a controller of the respiratory distress ventilator that signals the mechanical ventilation system of the respiratory distress ventilator internally according to a set-up value received by the controller via a request/command from a remote control device or system.

In some embodiments, the respiratory distress ventilator may be capable of internal or remote control, or capable of operation with aspects of both, and capable of determining which particular state or mode or states to employ or use at a predetermined or particular time. Further, the respiratory distress ventilator is capable of switching between modes or states of operation (such as modes that may include an internal control mode, a remote control mode, or aspects including both, etc.).

The controller may include physical aspects (such as one or more processors and one or more memories, etc.) and software-based aspects (which may include one or more programs, algorithms, or software-based aspects). The software-based aspects may be stored, for example, in one or more memories of the controller, accessed by one or more processors of the controller, and used or executed by the processors. In various embodiments, the Ventilation Control Director (VCD) may be or include, for example, a software-based aspect of one or more controllers, such as a respiratory distress ventilator controller or the like, or may be or include software and hardware aspects, such as may include processor and memory aspects and the like. In some embodiments, the VCD may be used to manage and implement aspects of the control of mechanical ventilation provided by the respiratory distress ventilator. This may include management and implementation of aspects of internal control, remote control, or both. In some embodiments, the VCD may be used to assess or determine whether aspects of internal control or remote control, or both, are implemented, and control is implemented accordingly, which may include, for example, switching between aspects of internal control or remote control, or both. In some embodiments, the VCD may determine a control mode, such as an internal control or a remote control, based on whether a failure mode condition is detected at a predetermined time. Further description related to embodiments of VCDs is provided with reference to fig. 11-25.

The term control may include physical controls, display/GUI based controls, or both. Controls may, for example, allow user interaction with a device or system, such as may affect operation of the device or system, etc., which may include, for example, making selections or providing inputs to set, select, change, increase, decrease, confirm, or override the implementation of parameter settings or modes. In various aspects, a device or system with controls may operate without user interaction, with user interaction, or both. This may include operations that may progress without user interaction in various aspects or instances, but may permit or require user interaction in some aspects or instances. The display/GUI may include a control and/or the control may include a display/GUI.

In some embodiments, a control set, such as a control set of a particular device, may include one or more respiratory aspects. The respiratory aspects of the control may include, for example, display/GUI aspects related to any aspect of ventilation, ventilation parameters, or aspects related to respiration, respiratory distress, or respiratory parameters. The respiratory aspect of the control may or may not include CSG.

Herein, remote control may include control or aspects of control provided from outside of or separate from the controlled device or system, such as by wired or wireless signaling or communication, such as may include, for example, bluetooth (Bluetooth) or ultra wideband (ultra wideband), and the like. In this way, the remote control may be realized, for example, via a wired-only connection connecting the remote control device and the remote controlled device, or by a wireless-only connection, or by a combination of a wired connection and a wireless connection. Remote control (such as remote control by a remote control device or system, etc.) may include control with or without aspects of user interaction with the remote control device or system (e.g., by a user using controls of the remote control device or system, etc.). The internal control (such as the device controlling itself internally, etc.) may or may not include aspects of user interaction with the internally controlled device (e.g., by a user using a control of the internally controlled device, etc.). The user interaction may include, for example, the user entering, setting, selecting, changing, increasing, decreasing, confirming, or overriding the implementation of the parameter settings or modes using controls. The user interaction may be prompted, guided or interactively guided, e.g. via or not, e.g. via CSG, one or more GUI-based prompting messages, pre-warnings or alarms which may be related, e.g. to patient parameters or ventilation parameters, such as may relate to ventilator operation, performance or components (such as sensors etc.).

Any of a variety of types of gas movers/gas flow generators may be used in various embodiments of the respiratory distress ventilator. These may include, for example, blowers/turbines, compressors, pneumatic regulators, bellows or pistons.

In some embodiments, the respiratory distress ventilator is configured for integration with one or more other devices or systems, such as an onsite or offsite remote device, system, or interface (aspects of which may or may not be included in various embodiments), and the like. For example, in some embodiments, the respiratory distress ventilator may be coupled with a device such as a patient monitor or a Critical Care Monitor (CCM) in a wired and/or wireless manner. In some embodiments, for example, a defibrillator, respiratory distress ventilator, or other device (such as another medical device, monitoring device, or computing device, etc.) may be, may include, or may be used as a CCM. Further, in some embodiments, the respiratory distress ventilator may be coupled with one or more computing systems, computers, computing devices, or portable computers (which may include, for example, cloud-based computing systems, computers, notebook computers, tablet computers, touch-based devices, smartphones, wearable devices, or implantable devices, etc.).

In some embodiments, smaller size, lighter weight, and/or greater simplicity may be desirable or optimized in a portable device that includes a respiratory distress ventilator. The optimization may take into account various factors such as the actual, predicted, possible or anticipated settings, circumstances or applications (such as pre-hospital scenarios, etc.), etc. Optimization may also consider the assignment of roles for various devices in such a scenario. Some embodiments provide respiratory distress ventilators and related devices, systems, and methods that are optimized in various ways. Respiratory distress ventilators may be smaller and/or lighter than various other ventilators or systems used, for example, in pre-hospital care. Furthermore, the respiratory distress ventilator may be optimized for training or empirically limited users. Still further, the respiratory distress ventilator may be optimized for use in environments that may include other integrated devices or systems. In addition, some embodiments provide systems that include devices for respiratory distress ventilators, wherein in view of these factors and potentially other factors, the devices and the overall system are optimized and capable of optimized operational integration.

For example, the space immediately surrounding the critical care patient may be packed with equipment or articles such as hoses, tubing, wiring, and various devices. For example, it may be beneficial or advantageous to minimize the spatial impact of the ventilator. In some embodiments, for example, respiratory distress ventilators may provide advantages by allowing for modularization of the system including the ventilator or allowing for a higher degree of modularization of the system including the ventilator (which may allow for smaller, simpler ventilators that are closer to the patient). Further, in some embodiments, the control in the remote control device or system or the control of the remote control device or system may be some variable distance from the patient (e.g., between 0 and 3 feet, between 3 and 6 feet, between 6 and 9 feet, between 9 and 12 feet, further than 12 feet, or offsite). Some embodiments provide benefits or advantages for patient care by, for example, simplifying the immediate clinical environment of the patient. For example, in some embodiments, even though the combined weight and/or size of the combination of ventilator and different remote control devices together is the same as or similar to a system in which the controls are provided or equipped with a ventilator, the combination of ventilator and different remote control devices may be more useful, more practical, or optimally useful, e.g., in various clinical contexts, because only a relatively small ventilator may be required on the patient side or very close to the patient. Some embodiments provide a respiratory distress ventilator that provides these advantages.

In some embodiments, the overall environment may include a respiratory distress ventilator that may be coupled to and operatively integrated with one or more other devices (each of which may provide certain roles or functions in the overall environment). These roles may relate, for example, to device and patient related sensing, operation, processing, software, algorithms, applications, data storage, communication, integration (of device and system, roles, functions, and physical software-based and conceptual components and aspects), user interaction and guidance, and patient related assessment or intervention. Within the integrated environment, the roles of the various devices can be optimized in view of factors related to, for example, the respective devices or systems, as well as the overall environment and intended settings. Such optimization may also take into account factors related to the need for the respiratory distress ventilator to be of a particular or sufficiently small size, light weight, and/or to be simple or easy to carry or use. In some embodiments, the respiratory distress ventilator enhances the ability to accurately assess or screen a patient's condition, determine or select, and initiate and deliver effective interventions, and/or to continuously control or adjust or assist in controlling and adjusting parameters related to the applied interventions. Furthermore, the enhancements may be optimized in view of the overall environment, available devices, systems or users at a given time or period, and available communications between available devices, systems or users at a given time or period, and their changing aspects over time.

In some embodiments, for example, one or more devices or systems coupled to or integrated into their environment may supply or partially supply components or other aspects that may enhance or enhance the operation of the respiratory distress ventilator, and/or that may otherwise be or need to be included with or in the respiratory distress ventilator. Some such aspects may include physiological and operational signaling, sensing, or measurement aspects. Other aspects may relate to power, communication, device identification, authentication, or coupling. Other aspects may relate to processing, hardware and software, such as for data processing and management, data and device integration, or operational aspects such as Closed Loop Control (CLC) (examples of which are described with reference to fig. 29), etc. Other aspects may relate to patient respiratory or condition assessment, diagnostic screening, diagnosis, treatment, or intervention. Other aspects may include controls and controls related to the respiratory distress ventilator (physical, display/GUI based, or both), and their features. Still other aspects may include the determination and/or presentation of Context Sensitive Guidance (CSG) as further described below with reference to, for example, fig. 30-35.

In some embodiments, the respiratory distress ventilator may have a set of (one or more) included controls, and the one or more remote control devices, systems, or monitors may also have a set of (one or more) remote controls associated with the respiratory distress ventilator. The set of remote controls may be used to allow remote control of the respiratory distress ventilator, such as may involve aspects of the operation of a mechanical ventilation system of the respiratory distress ventilator, for example. In various embodiments, the set of controls included with the respiratory distress ventilator may vary among a range of possibilities.

In various embodiments, the set of remote controls may include respiratory aspects separate from other aspects, or may include respiratory aspects mixed, combined, or integrated into a larger display/GUI or into a set of controls that may also include non-respiratory aspects, for example. Further, in various embodiments, the collection of remote controls may be separate or separable from, or may be integrated with, other aspects of the controls. In some embodiments, the respiratory distress ventilator may have no included controls at all, or may have a limited set of included controls. For example, any one or more controls associated with the respiratory distress ventilator may be provided by one or more sets of remote controls for one or more other devices, systems, or monitors. In some embodiments, the set of remote controls, or a portion thereof, may correspond, in whole or in part, to, simulate, mirror, copy, duplicate, simulate, or be similar to, the set of included controls of the respiratory distress ventilator, to any varying degree. Further, in some cases where the respiratory distress ventilator does not have a control or has a limited set of controls, the set of remote controls may be somewhat similar to or duplicate the set of assumptions that may be included in the respiratory distress ventilator.

Thus, in various embodiments, the set of remote controls may be identical, may be replicated, may be somewhat similar, or may be different from the set of controls included. Further, the various particular individual controls or aspects of the two sets may include controls or aspects that are the same or different, or have the same or different scope, and may overlap, partially overlap, or not overlap. In various embodiments, the set of included controls may be more limited or simplified in at least some respects, or vice versa, than the set of remote controls. For example, the set of included controls may or may not, or fully or partially, include a subset of the set of remote controls, or vice versa. The collection of remote controls may include individual controls or aspects that are similar to, reflect or mirror the individual controls or aspects of the included controls, or that are not similar to, do not reflect or mirror the individual controls or aspects. The collection of remote controls may provide visual or GUI features or information related to or allowing control of some or all of the aspects, modes, settings, or other parameters reflected by or incorporated into the included controls.

In some embodiments, planning, selecting, or restricting the set of included controls of the respiratory distress ventilator, such as to an optimal level, may provide various advantages. Such advantages may include, for example, ease or range of portability (which may include lightweight, small size, or small footprint), practicality, ease or range of availability, simplicity of control, simplicity of user interaction, or simplicity of operation.

In some embodiments, the set of included controls of the respiratory distress ventilator may be optimized, for example, taking into account factors such as the actual, anticipated, or likely environment or settings, which may include considerations related to location, situation, and use case scenario. Other factors may relate to the potential or potential extent of user training, experience, and availability or distraction at the site. Other factors may relate to the patient or the type of patient. Still other factors may relate to the device, the system, the communication, the reliability or speed of the communication, or aspects of data and data management. Some examples of controls for the respiratory distress ventilator including display/GUI aspects are described with reference to fig. 28A-28C.

The set of remote controls for the remote control device may also be optimized, including taking into account the aforementioned factors (as they apply to the remote control device) as well as other factors. For example, the set of remote controls may include a display/GUI that is more inclusive, larger, broader, more comprehensive, more sophisticated, more complex, and/or finer in the degree of selection or optimization than the set of included controls of the respiratory distress ventilator. In some embodiments where the set of remote controls is more inclusive or comprehensive than the set of included controls of the respiratory distress ventilator, for example, various advantages may be allowed by either using the set of remote controls or by control of an associated remote control device. These advantages may include, for example, larger, additional, more sophisticated, more complex or finer controls, aspects of controls, user-based controls, user interactivity, or user-based controls with larger available displays/GUIs. The larger available display/GUI may include, for example, information such as parameter values, alarms, pre-warnings, user messages or CSG, etc., user interactivity features.

In some embodiments, the respiratory distress ventilator may be remotely controlled, or may be capable of both remote control or internal control, or both aspects, such as may include the use of a controller of the respiratory distress ventilator, or the like. In some embodiments, for example, the respiratory distress ventilator may be able to determine whether to enable and use aspects of remote or internal control, or both, and be able to switch between remote and internal control modes, or modes including aspects of both. For example, in some embodiments, remote control or aspects thereof may be generally preferred when available or optimal, and internal control may be used only when external control or aspects thereof are determined to be unavailable, unsafe, impractical, or less than optimal relative to internal control. In various embodiments, remote control may be determined to be unavailable or not optimal if, for example, there is no or insufficient communication with the remote control device or system, or there are other issues such as may be related to effective, optimal, or safe control or operation of the respiratory distress ventilator by remote control or by specific remote control requests/commands.

In some embodiments, the remote control may include a more complex or sophisticated form or aspect of ventilation or ventilation control, for example, may include CLC aspects, etc., while the internal control may include less complex or sophisticated control, such as continuing to use the current parameter value without adjustment, or using default or standby parameter values, etc. Further, in some embodiments, the respiratory distress ventilator may include a controller that monitors and allows remote control within certain limits, parameters, or ranges of settings, but may override external control and utilize internal control only if, for example, a desired range of settings needs to be maintained.

In some embodiments, the respiratory distress ventilator or controller thereof may be configured to sometimes allow remote control when it is determined that no failure mode condition exists. In some embodiments, the failure mode condition may include a condition requiring utilization of internal controls or aspects thereof, as opposed to enabling or allowing remote controls. In some embodiments, a lack of or insufficient communication capability between the respiratory distress ventilator and a remote control device or system may constitute a failure mode condition. For example, if it is determined that such communication is not present (or lost), or is insufficient or not sufficiently reliable, the respiratory distress ventilator may use (or switch to) internal control (or internal control mode). In the case where control using the remote control device is unavailable or becomes unavailable or does not satisfy a certain required condition, the internal control mode can be effectively operated as a standby mode or a default mode. In some embodiments, as further described herein with reference to fig. 18-21, the failure mode condition may include a condition related to the remote control device or data received from the remote control device, such as may relate to, for example, communication, data integrity, ventilator settings, or alarm conditions, etc.

In some embodiments, ventilation delivered by the respiratory distress ventilator may include the use of various forms of CLC in ventilation. In some embodiments, such CLCs may be available when remote control is available, when specific physiological sensing capabilities are available, or both. Although respiratory distress ventilators may deliver ventilation, the control of aspects of the ventilation delivered may come from a remote source, and the remote source may take the form or control aspects or features that may include or incorporate the form or aspects of the CLC. Forms of CLC that may be useful may include a concentration fraction with inhaled oxygen (FiO ₂ ) Related CLC, which may be at least partially determined by the measured oxygen saturation or SpO of the patient ₂ And (5) driving. The form of CLC may also include CLC related to Positive End Expiratory Pressure (PEEP), which may be, for example, that of the current FiO ₂ And current PEEP driving. This may include associated PEEP change qualification rules and PEEP selection rules (further description of which is provided with reference to fig. 29). For example, in some embodiments, the respiratory distress ventilator and/or one or more remote control sources may each include a device with CLC capability (e.g., fiO ₂ PEEP, or both, and/or other parameters). Thus, in various embodiments, the controller of the respiratory distress ventilator is capable of internal control including a CLC, or implementing remote control including a CLC, or both. At the position of In some embodiments, an internally controllable or remotely controllable respiratory distress ventilator may provide only some forms of mechanical ventilation including CLC capability or CLC capability when remotely controlled.

In some embodiments, the respiratory distress ventilator may include one or more sensors, flow sensors, pneumotachs, or spirometers, such as may be coupled to an inspiratory or expiratory patient circuit or patient circuit branch of the respiratory distress ventilator, or the like, which is capable of sensing signals that may be used to determine at least one patient respiratory parameter. This in turn may be used in patient respiratory condition determination, screening or diagnosis, or for determining appropriate interventions. For example, the included flow sensor or pneumotach may be used in conjunction with sensing and measurement associated with the patient's respiratory function as well as in conjunction with respiratory distress ventilator performance and operation.

In some embodiments, the respiratory distress ventilator may include one or more non-ventilation modes that do not provide ventilation, and one or more ventilation modes that provide various possible types of ventilation. Further details regarding these modes are provided with reference to, for example, fig. 26-27.

In some embodiments, a user interactive CSG is determined and provided to a user. Details about CSG are further explained with reference to fig. 30 to 35, for example.

In some implementations, for example, after a user with a respiratory distress ventilator arrives at a site with a patient, the respiratory distress ventilator is initially used to obtain patient respiratory parameter data that is used (at the respiratory distress ventilator or elsewhere) to determine the respiratory condition of the patient and may be used (at the respiratory distress ventilator or elsewhere) to determine the CSG. The user may be alerted when the patient's respiratory condition is being assessed, such as via a CSG or the like (at a respiratory distress ventilator or elsewhere). Further, if additional physiological monitoring is required, the additional physiological monitoring may be initiated, or the user may be prompted to initiate the additional physiological monitoring, such as via a CSG or the like. The user may be prompted (at the respiratory distress ventilator or elsewhere), such as via a CSG or the like, to discontinue monitoring the patient using the respiratory distress ventilator only if further monitoring is determined to be inappropriate (such as may be determined to be within a normal range based at least in part on a physiological parameter of the patient, etc.). The user may be prompted such as by CSG or the like (at the respiratory distress ventilator and/or elsewhere) only if ventilation is appropriate, and certain determined or selected modes of ventilation may be initiated by the respiratory distress ventilator, potentially after user confirmation. In addition, patient respiratory parameters and respiratory conditions may continue to be monitored during ventilation provided by the respiratory distress ventilator. If ventilation is no longer needed (such as may be determined based at least in part on a physiological parameter of the patient, etc.), respiratory distress ventilator ventilation may be discontinued, or the user may be prompted to discontinue respiratory distress ventilator ventilation. Alternatively, if another ventilation mode is determined to be more suitable or optimal, the user may be prompted to switch to the other ventilation mode.

Furthermore, in some embodiments, the respiratory distress ventilator may be used to detect whether intervention is required, regardless of ventilation mode or otherwise. If it is determined that intervention is required, the CSG may be used to guide the user to manage the patient as needed.

The following is a simplified example event including the use of a respiratory distress ventilator in an emergency care scenario. Based at least in part on patient physiological parameters including a history of heart disease and including SpO ₂ Monitored parameters of Respiratory Rate (RR) and Crs may be determined as a patient having a respiratory condition including respiratory distress associated with acute heart failure. Can be determined to include SpO by continuous monitoring ₂ End tidal carbon dioxide (EtCO) ₂ ) And a minute volume (Ve) to initiate Continuous Positive Airway Pressure (CPAP) ventilation. The user may be guided accordingly via the determined CSG. If the condition of the patient is still further worsened despite the treatment (e.g., based at least in part on continuously monitored SpO ₂ 、EtCO ₂ And Ve, etc.), it may be determined that it is appropriate to initiate bi-level ventilation and the user may be guided accordingly via the CSG. Throughout the foregoing example events, an environment such as a flatA display/GUI is provided on a board computer, defibrillator, respiratory distress ventilator, and/or one or more other devices or systems, etc., which may include integrated respiratory aspects such as may include respiratory parameter values, pre-warnings, alerts, messages or CSG's, etc. Further, for example, the respiratory distress ventilator may be internally controlled, remotely controlled, controlled using aspects of both, or internally controlled during some periods of time and remotely controlled during other periods of time.

Fig. 1-7 illustrate example environments including respiratory distress ventilators, as well as other devices and systems, and the like, in accordance with various embodiments. The various devices and systems may be communicatively coupled via wired and/or wireless connections. Many different combinations of devices and systems may be used in various embodiments, and their respective roles, only a few examples of which are illustrated in fig. 1-7.

In fig. 1-7, in various implementations, the depicted respiratory distress ventilator can be remotely controlled by one or more of the other depicted devices or systems (which may include, for example, CCMs, defibrillators, medical or monitoring devices, computing devices, portable computing devices, tablet computers, smartphones, or offsite monitor systems). In some embodiments, the respiratory distress ventilator may be internally or remotely controllable and capable of switching between internal and remote control modes.

In various embodiments, particular sensing capabilities and components may be distributed among various devices or systems in an environment in various ways. These may include, for example, one or more electrodes, capnography sensors, pulse oximeters, flow sensors, pneumotachs, spirometers, pressure sensors, barometric pressure sensors, humidity sensors, oxygen sensors, temperature sensors, electromagnetic or magnetic sensors, light/electromagnetic spectrum/optical sensors, blood pressure monitors, heart rate monitors, electrocardiogram (ECG) sensors, and others. The sensing capabilities and components may relate to, for example, patient parameters and various patient systems (such as respiratory and circulatory systems, etc.). The sensing capabilities and components may also relate to parameters associated with the device and its operation, including respiratory distress ventilator and ventilation or defibrillator and electrotherapy, etc. In some embodiments, any of the various sensing capabilities (such as the sensing capabilities of a respiratory distress ventilator, CCM/defibrillator, or tablet, etc.) may instead be provided by one or more other devices, or may be distributed among multiple devices. Further, in various embodiments, all or a portion of the various sensing components, or patient circuit, may or may not be considered part of the respiratory distress ventilator or other device, even if they are connected to the respiratory distress ventilator or other device. Further, in various embodiments, the roles and functions of the various devices may be distributed differently among the devices.

Fig. 1 illustrates an example emergency care environment 4100 that includes a respiratory distress ventilator 4102, a CCM 4104 (such as a CCM/defibrillator, etc.), and a tablet 4108 or other portable computing device (e.g., a smart phone or notebook computer, etc.). Also shown is a user 4120, which user 4120 and/or one or more other users may monitor or interact with, for example, patient 4114, respiratory distress ventilator 4102, CCM/defibrillator 4104, and/or tablet 4108. In the depicted embodiment, the devices 4102, 4104, 4108 are coupled to each other by wired and/or wireless connection 4106 (such as included on the internet and/or one or more wireless networks 4101, etc.). However, in some implementations, such connections may not be available, lost, limited, or have different speeds at different times. Furthermore, their operation may be integrated in various ways.

In various embodiments, the device comprising respiratory distress ventilator 4102 may have housings that may be separate and spaced apart from each other, adjacent to or in contact, or physically or mechanically coupled, connected or attached (fixedly or movably). Some examples of the foregoing are described with reference to fig. 8.

In delivering mechanical ventilation, respiratory distress ventilator 4102 may deliver respiratory gases to patient 4114 via a mechanical ventilation device (examples of which are described with reference to, e.g., fig. 36-38) including a flow generator (such as a blower, turbine, compressor, pneumatic regulator, bellows, piston, or device based thereon, etc.) and a gas delivery device including a patient circuit 4116 including a mask 4118. However, in some embodiments, ventilation may be provided via a cannula or other patient interface, such as a nasal cannula, rather than via the mask 4118.

In the example depicted in fig. 1, CCM/defibrillator 4104 includes a processor for measuring a patient SpO ₂ Pulse oximeter 4122 for measuring EtCO ₂ A capnography sensor 4124, a blood pressure sensor/monitor 4128, an electrode 4126 that may be used to provide electrotherapy to the patient 4114, and may include various other components such as one or more flow sensors, pressure sensors, airway sensors, or spirometers. The respiratory distress ventilator 4102, CCM/defibrillator 4104, tablet 4108, and other devices may also include various sensing, measurement, computerized, electrical, mechanical, coupling, and output aspects or components (including power and batteries).

In the example depicted in fig. 1, respiratory distress ventilator 4102 may be coupled with a source of supplemental oxygen (O2), some examples of which are described with reference to fig. 38. In various embodiments, the respiratory distress ventilator 4102 can use an oxygen supply to supply oxygen in a number of different ways, or the respiratory distress ventilator 4102 can supply oxygen in any of a number of different ways. In various embodiments, the manner in which oxygen is supplied may be determined without user selection, or may be selected by a user, and may or may not require user confirmation.

In some embodiments, a gas storage bag may be used that allows oxygen to be entrained from a low pressure oxygen source. For example, the user may be based at least in part on a current SpO that may be monitored by one or more of the devices 4102, 4104, 4108 ₂ To adjust the flow rate of oxygen. In the embodiment depicted in fig. 1, CCM/defibrillator 4104 continuously monitors SpO ₂ . In various embodiments, the current SpO may be displayed ₂ For viewing by a user via one or more displays/GUIs of the devices 4102, 4104, 4108.

In some embodiments, respiratory distress ventilator 4102 includes and uses variable rate modulation The throttle valve 4140, wherein the oxygen output rate allowed or facilitated by the variable rate adjustment valve 4140 may be varied and changed to a particular oxygen flow rate in a range of possible oxygen flow rates (e.g., from 0L/min to 200L/min (or, for example, up to 220, 250, or 275L/min)). Variable rate regulator valve 4140 may be used to provide a variable and controllable flow of oxygen to the gas provided by respiratory distress ventilator 4102 during the provision of mechanical ventilation. For example, in the embodiment depicted in fig. 1, a variable output regulator valve 4140 may be attached to, for example, the gas inlet of the respiratory distress ventilator 4102, the high pressure oxygen source, and the CCM/defibrillator 4104 (its monitor SpO) ₂ )。

In some embodiments, the variable rate regulator valve 4140 may be controlled automatically or without user interaction. For example, this may be based at least in part on continuous monitoring of SpO by the patient ₂ And according to can be based at least in part on the current SpO ₂ Determined FiO ₂ Setting or adjusting. In some embodiments, this configuration may be used to provide FiO ₂ CLC (FiO) ₂ CLC). In some embodiments, a Portable Oxygen Concentrator (POC) may be used. FiO (Fio) ₂ CLC may be used to control and regulate POC output to entrain oxygen into the respiratory distress ventilator 4102 for use in gases delivered by the respiratory distress ventilator 4102 during mechanical ventilation. Furthermore, in some embodiments, including embodiments using variable output regulator valve 4140 or POC, pec (PEEP CLC) may also be included in the control of respiratory distress ventilator 4104. In some embodiments, the PEEP CLC may be based at least in part on the current FiO ₂ Settings and current PEEP settings. Providing FiO with reference to FIG. 29 ₂ Examples of embodiments of CLCs and PEEP CLCs. In various embodiments, fiO is utilized ₂ Control of the CLC and/or PEEP CLC may be provided internally by the respiratory distress ventilator 4102, or internally by a remote control device of the respiratory distress ventilator 4102 (such as a tablet 4108 or CCM/defibrillator 4104, etc.).

In some embodiments, respiratory distress ventilator 4102 may operate, or have one or more modes of operation that do not include, or sometimes do not include, delivering mechanical ventilation during certain periods of time. Further, respiratory distress ventilator 4102 may include an operation or mode of operation for use outside of an emergency care context. For example, in some embodiments, respiratory distress ventilator 4102 may include and/or may be coupled with one or more spirometers that may be used for patient respiratory assessment outside of emergency care situations. For example, such assessment may be made for a patient or individual who may not currently receive mechanical ventilation, may not need mechanical ventilation, and may not currently experience RD. In some embodiments, such assessment may include, for example, assessing and measuring changes in one or more respiratory parameter values (e.g., FEV1 or FVC) before and after some changes in a situation or procedure (e.g., bronchodilator treatment, or respiratory parameter and respiratory condition assessment of a patient during a routine, scheduled, or other doctor's office, or medical facility or hospital, etc.). In addition, some assessment may be made during periods when the patient is lying, sitting or standing, as well as during periods when the patient is not experiencing RD.

In the embodiment depicted in fig. 1, respiratory distress ventilator 4102 includes one or more flow sensors 4130, a respiratory rate meter, or a pressure sensor, which may be disposed within patient circuit 4116, or within respiratory distress ventilator 4102, elsewhere within respiratory distress ventilator 4102, or as part of respiratory distress ventilator 4102, for sensing signals indicative of gas flow within the gas delivery device of respiratory distress ventilator 4102. In embodiments, for example, one or more flow sensors 4130 may be coupled with or part of one or more spirometers. In some embodiments, the controller of respiratory distress ventilator 4102 receives a signal indicative of gas flow. Based at least in part on the signals representative of the flow of gas, the controller may generate breathing parameter data corresponding to at least one breathing parameter of the patient (e.g., crs, rrs, VC, FVC, FEV at timed intervals (such as FEV1, FEF or FEFs 25-75, etc.), PEF, PEFR, MVV, or others, etc.).

The controller may transmit breathing parameter data to be received by, for example, tablet 4108, CCM/defibrillator 4104, or elsewhere (directly or via one or more intermediate entities), such as for determining a breathing condition of the patient, etc. However, in some embodiments, respiratory distress ventilator 4102 may determine or participate in determining the respiratory condition of the patient. Various examples of embodiments including a respiratory distress ventilator 4102 are described with reference to fig. 2-7.

In some embodiments, for example, aspects of the system of devices including the respiratory distress ventilator 4102 (such as the distribution and integration of roles between devices and aspects of particular devices, etc.) may be optimized based on factors that may include a desired degree of portability or ease of operation of the respiratory distress ventilator 4102. Furthermore, aspects of the respective devices may be optimized. These aspects may include, for example, control sets, processing and memory aspects, software, algorithms, and CSG related aspects. In some embodiments, various capabilities may be included with the respiratory distress ventilator 4102, or may be included with one or more other devices or systems, or may be distributed or integrated among them. This may include, for example, a processor, memory, controller, or stored software or algorithms. These capabilities may be used, for example, to process signals, generate breathing parameter data, or determine the breathing condition of a patient. They may also be used to coordinate or integrate between devices. Thus, in this and other ways, the roles and processing power and components of the respiratory distress ventilator 4102 may be more or less, or determined or assigned based at least in part on the roles of one or more other devices in the environment. In some embodiments, reducing or limiting the role, processing power or components of the respiratory distress ventilator 4102 and the set of controls 4144 included therewith may increase or enhance the portability or portability utility of the respiratory distress ventilator 4102, such as by allowing for reduction in the size, weight, complexity, volume, occupied space or noise during operation of the respiratory distress ventilator. This in turn may allow various implementations that may be balanced or optimized for a particular intended or likely scenario, which may increase positive, potentially life-saving patient prognosis.

In some embodiments, for example, the size of the respiratory distress ventilator may be between 0.125 and 27L, such as between 5.0 and 27L, between 1.0 and 5.0L, between 0.5 and 1.0L, between 0.15 and 0.5L, or between 0.125 and 0.15L, etc. In addition, in some embodiments, the physical size of the respiratory distress ventilator may be between 50 x 50mm and 300 x 300mm, for example between 50X 50mm and 60X 60mm, between 60X 60mm and 75X 75mm, between 75X 75mm and 100X 100mm between 100X 100mm and 200X 200mm or between 200 x 200mm to 300 x 300mm, etc. Further, in some embodiments, the weight of the respiratory distress ventilator may be between 0.2 and 5.0kg, such as between 1.0 and 2.0, between 0.3 and 1.0, or between 0.2 and 0.3kg, etc. Further, in some embodiments, the maximum noise of the respiratory distress ventilator (or noise during a particular mode of operation) may be 40 to 70dB at 1m, such as between 40 to 50dB at 1m, between 50 to 60dB at 1m, or between 60 to 70dB at 1m, etc. Further, in some embodiments, the battery life of the respiratory distress ventilator may be between 2 and 10 hours, such as between 2 and 4 hours, between 4 and 6 hours, between 6 and 8 hours, or between 8 and 10 hours, etc. In some embodiments, the battery may be charged while the respiratory distress ventilator is operating.

In the embodiment depicted in fig. 1, the respiratory distress ventilator 4102, CCM/defibrillator 4104 and tablet 4108 each comprise a set of one or more controls (which may be physical, display/GUI-based, or both). In particular, as depicted, respiratory distress ventilator 4102 has a set of included controls 4144 that includes one or more physical controls 4146 (e.g., one or more physical switches, buttons, knobs, dials, etc.) and one or more GUI/display-based controls 4142. However, in some embodiments, the set of included controls 4144 may include only one or more physical controls, only one or more display/GUI-based controls, or no controls at all. CCM/defibrillator 4104 (which in some embodiments may be an automated external defibrillator or AED) has a collection of CCM/defibrillator controls 4134 that includes one or more physical controls 4132 and one or more GUI/display-based controls 4110. The tablet 4108 has a set of tablet controls 4112 that includes one or more physical controls 4138 and one or more GUI/display-based controls 4136. In various embodiments, aspects of the various sets of controls 4144, 4134, 4112 may be distributed in various ways, and may or may not include similar, identical, or overlapping aspects.

In some embodiments, the set of tablet controls 4112 may display data related to various patient physiological, respiratory, and ventilation related parameters, and may include other output or presentation components such as speakers and/or microphones. For example, a microphone may be used to determine the level of ambient noise, which may be used to determine and set or use specific settings to achieve an appropriate volume level or volume control for the respiratory distress ventilator or components thereof. Further, the user-interactive CSG or other interactions with the user may be implemented or delivered using a combination of a speaker and microphone (such as in combination with, or in lieu of, GUI-based interactions in some instances, etc.) with appropriate software that may be stored on the respiratory distress ventilator, remotely, or both. For example, this may involve voice input provided by the user via a microphone, such as may include commands, acknowledgements, questions, responses or answers, and the like. It may also include speech output such as may include prompts, acknowledgements, questions, responses, answers, guidance, instructions, or step-by-step instructions delivered to the user using a speaker, etc. In various embodiments, the voice output may be algorithmically determined by the respiratory distress ventilator or an associated remote system, or may be provided by another user or care provider speaking to the user via a speaker, wherein the other user or care provider uses a microphone of the other user or care provider's device. Further, the user input may be directed to the respiratory distress ventilator itself, or another care provider, or both. Other users or care providers may be relatively close to the user, such as in an area or different portion of the care scene, etc., or may be remote from the user, such as at a remote interface, etc., which may include, for example, a doctor or other care provider at a hospital or medical facility. In some embodiments, for example, the microphone and speaker of the respiratory distress ventilator may allow a user to interact with or receive step-wise instructions from a doctor or other care provider in real-time with respect to emergency care to a patient, whether or not related to ventilation or other care.

Additionally, the set of tablet controls 4112 may include a display of integrated data related to the operation of the respiratory distress ventilator 4102 and other devices that may also be in use (e.g., CCM/defibrillator 4104, etc.). In some embodiments, the set of tablet controls 4112 may allow user interaction, including obtaining or displaying data, changing the settings of the respiratory distress ventilator 4102, accepting or confirming suggested or recommended setting changes, or viewing or responding to alarms, pre-warnings or messages, etc.

In the embodiment depicted in fig. 1, any, some, or all of the set of included controls 4144, the set of CCM/defibrillator controls 4134, or the set of tablet controls 4112 of the respiratory distress ventilator 4102 may have one or more respiratory aspects. Either or both of the set of CCM/defibrillator controls 4134 and the set of tablet controls 4112 may include remote controls related to the respiratory distress ventilator 4102, such as may relate to control aspects of the mechanical ventilation provided, and the like. Further, any of the sets of controls 4144, 4134, 4112 may include, for example, display/GUI aspects related to respiratory parameter data, respiratory conditions, or CSG. In some embodiments, the set of included controls 4144 of the respiratory distress ventilator 4102 may be limited, while the set of CCM/defibrillator controls 4134 and/or the set of tablet controls 4112 may be more comprehensive or otherwise.

Further, in some embodiments, the remote control may include or allow for relatively precise or complex aspects of mechanical ventilation operations or control, such as may include, for example, fiO ₂ CLC, PEEP CLC or oneCLC, etc. of one or more other ventilation parameters. Further, in some embodiments, respiratory distress ventilator 4102 may be configured to switch to or operate using internal control as a backup or default form of control, for example, upon detection of a failure mode condition. Examples of fault mode conditions are provided with reference to fig. 18-21. The respiratory distress ventilator 4102 may also be configured to detect when a failure mode condition no longer exists and then switch back to or operate using internal control. In various embodiments, respiratory distress ventilator 4102 may be remotely controlled by CCM/defibrillator 4104, tablet 4108, or one or more other devices or systems.

Fig. 2-7 illustrate additional example environments including respiratory distress ventilators and other devices, systems, or monitors, although many other possibilities and combinations may be used. In various example environments, in various implementations, any of the depicted apparatus, systems, or monitors may include controls having respiratory aspects, and may include remote controls related to respiratory distress ventilators. Further, in various implementations, the respiratory distress ventilator may have any one of a series of different sets of included controls ranging from no included controls to a large set of included controls, some examples of which are further described with reference to fig. 28A-28C. Still further, in various implementations, various sets of remote controls may or may not reflect, in whole or in part, aspects of any included controls of the respiratory distress ventilator. Additionally, in various implementations, roles or sensing capabilities may be variously included and distributed among devices, systems, monitors, or users.

Fig. 2 illustrates an example emergency care environment 200, the example emergency care environment 200 including a respiratory distress ventilator 202 having a respiratory distress ventilator display/GUI 226, a CCM/defibrillator 204 having a CCM defibrillator display/GUI 218, a tablet 206 (or other portable computing device) having a tablet display/GUI 220, and an offsite monitor system 214, which may include one or more server computers, having an offsite monitor system display/GUI 222. In various embodiments, all or some of the devices or systems 202, 204, 206, 214 may be wirelessly coupled via a wired connection and/or via one or more wireless networks 210, which may include the internet. For example, tablet 206 or other device may be coupled with remote monitor 214 as an aspect of a cloud 212-based computing system or network. A local user 216 is shown as well as an offsite user 218 at a remote offsite monitor system 214.

In the embodiment depicted in fig. 2, local user 216 (or more) interacting via display/GUI 220 of tablet 206, display/GUI 218 of CCM/defibrillator 204, and/or display/GUI 226 of respiratory distress ventilator 202 communicates with offsite user 218 (or more) interacting via display/GUI 222 of offsite monitor system 214. In some embodiments, more than one local user may be present and in communication with each other, and the various devices or systems 202, 204, 206, 214 may be in direct or indirect communication with each other and/or coordinated or integrated. Offsite user 218 may be, for example, a doctor, nurse, or other skilled clinician or care provider such as at or associated with a hospital or medical facility, group or entity. In various embodiments, the communication and integration between various ones of the devices or systems 202, 204, 206, 214 may include patient care related data in terms of respiration, with or without user interaction. This may, for example, allow offsite monitor system 214 and/or offsite user 218 interacting with offsite monitor system 214 and interacting via offsite monitor system 214 to determine a guide, instruction, or CSG and provide the guide, instruction, or CSG to local user 216 via local devices 202, 204, 206. Further, in some embodiments, any or some combination of CCM/defibrillator 204, tablet 206, and remote monitor system 214 may control when providing mechanical ventilation to patient 224 or participate in controlling aspects of the operation of respiratory distress ventilator 202 for certain times or periods of time, such as may include controlling one or more ventilation parameters, etc. This may be done with permission (such as if the user changes, sets, or overrides certain parameters, etc.), with or without user interaction or subject to user interaction.

In some embodiments, respiratory distress ventilator 202 may obtain and communicate patient respiratory parameter data to one or more of the other devices or systems 204, 206, 214 and/or may exchange data between various ones of the devices or systems 202, 204, 206, 214. One or more of the devices or systems 202, 204, 206, 214 may use the communicated patient respiratory parameter data to determine a patient respiratory condition (including associated data). The patient breathing parameter data and/or the breathing condition data may be used, for example, to determine CSG. However, in some embodiments, for example, respiratory distress ventilator 202 may determine or participate in the determination and may store patient respiratory parameter data and/or patient respiratory condition data, which may then be communicated to other devices or systems.

In the environment 200 depicted in fig. 2, in various embodiments, the respiratory distress ventilator 202 is capable of remote control through one or more of the CCM/defibrillator 204, tablet 206, and remote monitor system 214.

Fig. 3 illustrates an example emergency care environment 350 including a respiratory distress ventilator 352 and a tablet 354 having a tablet display/GUI 356, which tablet display/GUI 356 may include respiratory aspects (such as may include CSG, etc.) and be capable of remotely controlling the respiratory distress ventilator 352. In the embodiment depicted in FIG. 3, respiratory distress ventilator 352 includes a device for measuring a patient's SpO ₂ Pulse oximeter 360, useful for measuring EtCO ₂ And may include other sensing components for sensing other patient parameters. However, in some embodiments, for example, some or all of the sensing components may be included with or distributed among the tablet 354 and/or other devices.

Fig. 4-7 illustrate schematic diagrams of additional emergency care environments 460, 500, 600, 700, including devices or systems that may be communicatively coupled via wired or wireless connections, according to various embodiments. In particular, fig. 4 illustrates an environment 460, the environment 460 comprising: respiratory distress ventilator 462, a tablet 464 including a display/GUI 468 that may have a respiratory aspect or CSG, and an offsite monitor system 466 including a display/GUI 470 that may have a respiratory aspect or CSG. Fig. 5 illustrates an environment 480, the environment 480 comprising: the respiratory distress ventilator 482 and a CCM/defibrillator 484 containing a display/GUI 486 that may have a respiratory aspect or CSG. Fig. 6 illustrates an environment 600, the environment 600 comprising: a respiratory distress ventilator 602, a CCM/defibrillator 604 including a display/GUI 606 that may have a respiratory aspect or CSG, and an offsite monitor system 608 including a display/GUI 610 that may have a respiratory aspect or CSG.

The various embodiments described in fig. 1-7 may provide various advantages. In some embodiments, the respiratory distress ventilator may be used with a CCM/defibrillator, as shown, for example, in fig. 1-2 (which also includes a tablet or other portable computing device) and fig. 5-6 (which do not include a tablet or other portable computing device). In some implementations, the respiratory distress ventilator may be used in some aspects as or to function as a co-treatment device for a CCM/defibrillator. For example, a CCM/defibrillator may provide sensing or patient parameter sensing capabilities such as oximetry, capnography, blood pressure monitoring, and/or other sensing capabilities, and the like. Additionally, CCMs/defibrillators (or in some embodiments, tablet computers, or both) can play an important role in providing display/GUI features (which can include CSG). As such, in various implementations including CCM/defibrillators, the respiratory distress ventilator may include or provide more limited sensing capabilities, or display/GUI or CSG capabilities. As such, in some implementations, the respiratory distress ventilator may be simpler, smaller, lighter, and/or more easily, quickly, or conveniently portable, and/or its functions, hardware, and software may be less or simpler. For example, in some implementations, a care provider with a respiratory distress ventilator may reach a patient site where a different care provider (or providers) has (at least) provided care with a CCM/defibrillator that the respiratory distress ventilator is capable of integrating, thereby providing respiratory monitoring and ventilation capabilities even after at least the use of the CCM/defibrillator initiates care and sensing. Alternatively, a care provider with a respiratory distress ventilator may arrive at the patient's site first, and one or more other devices may arrive and integrate later.

In some embodiments, the respiratory distress ventilator may be used with a tablet computer or other portable computing device, as shown, for example, in fig. 1-2 (also including a CCM/defibrillator) and fig. 3-4 (not including a CCM/defibrillator). In some implementations, a tablet or other portable computing device may be used as a device with an integrated and comprehensive display/GUI. As such, in some implementations, the respiratory distress ventilator may include fewer display/GUI and/or CSG features and/or associated hardware or software, as a tablet or other portable computing device may provide or to some extent provide these features. In some embodiments, this may allow the respiratory distress ventilator to be simpler, smaller, lighter, and/or easier, faster, or more convenient to carry.

In some embodiments, such as shown in fig. 2, 4, and 6, etc., may include a remote offsite care provider and/or an offsite computer system. In some implementations, the offsite care provider (and/or computer system) may provide additional support (computing or manual) or expertise beyond that available locally. For example, in some embodiments, a more trained care provider or medical professional (such as a medically trained person, nurse, or doctor, etc.) may provide CSG, support, instruction, and/or even step-by-step instructions via a remote interface (and potentially utilizing offsite computing system capabilities including hardware and software), such as may be delivered to a user of the respiratory distress ventilator, for example, via a display/GUI and potential speakers of a tablet, CCM/defibrillator, or respiratory distress ventilator, etc., wherein the user of the respiratory distress ventilator may interact via a display/GUI and/or potential microphones of one of the local devices.

In some implementations, additional or enhanced care may be provided by integrating roles of off-site care providers and/or off-site computing systems, which may include additional interaction and care enhancements or capabilities. Further, in some embodiments, a camera and display at the site of the respiratory distress ventilator or the user of the respiratory distress ventilator may additionally enhance this interaction and care capability, where the user of the respiratory distress ventilator potentially accepts step-by-step instructions from an offsite care provider who may also use the camera and microphone to provide video and audio feeds to the user. The offsite care provider may be notified in part by communicated real-time video and audio data, feeds or streams, which may include views and/or sounds of the patient and the user of the respiratory distress ventilator (and/or one or more other local care providers and/or devices). In some embodiments, this may include, for example, 3D video or augmented reality presentation to either or both of the user of the respiratory distress ventilator or portable ventilator and the point-of-care provider. For example, in some embodiments, either or both may use or wear one or more augmented or augmented reality devices in this regard, such as watches, head-mounted or body-worn devices, etc. with video and audio capabilities. In various embodiments, this may provide hands-free use, or may even include motion or other sensors to track and display movement of the user and/or the off-site care provider.

In some embodiments including a respiratory distress ventilator, such as shown in fig. 3 (including a tablet or other portable computing device but not including an offsite monitor system) and fig. 4 (including a tablet or other portable computing device and an offsite monitor system), a CCM/defibrillator may not be included, and in some embodiments, a respiratory distress ventilator may be used without a CCM/defibrillator, tablet or portable computing device or remote monitor system. In some embodiments, by not including a CCM/defibrillator, the overall system for monitoring and treating a patient may be more compact, simpler, smaller, lighter, and/or easier, faster, or more convenient to carry. However, in many embodiments and implementations, the flexible, integrated, fast-adapting nature of the system may allow for changes to the devices or systems that are included or excluded, while still maintaining optimal patient care with currently available devices and systems. This may include, for example: such as when a device or system (or user) is removed (or otherwise unavailable) or added (or otherwise available) to the overall system, etc., functions or roles provided by the remaining devices or systems (or users) that are currently available are added, removed, or transferred.

Fig. 7 illustrates an example emergency care environment 700 that includes a respiratory distress ventilator 730, a defibrillator/critical care monitor 708, and one or more companion devices such as a companion tablet 719. In the depicted embodiment, respiratory distress ventilator 730 has a limited set of included controls 732 (physical, display/GUI based, or both). However, the tablet 719 has a display/GUI 734 that includes a comprehensive set of remote controls associated with the respiratory distress ventilator 730 and its operation, which display/GUI 734 may include respiratory aspects or CSG.

In some embodiments, sensor data obtained by one or more sensors (e.g., 722, 726) associated with one or more of the devices 708, 719, 730 may be transmitted to a companion device (e.g., tablet 719) for display within one or more user interface views. For example, the companion device 719 (or one or more other devices of the devices 732, 708) may, for example, display some or all of the following, etc.: ECG and defibrillator shock data, airway pressure (Paw), plateau pressure (Pput), peak Inspiratory Pressure (PIP), spO ₂ 、FiO ₂ PEEP, FVC, FEV1, PEF/PEFR, rrs, crs, tidal volume of inhaled and exhaled, ve, etCO ₂ Amount of expired carbon dioxide (VCO) ₂ ) Breath count per minute (BPM) and Heart Rate (HR).

Additionally, the tablet 719 may transmit instructions or command signals to the respective medical treatment devices 708, 730. The transmitted instruction signals may provide information, initiate one or more functional operations, or set or change an operating parameter or mode of the respective medical treatment device 708, 730.

In some implementations, patient treatment information and/or other data (such as caregiver performance data, respiratory parameter data, or patient respiratory condition data, etc.) associated with the two medical treatment devices 708, 730 (and potentially others) may be displayed at the companion device 719. In some examples, main tube 718 may monitor patient treatment information received from defibrillator 708 and respiratory distress ventilator 730 at companion device 719. In some examples, patient treatment information may be displayed within one or more selectable views at the companion device 719 or within a single user interface view. Additionally, in some embodiments, the user interface view at the companion device 719 may include user inputs that enable the host 718 to transmit instruction signals to provide data or to issue commands to control one or more functional operations of the medical treatment devices 708, 730. In some embodiments, providing the ability for a single caregiver to view case information from multiple medical treatment devices 708, 730 provides a technical solution to clinical problems, as the caregivers and/or supervisors using the companion device 719 may provide enhanced guidance and support to the other rescuers 704, 706. Furthermore, in certain emergency care situations where patient access or rescuer is limited, the ability to monitor case information from multiple medical treatment devices 708, 730 simultaneously and transmit instruction signals to control the operation of the medical treatment devices 708, 730 is provided to a single caregiver, which enables the patient to receive advanced medical care in a remote or non-traditional care environment. However, some embodiments include various roles for various users.

In some embodiments, a local wireless communication channel may be established between two or more devices at the emergency care site 700 to enable safe and accurate sharing of data between the devices and the system. For example, health data related to the patient 702, data indicative of treatment delivered to the patient 702, or other types of data may be exchanged over a wireless communication channel that potentially includes one or more remote offsite systems 715. This may help coordinate or integrate the treatment of multiple rescuers in an efficient and accurate manner. In some examples, a wired and/or wireless communication channel is established only between some of the devices involved in the treatment of patient 702 (e.g., between two of these devices). In some examples, a wireless communication channel is established between all devices involved in the treatment of the patient.

Fig. 8 illustrates an example modular system 750 according to some embodiments, the modular system 750 including a respiratory distress ventilator 752, a CCM/defibrillator 754 (shown from two different angles), and a tablet 756 or other portable computing device. Such a system may provide various advantages. For example, in some implementations, users with different devices may arrive at a patient scene at different times. A modular system such as the modular system depicted in fig. 8 may allow for advantages such as faster or staged setup or operation of the device and/or multiple aspect integration. Not only can this save time, but the efficiency and operation of the overall system can be optimized, which may be critical or life-saving in emergency care scenarios.

In various embodiments, one or more of the depicted devices 752, 754, 756 may not be included in the modular system 750, or any of a variety of other devices may be included, such as one or more medical devices, monitoring devices, or portable computing devices, among others. In some embodiments, two or more devices in a local environment (such as any or all of the depicted devices 752, 754, 756, and/or other devices that may be included, etc.) may be adapted for and capable of being engaged or attached (fixedly or movably). For example, one or more devices can be engaged with or attached to and disengaged from one or more other devices. In some embodiments, one device (or one of several different devices) may be used as a device to which several other devices may be engaged or attached. Further, in some embodiments, one or more docking stations or docks may be included, where a plurality of devices (e.g., some or all of devices 752, 754, 756, or other devices) may each dock to the one or more docking stations or docks (which may include engaging or attaching to the docking station or dock). Still further, for example, a docking station or dock may be included in which multiple devices may be connected to the docking station or dock via a wired or wireless connection (such as via a wired connection using one or more insert cables, etc.) without being engaged or attached to the docking station or dock.

In various embodiments, any or each of these devices, as well as any included docking station or dock, may include physical, mechanical, or electrical components that may facilitate engagement, attachment, or docking, and may facilitate electrical connection, communication, and/or power. Such powering may include partial, optional, or selective powering as well as powering via wired or wireless connections, such as between devices, between docking devices, or between a docking station or dock and one or more docking devices, etc. Still further, in various embodiments, the engagement, attachment, or docking apparatus may be configured to operatively communicate, authenticate, coordinate, or integrate automatically, potentially including aspects related to display aspects (which may include CSG), sensing capabilities, processing, software, and power, etc., which may be enabled or facilitated by engagement, attachment, or docking.

In the illustrated embodiment, the CCM/defibrillator 754 includes a physical or mechanical coupling component such as a guide or attachment rail 758 or the like through which the respiratory distress ventilator 752 and the tablet 756 may be coupled (e.g., by sliding into the rail or otherwise, etc.). Although not shown, in some embodiments, the respiratory distress ventilator 752, CCM/defibrillator 754, and/or tablet 756, for example, may also have one or more components to facilitate engagement or attachment, such as complementary guide or attachment slots, and the like. However, any of a variety of engagement or attachment designs, assemblies, mechanisms, or methods may be used in various embodiments. While CCM/defibrillator 754 is used as the device to which other devices 752, 756 are engaged or attached in the illustrated embodiment, in other embodiments either of respiratory distress ventilator 752 or tablet 756 or other portable computing device, or another device may be used as the role, and/or a docking station or docking station may be used.

As described with reference to fig. 1-7, in various implementations, the respiratory distress ventilator 752 can be remotely controlled by one or more other devices, such as a CCM/defibrillator 754 or tablet 756, etc. In addition, some or each of the respiratory distress ventilator 752, CCM/defibrillator 754 and tablet 756 may include a display/GUI including a respiratory aspect or CCM.

Fig. 9 depicts an example environment 800 for customizing the display of case information at, for example, a companion device (e.g., a tablet or other portable computing device depicted in fig. 1-8), including a medical treatment system having a set of devices for providing treatment to a patient during a medical event. The environment 800 may include one or more medical treatment devices 802 (e.g., a respiratory distress ventilator or CCM/defibrillator or otherwise as depicted in fig. 1-8), and one or more companion devices 804 communicatively coupled to the medical treatment devices 802 via a communication link 806. In some embodiments, the companion device 804 or another device can remotely control the respiratory distress ventilator. In the illustrated example, the devices 802, 804 of the medical treatment system may be co-located at a treatment delivery site (such as a hospital, medical clinic, or ambulance, etc.). In other implementations, one or more of the companion devices 804 may be added to the system at some point during the delivery of the medical treatment or after the delivery of the treatment. Conversely, at least one companion device 804 may be removed from the common location during or after delivery of the therapy. These devices may be configured for data communication in a wired or wireless manner to communicate information between certain devices 802, 804 of the system during and/or after delivery of the therapy.

In some implementations, the wireless communication link 806 used to connect the medical treatment device 802 and the companion device 804 may be a Wi-Fi network, other short-range wireless communication network, or Near Field Communication (NFC) network, a Local Area Network (LAN), a Wide Area Network (WAN), or the internet in some examples. In other examples, the devices 802, 804 may be configured to communicate over a longer communication range, such as over a cellular communication network. In some implementations, the medical treatment device 802 may function as a wireless access point to provide a direct wireless connection with the companion device 804. In other examples, wireless communication link 806 may be provided via a bluetooth personal area network.

In some embodiments, different devices 802, 804 may be configured to communicate with each other over different types of communication links 806. In some implementations, the devices 802, 804 may be configured to transmit data to a receiver via a short-range wireless communication transmitter (e.g., a bluetooth beacon). In one example, the first companion device 804 may communicate with the medical treatment device 802 via a Wi-Fi communication link, while the second companion device 804 may communicate with the medical treatment device via a bluetooth communication link. In some implementations, companion device 804 may connect to medical treatment device 802 via a wireless communication link without having to physically access medical treatment device 802 or interact with medical treatment device 802. In some examples, transport Layer Security (TLS) is used at the application layer to provide a secure (encrypted) connection between the devices 802, 804. As a second layer protection, encrypted Wi-Fi or encrypted bluetooth may be used at the physical layer.

In some implementations, when the wireless communication link 806 is a cellular communication link, the functionality of the medical treatment device 802 may be extended to clinicians that are off-site and/or are conducting telemedicine. For example, when the EMS is transporting a patient to a hospital in an ambulance, a medical team waiting for the patient to arrive at the hospital may stream real-time case information at the hospital's companion device 804 via a cellular link. In some examples, the wireless communication link 806 may include a combination of multiple wireless communication networks based on the proximity of the medical treatment device 802 to the companion device 804.

In some implementations, the medical treatment device 802 and the companion device 804 each include a respective wireless communication engine 824, 836 for enabling wireless communication between the devices 802, 804 via the wireless communication link 806. For example, the wireless communication engine 824 of the medical treatment device 802 may be configured to transmit the message generated by the message configuration engine 820 to the companion device 804. The wireless communication engine 836 of the companion device 804 may be configured to transmit instruction signals generated by the signal generation engine 830, which may be used to control one or more functional operations of the medical treatment device 802 for some examples. In some examples, the wireless communication engines 824, 836 are configured to apply an encryption protocol to outgoing signals transmitted to the other devices 804, 802. Similarly, the wireless communication engines 824, 836 may decrypt incoming signals from other devices 804, 802.

In some embodiments, the wireless communication engine 824 of the medical treatment device 802 may be configured to detect that the respective companion device 804 is within communication range, and in response, initiate one or more actions to connect to the companion device 804 via the wireless communication link 806. In some implementations, a companion device 804 that can be paired with a medical treatment device 802 can be preconfigured to automatically connect to the medical treatment device 802 via a wireless communication link 806 when within range without having to distinguish between other devices that happen to be within range and/or negotiate a wireless communication connection. Moreover, rather than requiring the user to spend a significant amount of time manually configuring the system of each companion device 804 to connect to the medical treatment device 802 or to access the frames to be viewed and then select from among the possible device connections, the companion devices 804 located at the emergency scene may be preconfigured (e.g., automatically and/or with one or more simple actions (e.g., switch actuation, push buttons, near field communication connections, radio frequency, location/proximity identification, gesture codes, flick/bump identification, motion activation, sound/vibration, voice command/identification, etc.) and/or dynamically joined and/or joined with the medical treatment device 802 by merely physically approaching each other, such as through a bluetooth proximity connection, etc.). In some examples, the companion device 804 may be preconfigured for pairing with other medical treatment devices, and these preconfigured networks may also be displayed when icons are selected on the display.

Once such a connection is made via the wireless communication link 806, patient information (e.g., physiological data, patient history, rescue information) may be sent back and forth between the connected devices 802, 804 in a reliable and secure manner (e.g., according to the HIPAA standard, 802.11i protocol) using any suitable type of communication, despite the presence of many other devices located nearby. The companion device 804, which is properly paired with the corresponding medical treatment device 802, can help avoid the risk of transmitting false patient information between medical devices that may be detrimental to patient prognosis. In some embodiments, to maintain accurate and secure communications, proximity-based interactions may invoke authentication protocols (such as using encryption keys, vector initialization, hash encryption, digital certificates, etc.) to ensure that data transfers between devices are not discarded and/or compromised. In addition, the wireless communication engine 824 of the medical treatment device 802 may be configured to simultaneously cause data to be streamed in real-time to multiple companion devices 804 via separate wireless communication links 806 for each companion device 804.

In some implementations, many additional security-oriented design aspects may also be implemented for the medical treatment system to ensure that data exchanged between the medical treatment device 802 and the companion device 804 remains secure. For example, the medical treatment device 802 and/or the companion device 804 may use certificate-based authentication to ensure the authenticity of the respective companion device. In some examples, upon initial connection and setup, the device 804 may perform association processing to bind a particular companion device 804 to a single medical treatment device 802 such that only the companion device 804 (and any other similarly paired companion devices) may interoperate with the medical treatment device 802. In some embodiments, any representational state transfer (REST) or WebSocket communication may require an authenticated connection to enable data exchange between the devices 802, 804. In some examples, the medical treatment device 802 disables connections to open Wi-Fi communication links and may connect only to manually defined (e.g., supervisor defined) Wi-Fi networks. As an additional security measure, when the wireless communication link 806 is a bluetooth connection, in the case of configuring an initial connection setting, the devices pair during the initial setting. Furthermore, the data and computer architecture of the medical treatment device 802 may be designed for additional security, which may include separating communications and clinical control onto separate microprocessors.

In some examples, when there is more than one companion device 804 paired with the medical treatment device 802, one of the companion devices 804 may be pre-designated as the master companion device. The master companion device may be so designated by the medical treatment device 802 during device setup, pairing, and configuration by receiving and storing an encrypted token from the medical treatment device 802. The encrypted token may be sent to the medical treatment device 802 with each instruction from the master companion device 804.

In some implementations, the companion device 804 may display the status information of the medical treatment device 802 at one or more of the display views of the companion device 804. For example, the device view may include a status bar that displays the battery life amount, connection status, and unique name of the medical treatment device 802. Additionally, in some examples, the status bar may include a verification input that enables the companion device 804 to cause an indicator to flash at the medical treatment device 802 to confirm that the companion device 804 is connected to the correct medical treatment device 802 when in use. For example, one or more display views of the companion device 804 may include a companion device verification input that enables a companion device user to verify to which medical treatment device 802 the companion device 804 is connected. In some examples where multiple medical events are occurring simultaneously (such as in a hospital's wound ward or in a scene of group injury, etc.), multiple rescue teams may operate multiple medical treatment devices within proximity of each other. In these cases, the companion device paired with the corresponding medical treatment device may be easily confused. Thus, in some implementations, when the verification input is selected, the companion device 804 may generate an instruction signal that causes the connected medical treatment device 802 to generate an indication to pair with the companion device 804. In some implementations, upon receiving the verification signal from the companion device 804, the medical treatment device 802 may output a visual and/or audible indication of the connection to the companion device 804. In some examples, the indication may be a flashing light and/or a tonal sound pulse.

Fig. 10 illustrates an example respiratory distress ventilator 902 that is capable of providing ventilation and potentially other interventions or treatments to a patient 906, according to some embodiments. The respiratory distress ventilator 902 includes a mechanical ventilator 908 and at least one controller 918. The controller 918 includes at least one processor 920 and at least one memory 916 for storing data, and may also include software that may be stored in the at least one memory 916, such as may include a Ventilation Control Director (VCD) 922 (various examples of which are described, for example, with reference to fig. 11-25) or may include aspects of the Ventilation Control Director (VCD) 922, and the like. The respiratory distress ventilator 902 may include or be connected to an oxygen source 904.

In some embodiments, respiratory distress ventilator 902 is capable of sensing signals representative of the flow of gas that may be used to determine at least one patient respiratory parameter, such as the use of one or more pressure sensors 914, flow sensors, pneumotachs or pneumometers (which may be included as part of mechanical ventilator 908, within mechanical ventilator 908 or partially within mechanical ventilator 908, or may be separate but coupled by wired or wireless connection communication, in some embodiments), and the like. In various embodiments, one or more spirometers may be included within respiratory distress ventilator 902 and/or may be coupled (physically and/or communicatively via a wired or wireless connection) to respiratory distress ventilator 902. Although depicted in a separate block from patient circuit 913, it will be appreciated that pressure sensor 914 and/or other components such as a flow sensor, a pneumotach, or a pneumometer, etc. may be included within patient circuit 913 (such as a patient inhalation circuit and/or a patient exhalation circuit, etc.) or partially within patient circuit 913. In some embodiments, pressure sensor(s) 914 and other associated components may be used to sense or obtain breathing parameter data that may be used to determine or generate a breathing condition (which may include associated data). The breathing parameter data and the breathing condition data may also be used in conjunction with control of the operation of the respiratory distress ventilator 902 (such as in the control of mechanical ventilation provided by the respiratory distress ventilator 902, etc.), whether such control is provided internally by the respiratory distress ventilator 902, remotely, or both. Furthermore, in some embodiments, the breathing parameter data and the breathing conditions may be used to determine or generate a CSG (examples of which are further described with reference to, for example, fig. 30-35).

Fig. 11 illustrates an example of an emergency care setting 1000 according to some embodiments. The arrangement 1000 includes a respiratory distress ventilator 1002 for providing mechanical ventilation to a patient 1012. The respiratory distress ventilator 1002 may be controlled by a remote control source 1022 (including in relation to providing mechanical ventilation). Remote control source 1022 has a control set 1014 that includes remote controls for remotely controlling respiratory distress ventilator 1002. Respiratory distress ventilator 1002 may have an included set of controls 1010 that are more limited in some embodiments than remote controls 1014 of remote control source 1022. In the implementation depicted in fig. 11, the set of included controls 1010 of the respiratory distress ventilator includes a power switch and/or indicator 1032 and a communication (or remote control in some embodiments) indicator 1030, which communication indicator 1030 may indicate whether there is currently communication between the respiratory distress ventilator 1002 and the remote control source 1022 (or whether the respiratory distress ventilator 1002 is currently controlled by the remote control source 1022). Some examples of different sets of included controls for a respiratory distress ventilator are described with reference to, for example, fig. 28A-28C.

As depicted, respiratory distress ventilator 1002 may be remotely controlled by remote control source 1022 via remote control signals 1020, which remote control signals 1020 may include request/command signals, communicated by remote control source 1022 to respiratory distress ventilator 1002 via wired and/or wireless communications (whether directly or via one or more intermediate entities). Remote control signal 1020 is received by respiratory distress ventilator controller 1006. The respiratory distress ventilator controller 1006 then internally transmits a control signal 1020 such that the respiratory distress ventilator mechanical ventilation system 1004 is controlled in accordance with the remote control signal 1020. In particular, in the depicted embodiment, a software-based Ventilation Control Director (VCD) 1008 is used to effect control of the mechanical ventilation system 1004 in accordance with a remote control signal 1020.

As depicted, remote control source display/GUI 1014 includes CSG 1018, which CSG 1018 may be user interactive and may be used in connection with the operation of respiratory distress ventilator 1002. Further description of examples of CSG are described with reference to fig. 30-35. In some embodiments, respiratory parameter data obtained by respiratory distress ventilator 1002 is sent to remote control source 1022 and used to assess or determine the respiratory condition of the patient and determine the CSG.

In the depicted embodiment, the control by the remote control source 1022 includes a CLC 1024 of any of various types related to ventilation provided (examples of which are described with reference to fig. 29). In various embodiments, sensor data used in the CLC may be acquired by the remote control source 1022 from various different combinations of one or more devices or systems included in the environment 1000 (locally or offsite). In fig. 11 and the various other figures, CLC 1024 may or may not be depicted, but in various implementations and embodiments CLC 1024 may or may not be included, or CLC 1024 may be implemented by any of the various depicted devices.

Fig. 12 illustrates an example of signaling 1100 of a VCD 1110 (detailed examples of which are described with reference to, for example, fig. 13-16) incorporating a respiratory distress ventilator utilizing failure mode condition analysis 1116, in accordance with some embodiments. As depicted in fig. 12, signaling 1100 includes communication signaling 1102, data integrity signaling 1104, ventilation setting signaling 1106, and patient physiological signaling 1108. However, in various embodiments, other types or categories of signaling may be included.

Communication signaling 1102 may relate to, for example, the communication between the respiratory distress ventilator and a remote control source or the presence/existence, degree, or speed of the communication. Communication signaling 1102 may also include data used by the VCD to determine whether the remote source is authorized or properly configured for remote control of the respiratory distress ventilator. Communication signaling 1104 may be sent, for example, by a remote control source and may or may not be sent in response to a request or other communication received by the respiratory distress ventilator.

The data integrity signaling 1104 may relate to, for example, the integrity of data, such as control data, received by the respiratory distress ventilator from a remote control source (either directly or via one or more intermediate entities), for example, whether the data is uncorrupted, valid, correctly formatted, correctly bordered, or correctly structured, etc. The data integrity signaling 1104 may be sent, for example, by a remote control source and may or may not be sent in response to requests/commands or other communications received by the respiratory distress ventilator.

The ventilation setting signaling 1106 may, for example, relate to particular ventilation parameter settings related to aspects of mechanical ventilation provided to the patient. The ventilation setting signaling 1106 may be sent, for example, by a remote control source, such as in association with one or more requests, etc., and may or may not be sent in response to requests/commands or other communications received by the respiratory distress ventilator.

The patient physiological signaling 1108 may, for example, relate to a patient physiological parameter sensed by a sensing aspect of the device or system, which may include respiratory parameter signals as well as other patient physiological parameter signals. Patient physiological signaling 1108 may or may not be sent in response to a request or other communication received by the respiratory distress ventilator. Further, in various environments and implementations, various types of patient physiological signaling may be sent by or obtained from one or more devices, systems, or components in the environment (e.g., CCM/defibrillators, tablet computers, other devices, or respiratory distress ventilators, etc. (some or any of these devices may include various patient parameter sensing capabilities in various embodiments)).

Signaling 1102, 1104, 1106, 1108 is received by VCD 1110. VCD 1110 performs failure mode condition analysis 1116 based at least in part on at least some of received signaling 1102, 1104, 1106, 1108. The VCD 1110 sends ventilation control signaling 1112 to a mechanical ventilation system 1114 (or device) of the respiratory distress ventilator based at least in part on the conducted failure mode condition analysis 1116.

Fig. 13 illustrates a method 1200 relating to failure mode condition analysis implemented by a VCD 1202 of a respiratory distress ventilator, in accordance with some embodiments. VCD 1202 uses fault mode condition analysis software 1204 in conjunction with signaling to perform fault mode condition analysis 1212, such as may include signaling 1102, 1104, 1106, 1108, etc. described with reference to fig. 12.

In step 1206, the vcd 1202 queries whether a failure mode condition is detected based on the failure mode condition analysis 1212. If a failure mode condition is not detected, VCD 1202 internally sends a ventilation control signal to the mechanical ventilator of the respiratory distress ventilator in accordance with the remote control source request/command, as shown in block 1208.

However, if VCD 1202 does detect a failure mode condition, VCD 1202 internally controls the mechanical ventilation of the respiratory distress ventilator, such as based on one or more of a standby, default, current in use, last or last received valid set-up values, or set-up values determined based on an adjustment to at least one requested or received set-up value, etc.

Fig. 14 and 15 illustrate examples of emergency care environments 1300, 1400 including VCDs of a respiratory distress ventilator controller that allow for control of respiratory distress ventilator mechanical ventilation by a remote control source, according to some embodiments. Fig. 14 and 15, for example, illustrate conditions of respective times that may exist in two different times.

In the environment 4200 depicted in fig. 14, at a first current time, the remote control source 4202 transmits a remote control signal 4206 to be received by the VCD 4212 of the respiratory distress ventilator controller 4210. At the current time, the VCD 4212 detects the absence of a failure mode condition, as indicated in block 4208. Thus, as conceptually indicated by dashed line 4214, VCD 4212 allows control of mechanical ventilation system 4218 of respiratory distress ventilator 4204 by remote control source 4202 in accordance with received remote control signal 4206 via internal signaling 4216 from respiratory distress ventilator controller 4210 to mechanical ventilation system 4218 of respiratory distress ventilator 4204 in accordance with received remote control signal 4206. The display/GUI 4220 of the remote control source 4202 may include breathing aspects and be used to provide CSG 4222.

In the environment 1400 shown in fig. 15, at a second current time, remote control source 4202 transmits remote control signal 1404 to be received by VCD 4212 of respiratory distress ventilator controller 4210. At a second time, the VCD 4212 detects that a failure mode condition (or more than one) does exist, as indicated in block 1402. Thus, as shown by the forked dashed line 1406, the VCD 4212 does not allow for control of the mechanical ventilation system 4218 of the respiratory distress ventilator 4204 by the remote control source 4202 in accordance with the received remote control signal 1404. Instead, VCD 4212 controls mechanical ventilation system 4218 of respiratory distress ventilator 4204, such as based on one or more of the alternate, default, current in use, last or last received valid settings, or settings determined based on adjustments to the requested or received settings, etc., via internal signaling 1408 from respiratory distress ventilator controller 4210 to mechanical ventilation system 4218 of respiratory distress ventilator 4204 according to control determined by VCD 4212.

Fig. 16 illustrates an example of an emergency care setting 1500 according to some embodiments, which provides one example of the setting 1400 shown in fig. 15. As shown in block 1502, at the current time, VCD 4212 detects the presence of a particular type of failure mode condition, i.e., no communication or communication capability is detected between remote control source 4202 and respiratory distress ventilator controller 4210. As conceptually indicated by fold line 1506, communication between remote control source 4202 and the respiratory distress ventilator controller is currently cut off or not present. As such, as conceptually indicated by the broken line with forks 1504, the VCD 4212 does not receive control signals from a remote control source and allows control accordingly. Instead, VCD 4210 controls mechanical ventilation system 4218 of respiratory distress ventilator 4204, such as based on one or more of the alternate, default, current in use, last or last received valid settings, or settings determined based on adjustments to the requested or received settings, etc., via internal signaling 1408 from respiratory distress ventilator controller 4210 to mechanical ventilation system 4218 of the respiratory distress ventilator according to control determined by VCD 4212.

Fig. 17 illustrates an example of an emergency care setting 1900 according to some embodiments that includes remotely controlling a respiratory distress ventilator 1902 via an offsite cloud-based monitor 1912 at an offsite location 1906, via a remote control signal 1904 sent from the offsite monitor system 1912 to a VCD 1916 of a respiratory distress ventilator controller 1914, and that includes one or more forms of CLC 1918. In the depicted implementation, both local user/care provider 1908 and offsite user/care provider 1910 are shown. In various embodiments, a local remote control of respiratory distress ventilator 1902 may be included or alternatively included or may not be included or alternatively not be included.

Fig. 17A and 17B illustrate an example of a non-hospital emergency care environment 1950, such as a field environment, that includes a respiratory distress ventilator 1952 and a plurality of other devices 1956-1964. Such an environment may be more spontaneous, less planned, less static, less stable, less preconfigured and less structured in various ways relative to a typical hospital environment, generally due to its nature and necessity. In some embodiments, the respiratory distress ventilator, while capable of efficient operation in a hospital or similar environment, is also capable of efficient operation in a variety of non-hospital emergency care environments. In a non-hospital emergency environment, there may be many devices and operators whose detailed information may not be entirely pre-planned. In addition, devices (including respiratory distress ventilator 1952) and operators may arrive and depart at different times (which may not also be entirely pre-planned), and some devices may experience frequent movement or physical instability. Some of the devices 1956-1964 can be operatively integrated with the respiratory distress ventilator 1952, which in some examples can include a device that can remotely control the mechanical ventilation provided to the patient 1951 by the respiratory distress ventilator 1952. Devices 1956 through 1964 may include, for example, other medical devices such as CCMs or defibrillators that may be operatively integrated with respiratory distress ventilator 1952. For example, such integration may include coupling with patient 1951 to obtain and provide patient parameter signaling. Such integration may also include providing a display, GUI, and/or control that may be integrated with or include aspects related to the operation of respiratory distress ventilator 1952 (examples of which are described, for example, with reference to fig. 1-7). In addition, some of the devices 1956-1964 are capable of remotely controlling the respiratory distress ventilator 1952, while some devices may not be capable of remotely controlling the respiratory distress ventilator 1952. The various communications and signaling (including wireless signaling) within the non-hospital emergency care environment 1950 may include signaling that is not related to the operation of the respiratory distress ventilator 1952 or even not related to patient care. Furthermore, communications in non-hospital emergency care environment 1950, such as through one or more wireless networks, may be non-uniform and potentially subject to frequent disruption and re-establishment. In some embodiments, respiratory distress ventilator 1952 is configured for efficient, effective, and safe operation even in non-hospital environments that may include the aforementioned challenges. In some embodiments, software related to such operation may be stored in a memory of a controller of respiratory distress ventilator 1952 including a Ventilation Control Director (VCD) (examples of which are described with reference to fig. 11-25).

In some embodiments, VCD 1980 may include software implementation rules or procedures for detecting and identifying other devices, for determining required authorizations and required configurations of other devices, and for operative integration with other devices. The VCD 1980 may also include or otherwise have access to stored information for use in these aspects. In some embodiments, VCD 1980 may detect changes over time of the current device or operator, and respiratory distress ventilator 1952 may be operatively integrated with one or more appropriate devices, which in some cases may include remote control by a particular device. The VCD 1980 may also include software implementation rules or procedures for making device selection for remote control between a plurality of properly authorized and properly configured devices, or for switching between different remote control devices, as appropriate. VCD 1980 may also include software implemented rules or procedures that take into account certain identified communication-related conditions or patterns (such as may include short or long loss of communication, etc.). In some embodiments, one or more other devices themselves may also include software and stored information for integration with the communication and operation of respiratory distress ventilator 1952.

As depicted in fig. 17A, at a non-hospital emergency care environment 1950, a respiratory distress ventilator operator 1954 operates a respiratory distress ventilator 1952 to provide treatment to a patient 1951, which may include delivering mechanical ventilation to the patient 1951. The emergency care environment 1950 may include a number of potentially different devices, shown as other devices 1956-1964, in addition to the respiratory distress ventilator 1952. Other devices 1956-1964 may include, for example, portable devices, medical or treatment devices, computers and computerized devices, hand held devices such as tablets and smartphones, and others. Some or all of the other devices 1956-1964 may be operated by one or more operators, indicated as operators 1968-1976, while some may be operated at some or all times without an operator or automatically. The devices 1952, 1956-1964 and operators 1954, 1968-1976 in the environment 1950 may arrive and leave at different times such that the devices and operators present in the environment 1950 may change over time.

In various examples, one or more of the other devices 1956-1964 can be operatively integrated with the respiratory distress ventilator 1952, and potentially with each other as well. For example, other devices 1956-1964 may include CCMs, defibrillators, and/or tablet computers, which may be operatively integrated with respiratory distress ventilator 1952 (various examples of which are described with reference to fig. 1-7). However, other devices 1956 through 1964 may also include devices that cannot be operatively integrated with the respiratory distress ventilator 1952. In some examples, a device operatively integrated with respiratory distress ventilator 1952 may be coupled with patient 1951 and/or may include a sensor or other component for collecting signals from patient 1951 that may be indicative of a patient physiological parameter (some examples of which are described with reference to fig. 1-7). Although not depicted in fig. 17A and 17B, devices or sources other than respiratory distress ventilator 1952 may include one or more offsite devices or sources capable of being operatively integrated with respiratory distress ventilator 1952 (examples of which are described with reference to fig. 2, 4, and 6). In some cases, this operational integration may include remote control of respiratory distress ventilator 1952.

Respiratory distress ventilator 1952 includes a VCD 1980, examples of which are described, for example, in the summary section and with reference to fig. 10-25. In the example depicted in fig. 17A and 17B, VCD 1980 is implemented as software stored in a memory including respiratory distress ventilator 1952.

The various devices in respiratory distress ventilator 1952 and other devices 1956-1964 may include controls for their operators (examples of controls for the various devices are described with reference to fig. 28A-28C and 33-35). The respiratory distress ventilator 1952 is capable of wired and/or wireless bi-directional communication with some or all of the other devices 1956-1964 via wired or wireless connections, and the various devices of the other devices 1956-1964 are capable of wired and/or wireless bi-directional communication with each other.

In some embodiments, one or more of the other devices 1956-1964 are capable of remotely controlling the mechanical ventilation provided to the patient 1951 by the respiratory distress ventilator 1952, such as may include control via input (such as may involve setting related commands, etc.), such as selection or typing via device controls, etc. by individual operators of the devices or in some cases or at some times automatically by the devices, etc.

In some embodiments, in instances where remote control is established with a particular remote control device, the VCD 1980 may manage and implement control of mechanical ventilation by the respiratory distress ventilator 1952 (examples of which are described with reference to fig. 12-25) including use of failure mode condition analysis, which may affect whether the particular remote control device or the VCD 1980 itself is controlled at a particular time.

Furthermore, VCD 1980 may only allow remote control by means of a properly authorized and properly configured device or source. In particular, in some embodiments, VCD 1980 may determine whether a device meets one or more specified authorization requirements and one or more specified configuration requirements (such as device-related, hardware and/or software configuration requirements, etc.) via two-way communication with the device. In various embodiments, for example, respiratory distress ventilator 1952, the device, or both, may be configured to detect when another is present (such as within a particular distance, etc.), and/or whether other conditions are met (e.g., another power on). Communication between them may be initiated by the respiratory distress ventilator 1952 or the device (e.g., the device may send a proposal or request to remotely control the respiratory distress ventilator 1952, or the respiratory distress ventilator 1952 may send a proposal or request to be remotely controlled by the device). The device may send information to respiratory distress ventilator 1952 (or, for example, VCD 1980 may request the information and then the device may send the information) to enable VCD 1980 to determine that the device (or device and operator) meets authorization and configuration requirements (e.g., the device may send device and/or operator identification information, authorization code or code information, device configuration information, and/or other information). If the VCD 1980 determines that the device meets these requirements, the VCD 1980 may only allow remote control with the device.

In addition, in an environment including multiple potential remote control devices, the VCD 1980 may include software implementation rules or procedures for managing remote controls in this context. This may include, for example, rules or procedures for authorization and configuration determination for each of several devices or for different devices at different times. This may also include, for example, rules or procedures for making selections for remote control between a plurality of appropriately authorized and appropriately configured devices, or rules or procedures for switching from one remote control device to another under specified conditions.

Fig. 17B illustrates some of the components of the non-hospital emergency care environment 1950 as depicted in fig. 17A, including one of the other devices, specifically device 1966 (other devices not shown). The device 1966 may be, for example, a CCM, defibrillator, or tablet computer in bi-directional communication 1984 with the respiratory distress ventilator 1952. In the depicted example, the VCD 1980 determines that the device 1966 is properly authorized and properly configured, and remote control using the device 1966 is established.

As described with reference to fig. 16, for example, in some cases, communication between the respiratory distress ventilator 1952 and the remote control 1966 may be cut off or otherwise lost at a particular time. For example, as described with reference to fig. 22-25, this may be an example of a failure mode condition that causes VCD 1956 to control mechanical ventilation with respiratory distress ventilator 1952, such as based on one or more of standby, default, currently in use, last or last received valid settings, etc.

Additionally, in some embodiments, VCD 1980 may include software implementation rules or procedures that are specific to situations such as transient communication loss, such as situations where communication is lost or cut off in a very short period of time (e.g., less than one or several seconds), etc. For example, in some embodiments, VCD 1980 may be configured to use the last received active setting for a communication loss up to a specified first threshold period of time (referred to herein as an instantaneous communication loss), but switch to using a different standby setting if the communication loss extends longer than the first threshold period of time (referred to herein as a non-instantaneous communication loss). In various embodiments, for example, various different rules may be used in a transient communication loss situation, as opposed to a non-transient communication loss situation (such as may involve the use of different spares in such situations, last received valid, or other settings, etc.). Still further, in some embodiments, VCD 1980 may be configured to store information regarding recent communications, may use one or more algorithms to identify communication-related patterns in recent communications, and may use rules for determining the set values, which rules are based at least in part on the detected recent communication-related patterns. As one of many possible examples, the identified recent communication-related pattern of frequent transient communication loss may indicate an increased probability of relatively rapid reestablishment of communication in an immediately subsequent future time period, and may trigger some particular action to be taken in the immediately subsequent future time period, such as a slight increase in the first threshold time period, or the use of a slightly different particular backup setting, etc.

However, it is noted that because communication between devices is not truly instantaneous (taking into account various factors such as normal latency, normal network traffic, etc.), in some embodiments very short and normal delays in communication (e.g., up to a threshold of less than one or several seconds in various embodiments) cannot even be considered or defined as instantaneous communication loss. Further, in some embodiments, for example, an instantaneous communication loss may be considered or defined as a communication loss that is above and up to a specified maximum threshold period associated with an instantaneous delay (considered or defined as associated with a normal delay in the communication). In some embodiments, the normal delay does not result in any setting related changes implemented by VCD 1980, which may result in using the last received valid setting, for example, during the normal delay period.

In some embodiments, respiratory distress ventilator 1952 continuously transmits data including the current settings in use to remote control 1966, such as via wireless communication. During remote control, remote control 1966 may periodically send a set value command to respiratory distress ventilator 1952, such as to change a particular set value to a particular new set value, etc. The set value command may reflect a set value selected or entered by an operator 1976 of the remote control 1966 via a control of the remote control 1966. Additionally, however, the respiratory distress ventilator 1952 may have controls by which the operator 1954 of the respiratory distress ventilator 1952 may potentially make selections or key-ins of set value commands even during control with the remote control 1966. In some embodiments, this may sometimes result in a conflict at a given time between a command received by the respiratory distress ventilator 1952 via communication from the remote control 1966 and a mismatch command received by the respiratory distress ventilator 1952 and based on one or more selections or entries by the operator 1954 of the respiratory distress ventilator 1952 (e.g., a command specifying a different value for a particular setting). In some embodiments, VCD 1980 includes software implementation rules or procedures for handling such conflict situations. For example, in some embodiments, in such conflict situations, commands received by the respiratory distress ventilator 1952 based on the selection or typing of the operator 1954 of the respiratory distress ventilator 1952 are given priority or priority and are implemented in lieu of conflicting and mismatched commands received by the respiratory distress ventilator 1952 via communication from the remote control 1966. However, in various embodiments, various other conflict resolution and management rules or procedures may be followed, which may include, for example, notifying either or both operators 1976, 1954 of the conflict, and prompting either or both to acknowledge, accept the conflict command, command change, or take other steps.

Furthermore, loss of communication between the respiratory distress ventilator 1952 and the remote control 1966 may lead to the following: for example, the hypothetical current setting (or other information such as patient parameter information, etc.) available at the remote control 1966 and potentially viewed by the operator 1976 on the controls of the remote control 1966 is not actually current and therefore incorrect. For example, they may reflect current settings a few seconds or minutes before the communication is cut off, and these settings may have changed during the cut off period. As a result, the operator 1976 may potentially make selections or key-ins based on incorrect information, which results in associated commands such that the settings selected or typed by the operator 1976, and the resulting commands, may be suboptimal or inadvisable based on incorrect related information. Furthermore, in a cut-off communication scenario, operator 1954 of respiratory distress ventilator 1952 may receive non-current information sent by remote control 1966. In some embodiments, VCD 1980 (and possibly other means) includes aspects and software for implementing rules or procedures to solve or mitigate problems associated with such a scenario. For example, in some embodiments, VCD 1980 may cause an alert or alarm (e.g., light, colored light, other visual display, or sound) to be provided to operator 1954 of respiratory distress ventilator 1952, such as may alert or pre-warn operator 1954 that one or more commands received from remote control 1966 may reflect consideration of specific underlying information that is not current (e.g., upon one or more associated selections or keys made by operator 1976 of device 1966, operator 1976 receives current setting information that is not actually current, and thus incorrect or potentially incorrect). The alert or pre-warning may further indicate the extent to which the particular underlying information is non-current information (such as a range of seconds or minutes, etc.), and/or the alert or pre-warning may be different, such as having a greater magnitude (e.g., a louder tone, brighter light, different colored light) if the extent is greater (e.g., if the particular information is non-current information for a greater amount of time), etc. In some embodiments, the remote control 1966 may use the time information or time stamp of receipt of the last information from the respiratory distress ventilator 1952, and may provide an early warning or alert to the operator 1976 accordingly. However, in some embodiments, normal delays in communication are not considered to make the received information non-current.

Fig. 18-21 illustrate examples of various types of failure mode conditions, such as related to communication 1102, data integrity 1104, ventilation settings 1106, and patient physiology 1108 as depicted in fig. 12. As described with reference to, for example, fig. 12-17, in some embodiments, the VCD of the respiratory distress ventilator may manage aspects related to failure mode conditions, and may also manage and implement aspects related to control of the respiratory distress ventilator (such as by internal control, by enabling or allowing remote control, or by aspects of both, etc.).

Fig. 18 illustrates a table 2000 of examples of communication-related failure mode conditions 1102, in accordance with some embodiments. The communication-related failure mode conditions 1102 may include, for example, a condition that the VCD detects that communication with a remote control source has been lost 2002 (or, in some embodiments, insufficient or too slow) or a condition that the VCD detects attempted control of an unauthorized or improperly configured source 2004.

In various embodiments, various error detection and/or correction (EDC) schemes may be utilized to reduce Bit Error Rate (BER) and subsequent communication failures and detection or errors. In some embodiments, for example, acknowledgement (ACK) and/or Negative Acknowledgement (NACK) software techniques or schemes may be utilized. The ACK/NACK scheme may be used, for example, to determine whether there is currently communication, which may be required to permit remote control. A simple Cyclic Redundancy Check (CRC) may be performed. Alternatively, a block code or a convolutional code may be employed. Alternatively, a more complex EDC process may be utilized. In some examples, the EDC method may be specifically tailored to a unique set of requirements presented by a remotely controlled activity.

In various embodiments, in a remote control application, a controlled device communicates with a remote controller. The communication may be wired or wireless, synchronous or packet-based. Typically, controlled devices have a limited set of commands/controls/actions/movements that they can perform. For example, remote control often occurs in noisy environments in ambulances, helicopters or other aircraft, as well as in electromagnetic interference environments. The combination of the actions of the controlled device and the environmental disturbances may cause a change in parameters describing the state of the system. The controlled devices may need to communicate with the remote controller regarding their current state and take further instructions. The information stream will experience noise; thus, system performance may depend on encoding the transmission for channel noise. Furthermore, there may be additional constraints of remote control due to: real-time response to the transmission is required; causal encoding and decoding (bits of the code may depend only on past events); and a tradeoff between accuracy and reliability of information and the amount of delay allowed for real-time communications. In some embodiments, as described in "Error Correcting Codes for Automatic Control", IEEE Transactions on Information Theory, vol 55,No.7,July 2009, an encoding scheme optimized for remote control applications, such as track codes or tree codes, may be employed.

In some embodiments, the VCD is configured to only allow remote control with authorized or properly configured sources. For example, in some embodiments, it is desirable to ensure that unauthorized or incorrectly configured devices or systems are not licensed to control the respiratory distress ventilator, such as by controlling mechanical ventilation aspects of the respiratory distress ventilator, etc. Thus, in some embodiments, the VCD allows only certain devices or systems, or devices or systems that meet predetermined authorization or configuration requirements, to remotely control the respiratory distress ventilator (e.g., subject to failure mode condition analysis).

For example, as depicted in fig. 12, communication signaling 1102 may include a set of data to be received by the respiratory distress ventilator (whether directly or via one or more intermediate entities) sent by a remote device. The data set may include information that may be used by the VCD in determining whether to permit a device or system to remotely control the respiratory distress ventilator (e.g., subject to failure mode analysis). In some embodiments, for example, the VCD may compare the received data set to stored data (such as may be stored in a memory of a controller of the respiratory distress ventilator, etc.), where both the received data set and the stored data may relate to authorization or configuration. Based at least in part on the comparison, the VCD may determine whether the remote device or system meets authorization and/or configuration requirements, and may or may not permit remote control accordingly. In some embodiments, only certain devices or systems or certain types or groups of devices or systems may meet these requirements. For example, the received data set may specify certain authorization or configuration information that may be compared and must be matched or matched with stored data specifying the required authorization or configuration information in order for the VCD to permit remote control.

In some embodiments, the remote device or system may send the data set to the respiratory distress ventilator based on a user initiated request (such as via a display/GUI, etc.) made at the remote device or system, the respiratory distress ventilator, or another device or system. However, in some embodiments, the data may be sent without user initiation. For example, a remote device or system may be configured to be automatically triggered to send data, or a VCD may be triggered to request data, by any of a variety of trigger conditions. For example, where the remote device or system is a local device, the data transmission may be triggered only by the respiratory distress ventilator and the remote device being sufficiently close to each other (as may be detected by either or both of the devices). As another example, in the case of a modular environment, such as the modular environment depicted in fig. 8, data transmission may be engaged, attached, or docked together or triggered at the same docking station or dock by the respiratory distress ventilator and remote device. In some embodiments, even if the VCD determines that remote control is permitted, the user may be prompted and may be required to confirm that remote control should occur. The prompting and confirmation may occur at the respiratory distress ventilator, a remote device or system, or another device or system.

Fig. 19 illustrates a table 2150 of an example 2152 of data integrity related failure mode conditions according to some embodiments. As depicted in fig. 19, the data integrity related failure mode conditions may include, for example, conditions in which the VCD detects invalid request/command data (e.g., unusable, corrupted, or unrealizable for any of a variety of potential reasons).

In some embodiments, for example, an ACK/NACK scheme is used to check for received invalid control data and acknowledge communication. Furthermore, in some embodiments, cyclic Redundancy Check (CRC) or one or more other error detection methods or techniques may also be utilized.

For example, in some embodiments, it is checked whether control requests/commands received by the VCD of the respiratory distress ventilator from a remote control device or system meet certain requirements, and the receipt of the control command may also be used to confirm that a communication is present. The requirements of validity may relate to, for example, received data packets, appropriate/allowed data packet sizes, formatting, framing, the existence of start and stop delimiters/boundaries, the effective length, and the acknowledgement that one or more aspects of the control command are not corrupted. Additionally, a CRC may be performed.

In some embodiments, the predetermined set of commands may be stored in a memory of the controller and may be accessed by the VCD. As a requirement for validity, the VCD may check to ensure that the received command matches at least one of the predetermined set of valid commands. For example, in some implementations, each command may have associated command identification data (command ID), such as an associated numeric or alphanumeric string or the like. Among other requirements, it may be required that the received command ID matches one of the valid command sets.

Further, in some embodiments, as an additional requirement of demand, availability, or availability, the VCD may require that certain enablement identification data ("enablement ID") be received from a remote control device or system, such as periodically or at regular intervals, such as once every 10 seconds (or e.g., once every less than one second, once every 1 to 10 seconds, or once every 10 to 30 seconds), etc. The set of predetermined enabling IDs may be stored, for example, in a memory of the controller, etc., wherein each enabling ID relates to a specific set of commands, wherein each specific set of commands may be, for example, a subset of all possible commands. For example, each particular command set may relate to one or more particular types, categories, or widths of commands, such as test function related commands, monitor function related commands, ventilation control related commands, and the like. The particular enablement ID may relate to one or more of a particular set of commands (e.g., a test-function-related command only, a monitor-function-related command only, or a ventilation control-related command only, etc.), or may relate to two or more sets of commands (e.g., a monitor-related command and a ventilation control-related command, or a monitor-related command, a ventilation control-related command, and a test-related command, etc.). In various embodiments, to enable remote control related to a particular one or more command sets associated with a particular enablement ID, or to enable communication or command related communication related to a particular one or more command sets with a remote control device or system, or to enable any type of communication or command related communication with a remote control device or system, for example, a VCD may require that enablement IDs be received from remote control devices or systems that match a particular enablement ID for every particular period of time or interval.

In some implementations, if the packet meets the requirements, it is considered valid, the VCD may respond by sending an ACK packet to the device and allow remote control. However, if the packet does not meet the requirements, it is considered invalid, the VCD may not respond by sending an ACK packet to the device (or may respond with an ACK packet different from that in the case where the control command meets the requirements), and remote control is not allowed.

In some embodiments, a specific protocol is used in conjunction with an ACK/NACK scheme. For example, in some implementations, the VCD may wait for an ACK or NACK reply from the device for a predetermined reply period (e.g., 500 ms). If no reply is received within a predetermined reply period (e.g., a timeout occurs), the VCD may or may not immediately transmit additional communications and may again wait for a response (e.g., between 1 and 20 such attempts, such as 2 to 5 or 3, etc., at most). In some embodiments, the predetermined reply time period, number of attempts, and/or number of times timeout may be determined or optimized based in part on or related to a possible or expected bit error rate or maximum bit error rate associated with the reply or communication link.

Furthermore, in some embodiments, an ACK/NACK and retry scheme may be utilized or additionally serve the purpose of, for example, effectively adjusting or limiting the packet rate (or other data reception rate) at which the VCD and respiratory distress ventilator receive data from the device or system. For example, the scheme may be used to limit the packet reception rate to traffic manageable by the respiratory distress ventilator, such as without causing problems, data loss, overflow, delay or unacceptable amounts of delay, or optimization to reduce overall operation. For example, in some embodiments, if the rate of data packet reception is unacceptably high, the VCD may control or determine the timing or rate of the response(s) to throttle, control, or limit the rate to a maximum acceptable level.

In some embodiments, the VCD does not allow remote control based on request/command data determined to be invalid. In the event that invalid request/command data is received, the VCD may monitor and/or wait for new valid request/command data. Upon receipt of valid new data, the VCD may allow control accordingly depending on the failure mode condition analysis.

In some embodiments, the VCD may be configured to determine whether control in accordance with the newly received valid request/command data may represent a too large or too abrupt change in one or more ventilation settings, which may represent a ventilation setting-related failure mode condition (further examples of which are provided with reference to fig. 20). This may be the case, for example, if the mechanical ventilator of the respiratory distress ventilator would not be able to make such a large or abrupt change (or combination of changes) immediately, or if such a large or abrupt change (or combination of changes) may pose a risk, or an unacceptable or undesirable level of risk, to the ventilation system or patient. In various embodiments or examples, the VCD may respond in various ways in this case. For example, the VCD may algorithmically specify a gradual increase or decrease in one or more settings over time, such as may include an adjustment of one or more settings over time, or the like. For example, the rate of increase or decrease may be limited to a possible, optimal or safe rate.

In various embodiments, the VCD may internally control mechanical ventilation with the respiratory distress ventilator in various possible ways until new, valid request/command data is received (or in instances where communication is lost or inadequate until communication is reestablished). In some embodiments, the VCD may control mechanical ventilation according to the currently in-use, most recent, or last received valid, standby, or default settings until new, valid request/command data is received (depending on failure mode condition analysis). Further, in some embodiments, the controller and VCD of the respiratory distress ventilator may be configured to use an indexing scheme to allow for quick, efficient, or optimized retrieval of the last received active, standby, or default settings, which may allow for faster or more efficient control.

In some embodiments, aspects of the respiratory distress ventilator controller or VCD include optimization features, such as reducing risk and/or increasing optimization, etc., in combination with control of mechanical ventilation provided by the respiratory distress ventilator. Such optimization may take into account, for example, priorities of VCD operations, which may include, for example: sometimes some degree of emphasis or prioritization is placed on avoiding stalls, freezes, stalls or delays, for example, with respect to efficiency or savings in resource usage for processing. Additionally, such optimization may take into account the importance of minimizing stops, delays, or incompatible determinations, which in some instances may pause, delay, or reduce the degree of implementation speed of optimal ventilation setting adjustments. This in turn may reduce the optimization of ventilation provided, potentially reducing optimal patient care, or creating or increasing patient risk. The optimization features may include, for example, disabling interrupts if determined to be appropriate, e.g., to prevent temporary stopping of VCD operations and using single-threaded processing aspects, which may reduce temporary processing stalls and stops associated with VCD operations.

In some embodiments, single-threaded processing and/or multi-threaded processing may be utilized. In a single thread process, instructions are executed by a processor in a single sequence. In contrast, in multi-threaded processing, portions of a program execute concurrently in multiple concurrently executing threads (which are sequences of programmed instructions). Multithreading may be faster and more efficient than single-threaded processing, allowing multiple threads to share access resources. However, multi-threaded processing tends to be more complex and may be more prone to errors or stalls. This may be due to the much higher complexity of multi-threaded programming or may be related to the required locking of resources in the multi-threads, which limits access to particular resources to prevent e.g. inconsistencies. In some embodiments or regions, single-threaded processing is utilized because single-threaded processing may be simpler and less prone to potentially causing errors or stalls, for example, because locking of resources is not required. However, in some embodiments, the advantages of multithreading are taken into account, with or without further utilization, but as described below, various optimization features may be employed in connection with the use of multithreading to minimize or reduce disadvantages.

In terms of multithreading, the optimization feature may include, for example, using a thread security aspect so that multiple threads may utilize common resources with reduced latency or unpredictability. Such optimization features may include, for example, the use of the following: stateless implementation aspects (e.g., using a stateless deterministic function); immutable implementation aspects (e.g., class instances with internal states that cannot be modified after construction); a wirelocal field (e.g., a class that does not share state between threads); synchronization sets (e.g., sets that use synchronization wrappers included within a set framework), concurrency sets (e.g., that divide their data into segments); an atomic object (e.g., which allows operation without using synchronization); a synchronization method (e.g., where only one thread may access the synchronization method at a time while blocking access to the method from other threads), a synchronization statement (e.g., synchronize the entire method), use other objects as locks, such as re-entry locks or read/write locks (e.g., use an external entity to force exclusive access to a resource), etc.; notes (e.g., avoid locking with strings); and volatile fields (e.g., storing and reading counter variables with respect to main memory or other memory rather than cache memory).

The optimization features may also suitably include: such as in filtering out and reducing data noise, a histogram or histogram filter is used for flow measurements with the respiratory distress ventilator. This may include, for example, using a histogram filter or one or more other types of digital filters to determine the most probable signal value, and using the determined most probable signal value to filter out data noise. The optimization features may also include, for example: a predetermined or optimized buffer or unused portion of processing capacity or memory is maintained to reduce the risk of overload, freezing or stopping.

Fig. 20 illustrates a table 2220 of ventilator setting-related fault mode conditions in accordance with some embodiments. The ventilator setting-related failure mode conditions may include, for example, an overall system failure 2222, and the overall system failure 2222 may include a case where the VCD fails to control according to the remote control. In such instances, the VCD may be configured to control the mechanical ventilation device according to, for example, standby, default, current in use, last or last received valid settings. Further, the controller and VCD may be configured to implement such control even when experiencing any of a variety of failures (e.g., inability or inability to receive, interpret, process, or implement remote control data or commands).

The ventilator setting-related fault mode conditions may also include fault mode conditions related to a ventilation setting check failure 2224, such as where one or more requested ventilation settings, or a combination thereof, are not possible or exceed an allowable limit, etc. These may include, for example, VCD checks to ensure that the requested ventilation settings (e.g., PIP, flow targets) or combinations thereof are within an acceptable range or combination of ranges based on factors such as security, availability, or implementation capabilities. For example, in some embodiments, the scope of permissions may be preconfigured and based on the design and constraints of the system (such as maximum or minimum settings that are achievable, controllable or stably or non-irregularly controllable, etc.), or may be based on preconfigured rules but dependent on particular operating conditions or other settings. In various embodiments, the controller and VCD may process the out-of-range setting command in various ways in certain situations. In some embodiments, for example, a warning or other message may be triggered and provided to the user with respect to the requested setting. In various instances, the user may be alerted and prompted to confirm the change, such as via a CSG or the like, or given a message not permitting the requested change. The message may include additional details such as the reason for not permitting the requested change, or the maximum minor change that may be permitted, etc. In some embodiments or examples, the VCD may not be controlled according to a setting (or settings) request/command determined to be outside of the allow/permit limits, and may instead be controlled according to, for example, standby, default, currently in use, last or last received valid settings.

In other embodiments or examples, the VCD may be configured to determine the adjusted setting(s) based at least in part on the setting(s) associated with the setting request/command. For example, in some instances, the VCD may determine an adjusted setting at a maximum value of the licensed range if the requested setting is above the licensed range, and the VCD may determine an adjusted setting at a minimum value of the licensed range if the requested setting is below the licensed range. The VCD may then control the mechanical ventilator of the respiratory distress ventilator according to the determined adjusted settings. Further, in some examples, combinations of two or more settings may be constrained within interdependence ranges such that respective permitted ranges depend at least in part on the permitted ranges or one or more other. Such interdependent settings may include, for example, respiratory rate, I: E ratio, and inspiration time, among others. In this case, in various ways, the VCD may determine an adjusted setting for one or more of the requested settings, such that, for example, a combination of settings is permitted, and may be controlled accordingly.

Further, in some implementations, for some requested settings or requested settings that fall within a particular range, the VCD may be configured to obtain user confirmation, authorization, or permission of the settings prior to control according to the requested settings. For example, a change in settings regarding a patient risk that may affect or create a patient in some way may require user confirmation, or the user confirmation may indicate or be related to a potential data error. For example, such errors may be human/user errors (such as requests/commands associated with user settings changes, etc., where the user may accidentally input an erroneous value), or equipment, hardware, or software-based errors (e.g., caused by erroneous sensor readings, such as erroneous sensor readings that may be caused by a misplaced or shifted detector). For example, in some implementations, a requested PIP or PEEP setting that falls within or exceeds a certain high threshold or that is potentially too high may require user confirmation. Further, in some implementations, when user confirmation is required, the user may be prompted accordingly, e.g., via a display/GUI or CSG of the remote control and/or the respiratory distress ventilator, etc.

Fig. 21 illustrates a table 2350 of example alert related fault mode conditions 2352 in accordance with some embodiments. The alarm-related fault mode condition may, for example, comprise a patient physiological-related alarm. In some embodiments, for example, the VCD may be configured to monitor predefined patient physiological parameter values, such as high risk or unsafe parameter values, etc., that may develop and may render one or more current ventilation settings unlicensed. For example, in some instances, high risk or unsafe patient physiological parameter values may develop and may make one or more particular current ventilation settings unsafe. In various embodiments, in such instances, the VCD may be controlled, for example, according to an adjusted, standby, or last received active setting (including changing the current setting as needed). Further, in some implementations, the VCD is configured such that the alert or alerts cause presentation of an alert, such as a visual or audio (e.g., audible or text) alert or the like, presented to the user, which may be presented, for example, on a display/GUI or CSG of the remote control device and/or the respiratory distress ventilator. It is noted that in some embodiments, the VCD may monitor and take actions related to the alarm condition separately or independently from or in addition to other fault mode conditions and fault mode condition analyses, such as by continuously or frequently monitoring the alarm condition and taking appropriate actions accordingly, etc.

Fig. 22 illustrates a method 2400 related to failure mode condition analysis implemented by a VCD that includes signaling a ventilation system with control of the VCD based on a received ventilation setting or a setting determined by the VCD, in accordance with some embodiments. In step 2402, the vcd monitors for the occurrence or existence of a failure mode condition (e.g., related to communication, data integrity, ventilation settings, or alarms). In step 2404, the VCD queries whether a failure mode condition (or more than one) is detected, e.g., at a predetermined or specific time, etc.

If the VCD does not detect a failure mode condition at step 2404, the VCD enables control of ventilation by signaling the ventilation system of the respiratory distress ventilator according to one or more ventilation settings requested by the remote control source at step 2406 using the remote control source. The VCD then waits for a predetermined period of time (e.g., 1 second, less than one second, or a few seconds (e.g., between 0.1 and 1 second, or between 1 and 10 seconds), and then returns to step 2402.

However, if the VCD detects a failure mode condition at step 2404, then at step 2408 the VCD controls the ventilation system of the respiratory distress ventilator according to one or more settings determined by the VCD (e.g., based on adjusting the requested settings, or based on standby, default, current in use, last or last received active settings). The VCD then waits for a predetermined period of time (e.g., 1 second, less than one second, or a few seconds) and then returns to step 2402.

Fig. 23 illustrates a method 2500 related to failure mode condition analysis implemented by a VCD that includes details related to failure mode condition analysis related to communications, in accordance with some embodiments. In step 2502, the vcd performs one or more CRCs and an ACK/NACK scheme including a retry protocol while checking for communication between the respiratory distress ventilator and the remote control source. At step 2504, the VCD queries, for example, whether there is communication (or, in some embodiments, whether there is sufficient communication or communication at a sufficient rate) at the current time, etc.

If, at step 2504, it is determined that there is no communication, then, at step 2506, the vcd queries whether the valid ventilation settings last received from the remote control source triggered any alarms. In some embodiments, this may provide additional or alternate checks to monitor the settings that trigger any alarms. If an alarm is not triggered, the vcd controls the mechanical ventilation system of the respiratory distress ventilator according to the last received active settings, step 2510. If an alarm is triggered, the vcd controls according to the standby settings in step 2512.

However, if it is determined at step 2504 that there is communication, then at step 2508 the VCD queries whether there are any non-communication failure mode conditions (e.g., related to data integrity, ventilation settings, or alarms, examples of which are described with reference to fig. 19-21). If a non-communication failure mode condition does not exist, the VCD controls the mechanical ventilation system of the respiratory distress ventilator according to the requested settings, step 2514. If a non-communication failure mode condition exists, the VCD controls according to the ventilation settings based on the non-communication related amount failure mode condition analysis at step 2516.

Fig. 24 illustrates a method 2600 related to failure mode condition analysis implemented by a VCD, including details related to failure mode condition analysis related to data integrity, in accordance with some embodiments. At step 2602, the VCD determines that there is communication between the VCD and the remote control source. At step 2604, the vcd performs a data integrity related failure mode condition analysis on the received set request data(s), including one or more CRC checks for valid command IDs, data formatting and data bordering, and potentially others. At step 2606, the vcd queries whether the set request data(s) pass data integrity-related failure mode condition analysis (e.g., such as at the current time, etc., it is determined that no data integrity-related failure mode condition exists).

If the data is not analyzed (e.g., it is determined that at least one data integrity related failure mode condition exists) at step 2606, the vcd queries whether the last received valid ventilation settings from the remote control source triggered any alarms at step 2608. If an alarm is not triggered, the vcd controls the mechanical ventilation system of the respiratory distress ventilator according to the last received active settings at step 2612. If an alarm is triggered, the vcd controls according to the standby setting in step 2614.

However, if the data passes the analysis (e.g., it is determined that no data integrity related failure mode condition exists) at step 2606, then the vcd controls the mechanical ventilation system of the respiratory distress ventilator according to ventilation settings based on the ventilation settings related failure mode condition analysis and the alarm related failure mode condition analysis at step 2610.

Fig. 25 illustrates a method 2760 related to failure mode condition analysis implemented by a VCD, including details related to failure mode condition analysis related to ventilation settings, in accordance with some embodiments. In step 2762, the VCD determines that there is communication between the VCD and the remote control source. In step 2764, the vcd determines that the received set request data(s) pass the data integrity related failure mode condition analysis test (e.g., no data integrity related failure mode condition is detected). At step 2766, the vcd performs a ventilation parameter set-related failure mode condition analysis on the received set-up request data, including determining that the requested ventilation parameter set-up(s) value(s) falls within the allowable ventilation parameter range(s). Next, the vcd inquires whether the requested data passes the analysis at step 2768. If the requested data is not analyzed (e.g., at least one ventilation parameter failure mode condition is detected, or an alarm is triggered) at step 2768, the vcd controls the mechanical ventilation system of the respiratory distress ventilator according to the last received active setting, standby setting, or a setting determined by adjusting the requested setting at step 2770. However, if the requested data is analyzed (e.g., no ventilation parameter failure mode condition is detected) and no alarm is triggered at step 2768, the vcd controls according to the requested settings at step 2772. In some embodiments, for a requested setting within certain limits, user confirmation may be prompted and required before the VCD is controlled according to the requested setting.

Fig. 26 illustrates a block diagram 3050 of an example respiratory distress ventilator 3052 having one or more non-ventilation modes 3054 and one or more ventilation modes 3056. In the depicted example, when in non-ventilation mode 3054, the respiratory distress ventilator 3052 may be used to perform patient monitoring and assessment without providing any form of ventilation. In some embodiments, in non-ventilation mode 3054, one or more spirometers may be used to assess respiratory function of the patient. One or more non-ventilation modes 3054 may be used in an emergency setting, such as for patients experiencing respiratory distress and requiring monitoring but not currently requiring mechanical ventilation, and the like. One or more non-ventilation modes may also be used in non-emergency situations, such as for patients who are not experiencing respiratory distress or who are at the office or hospital visit of a non-emergency doctor, and the like. In some implementations, in a non-emergency care scenario, the respiratory distress ventilator may be used with its spirometer to assess the respiratory function or condition of the patient. Such non-emergency care assessment may not include the use of certain components that may be used in an emergency care setting, such as patient circuits, aspects of a particular patient circuit or patient circuit, and the like. The respiratory distress ventilator can switch between a non-ventilation mode and a ventilation mode, such as by user selection, automatically, by user prompting and confirmation, or otherwise.

While in one of the ventilation modes 3056, the respiratory distress ventilator 3052 may provide any of a variety of forms of ventilation (examples of which are described with reference to fig. 27), but may also or continue to provide patient monitoring and assessment.

Fig. 27 illustrates a block diagram of an example respiratory distress ventilator ventilation capability or pattern 3000, according to some embodiments. As depicted, respiratory distress ventilator 3002 includes various types and/or modes of ventilation capabilities 3004. In some embodiments, for example, these include: (1) Non-invasive ventilation (NIV) 3006, which includes Continuous Positive Airway Pressure (CPAP) 3008 and bi-level positive airway pressure (BPAP) ventilation 3010; (2) a High Flow Nasal Cannula (HFNC) 3012; (3) Invasive Ventilation (IV) 3014, which includes Auxiliary Control (AC) 3016, synchronous intermittent forced ventilation (SIMV) 3018; and (4) ventilation 3022 provided during CPR chest compressions. Further, in some embodiments, the respiratory distress ventilator may provide ventilation in a pressure or volume target mode.

In general, NIV 3004 has been increasingly used in acute care settings over the last 20 years, particularly for hypercarbonated respiratory failure. In particular, patients with acute hypercapnic respiratory failure due to COPD or other causes may respond well to NIV 3006. Furthermore, there is evidence supporting the use of NIV 3006 for the treatment of hypercapnic respiratory failure of other etiologies as well. In some embodiments, the respiratory distress ventilator may be optimized to provide excellent NIV 3006 in CPAP 3008 and bi-level 3010 modes.

In some embodiments, the respiratory distress ventilator may be equipped with the characteristics of providing NIV 3006 as follows. Respiratory distress when providing NIV 3006The forced breathing machine can be used for at least 0 to 50cm H ₂ O is operated in a pressure range and can provide, for example, plus or minus 0.3cm H ₂ Maximum change in O. Further, in some embodiments, the maximum pressure variation may be maintained as follows. At less than 10cm H ₂ At the pressure of O, the following maximum pressure variations can be maintained: at 10BPM, add or subtract 0.4cm H ₂ O; at 15BPM, add or subtract 0.5cm H ₂ O; and at 20BPM, add or subtract 0.8cm H ₂ O. At 10 and 50cm H ₂ At the pressure of O, the following maximum pressure variations can be maintained: at 10 Breaths Per Minute (BPM), 0.5cm H was added or subtracted ₂ O; at 15BPM, add or subtract 0.8cm H ₂ O; and at 20BPM, add or subtract 1.0cm H ₂ O. Still further, in some implementations, a maximum flow rate of 250 liters/min may be maintained over an operating range of pressures. However, other embodiments may be used with greater or lesser accuracy and variation and different characteristics.

In some embodiments, in an operating mode such as NIV 3006 mode, various respiratory distress ventilator operating parameters may be gradually increased for reasons that may include maximizing or optimizing system performance, stability or efficiency (e.g., related to clinical concerns, or energy, oxygen or other resource usage, etc.), or patient safety or comfort. Additionally, in some embodiments, for similar reasons, the portable ventilation or respiratory distress ventilator is capable of detecting and compensating for detected leaks (such as inspiratory or expiratory patient circuit leaks, etc.). In various embodiments, leak detection may be performed in different ways. Leak detection may be achieved, for example, by determining the difference between the detected inspiratory and expiratory flow. As another example, leak detection may also be achieved by determining a decreasing PEEP at the end of expiration. Leakage compensation may be achieved, for example, by using an air flow generator such as a blower or the like to cause an appropriate compensation of the additional air flow. In some embodiments, the user is able to repair the leak, and the CSG may be used to guide the user in this regard.

In some embodiments, in modes such as NIV 3006 or others, respiratory distressThe ventilator may provide alarms (whether presented on or at the respiratory distress ventilator or elsewhere (such as part of a CSG on a display/GUI, etc.), which may relate to, for example, patient or ventilation related parameters such as leaks or potential leaks (such as in relation to PEEP or Expiratory Positive Airway Pressure (EPAP), etc.), too high or too low parameter values (such as SpO) ₂ Or other gas exchange related parameters, vt, ve or RR, etc.), respiratory parameters such as RRs, respiratory compliance, and others. Further, in some embodiments, the respiratory distress ventilator may change parameters such as PIP or Inspiratory Positive Airway Pressure (IPAP) during the provision of bi-level ventilation, such as to ensure or help ensure that a target Vt is achieved. Additionally, in some embodiments, the respiratory distress ventilator may, for example, change the baseline pressure to determine or assist in determining an optimal level of PEEP or EPAP to apply. Further, in some embodiments, the respiratory distress ventilator may detect or determine asynchronous or potentially asynchronous related events, and may accordingly determine and provide an early warning, alarm, or CG. Still further, in some embodiments, the respiratory distress ventilator may detect or determine trends over time, such as with respect to parameters such as respiratory resistance (Rrs) and Crs or others, and may provide an early warning, alarm, or CSG accordingly. Further, in some embodiments, the portable ventilation or respiratory distress ventilator may include manual breathing options or buttons.

In HFNC 3012, heated and humidified oxygen or oxygen-containing gas can be delivered to the nose at a high flow rate. These high flow rates may generate low levels of positive pressure in the upper airway and may, for example, adjust FiO accordingly ₂ . The high flow rate may also reduce physiologic dead space by flushing exhaled carbon dioxide from the upper airway using HFNC 3012, a process that potentially accounts for the observed reduction in the work of patient breathing. In patients with acute respiratory failure of various origins, high flow rates of oxygen have proven to provide better comfort and oxygenation than other types of oxygen therapy. In particular, there is evidence supporting the use of HFNC 3012 for pediatric patients with mild to severe bronchiolitis. The results of the study showed that using HFNC 3012The patient placed resumes feeding faster than the patient receiving the other oxygen therapy, requires less oxygen, and is discharged more quickly.

HFNC 3012 has been observed to play an important role in heating to core temperature and humidifying the patient's respiratory system, particularly at high flow rates where other oxygen delivery systems may fail or perform poorly. For example, HFNC may improve mucociliary function and secretion clearance as has been demonstrated in idiopathic bronchodilators, such as by observing a decrease in the percentage of retention of inhaled tracers before and after receiving warm and humidified gases via HFNC, and the like. Additionally, it has been observed that with HFNC, particularly in patients with high spontaneity Ve, the required metabolic costs of heating and increasing the relative humidity of the inhaled gas are reduced. In some embodiments, the respiratory distress ventilator includes or is equipped with a heated humidifier. Further, in some embodiments, an alert is provided that is related to heating humidifier operation.

In some embodiments, in providing IV 3014, the respiratory distress ventilator may provide the following parameter value ranges: RR is in the range of 1 to 12BPM plus or minus 1BPM, RR is in the range of 12 to 50BPM plus or minus 2 BPM; vt is 50 to 2000ml plus or minus 15++4ml; PIP of 5 to 65cm H ₂ O, an inspiration Time (TI) of 0.3 to 3 plus or minus 10% seconds; peak flow is 200 plus or minus 10% liters/min; PEEP of 5 to 30cm H ₂ O, trigger sensitivity of-2.5 to 10cm H ₂ O; pressure Support (PS) of 5 to 50cm H ₂ O; fiO (fiber-optic) system ₂ 21 to 100%. However, other embodiments may be used with greater or lesser accuracy and variation, as well as different characteristics.

In some embodiments, the respiratory distress ventilator provides ventilation during CPR chest compressions, including ventilation provided during periods in which CPR chest compressions or CPR chest compression therapy is being provided. The ventilation provided during CPR chest compressions may be coordinated or synchronized with the compressions, for example. This may include, for example, determining an amount of breath per minute (or other unit of time) based, at least in part, on the number of compressions per minute (or other unit of time). The ventilation provided during CPR chest compressions may be provided asynchronously to CPR chest compressions, such as the number of breaths per minute (or other units of time) independent of the rate of CPR chest compressions, etc. In some embodiments, a pressure target is used to provide ventilation (e.g., SIMV, etc.) during CPR, regardless of airway status.

In some embodiments, the respiratory distress ventilator includes at least one spirometer. In various embodiments, basic or advanced spirometry of varying degrees, widths, or levels may be included.

In some embodiments, the goal of limited spirometry may facilitate patient respiratory assessment to facilitate screening for or assessing associated with a disease state or cause. In some embodiments, for example, one or more respiratory parameters of a patient determined or obtained using spirometry may be used to make an assessment or determination regarding a disease state or cause, a possible disease state or cause, or a probability or probability range associated with a particular disease state or cause. In some embodiments, the value or range of a particular respiratory parameter of a patient determined or obtained using spirometry may be compared to a value or range associated with a healthy patient, or a patient having a particular disease state or cause, or a patient that is particularly likely to have a particular disease state or cause. The respiratory condition of the patient may include any of the foregoing or data related to any of the foregoing, among others, including respiratory distress associated with another condition (which may be a respiratory or non-respiratory condition).

For example, in some embodiments, the respiratory distress ventilator may include a spirometry that meets the american society of thoracic (ATS)/European Respiratory Society (ERS) standards and international organization for standardization (ISO) 26782. The spirometer can perform spirometry in the range of 0 to 9 liters (or e.g., up to 12, 15, 18, or 21 liters), flow detection in the range of 12 to 900 liters/minute (or e.g., a lower limit of 2, 5, or 9, 15, 20, 25, or 30, or e.g., a lower limit of 150, 200, 250, 300, 350, 400, 450, 500, 600, 700, 800, 850, 950, 1000, 1100, 1200, 1300, 1400, or 1500), and accuracy of plus or minus 2.5% (or e.g., between 0.1% and 10%, such as 0.1%, 0.5%, 1%, 1.5%, 2%, 2.5%, 3.0%, 3.5%, 4, 4.5%, 5%, 6%, 7, 8%, 9%, or 10%, etc.).

In some embodiments, patient-related data or measurements determined or obtained using spirometry may be compared to a reference or predicted value based on characteristics of the patient. This may be done in connection with determining whether a patient has or is likely to have a particular, significant or severe disease state or cause, or in connection with determining an associated probability or probability range. For example, a measurement within a normal (or other) range or a range sufficiently far away may indicate or prove the absence of such a disease state or cause. However, measurements outside of the normal (or other) range or outside of a range far enough away may suggest or prove the presence of such a disease state or cause. In some embodiments, patient-related data or measurements determined or obtained using spirometry may be compared to other reference spirometry data (such as spirometry data averages, or data associated with a particular disease state or cause, type or population thereof, or associated probabilities thereof, etc.). Doing so may facilitate patient disease state or etiology assessment or determination. Furthermore, in some embodiments, the patient-related spirometry data or measurements may be compared to reference spirometry data associated with a particular type, population, or demographic or physiological characteristic of the individual (e.g., age, gender, ethnic background, current or historical health, health issue or medical history, etc.). Similarities or differences between characteristics of the patient (or patient-related data) and characteristics of individuals associated with the reference data (or other aspects of the reference data) may be considered in patient disease status or etiology assessment or determination. In some embodiments, various algorithms, machine learning, or artificial intelligence may be used to facilitate patient disease state or etiology assessment or determination.

Studies have shown that hyperventilation can lead to, or be associated with, for example, increased intrathoracic pressure, impaired venous return, reduced coronary perfusion pressure, and lower patient survival. As a result, in some embodiments, the respiratory distress ventilator may be used to provide, for example, moderate/conservative, consistent ventilation during CPR chest compressions. In some embodiments, for example, during mask ventilation without airway protection, the respiratory distress ventilator may deliver synchronous ventilation, e.g., 2 (or, e.g., 1 to 5) breaths per 30 (or, e.g., 10 to 100) compressions. Furthermore, in some embodiments, for example, during ventilation with airway protection (e.g., via an endotracheal tube or esophageal tracheal airway), the respiratory distress ventilator may deliver, for example, 10 breaths/minute (or, for example, 5 to 20 times) independently of the compression rate (asynchronously).

Fig. 28A-28C illustrate a few of the many possible variations of a respiratory distress ventilator including controls that may be used in various embodiments. In fig. 28A-28C, the outline and shape of the suggested respiratory distress ventilator is shown, and details are omitted at the top and sides. In various embodiments, the degree to which controls are included may vary along the spectrum of inclusion and complexity. A more limited set of included controls may emphasize or favor aspects such as ease of operation, smaller size, or more reliance on remote control, for example. More included sets of controls may emphasize or favor, for example, more user information, more controls available at the respiratory distress ventilator, and less reliance on remote controls. In some embodiments, particular included features in the set of included controls may be optimized based on various factors, such as may relate to, for example, one or more of intended or likely use, user training or experience, available user attention to the respiratory distress ventilator, or other factors. In some embodiments, aspects of the included control sets 4002, 4022, 4042 as depicted in fig. 28A-28C may be used to provide a user-interactive CSG (examples of which are described with reference to fig. 30-35). In some embodiments, one or more remote control devices may have a set of controls that is optimized based in part on the included controls of the respiratory distress ventilator, as these devices may operate in an integrated manner and in an integrated environment.

Fig. 28A illustrates an example front side of a respiratory distress ventilator 4000. Respiratory distress ventilator 4000 has included control 4002, including control 4002 including only power switch 4004 and communication indicator light 4006 (or in other embodiments, the communication indicator light may be a remote control indicator light, for example). The communication indicator light 4006 (or remote control indicator light) may be illuminated when there is communication with a remote control device or system (or when remote control is occurring in the case of a remote control indicator light), or refers to, for example, a wired connection, a wireless connection, a bluetooth connection, or one or more other connection forms or protocols.

In embodiments such as those depicted in fig. 28A-28C, the display/GUI of respiratory distress ventilator 4000 may include, for example, a Liquid Crystal Display (LCD), organic LED (OLED), micro LED, or other type of display. In some embodiments, the display/GUI may include a touch screen aspect. Further, in some embodiments, the display/GUI may be selectively hidden or displayed by the user, and upon hiding, some indication such as a visible or flashing light may be provided if the user's attention is required.

In some embodiments, the display/GUI of the respiratory distress ventilator 4000 or one or more other portions or components of the respiratory distress ventilator 4000 may be modular and may be attachable to the respiratory distress ventilator 4000 as well as removable from the respiratory distress ventilator 4000, such as an attachable and detachable LCD display module or the like. Further, in some embodiments, various different types of display modules (such as display modules of different complexity, etc.) may be attached to the respiratory distress ventilator 4000 such that the respiratory distress ventilator 4000 may be customized by a user for the display/GUI. Further, in some embodiments, the display/GUI of the respiratory distress ventilator 4000 may itself be modular and include multiple modular components, such as top, middle, and lower components, etc. Any of these components may be attachable and detachable, allowing for a mix of different display components and associated customization of the entire display/GUI of the respiratory distress ventilator 4000.

In some embodiments, the patient circuit of or coupleable with the respiratory distress ventilator 4000 may be configured such that all portions of the patient circuit are attached and these portions are attached to the respiratory distress ventilator 4000 as a modular unit.

Further, in some embodiments, the respiratory distress ventilator 4000 may include a handle or through hole, for example, allowing for convenient or stable grasping or maneuvering of the respiratory distress ventilator 4000. In some embodiments, the handle itself may include a display, which may include, for example, a status or alarm indication area or a light emitting area.

Fig. 28B illustrates an example front side of a respiratory distress ventilator 4020 in which controls 4022 are included including a power switch 4024, a communication or remote control light 4026 (which may be similar in features to respective features 4004, 4006 as depicted in fig. 28A, for example), and a display/GUI area 4028.

The display/GUI may include a central display/GUI area 4032, up and down arrow selection buttons 4030, and plus and minus selection buttons 4034. In the illustrated embodiment, the user may scroll through multiple items for display using up and down arrow selection buttons 4030, some or all of which may be subject to potential settings or adjustments by the user. The scrollable item may include, for example, one or more modes of operation (e.g., one or more non-ventilation modes or one or more ventilation modes, such as those described with reference to fig. 26 and 27, etc.) as well as various parameter settings (such as patient physiological-related parameter settings or ventilation-related parameter settings, among others). In the example shown, the current FiO of the respiratory distress ventilator 4020 is shown in the central display/GUI area 4032 ₂ Settings (actual settings are not shown, but in some embodiments, fiO) ₂ May vary between 21% and 100%, for example). As an example, the user may use up-down arrow selection button 4030 to select FiO ₂ Parameters are set for display. Once displayed, the user can change the current value displayed (potentially subject to potential restrictions, confirmations, etc.) by increasing or decreasing the current value using the plus and minus select buttons 4034. In various embodiments, the user may be undirectedIn the case of a further indication of (potentially unless user confirmation is required) the displayed setting after change is effected or some indication may be provided to the user (e.g. the display/GUI may flash briefly or change colour or some audio confirmation may be provided (such as sound or one or more words etc.)).

Fig. 28C illustrates an example front side of a respiratory distress ventilator 4040 in which controls 4042 are included including a power switch 4044 and a communication or remote control indicator light 4046 (which may be similar to components 4004, 4024, 4006, 4026 depicted in fig. 28A-28B, for example). The controls 4042 included also include a display/GUI area 4055 and plus and minus selection arrows 4056, which may be similar to some extent to the central display/GUI area 4032 and plus and minus selection arrows 4034 as depicted in fig. 28B. However, in the embodiment depicted in fig. 28C, no up-down arrows are provided. In the present embodiment, instead of using up-down arrows to select items for display (and potentially for the user to change settings), a dial 4050 is provided. In some embodiments, for example, the user may turn the dial 4050 clockwise or counterclockwise to scroll through and change the currently displayed item in the display/GUI area 4055 (or other area of the display/GUI) and may press the dial to make certain selections, adjustments, changes, acknowledgements. In some embodiments, a scroll wheel may be included, for example, to allow scrolling to select a displayed item and pressing to select the item, for example, to select or deactivate an alarm, etc. However, in various embodiments, many variations may be used with respect to the set of controls included, such as different widths and sizes of the set of controls included, controls of a particular type and item, and different ways in which a user may interact or provide different forms of input, etc.

In the embodiment depicted in fig. 28C, a larger top display/GUI area 4048 displays various information. The top display/GUI area 4048 includes a display of a current mode of operation, such as the current type of ventilation being provided by the respiratory distress ventilator (examples of the types of ventilation that may be provided are described with reference to fig. 27). The top display/GUI area also includes various patient and ventilation related parametersAnd (5) displaying. These include HR, BPM and SpO on the left ₂ FiO on the right side ₂ PEEP, PIP, and Vt. Double arrow set 4058 is shown in FiO ₂ And beside the PEEP value. This may indicate FiO ₂ CLC and PEEP CLC are currently on/operating. In various embodiments, if FiO ₂ The CLC or PEEP CLC is not currently on/operating, then the corresponding double-arrow group may not appear, or may appear, but includes, for example, a visible scratch-out to provide the user with an appropriate visual indication.

In a central region of the included control 4042, an alert/early warning display/GUI region 4052 and a message region 4054 are provided. The alarm/pre-alarm display area 4052 may be used to display any of a variety of alarms or pre-alarms to the user, such as may relate to a relevant or unsafe patient or ventilation condition or parameter, etc. In some embodiments, the displayed alert may be coded or color coded, such as may indicate priority or urgency of the alert, or the like. For example, an alarm displayed in green, yellow, or red, or including an associated green, yellow, or red displayed light emitting region, may indicate an increasing level of priority or urgency. The message area 4054 may be used to display any of a variety of messages to the user, for example, may include a CSG or may provide additional information related to the provided pre-warning or alarm, or the like. In some embodiments, user scrolling may be used (such as using dial 4050, etc.) to scroll through and change the currently displayed item in alert/pre-alarm display/GUI area 4052 or message area 4054. For example, in some embodiments, the user can scroll up and down through a list of saved pre-warnings or alarms or a list of saved messages.

In some embodiments, respiratory distress ventilator 4102 (an example of which is provided in fig. 1) may provide for incorporation of one or more forms of CLC (such as FiO ₂ CLC or PEEP CLC, etc.). In various embodiments, the CLC (or one or more forms) may be implemented via remote control using one or more remote control devices or systems, or via control using a respiratory distress ventilator, or by aspects of both.In some embodiments, control including CLC may or may not be subject to user interaction, or may not include CSG. In various embodiments, if user interaction is included, the user interaction may occur at any of a variety of devices (such as the respiratory distress ventilator 4102, another device or system in a remote control device or environment, etc.).

As used herein, the term CLC may refer to control of one or more ventilation-related or patient-related parameters (such as with relatively little or no user action, participation or intervention, etc.) and may include reference to fully automatic or fully automatic regulatory control, but is not limited to reference to fully automatic or fully automatic regulatory control. The CLC may include, for example, device-facilitated or algorithm-facilitated tracking, control, and adjustment of one or more parameters, which may or may not include user involvement or participation. Where included, it may include, for example, confirming a suggested or recommended ventilation setting change or configuration, deciding to implement a course of action, selecting one of several suggested courses of action, responding to a presented pre-alarm or alert, or other decision, selection or action. The user involvement or participation may also include, for example, setting or changing parameters, wherein the closed-loop-control algorithm initially begins there from according to the user settings or user-changed parameter settings. In various embodiments, if there is a user involvement, the user involvement may be, for example, wholly or partially user initiated, or wholly or partially prompted, suggested, recommended, or required, among others.

In some embodiments, closed loop control may be utilized, but may be subject to manual adjustment or override by a user. For example, in some embodiments, although FiO may be algorithmically and automatically controlled ₂ And PEEP, but the user can intervene and manually change FiO ₂ And/or PEEP settings. In some embodiments, after any manual adjustment, the FiO ₂ And/or closed loop control of PEEP may resume from this point at least until any further manual adjustments are made.

In various embodiments, CLC may include based on measured SpO of the patient ₂ Continuous adjustment of FiO (which is used as an indicator of patient oxygen saturation) ₂ . Typically, lower SpO ₂ Or reduced SpO ₂ (as may be based on, for example, single or current SpO ₂ Measuring or multiple spos over time ₂ Measured values) may tend to indicate "more heavily ill" patients or more patients with impaired lung or respiratory function that require more oxygenation support. In some embodiments, generally, when the SpO of the patient ₂ Below a target level (such as a predetermined SpO ₂ Value, etc.), and potentially based at least in part on how much is lowered and/or reduced, fiO ₂ May tend to increase algorithmically to increase support for oxygenation of the patient. When SpO ₂ Above the target level, and potentially based at least in part on how much higher, fiO is possible because the patient may not need as much oxygenation support as possible ₂ May be algorithmically prone to degradation. Thus, it may be based at least in part on, for example, being at least partially formed by SpO ₂ And/or increasing or decreasing FiO, for example, by the need of the patient indicated by some other indication(s), such as one or more other non-invasively sensed, measured or determined indications of patient oxygen saturation, etc ₂ . Algorithmically determined factors such as differential gain and proportional gain factors may affect FiO ₂ Direction (increase or decrease) and amount of adjustment.

In some embodiments, in determining FiO ₂ One or more previously measured SpO may be algorithmically considered in the adjustment ₂ Values. In particular, in some embodiments, the proportional gain and the differential gain may take into account one or more previously measured SpO ₂ Values. Generally, in some embodiments, the SpO is measured up to and including ₂ The differential gain may take into account SpO during a certain period of time ₂ Such as may include the use of moving averages, etc.). At SpO ₂ Such as with the determined SpO ₂ Differential gain may tend to increase FiO when the rate of decrease is related or proportional, etc. decreases ₂ And (5) adjusting. However, in some embodiments, when SpO ₂ When increased, the differential gain may not operate to tend to reduce FiO ₂ And may be operationally asymmetric in this respect. Furthermore, in some embodiments, the proportional gain may take into account the current (or current and recent) SpO ₂ To target SpO ₂ The magnitude of the difference between them is determined, where a larger difference may result in a larger adjustment. FiO including the use of differential and proportional gains is described with reference to FIG. 12A ₂ An embodiment of the algorithm for closed loop control of (a).

In some embodiments, based at least in part on FiO ₂ The PEEP is adjusted based at least in part on the current PEEP. Due to being at least partially based on patient SpO ₂ To adjust FiO ₂ And due to SpO ₂ Can be correlated to the extent to which the patient's lungs or respiratory system are "ill", compromised or functionally impaired, thus conceptually FiO ₂ Can be used to some extent as a surrogate or indicator of the extent to which the patient's lungs or respiratory system are "ill". For example, in some examples, a relatively lower and/or reduced SpO ₂ May indicate a significant and/or increased extent of functional lung injury, and may result in relatively high FiO ₂ . The high FiO ₂ PEEP may be required and caused to rise under appropriate circumstances (as may be determined with reference to, for example, PEEP change qualification rules and PEEP selection rules), where PEEP may help substantially open alveoli and support respiratory function. Conversely, in some examples, the SpO is relatively higher and/or increased ₂ Less significant and/or reduced lung injury may be indicated (i.e., generally, the patient may "breathe better" by himself), and may result in relatively lower FiO ₂ This may be required and cause PEEP to decrease in some instances (as may be determined with reference to, for example, PEEP change qualification rules and PEEP selection rules).

Thus, based at least in part on FiO ₂ Adjusting PEEP may be such that PEEP is adjusted based at least in part on an indication of the extent to which the patient's lungs or respiratory system may be "sick" or impaired.

PEEP may support a patient by, for example, increasing alveolar pressure and volume, which may substantially expand and prevent alveolar collapse, thereby improving oxygenation. However, PEEP too high can present a risk to the patient. For example, PEEP may result in an increase in chest pressure, which in turn may cause a drop in patient blood pressure by inhibiting or otherwise limiting venous blood return, thereby causing a hypotensive-related risk to the patient. Furthermore, since the increased PEEP may take some time to develop full efficacy on alveoli, the full efficacy of the increased PEEP may take some time (such as minutes, etc.) to fully develop. This may be the reason to avoid too rapid an increase in PEEP, as there may be a substantial "over-standard" possibility from the standpoint of the rate of PEEP increase and the resulting risk to the patient. Furthermore, too high or too frequent changes in PEEP can create other risks to the patient, such as barotrauma, alveolar injury or rupture, pneumothorax, pulmonary interstitial emphysema, mediastinal emphysema, fibrosis, risk of inflammation or destructive immune response, and the like. Thus, while increasing PEEP may be important if desired, it may also be important to avoid increasing PEEP too much or too frequently. In some embodiments, algorithms including PEEP change qualification rules and PEEP selection rules provide an optimization method for PEEP control, balancing the assessed need for PEEP adjustment with the need to avoid PEEP being too high and avoid too frequent changes in PEEP. Lowering PEEP may require a more conservative or slower approach than increasing PEEP, as lowering PEEP is not done to meet the patient's need for increased support.

In some embodiments, the FiO removal may be adjusted continuously or using closed loop control adjustment ₂ And various parameters other than PEEP. These may include, for example, being based at least in part on EtCO ₂ Which may indicate or indicate hypercapnia, hypercapnia or hypocapia. For example, in some embodiments, parameters including Vt, ve, PIP and drive or platform pressure may be continuously adjusted.

While embodiments of the present invention may be applicable to both hospital and non-hospital environments, some embodiments may be particularly advantageous in non-hospital, off-hospital or field settings, such as for or as a respiratory distress ventilator operated or supervised by a user or care provider with limited ventilation-related training or experience, and the like. In some embodiments of CLCs as described herein, patient care, safety, prognosis, and even survival may be significantly improved by reducing the required user monitoring or control of various ventilation or patient-related parameters, while still optimizing these parameters, particularly in pre-hospital situations. In some embodiments, one or more initial ventilation settings may be determined or optimized based at least in part on patient data (which may be at least in part user-provided), such as the gender and height of the patient or estimated height, etc.

In some embodiments, the oxygen concentration of the patient's blood (such as SpO) is measured, determined, and tracked continuously during ventilation of the patient ₂ Etc.) or other patient oxygenation-related parameters. Appropriately adjusting the FiO of the ventilator based at least in part on the determined oxygen concentration of the patient's blood ₂ The settings or other oxygen related settings that may be associated with the provided breathing gas, such as may include appropriate actuation of an oxygen source valve, actuation or adjustment of one or more other valves or settings associated with an oxygen source or oxygen concentrator, or otherwise, etc. Based at least in part on the pair FiO ₂ Adjustment of the settings, the PEEP settings of the ventilator are adjusted appropriately, such as may include appropriate actuation of an exhalation valve, actuation or adjustment of one or more other valves or settings, or otherwise, etc.

Monitoring of the oxygen concentration of the patient's blood, fiO, may be performed very frequently (e.g., every less than one second, every more than one or a few seconds, every minute or a few minutes, etc.) or based on irregular or constantly changing time durations ₂ Checking/updating of settings, and checking/updating of PEEP settings. In various embodiments, the FiO may be adjusted at the same frequency as PEEP ₂ Or the FiO can be adjusted at different frequencies ₂ . The monitoring and adjustment of parameters may be implemented or facilitated by one or more controllers that may execute one or more appropriate algorithms stored in one or more memories. In addition, canTo determine and utilize the optimized initial settings.

In some embodiments, PEEP selection rules are provided. According to some embodiments, only in FiO ₂ Setting changes to fall on FiO associated with current PEEP settings ₂ Only if outside the range, the PEEP setting can be changed. Furthermore, in some embodiments, a plurality of possible PEEP settings are each associated with a particular FiO ₂ Range is associated, but FiO ₂ Range or adjacent FiO ₂ The ranges may overlap. As a result, unless FiO ₂ The setting changes not only (a) enough to fall into the current FiO ₂ Another FiO of range associated with a different PEEP setting ₂ In overlapping portions of the ranges, and (b) sufficiently beyond the overlapping portions and into FiO associated with different PEEP settings ₂ In range, otherwise, the current PEEP setting is maintained. Typically, as described in the embodiments herein, fiO is required ₂ Changing beyond the applicable range to change PEEP settings (whether increasing or decreasing) can effectively limit the rate or frequency of PEEP changes to balance the need to change PEEP over time as needed. This in turn may have advantages such as allowing more time for a previous PEEP change to have full efficacy (because the PEEP change requires some time to have full efficacy on the alveoli) before changing the PEEP. This also has the following advantages, for example: avoiding abrupt or overly frequent PEEP oscillations (which may disrupt, destroy or otherwise damage alveoli) and achieving overall throttling or smoothing of PEEP changes over time.

In some embodiments, the above may be considered to produce a trend to maintain, rather than change, the expected, throttled or balanced current PEEP settings, but still indicate a PEEP change where appropriate. In some embodiments, such maintenance may in turn improve patient safety and prognosis, considering that, for example, while PEEP setting changes are required in appropriate circumstances, too frequent PEEP changes may, for example, rupture alveoli and damage the patient's lungs, and thus too frequent, abrupt and/or large changes in PEEP settings may pose serious risks to the patient. Accordingly, it may be optimal to properly balance the various factors, which may be achieved by some embodiments disclosed herein.

Furthermore, in some embodiments, the possible or allowed PEEP settings are determined to include a discrete set of specific PEEP settings or levels, each of which is associated with a FiO ₂ A range is associated, where the range may overlap with an adjacent range. In some embodiments, even if, for example, fiO ₂ The settings change significantly and the PEEP settings can also be adjusted only up to one level up or down.

In addition, some embodiments provide or utilize specific rules or conditions, or PEEP change pass rules or conditions (and/or fail rules or conditions), which must be satisfied in order to allow and actually make PEEP setting changes, even though, for example, the PEEP setting changes may be indicated by PEEP selection rules. In some embodiments, PEEP is maintained at the current setting unless and until a specified pass condition (or fail condition is avoided) is met, even though the PEEP setting may otherwise be indicated by a PEEP selection rule. In some embodiments, for example, these conditions or rules provide a proper or optimal balance of factors that affect performance and safety, such as by balancing the advantages of proper variation or rate of variation with the advantages of proper relative stability and limited rate of variation, for example.

Generally, in some embodiments, as described above, the period of time required for PEEP to qualify for change may reflect a balance of stability advantages over changing requirements. In some embodiments, the PEEP change qualification rules may include that PEEP has not changed for at least a specified period of time, and the specified period of time may be different depending on whether PEEP increases or decreases are being evaluated. Further, in some embodiments, the specified period of time (e.g., between 2 to 3, 3 to 4, 4 to 5, 5 to 7, 7 to 10, 10 to 15, 15 to 20, 20 to 25, 25 to 30, 30 to 35, or 35 to 40 minutes) for which PEEP is increased may be less than the specified period of time (e.g., between 10 to 20, 20 to 30, 30 to 40, 40 to 50, 50 to 60, 60 to 70, 70 to 80, 80 to 90, 90 to 100, 100 to 110, or 110 to 120 minutes) for which PEEP is decreased in minutes. Reasons for this may include that if an increase in PEEP is indicated, this may mean that the patient's lungs become "diseased" more or have impaired function, which may require a relatively rapid action to change PEEP to provide more support to the patient, while lowering PEEP does not increase patient support, and thus may take a longer period of time to effect a PEEP decrease.

Furthermore, in some embodiments, as described with reference to FIG. 13, the PEEP change eligibility rules may include FiO during the first time period ₂ The settings are unchanged or unchanged by at least a specific amount (which for convenience may be referred to as relating to FiO ₂ Or the patient has been in what may be referred to as a desaturation condition (such as may be performed by the patient SpO) for at least a second period of time ₂ Indication, etc.). In some such embodiments, the PEEP may only be changed if at least one of the following two conditions is met, even if the PEEP change is otherwise indicated: (1) FiO (Fio) ₂ The first time period (e.g., 0 to 15, 15 to 30, or 30 to 60 seconds in seconds, or 1 to 2, 2 to 5, 5 to 10, 10 to 12, 12 to 15, 15 to 20, 30 to 45, or 45-60 minutes in minutes) has been in steady state; and (2) the patient has been in a desaturation condition (e.g., spO) for at least a second period of time (e.g., 0 to 15, 15 to 30, or 30 to 60 seconds in seconds, or 1 to 2, 2 to 5, 5 to 10, 10 to 12, 12 to 15, or 15 to 20 minutes in minutes) ₂ At or below, for example, 85%, 86%, 87%, 88%, 89%, 90%, 91%, or 92%).

In some embodiments, conditions (1) and (2) may prevent the presence of FiO ₂ The potential PEEP change is allowed under conditions that suddenly change or appear to suddenly change because the correct patient conditions that allow the change in PEEP settings cannot be reflected (e.g., possibly due to FiO ₂ Resulting from erroneous or inaccurate measurements or determinations). However, condition (2) may include a smaller time period requirement to allow potential PEEP changes to provide an enhanced or prioritized ability to quickly respond to patient desaturation, which may indicate critical and urgent emergency situations (which may include PEEP increases, for example) requiring urgent increased patient support.

In some embodiments, PEEP change eligibility rules may include: for an increase in PEEP, PEEP does not change for at least a first period of time, and for a decrease in PEEP, PEEP does not change for at least a second period of time. The first time period and the second time period may be different. Thus, in some embodiments, specific time thresholds are set, wherein even if PEEP increases or decreases are otherwise indicated, these specific time thresholds must be met to increase or decrease PEEP. Further, the threshold may be different based on whether the indicated PEEP change increases or decreases. As such, in some embodiments, PEEP selection rules or aspects thereof may be referenced as part of or in connection with the use of PEEP change qualification rules.

Additionally, in some embodiments, the PEEP change qualification condition may include one or more metrics of the patient's hemodynamic condition (e.g., may be determined based at least in part on a blood pressure measurement) that, in various embodiments, may be obtained by the ventilator or another system or device in communication with the ventilator (e.g., a separate intensive care monitor, defibrillator, or other device). In some embodiments, the conditions may ensure that the patient's hemodynamic condition is sufficient to require a change in PEEP.

Fig. 29 illustrates a block diagram of ventilation control software 300 including CLC capability. In various embodiments, software 300 may be stored in whole or in part in one or more memories of one or more controllers and may be executed by one or more processors of one or more controllers. The one or more controllers may include a controller of the respiratory distress ventilator, or a controller of one or more remote control devices or systems, for example, for remotely controlling the respiratory distress ventilator.

The ventilation control software 300 includes components including an initiating mode 302, a test breathing mode 304, and a ventilation mode/active mode 306, which may represent software architecture or conceptual components, for example. Various other software may be included.

The active mode 306 includes ventilation control 310, fiO ₂ A control 312 and a PEEP control 314, wherein each or some of these aspects 310, 312, 314 may be associated withThe central control aspect 308 operates in coordination or independently, and each may or may not be in coordination with each of the other or some of the other aspects. Different aspects of the CLC may be activated individually or in combination. For example, in some embodiments, fiO is activated without PEEP closed loop control ₂ Closed loop control, such that PEEP is manually adjusted by a user; or in the absence of FiO ₂ In the case of closed-loop control, PEEP closed-loop control is activated so that FiO ₂ Manually adjusted by a user; or may activate closed-loop ventilation control, where FiO ₂ And PEEP are both manually adjusted by the user.

In some embodiments, fiO ₂ Closed loop control may provide advantages including minimizing SpO of the patient ₂ Time below or substantially below target value, providing SpO to patient ₂ The rapid oxygenation response of the desaturation event helps prevent hypoxia and hyperxyemia in the patient.

Note that although the mode and control aspects are depicted separately for conceptual purposes, these may be implemented in a combined, integrated or different manner, such as an embodiment, etc. where the aspects of the roles of the various mode or control aspects are distributed differently or combined in various ways. In addition, other conceptual frameworks may also be used in various embodiments.

In some embodiments, the portable ventilation or respiratory distress ventilator may be operated (by the respiratory distress ventilator or by a remote control device) in one of several overall system modes of operation. One (or several) such system modes may include FiO ₂ And closed loop control of PEEP, which for convenience and without limitation may be referred to herein as ventilation/PEEP/FiO ₂ Controller (VPFC) system mode. In some embodiments, operation in the VPFC system mode includes an initiating mode 302, a test breathing mode 304, and an active mode (or ventilation mode) 306, which may occur sequentially in some embodiments and represent phases of operation in the VPFC system mode.

In various embodiments, various types of closed loop control, such as VPFC mode, may be started or engaged and stopped in different waysOr disengaged. In some embodiments, the closed loop controlled VPFC or other aspects may be automatically started, such as at the start of active mode ventilation. In some embodiments, the respiratory distress ventilator or remote control may include a control aspect, such as a physical button, control knob, or GUI aspect, that a user may press, engage, or actuate to initiate, select, or turn on a VPFC or particular aspect of the closed loop control. For example, in some embodiments, the user may be provided with options to, for example, select and initiate the following: fiO (Fio) ₂ VPFC closed loop control but manual PEEP control or adjustment; or closed loop control of PEEP but manual FiO ₂ Control or adjustment. Further, in some embodiments, the user may be provided with the option to start, stop, or restart various types of closed loop control at different times so that the VPFC or other aspects of closed loop control are available, but also subject to disengagement, and thus are essentially on demand. Furthermore, as previously described, in some embodiments, during operation in terms of closed loop control, a user can change, for example, fiO ₂ Or PEEP, etc., and closed loop control may then be restored from that point and initially at that setting or settings. Further, in some embodiments, the user may be provided with an option to stop or disengage the VPFC or some other aspect of closed loop control, and the user may later resume the VPFC or some other aspect of closed loop control. Still further, in some embodiments, multiple or different users may supervise or manage the operation of the respiratory distress ventilator, such as at different times, and each user may take different actions.

In some embodiments, for example, a user (such as a minimally trained user, etc.) may initiate active mode ventilation in VPFC mode (or another aspect of closed loop control). At some point during active mode ventilation, the user or another user (such as a more trained user, etc.) may change from VPFC (or another aspect of closed loop control) to manual or more manual operation (whether via a respiratory distress ventilator or a remote control device). Alternatively, active mode ventilation may be initiated without a closed loop controlled VPFC or some other aspect, and closed loop controlled VPFC or some other aspect may be initiated or engaged later, such as in the event the user becomes distracted (or during periods of user distraction), or by a less trained user who may later arrive at the scene, for example.

According to some embodiments, an example overview of operation in VPFC system mode is provided below. In some embodiments, at the beginning of the initiation mode 302, or after the user selects the VPFC system mode, the user may be prompted (via a display, such as at a respiratory distress ventilator or remote control device, etc.) to enter the patient's gender and height. Thus, a controller (of a control device such as a respiratory distress ventilator, a remote control device, or another device or system) may determine an associated weight, which may be referred to as a patient's "predicted" weight (PBW). However, the determined body weight may not be the actual body weight of the patient, and may represent, for example, an ideal body weight, an approximate, typical, or other associated body weight used in determining or optimizing certain ventilation settings. For example, predicted weight may be used instead of actual weight, as actual weight may fluctuate widely from person to person due to differences in the amount of muscle and fat from person to person, and even between individuals with similar characteristics (such as height and gender, etc.), while lung volume, capacity, and function remain relatively unaffected by these factors. As such, in some embodiments, the PBW may be used, at least in part, as an indicator associated with the breathing capacity of an individual, and may generally be a better indicator than the actual patient weight.

During the initiation mode 302, the controller may utilize the PBW to determine one or more ventilation parameter settings to be used for one or several operational breaths to be delivered to the patient during the initiation mode, which may be used, for example, to confirm proper operation of the respiratory distress ventilator 4102, which may include confirming that no or significant leaks are present in the circuit. For example, PBW may be used to set an initial Vt, such as may be set to Vt (in mL) =a PBW, etc., where a may be, for example, 5, 6, 7, 8, or 9. Further, for example, the initial Ve (in mL/min) may be set to B PBW, where B may be, for example, 80, 90, 100, 110, or 120.

Once initiating mode 302 completes successfully, respiratory distress ventilator 4102 may enter test breathing mode 304. During test breath mode 304, one or more test breaths are delivered to the patient and breath data is obtained. The breathing data is used to determine one or more patient breathing parameters, such as estimated patient respiratory compliance (Crs), and in some embodiments, one or more additional parameters, such as estimated patient respiratory resistance (Rrs), and the like. The determined patient respiratory compliance (Crs) is then used to determine an initial inspiratory peak pressure (PIP (0)) setting to be used at the beginning of the active mode 306.

In some embodiments, the active mode 306 may include FiO ₂ And closed loop control of PEEP and/or possibly one or more other parameters. During the active mode 306, the central control 308 and ventilation control 310, fiO ₂ Control 312 and PEEP control 314 cooperatively set or adjust a control including FiO ₂ Ventilation settings for PEEP, PIP, target tidal volume (Vt), target minute volume (Ve), respiratory Rate (RR), inspiration to expiration ratio (I: E). However, in some embodiments, the ventilation control 310, fiO may be set or adjusted ₂ One or more of the controls 312, PEEP controls 314, or other aspects, or the one or more settings or adjustments that participate in some of these or other ventilation settings.

In some embodiments, the controller continuously monitors autoPEEP (PEEPi), which may be due to incomplete evacuation of the lungs during the exhalation phase being too short, and may create a risk of dynamic over-inflation of the lungs. In some embodiments, PEEPi is detected and measured based on the detection and measurement of airflow present at the end of the expiration period. When PEEPi is detected, in some embodiments, the controller may continuously adjust I: E to increase exhalation, or may decrease Vt/kg, which may increase the evacuation of gas to eliminate PEEPi.

As described in detail herein, the controller may utilize a target SpO ₂ Such as 94%, etc. (however, in various embodiments, the purpose isMark SpO ₂ For example, between 93% and 95%, between 93% and 96%, between 93% and 97%, between 93% and 98%, between 93% and 99%, between 94% and 95%, between 94% and 96%, between 94% and 97%, between 94% and 98%, between 94% and 99%, or another suitable range). Actually measured SpO of patient on a continuous basis ₂ Can be used for regulating FiO ₂ Input of settings, while FiO is changed ₂ The settings or adjustments may further be used to adjust PEEP settings.

In some embodiments, the patient end tidal carbon dioxide (EtCO ₂ ) The determined parameters of the determined patient airway pressure waveform (P), patient airway flow waveform (Vdot), and volume waveform (V) may be used to determine Vt, ve, PIP, RR and the active mode initial setting of I: E, and/or in some embodiments, parameters derived at least in part from the Vdot and V waveforms may be used, which may include platform pressure, drive pressure, respiratory compliance (Crs), and Rrs. Further, the controller may continuously use the determined patient respiratory compliance (Crs) and respiratory resistance (Rrs) to determine adjustments to Vt, such as may maintain Vt at a safe level, or the like. Controller 202 may also continuously adjust RR, such as maintaining Ve at a constant level while adjusting Vt, where Ve = Vt.

During the active mode 306, the controller may use continuously updated ventilation parameters (which may include FiO ₂ And PEEP) to deliver ventilation to the patient. It will be appreciated that other embodiments do not use the specific exemplary modes described herein.

In the initiating mode 302, the user may be prompted to enter the sex and height of the patient, which may be used to determine the patient's PBW. Based on the determined PBW of the patient, a number of ventilation parameter settings may be determined for use in the test breathing pattern 304.

In various embodiments, in the initiating mode, various calculations may be utilized to determine the test breathing parameter setting. In one example, in the use and study of pigs (examples of which are provided herein with reference to the following figures), vt (in ml) may be calculated as 10 x actual weight in kg, ve (in ml/min) may be calculated as 140 x actual weight in kg, and RR may be calculated as Ve/Vt, where RR may be rounded to the next higher integer value. However, various other calculations and values may be used in various embodiments.

In another example, in human use, the following calculations may be utilized. PBW (in kg) may be calculated as c+d (height in cm-E), where C may be, for example, between 35 and 60, D may be, for example, between 0.80 and 1.00, and E may be, for example, between 140 and 160, and where in some embodiments at least C may be lower for females than for males. Rounding to, for example, the nearest 3 to 7ml may be performed for Vt greater than or equal to, for example, a value between 150 to 250ml, and rounding to, for example, the nearest 0.5 to 3ml may be performed for Vt less than or equal to, for example, a value between 15 to 200 ml. However, various other calculations and values may be used in various embodiments, such as various calculations based on or functioning as height, gender, and/or one or more other patient body or health related characteristics.

In some embodiments, some or all of the results of the calculations performed in initiation mode 302 are displayed to the user. For example, the user may be prompted (e.g., at the respiratory distress ventilator or remote control device) to accept the determined parameters and then couple the patient to the ventilator.

In some embodiments, after completion of the initiation mode 302, the controller enters the test breath mode 304. In test breath mode 304, the system may deliver one or more ventilation test breaths based on which the system may determine one or more patient parameters and/or particular ventilator settings utilized at the beginning of active mode 306. For example, in some embodiments, in test breath mode 304, patient Crs, such as estimated patient Crs, is determined and used to determine PIP (0) ventilator settings. In some embodiments, respiratory compliance (Crs) may be calculated or estimated using patient respiratory kinetic data and equations of motion of the respiratory system. Furthermore, in some embodiments, the call is testedIn the suction mode 304, the following specific parameter settings may be used: i: e=1:3, peep=5 cm H ₂ O，FiO ₂ =0.5 (or 50%). However, in various embodiments, other initial settings may be used.

After successful completion of the test breath mode 304 and determination of the patient Crs, the controller may enter an active mode 306. In some embodiments, the system may enter the active mode 306 even if patient respiratory compliance (Crs) cannot be determined. For example, in some embodiments, if respiratory compliance (Crs) cannot be determined, a default respiratory compliance (Crs) value may be utilized. In some embodiments, the default value may be determined to be relatively high, as this may result in relatively small changes in the PIP correction value (Pcorr), thereby providing a relatively conservative approach.

In some embodiments, during the active mode 306, the controller delivers continuously adjusted ventilation to the patient, which may include closed loop control of one or more patient and/or ventilation-related parameters.

In some embodiments, during the active mode 306, the continuous adjustment includes FiO ₂ And a plurality of ventilation parameters of PEEP. Other parameters that are adjusted in a continuous manner during the ventilation mode 308 may include PIP, vt, ve, RR and I: E. In some embodiments, the target patient oxygenation level (such as 94% SpO ₂ Etc.) to continuously adjust FiO ₂ . In some embodiments, fiO ₂ Beginning at 21% (or e.g. 20 to 25%). However, in some embodiments, the user may select an initial FiO ₂ Setting, for example, between 21% and 100%, etc.

The central control 308 may provide data to the ventilation control 310, including current EtCO, on a continuous basis ₂ And pressure (P) and volume (V) waveforms, and/or parameters derived at least in part from the P and V waveforms. The ventilation control 310 may use this data (potentially in addition to other data) to determine Vt, ve, PIP, RR and I: E values, which are then sent to the central control 308. The central control 308 may then implement any appropriate adjustments to the Vt, ve, PIP, RR and i: E settings based at least in part on the transmitted values.

Furthermore, the central control 308 may provide the FiO with a continuous basis ₂ Control 312 provides a current patient SpO including ₂ Is a data of (a) a data of (b). FiO (Fio) ₂ Control 312 may use this data (potentially in addition to other data) to determine FiO ₂ Which is then sent to the central control 308. Central control 308 may then implement the FiO based at least in part on the transmitted values ₂ Any suitable adjustment of the settings. FiO (Fio) ₂ Adjustment of the settings may be achieved via appropriate actuation of the oxygen source valve, or by adjusting the oxygen concentration from the oxygen supply, or in other ways.

Still further, the central control 308 may provide the PEEP control 314 with information including the current FiO on a continuous basis ₂ And current PEEP data. The PEEP control 314 may then use this data (potentially in addition to other data) to determine an updated value of PEEP, which is then sent to the central control 308. Central control 308 may then implement any suitable adjustment to PEEP settings based at least in part on the transmitted values. For example, adjustment of the PEEP setting may be achieved via appropriate actuation of the exhalation valve of the respiratory distress ventilator 4102.

It will be appreciated that although central control 308, ventilation control 310, fiO ₂ Control 312 and PEEP control are illustrated separately and in communication with each other, but in some embodiments some or all of these aspects may be combined or integrated or may function independently. In such embodiments, communication between combined or integrated aspects may be less or may not be necessary.

Aspects of the invention include systems and methods that include generating Context Sensitive Guides (CSGs) for medical diagnosis and delivering medical interventions by medical treatment and diagnostic devices (e.g., by respiratory distress ventilator 4102, such as depicted in FIG. 1). Such systems and methods may additionally provide a guidance user interface for guiding and interacting with a context-sensitive guidance aspect of a provider of medical care. For example, the lead user interface may be implemented at a companion device communicatively coupled via wired and/or wireless communication link(s) to one or more medical treatment and/or diagnostic devices (e.g., patient monitor/defibrillator, ventilation system or device (such as respiratory distress ventilator 4102, etc.) and/or drug delivery device) for medical assessment interventions during emergency medical events. In some embodiments, for example, the CSG enabled companion device or another device or system may be a remote control device or system for the respiratory distress ventilator 4102.

The companion device (which may be a remote control device for the respiratory distress ventilator 4102 in some embodiments) may be a mobile computing device such as a tablet, personal display/digital assistant device, or telephone. In implementations, the companion device(s) may be preconfigured to be associated with medical treatment and/or diagnostic devices to streamline wireless communication pairing without having to go through time-consuming query and response negotiations for establishing a secure connection. In some embodiments, a companion device configured to operate with a medical treatment device may be used in an Emergency Medical Service (EMS) environment by trained emergency responders at an emergency site or during pre-hospital delivery. The companion device may also be used in the EMS during ground and air transport of patients between medical facilities. In some examples, the kit may also be used in hospital emergency rooms, general endo-surgery and intermediate care floors, heart care units, electrophysiology (EP) laboratories, operating rooms, and hospitals and/or other similar areas for in-hospital transport of patients.

In an example scenario, an emergency responder or other medical care provider of a patient or victim responsible for handling an emergency event may first visually evaluate the patient's performance. For example, such assessment may include observing patient responsiveness, any respiratory distress, confusion, visible wounds. In addition, caregivers may talk to family members or friends of conscious or unconscious patients to determine complaints, health history, or other information related to treatment. Upon initiating care, the caregiver may begin with an airway-respiratory-cycle (ABC) assessment. Based at least on the ABC assessment, the caregiver may connect the victim to the ventilator, patient monitor, and/or patient monitor/defibrillator to treat the patient exhibiting abnormal breathing and/or hemodynamic conditions. The caregivers may further step through the OPQRST assessment for any pain described and/or exhibited by the patient. "OPQRST" is a mnemonic used by emergency care providers to alert them to evaluate morbidity, exacerbation/relief, quality, radiation, severity, and time associated with patient pain.

Patients experiencing respiratory distress often require rapid and accurate targeted intervention. The caregivers may need to identify and effect the appropriate effective interventions within minutes to ensure that the patient is alive and that the nerves are intact. Such interventions include actions that directly contribute to the care of the patient's (one or more) presentation condition, and may determine the predisposition of the patient. The intervention may or may not treat the etiology of the presented condition(s). However, if the condition(s) present remains unchanged by intervention, the patient may not survive long enough to treat the root cause.

For example, patients may exhibit respiratory distress due to Congestive Heart Failure (CHF). In this case, respiratory distress has a cardiac etiology. Intervention to alleviate RD (such as providing oxygen to the patient to remedy hypoxia, etc.) is needed to keep the patient alive and the nerves intact until the etiology of the heart can be diagnosed and resolved by treatment. The treatment of heart failure may be separated from the intervention of oxygen. For example, the treatment may include angioplasty, hypertensive drugs, and/or arrhythmia drugs.

As another example, the patient may exhibit respiratory distress due to pneumonia. In this case, respiratory distress has a respiratory etiology. Here, intervention to alleviate RD (such as providing oxygen, etc.) is required until respiratory etiology can be diagnosed and resolved by treatment. For example, the treatment may include administration of antibiotics to the pneumonia infection.

As yet another example, the patient may be briefly exposed to an oxygen deficient gaseous environment. For example, the patient may be in an automobile or home where there is a carbon monoxide leak and thus be exposed to low oxygen levels. In this case, the intervention to provide oxygen also deals with the root cause of RD. In this case, once the root cause of hypoxia in the patient is diagnosed, the intervention will play the role of treatment.

Thus, as indicated by the above examples, all treatments are interventions, but not all interventions are treatments. Treatment includes actions taken by a caregiver to address the presenting condition as well as to present the root cause or etiology of the condition. The intervention includes actions by the caregiver in response to a particular presentation condition. In some cases, such actions may only address presenting the condition, and thus may not be a treatment of the etiology of the condition. In other cases, such actions may address the presenting conditions and the root causes of those conditions.

As described herein, the Context Sensitive Guidance (CSG) system provides care guidance (whether determined and/or provided by the respiratory distress ventilator 4102, remote control device, or another device or system) in the context of an initially presented condition of a patient before any reasonably accurate diagnosis is possible or in some cases even before such diagnosis is possible. The CSG system collects objective physiological and other medical data of a patient and identifies therapeutic interventions tailored to alleviate the physiological condition indicated by the data. The care guide identifies and enables intervention for the initially presented condition, which in some cases constitutes an acute and immediate risk to the patient's life. Once the patient is stable, the CSG system may provide further guidance in identifying a diagnosis or specific root cause and identifying and enabling treatment based on the diagnosis. In addition, CSG systems can monitor patients for recovery indicators of acute and potentially life threatening medical conditions. In various embodiments, the CSG may be determined and/or provided at a device including the respiratory distress ventilator 4102, a device that remotely controls the respiratory distress ventilator 4102, and/or other devices or systems, either local or offsite.

Based on the patient's initial performance and physiological data characterizing the initial performance, the caregiver and/or medical device system implements a care plan that includes a set of interventions for the initial performance. As care progresses, the caregiver and/or medical device system accumulates data from, for example, physiological sensors, diagnostic tests and images (such as blood tests, X-rays, ultrasound, etc.), as well as observed or measured patient conditions before and after various interventions administered to the patient. This data informs the differential diagnosis process. In the differential diagnosis process, the cause of the health impairment is excluded in a stepwise manner by the thus obtained identification or diagnosis of one or more causes or root causes. The goal of this process is diagnosis, in other words, to explicitly identify one or more root causes of the patient's health impairment, and to identify one or more treatments for the root causes based on the diagnosis. CSG systems protect the health of a patient during a differential diagnosis process by identifying and implementing the interventions necessary for an adverse medical condition originating from a root cause.

In some cases, CSG systems operable in a pre-hospital environment may identify both interventions and diagnostics. In other cases, the CSG system may recognize the intervention rather than the diagnosis. Diagnosis may not be performed until the patient is transported to a hospital and the results of the more extensive testing and trial treatments are analyzed. However, CSG enables effective providing of critical care, wherein without CSG, the patient will not survive or leave the nerve intact long enough to reach the diagnostic stage in many cases.

Returning to the example of RD, the respiratory component of the ABC assessment may indicate respiratory status from a patient without dyspnea to a patient with mild to severe dyspnea, to a patient who is alive but not breathing spontaneously at all. For these patients with no difficulty breathing, caregivers will initially focus their attention on non-respiratory presenting conditions such as trauma or sepsis.

For patients with dyspnea or no breathing at all, the caregivers will monitor both proper breathing and cardiac function. Respiratory distress may be of respiratory etiology, cardiac etiology, or a combination of root causes. However, regardless of the etiology, respiratory function and cardiac function are interrelated, and the presenting condition of respiratory distress requires cardiac monitoring, and vice versa. Thus, the CSG system, when applied to a respiratory representation of a patient, performs a respiratory/ventilation (R/V) algorithm based on the patient's respiratory and ventilation metrics in parallel with the hemodynamic metrics based algorithm. Thus, the caregivers of the victim of respiratory distress connect the patient to the medical devices described above, i.e., the ventilation system (such as respiratory distress ventilator 4102, etc.) and the patient monitor or patient monitor/defibrillator. These medical devices may monitor and measure respiratory health indicators (e.g., respiratory gas exchange and/or pulmonary mechanics) and cardiac health indicators (e.g., blood pressure, heart rate, and Electrocardiogram (ECG)). Respiratory gas exchange measurements may include, but are not limited to, pulse oximetry and capnography, and pulmonary mechanics measurements may include, but are not limited to, pulmonary elasticity and pulmonary resistance.

Several examples illustrate the need for parallel operation of the R/V algorithm and hemodynamic algorithm in implementing CSG for RD performance. As a first example, a patient exhibiting respiratory distress may have pneumonia. Patients need intervention for RD. However, pneumonia generally increases the heart rate of patients. If the heart rate is too high, an increase in heart rate may be an abnormal and life threatening condition, placing the patient at direct risk of death from cardiac dysfunction. Thus, in monitoring and effecting intervention of an RD for a patient, the CSG system must monitor hemodynamic index and effect cardiac intervention as needed.

As a second example, a patient exhibiting respiratory distress may suffer from CHF. Patients need intervention for RD. However, CHF may be due to arrhythmia that leads to a patient being susceptible to stroke. Thus, as with the pneumonia example, in monitoring and effecting intervention of RD for a patient, the CSG system must monitor hemodynamic index and effect cardiac intervention as needed.

In both examples, it is important to recognize that in pre-hospital care, such as in response to a 911 call, on a battlefield, or in another emergency treatment environment, a caregiver may at least initially be aware of only the presence condition and the condition revealed by the medical device. Thus, potential and possible chronic conditions may not be apparent or known to the caregivers. Thus, CSG systems for respiratory distress based on parallel monitoring of R/V and hemodynamics are critical in the treatment of respiratory distress manifestations. Pneumonia infections or chronic arrhythmias are likely to be unknown initially to the caregivers and by monitoring only two physiological systems, interventions can be applied correctly to survive the patient long enough for a subsequent diagnosis of these etiologies. This is in contrast to non-emergency hospital environments or doctor offices where patients and patient health histories are generally known and/or at least easily accessible to caregivers.

The CSG system may reside on the above-described companion device, a medical device (e.g., respiratory distress ventilator 4102 or CCM/defibrillator, etc.), another computing device or system, a cloud server, or a combination thereof. The CSG system may be communicatively coupled to the medical device and receive inputs from the medical device including physiological data collected by the medical device from the patient and data describing actions taken by the medical device during patient care. The CSG system may also provide a guide user interface and receive input from a caregiver at the guide user interface regarding patient medical data and/or actions taken by the caregiver. Based on the received data, the CSG system may identify clinical interventions and update previously identified interventions, and may generate an etiology estimate and determination. The CSG system may then instruct and/or control the medical device to perform a clinical intervention and/or provide patient record data and event markers to the medical device. The CSG system may also request specific patient data from the medical device. The CSG system may access medical records of a patient (e.g., electronic patient care records (ePCR) (i.e., patient charts) generated during a medical procedure, archived patient charts, records in a Health Information Exchange (HIE) or other regional database, and/or hospital Electronic Health Records (EHR)). Further, the CSG system may provide prompts and/or instructions to a caregiver at a guiding user interface to enable clinical intervention and guide patient care.

Referring to FIG. 30, an example of a context sensitive guided device configuration is shown. The amount of each component in fig. 30 is merely an example, and other amounts of each or any component may be used. As shown in fig. 30, at a patient care site 100, a rescuer or caregiver 103 attends to a victim or patient 101 (these terms are used interchangeably herein to indicate a person who is the subject of intended or actual medical treatment(s) and/or intervention), such as an individual at RD, or the like. The emergency care site 100 may be, for example, at the site of an accident or health emergency, in an ambulance, in an emergency room or hospital, or in another type of emergency situation. The rescuer 103 may be, for example: civilian responders with limited or no training in terms of life saving technology; a first responder, such as an Emergency Medical Technician (EMT), a caregiver, police, fire fighter, etc.; or a medical professional such as a doctor or nurse, etc. Rescuer 103 may act alone or may act with the assistance of one or more other rescuers, such as partner EMT 104 or the like.

In this illustration, rescuers 103, 104 may deploy medical/other device(s) 180 (e.g., respiratory distress ventilator 4102, CCM/defibrillator, other medical or monitoring devices, or other portable computing devices, etc.) coupled to patient interface device 170. For example, the medical/other device(s) 180 may be medical treatment delivery device(s) configured to collect physiological data from a patient via the patient interface device 170, monitor the data, and deliver treatment (e.g., electrotherapy or respiratory treatment) to the patient based on the collected and monitored data.

The patient interface device 170 may also include other sensors for monitoring parameters indicative of the patient's health condition (e.g., physical parameters such as the patient's heart rate, temperature, respiration rate, blood oxygen level, blood glucose level, etc., or other parameters indicative of the patient's health condition). Some sensors (such as heart rate or ECG sensors, etc.) may be included in electrode pads coupled to the patient monitor/defibrillator. Additionally, the one or more sensors may monitor the treatment(s) and/or intervention(s) delivered to the patient 101. For example, when the rescuer 103 administers CPR by detecting the rate, depth, or duration of compressions delivered to the patient 101, the compression tray can be positioned under the hand of the rescuer 103. Additionally, airflow sensors included in, for example, respiratory distress ventilator 4102 may monitor the volume and rate of respiration administered to patient 101 by rescuers 103, 104. Thus, some sensors may monitor both parameters indicative of the patient's health condition and parameters indicative of the treatment and/or intervention delivered to the patient.

The rescuer 103, 104 can use at least one accessory 105. The companion device 105 may be a mobile device such as, but not limited to, a smart phone, a tablet, or a wearable device (e.g., a watch or glasses), etc. The rescuer(s) may also utilize additional computing devices, such as a laptop computer or computing device integrated into the ambulance, etc., which may be used to analyze the health data about the patient or data indicative of the treatment and/or intervention delivered to the patient, or to communicate such data to a remote location (e.g., dispatch center, emergency room, or remote server).

Companion device 105 and medical/other device 180 may be communicatively coupled to each other via a local wireless communication channel 199 established between the devices. In implementations, the devices 105 and/or 180 may also be communicatively coupled to other medical and/or computing devices at the emergency site 100. The communication channel 199 enables safe and accurate sharing of data between two or more devices at the emergency site 100. During deployment of the medical/other device(s) 180, the devices may store one or more patient diagnostic data files 188, the one or more patient diagnostic data files 188 including records of data collected during patient cases and treatment and/or intervention of the medical device(s), as well as records of device settings and operations during patient cases.

Companion device 105 may include a processor 108 and a memory 109. Memory 109 may store CSG algorithm 121, which includes instructions executable by processor 108 to implement CSG processor module 120. CSG algorithm 121 may implement CSG User Interface (UI) 110 at one or more input/output devices of companion device 105, including, for example, a display and/or one or more audio and/or haptic devices. However, in other embodiments, one or more other devices and their processors and memories may be used in these aspects.

Additionally, companion device 105 (or other device) may include a patient mapping application 131. The patient mapping application 131 may generate an electronic patient care record (ePCR) as a simultaneous record of caregiver observations, provided treatments and interventions, patient physiological data, patient delivery, delivery destination, time and duration of patient care activities, emergency personnel identification, patient demographic information, patient health insurance information, and the like. The information entered into the ePCR may be entries from a caregiver captured by a companion device (e.g., touch screen or keyboard entries, voice entries), entries via one or more input devices (e.g., scanner, microphone, camera, etc.), and/or automatic entries from a communicatively coupled device or database. The application 131 may operate in parallel or in cooperation with the CSG algorithm 121. In an implementation, the CSG processor module 120 may implement the patient mapping application 131 and the CSG algorithm 121 through a combined user interface.

Referring to fig. 31, an example of a CSG algorithm and corresponding processor module is schematically illustrated, such as may be stored and executed using a controller of an apparatus (or system, local or offsite) (such as a respiratory distress ventilator 4102, CCM/defibrillator or other apparatus or system, etc.) including a processor and memory, such as may be used for remote control of respiratory distress ventilator 4102, etc. CSG algorithm 121 may include instructions stored in a non-transitory medium and executable by an apparatus. CSG algorithm 121, which may be stored in a memory of the device, includes CSG initialization algorithm 411, respiratory distress manifestation CSG algorithm 422, and non-RD manifestation CSG algorithm 455. For example, CSG processor module 120 of processor 108 at companion device 105 may execute CSG algorithm 121.CSG processor module 120 includes a CSG initialization processor module 401, a respiratory distress manifestation CSG processor module 402, and a non-RD manifestation CSG processor module 405.

Examples of CSG algorithms 121 as described herein are partitioned based on the performance of patients with or without RD. However, this is merely an example, and in other examples, CSG algorithms may be structurally organized around one or more other clinical conditions (e.g., patient performance with or without cardiac distress, emergency vs non-emergency conditions, patient performance with or without trauma, etc.). In practice, patients often exhibit multiple clinical conditions, and thus multiple algorithms run concurrently while managing interactions with users of the algorithms and communicatively coupled devices to guide, monitor and control patient care.

CSG initialization algorithm 411 may be executed by CSG initialization processor module 401. CSG initialization algorithm 411 initiates care with a caregiver assessment of the medical care recipient and initiates an appropriate CSG algorithm based on the caregiver assessment.

In the presence of a respiratory distress manifestation, CSG initialization algorithm 411 initiates a respiratory distress manifestation CSG algorithm 422 executable by respiratory distress manifestation CSG processor module 402. The respiratory distress manifestation CSG algorithms 422 include an R/V algorithm 433 executable by the R/V processor module 403 and a hemodynamic algorithm 444 executable by the hemodynamic processor module 404. The R/V algorithm 433 is discussed in more detail with respect to FIGS. 7-11, and the hemodynamic algorithm 444 is discussed in more detail with respect to FIG. 12. The R/V algorithm 433 directs, monitors, and/or controls patient respiratory and ventilation care as provided by the medical device(s) 180 and caregivers 103. The hemodynamic algorithm 444 directs, monitors, and/or controls patient hemodynamic care as provided by the medical device(s) 180 and the caregiver 103.

In the absence of respiratory distress manifestations, CSG initialization algorithm 411 initiates a non-RD-manifestation CSG algorithm executable by non-RD-manifestation CSG processor module 405. In various implementations, the non-RD-performing CSG algorithm 455 may perform functions similar to those described herein for the respiratory distress performing CSG algorithm 422. However, rather than performing these functions in the context of respiratory performance, the non-RD-performance CSG algorithm performs these functions in the context of non-RD performance (e.g., without limitation, cardiac performance, wound performance, sepsis performance, etc.). In these cases, the medical/other device(s) 180 may include a ventilation system 280, a patient monitor/defibrillator 285, and/or other medical/other devices suitable for the particular patient's performance. In an implementation, the respiratory distress performance algorithm 422 and the non-RD performance algorithm 455 may run in parallel for patients with multiple performance.

Referring to fig. 32A-32C, an example of a method 500 of providing context-sensitive guidance is shown. However, the method 500 is merely exemplary and not limiting. The method 500 may be altered, for example, by having stages added, removed, rearranged, combined, and/or performed in parallel. In various other exemplary implementations, CSG algorithm 121 may apply method 500 to another patient performance, such as, but not limited to, respiration, cardiac performance, wound performance, sepsis performance, neurological performance (such as stroke, drug overdose), and the like.

At stage 503, the method includes receiving first physiological data from one or more medical devices. For example, the CSG processor module 120 at the companion device 105 or cloud server may receive the first physiological data from the medical/other device(s) 180. In implementations, the caregiver 103 can couple the medical/other device(s) 180 to the patient or victim 101 via the patient interface device 170 to initiate patient care. The patient interface device 170 may collect and/or measure one or more physiological parameters of the patient 101. The medical/other device(s) 240 may provide the first physiological data as CSG inputs to the CSG processor module 120.

In an implementation, stage 503 may also include receiving a portion of the first physiological data from CSG UI 110. The caregivers 103, 104 may provide user input to the user interface 110, including physiological data, such as patient information observed by the caregivers and/or measured by the caregivers without using the medical device(s) 180, etc. CSG UI 110 may provide the user input as CSG input to CSG processor module 120.

At stage 506, the method includes evaluating the first physiological data. For example, CSG processor module 120 at companion device 105 or cloud server(s) 398 may execute CSG algorithm 121 to evaluate the first physiological data. In an implementation, CSG algorithm 121 may evaluate all or a portion of the first physiological data and may focus the evaluation on determining one or more physiological parameters of the initial intervention. The initial intervention may be the same intervention, regardless of the etiology of the patient's performance. For example, a physiological parameter indicative of abnormal oxygen levels, cardiac arrhythmias, or massive blood loss is indicative of an initial life-saving intervention. In the case of abnormal oxygen levels, the cause may be, for example, exposure to gas leakage or asthma. Although these are different etiologies that require different treatments later in the care of the patient, the initial intervention for oxygen supplementation may be the same.

In various implementations, the CSG algorithm 121 may evaluate the first physiological data according to one of various analyses. For example, the evaluation of the first physiological data may include comparing one or more physiological parameters to a target range, a target minimum, and/or a target maximum of parameters. Each parameter may correspond to a respective target range, minimum, and/or maximum. CSG algorithm 121 may flag any of the one or more parameters that are out of the target range, below a minimum value, and/or above a maximum value.

At stage 509, the method includes identifying a clinical intervention based on the evaluation. For example, CSG processor module 120 at companion device 105 or cloud server may execute CSG algorithm 121 to identify a clinical intervention.

The CSG algorithm 121 determines or selects at least one clinical intervention based at least in part on the received physiological data and an evaluation of the data. In some implementations, CSG algorithm 121 may receive and evaluate medical history data and/or data entered by a user at CSG UI 110 based on caregiver observations and evaluations. CSG algorithm 121 may select at least one clinical intervention from a series of interventions according to a protocol (e.g., clinical practice guidelines and/or standard of care) that may include, for example, the following: pharmacology, supplement O ₂ Mechanical respiration or ventilation support (which may include various forms of CLC), additional monitoring, or logistical instructions with respect to patient management. CSG algorithm 121 may include one or more predetermined clinical interventions. Each clinical intervention may correspond to a particular value of one or more physiological parameters. CSG algorithm 121 may access, for example, protocols stored in one or more memories (e.g., clinical practice guidelines and/or care labels)Quasi-). These protocols may be predetermined by a user of the CSG system and/or by an administrator or medical supervisor of an emergency agency or other care provider service. In implementations, the protocol may be customized by a user, administrator, and/or medical supervisor. In an implementation, CSG algorithm 121 may allow for customizing the protocol at the time of care. In implementations, the remote caregiver can select, provide, create, and/or customize or otherwise edit the predetermined protocol.

At stage 512, the method includes sending instructions to the medical device(s) based on the clinical intervention. The instructions may include implementation instructions for clinical intervention and/or event marker(s) for clinical intervention. For example, the CSG processor module 120 at the companion device 105 or cloud server may send instructions as CSG output to the medical device(s) 180.

The implementation instructions may include control signals for causing the medical/other device(s) 180 to initiate or implement a particular intervention and/or to set an intervention delivery or operating parameter of the medical/other device(s) 180. In an implementation, the medical/other device(s) 180 and/or CSG UI 110 may request user confirmation. The medical/other device(s) may initiate or effect a particular intervention and/or change or set delivery or operating parameters in response to receiving a user confirmation.

The instructions may include instructions for the medical/other device(s) 180 to record one or more event markers associated with the evaluation of the first physiological data and/or the identified clinical intervention. In an implementation, the instructions may include event markers. The medical/other device(s) 180 may record one or more event markers in response to receiving event markers and/or event marker instructions from the CSG processor module 120. The medical/other device(s) 180 may record one or more event markers in the patient diagnostic data file(s) 188 in the memory 187. In implementations, the medical device(s) may transmit the patient diagnostic data file(s) 188 to the cloud server during or after a patient diagnostic to be stored as medical device data files in memory. In an implementation, the medical/other device(s) 180 may transmit one or more event markers to the cloud server for recording in the medical device data file.

In an implementation, the method may include sending an instruction to CSG UI 110 as CSG output 225. The instructions sent to CSG UI 110 may include prompts for a caregiver to perform a particular intervention or other care activity, prompts for the caregiver to provide confirmation or other information prior to the intervention, prompts for the caregiver to adjust or set particular parameters at medical device(s) 180, prompts for the caregiver to couple or decouple a particular patient interface device 170 to a patient, alerts for the caregiver, and/or messages informing the caregiver of actions to be taken or taken by medical/other device(s) 180. The instructions sent to CSG UI 110 may also include instructional or other instruction feedback to ensure that the care task of the caregiver is properly performed.

Sending the instruction to CSG UI 110 may include sending the instruction to one or more companion devices. For example, in an implementation, CSG processor module 120 may send instructions and/or other CSG outputs 225 to one or more companion devices 105 at the patient's site. As another example, in an implementation, CSG processor module 120 may send instructions and/or other CSG outputs to one or more companion devices at a patient site and one or more companion devices located off-patient site. In an implementation, an offsite caregiver may view CSG interface 110 at an offsite companion device. The offsite caregiver may provide user input to CSG interface 110 at the offsite companion device and offsite companion device 105b may transmit the user input to the companion device, medical/other device(s) 180, and/or cloud server via one or more wired or wireless connections or networks.

At stage 515, the method includes receiving second physiological data from the medical/other device(s). For example, the CSG processor module 120 at the companion device 105 or cloud server may receive the second physiological data from the medical/other device(s) 180. The second physiological data may be the same type of data as the first physiological data, a different type of data, or a combination thereof.

For example, the first physiological data may include pulse oximetry (SpO) ₂ ) Measured values or waveforms and end tidal carbon dioxide (EtCO ₂ ) Measured values or waveforms. The second physiological data may include pulmonary mechanics data (e.g., resistance and elasticity), which is a different type of data than the first physiological data. Alternatively, the second physiological data may include updated measurements of the same type of data as the first physiological data, e.g., updated SpO ₂ And/or EtCO ₂ Data. As another alternative, the second physiological data may comprise updated measurements of the first physiological data combined with different types of data. For example, the second physiological data may include updated SpO combined with pulmonary mechanics data (e.g., resistance and/or elasticity data) ₂ And/or EtCO ₂ Data.

As another example, the first physiological data may include blood pressure and heart rate data. The second physiological data may include updated blood pressure and heart rate data. Alternatively, the second physiological data may comprise a new type of data, such as ECG data. As another alternative, the second physiological data may include a combination of updated blood pressure and/or updated heart rate data with new types of data (e.g., ECG data).

As described above, the instructions to CSG UI 110 may include instructions for a caregiver to couple or decouple a particular patient interface device 170 to or from a patient. In an implementation, the patient interface device 170 that the caregiver couples to the patient in response to the instruction may be a source of the second physiological data. For example, a caregiver may initially couple a patient to a patient as first physiological data (e.g., spO ₂ And EtCO ₂ Data) and then couple the patient to the ventilation system 280, which is a source of second physiological data (e.g., pulmonary mechanics data).

In another example, CSG UI 110 may include instructions for a caregiver to couple an electroencephalograph (EEG) patient interface device 170 to a patient as a source of second physiological data. In another example, an EEG may be configured to measure the so-called depth of anesthesia via a method such as a double frequency (BIS) index that may be used to distinguish between overdose and stroke. If the CSG engine determines that the more likely cause of the neurological problem is overdose, the proposed therapeutic intervention will be to deliver a naloxone dose.

At stage 518, the method includes evaluating the second physiological data. For example, the CSG processor module 120 at the companion device 105 or cloud server may execute the CSG algorithm 121 to evaluate the second physiological data. In various implementations, the CSG algorithm 121 may evaluate the second physiological data according to one of the various analyses described above with respect to the first physiological data.

At stage 521, the method includes updating the clinical intervention based on the second physiological measurement. For example, CSG processor module 120 at companion device 105 or cloud server may execute CSG algorithm 121 to update the clinical intervention. The clinical intervention identified at stage 509 may be a first clinical intervention and the updated clinical intervention from stage 521 may be a second clinical intervention. Updating the clinical intervention may include maintaining the first clinical intervention in progress from stage 512. In this case, the update is a verification of the ongoing clinical intervention. For example, if the first clinical intervention at stage 512 is at a particular flow rate and a particular FiO ₂ High Flow Nasal Cannula (HFNC) (fraction of inhaled oxygen concentration), which may be implemented by respiratory distress ventilator 4102, then the update at stage 521 may be validated and continued such that the second intervention at stage 521 is also at the same flow rate and FiO ₂ Is a HFNC of (c). Alternatively, updating the clinical intervention may include continuing to provide the same type of clinical intervention, but modifying parameters of the clinical intervention. For example, if the first clinical intervention at stage 512 is at a particular flow rate and a particular FiO ₂ The update at stage 521 may modify the first intervention so that the second intervention at stage 521 is also HFNC, but at a different flow rate and/or FiO ₂ . As another alternative, updating the clinical intervention may include using a second interventionSupplementing the first clinical intervention. For example, if the first clinical intervention at stage 512 is at a particular flow rate and a particular FiO ₂ The update at stage 521 may supplement the first intervention such that the second intervention is a combination of the (maintained or modified) first intervention with one or more additional interventions. For example, the additional intervention may be a HFNC-equipped CPAP, a HFNC-equipped pharmaceutical intervention, or a combination of CPAP and HFNC-equipped pharmaceutical intervention. As yet another alternative, updating the clinical intervention may include replacing the first clinical intervention with one or more second interventions. For example, at stage 521, the system may terminate the HFNC and replace it with CPAP.

CSG algorithm 121 may update at least one clinical intervention based on a series of intervention types and parameters according to a protocol. CSG algorithm 121 may update at least one clinical intervention according to an implementation substantially similar to that described above with respect to stage 509 (e.g., identification of a clinical intervention based on first physiological data).

At stage 524, the method includes sending updated instructions to the medical/other device(s) based on and indicative of the updated clinical intervention. The updated instructions may include instructions for the medical/other device(s) 180 to effect a clinical intervention and/or instructions for recording event marker(s) of the clinical intervention. For example, the CSG processor module 120 at the companion device 105 or cloud server may send updated instructions to the medical/other device(s) 180.

In an implementation, stages 515, 518, and 521 may occur substantially simultaneously or in rapid succession with stages 503, 506, and 509. If the medical/other device and sensor providing the first and second physiological data are the same, the first clinical intervention may occur as a rapid response that the caregiver presents to the patient when initiating the intervention, and the second clinical intervention may fine tune the response based on the data collection of the medical device and sensor. However, if the caregiver has to connect the patient to the initial sensor to receive the first physiological data and then to the additional sensor to receive the second physiological dataThe time proximity of these phases may depend on the speed at which the caregiver may connect the various sensors. Furthermore, the first physiological data is not limited to a single type of data, but may be one or more types of physiological data collected based on an initial impression of the caregiver. For example, as discussed below, if the patient exhibits respiratory distress, the first physiological data may include SpO ₂ And EtCO ₂ Both data are used to assess respiratory distress. The first physiological data may also include heart rate, blood pressure, and other vital signs used to initially characterize or identify a patient condition. Similarly, the second physiological data is not limited to a single type of data. The second physiological data may be the same type(s) of data as the first physiological data, but corresponds to a later time. Thus, the second physiological data may reflect a change in condition of the patient in response to the first intervention according to the same metric. Alternatively, the second physiological data may add a new type of data by adding sensors that may reflect not only changes in the condition of the patient in response to the first intervention, but may also improve the characterization of the condition of the patient by adding additional metrics. For example, as discussed below, the first physiological data may include a breath gas analysis (e.g., spO ₂ And EtCO ₂ ) The second physiological data may then include pulmonary mechanics data (e.g., lung elasticity and resistance). Pulmonary mechanics data may enable caregivers and medical devices to improve intervention based on a more detailed understanding of the patient's condition provided by adding second physiological data.

At stage 524, the method 500 follows the "X" connector to continue to the monitoring loop 590 shown in FIG. 32B. In addition, the method 500 optionally follows the "Y" connector to continue to the etiology sequence 595 shown in fig. 32C. The monitoring loop 590 runs concurrently with the etiology sequence 595.

As shown in fig. 32B, method 500 enters a monitoring loop 590 at an X connection point 598. At this point of method 500, the patient is connected to the medical device via the patient interface device required to provide the first physiological data and the second physiological data. For example, the patient may via SpO for the first physiological data ₂ Sensor and EtCO ₂ The sensor is connected to a patient monitor/defibrillator. In addition, the patient may also be connected to respiratory distress ventilator 4102 via an airway pressure sensor and a respiratory rate meter for the second physiological data. The patient monitor/defibrillator may also be connected to the patient via electrodes to monitor heart rate, to the patient via an NIBP sensor to measure blood pressure, and/or to the patient via one or more of the other patient interface devices 170, as determined by patient presentation. Thus, at stage 527, csg algorithm 121 is monitoring data (e.g., first physiological data and second physiological data) acquired from the patient by medical/other device(s) 180 via patient interface device 170 attached to the patient. Further, at stage 527, the first and second physiological data are provided to CSG algorithm 121 substantially continuously (e.g., non-invasive blood pressure (NIBP) measurements are typically taken every 5 minutes, heart rate is typically recalculated every QRS and updated about every 1 to 2 seconds, heart rate is calculated at an average of 2 to 6 QRS intervals, pulse oximetry measurements are updated about every 1 to 2 seconds, capnography is updated every detected breath, etc.).

Once the patient is connected to the medical/other device(s) 180, the patient remains connected and the CSG algorithm 121 monitors the data, e.g., according to the monitoring cycle 590, until the patient's present condition is resolved and/or until the patient's care is turned (e.g., EMS arrives at the hospital and the patient is transferred to the hospital's care, patient leaves the ICU, patient discharge, caregiver determines that an emergency condition is resolved and/or diagnosed, patient death, etc.).

The data monitoring at stage 527 occurs after the medical/other device has achieved and updated clinical intervention in response to the instructions at stages 512 and 524 in fig. 32A. At least a portion of the data monitoring at stage 527 enables evaluation of the impact of the previously applied intervention on the patient's physiological system at stage 533. Additionally, the purpose of data monitoring at stage 527 enables the assessment of the patient condition at stage 533 without any intervening changes or supplements to determine whether a change or supplement is needed to remedy the condition identified based on the assessment.

To properly evaluate the monitoring data at stage 533, the monitoring stage 527 and the evaluation stage 533 are separated by steady state query 530. The steady state query 530 accounts for possible hysteresis between the application of the intervention and the performance of the intervention in the physiological data. More specifically, if the caregiver and medical/other device(s) 180 are at time T ₁ Where an intervention is applied to the patient, the performance of the intervention in the monitored physiological data may not be instantaneous and may be at time T ₂ Where occurs, where (T) ₂ -T ₁ ) Approximately equal to the aforementioned hysteresis (also referred to as steady-state delay). The duration of this steady state delay for any particular intervention and sensor data combination depends on a number of factors including, but not limited to, the type of intervention, the type of sensor used to collect data indicative of the effect of the intervention on the patient, the position of the sensor on the patient's body relative to the target location of the intervention, the type of physiological response to the intervention, the number and type of co-occurring physiological conditions and/or co-morbidity in the patient that affect the effectiveness of the intervention, the number and type of co-occurring interventions that affect the effectiveness of the intervention, and the electronic connection between the sensor, the medical device(s), and the user interface.

For example, CSG algorithm 121 may be responsive to SpO indicating hypoxia ₂ Provides instructions for clinical intervention of the HFNC. CSG algorithm 121 may monitor SpO at stage 527 ₂ A signal and evaluate the signal at stage 533. However, HFNC vs SpO ₂ The influence of the signal can be related to the time of application of the HFNC to the patient and the monitored SpO ₂ The signal indicates a steady state delay correlation between times of the HFNC's effect on the patient's lungs. The delay may vary in duration between the finger blood oxygen detector and the earlobe blood oxygen detector. Furthermore, the delay may depend on other factors (e.g., anesthesia, walking, blood pressure, weight, heart condition, medication, etc.) that affect the oxygen saturation and blood circulation of the blood of a particular patient. CSG algorithm 121 may apply an empirical derivative corresponding to the average lag time or to a predetermined number of standard deviations between average lag time + stages 527 and 533The steady state delay is shown. For example, the duration of the steady state delay may be a value between 10 and 40 seconds, or in some cases, between 30 and 300 seconds. The CSG system may apply this delay any time that data is monitored and evaluated after intervention is applied. Thus, at stage 530, csg algorithm 121 continues to monitor physiological data and wait for a predetermined duration of steady state delay until evaluation stage 533 is entered. If the steady state delay is not applied by the system, the system may adversely affect patient care by unnecessarily and/or erroneously altering the intervention before accurately assessing the data indicative of the effectiveness of the intervention.

At stage 533, csg algorithm 121 evaluates the monitored first and second physiological data in a manner similar to that described above in stages 506 and 518. Based on the evaluation, CSG algorithm 121 updates the clinical intervention at stage 539. As similarly described for stage 521, updating the clinical intervention may include maintaining the ongoing intervention, modifying parameters of the ongoing intervention, supplementing the ongoing intervention, or replacing the ongoing intervention with one or more other and different interventions.

At stage 536, CSG algorithm 121 provides updated instructions to the medical device(s) based on the updated clinical intervention, as similarly described for stage 524. CSG algorithm 121 then returns to stage 527 to continue monitoring the physiological data.

Optionally, in parallel with the monitoring cycle 590, the method 500 may implement the etiology sequence 595 after stage 524 and as shown in fig. 32C. Method 500 may enter the sequence at "Y" connection point 599 and proceed to stage 555.

At stage 555, the method includes generating an etiology estimate based on the first physiological data and the second physiological data. For example, CSG processor module 120 at companion device 105 or cloud server may execute CSG algorithm 121 to generate an etiology estimate. Based on the first physiological data and the second physiological data, the CSG algorithm 121 may initiate a etiology differentiation engine with the etiology estimation. The etiology estimation indicates a broad etiology category clinically indicated by the first physiological data and the second physiological data, and the etiology differentiation engine may convert the etiology estimation from the etiology category to an etiology determination. For example, the first physiological data and the second physiological data of respiratory distress may be indicative of an etiology estimate of an obstructive pulmonary condition. However, obstructive pulmonary disease conditions are estimated rather than determined, as obstructive pulmonary conditions may originate from a variety of different underlying conditions, such as Chronic Obstructive Pulmonary Disease (COPD), asthma, and the like. In order to distinguish between these two causes, the CSG algorithm 121 may require additional information in addition to the first physiological data and the second physiological data. However, the first physiological data and the second physiological data enable the CSG algorithm 121 to guide, monitor and control the intervention of providing therapy (potentially life-saving therapy) to the patient while the diagnostic process is ongoing. The benefit of the CSG algorithm 121 is that the provided interventions are context sensitive, as they are tailored to at least the specific physiological context defined by the first and second physiological data and the interaction between the CSG algorithm 121 and the medical/other device(s) 180.

At stage 560, the method includes requesting target physiological data based on the etiology estimate. For example, the CSG processor module 120 at the companion device 105 or cloud server may request target physiological data from the medical/other device(s) 180. CSG algorithm 121 may identify and CSG processor module 120 may request one or more physiological data that may differentiate between various etiological determinations over a broader range of etiological estimates. For example, the etiology of an obstructive pulmonary condition is estimated to be indicative of both COPD and asthma. However, spirometric data and/or exhaled nitric oxide data may distinguish COPD from asthma. These one or more physiological data may distinguish the etiology individually and/or may distinguish in the population.

The CSG processor module 120 can send a request for the identified target physiological data as a CSG output to the medical/other device 180 and/or can send the request as a CSG output to the CSG UI 110 to the companion device 105.

The request for the medical device(s) 180 may include instructions to send data, or may include instructions to collect and send data. In an implementation, the medical/other device(s) 180 may collect the target physiological data in response to a request from the CSG processor module 120. Thus, the request may trigger the collection of target physiological data by the medical/other device(s) 180. Alternatively, the medical/other device(s) 180 may extract the target physiological data from the patient diagnostic data file 188 stored at the medical/other device(s) 180. The extracted and stored data may be collected by the medical/other device(s) 180 prior to a request from the CSG processor module 120.

The request for the companion device 105 may generate a prompt at the CSG UI 110 for the caregiver to enter or collect and enter the target physiological data. Thus, the caregiver may change the settings on the medical/other device(s) 180 and/or the patient interface device 170 that have been connected to the patient to collect this data. Alternatively, the caregiver may couple additional medical/other devices 180 or patient interface devices 170 to the patient to collect the requested data. CSG UI 110 may provide a user input field to capture requested data in response to user input of the data.

At stage 565, the method includes receiving target physiological data from the medical/other device(s) 180 and/or from the companion device 105. For example, the CSG processor module 120 at the companion device 105 or cloud server may receive target physiological data from the medical/other device(s) 180 and/or from the CSG UI 110 at the companion device 105. The medical/other device(s) 180 and/or companion device 105 may automatically provide the target physiological data in response to a request from CSG processor module 120 or may request user confirmation prior to providing the target physiological data.

Optionally, at stage 570, the method may include receiving medical history information for the patient. Additionally, in some implementations, the method 500 may include receiving medical history information at one or more of stage 502 and stage 515. Thus, one or more of stages 509 and 521 may include identifying and/or updating clinical interventions based on the medical history. Similarly, one or more of stages 555 and/or 580 may include generating and/or converting an etiology estimate based on the medical history. For example, the patient's medical history may include chronic conditions such as asthma, COPD, heart disease, or diabetes, among others. Such conditions inform of clinical intervention and may simplify the conversion of etiological estimates to etiological determinations. As another example, the medical history may include medications or diseases, such as infectious blood-borne diseases, that may also inform clinical intervention and/or simplify the conversion of etiology estimates to etiology determinations. In both examples, the medical history may provide information that disables one or more clinical interventions or indicates a need or potential need for additional clinical interventions other than those indicated by the physiological information collected by the medical/other device(s).

For example, CSG UI 110 (such as on respiratory distress ventilator 4102, a tablet, CCM/defibrillator, or other device or system) may capture a user input medical history of the patient. CSG UI 110 may prompt the user and/or provide selectable input fields for the user to provide a medical history. The user may obtain medical history from the patient and/or from a partner of the patient. For example, the user may interview the patient and/or patient's partners to obtain a medical history. The user or caregiver may also determine the medical history by observing and/or assessing the condition of the patient. For example, a user or caregiver may obtain information from a medical pre-alarm bracelet, from a medication container near the patient, from the site of patient emergency (e.g., chemical spill, car accident, illicit drug use, medical treatment equipment such as oxygen tanks or a wearable defibrillator, etc.). The user or caregiver may also observe the symptoms of the chronic or historic condition through physical examination of the patient. The companion device 105 may provide information provided at the CSG UI 110 as CSG input 230 from the UI to the CSG processor module 120. The information-providing companion device may be on-site with the patient (e.g., companion device 105 a) and/or may be an off-site companion device 105b in an off-site location. The offsite caregivers may have knowledge of and/or access to patient records and may provide medical history as input to CSG UI 110 at the offsite kit.

As another example, CSG processor module 120 may receive medical history information from one or more medical records databases via one or more networks. The CSG processor module 120 may send a query to one or more medical records databases regarding medical history information. CSG algorithm 121 may automatically generate a query during process 500 and/or CSG algorithm 121 may provide a user prompt and/or request a user confirmation at CSG UI 110 and generate a query in response to the prompt and/or confirmation.

Optionally, in an implementation, the method 500 may include identifying one or more supplemental clinical interventions at stage 575 based on the etiology determination and/or medical history information. CSG algorithm 121 may identify one or more clinical interventions, such as pharmaceutical interventions, that are determined specific to the etiology. For example, CSG algorithm 121 may determine administration of a bronchodilator as an additional clinical intervention based on a causal determination of COPD, while CSG algorithm 121 may determine administration of a corticosteroid as an additional clinical intervention based on a causal determination of asthma.

At stage 580, the method includes converting the etiology estimate to an etiology determination based on the target physiological data and/or medical history information. For example, CSG processor module 120 at companion device 105 or cloud server may execute CSG algorithm 121 to convert the etiology estimation to an etiology determination. As discussed above, the target physiological data may distinguish between various etiologic determinations over a broader range of etiologic estimates. Thus, in continuation of the example provided above with respect to stage 560, spirometry data showing a decrease in forced spirometry (FVC) may be indicative of COPD, while spirometry data showing a near normal FVC may be indicative of asthma. In this way, the spirometric data can distinguish between two possible etiologies of the obstructive pulmonary disease indicated by the first physiological data and the second physiological data. As another example, swelling of lung tissue associated with asthma may increase exhaled nitric oxide levels. Thus, such increased levels may indicate that the etiology determination of asthma is independent, or because such an increase may also occur with COPD, such an overall increase in spirometric data showing near normal FVC may support the etiology determination of asthma. In an implementation, the combination of the target data may enable conversion of the etiology estimation into the etiology determination. For example, the target data may include a combination of spirometry data, s3-s4 heart sounds, and lung fluid retention data measured by RF-based lung fluid measurements. Together, these data enable differentiation between CHF and COPD.

In an implementation, the CSG algorithm may utilize the medical history data as well as the target data to convert the etiology estimation to an etiology determination. For example, spirometry data alone may not distinguish between the various etiologies of obstructive pulmonary disease, but spirometry and medical history may provide such differentiation. As a more specific example, a spirometry in combination with a medical history indicative of exposure to asbestos may effect a etiology determination of asbestos lung disease, or a spirometry in combination with a medical history indicative of exposure to coal dust may effect a etiology determination of black lung disease. As another example, a combination of a medical history indicative of hypotension and heart disease with an etiology estimate including CHF may enable narrowing the etiology determination to CHF.

At stage 585, the method includes transmitting a etiology determination to the medical device(s) and the CSG UI. For example, companion device 105 or cloud server(s) may send a etiology determination to medical device(s) 180. The companion device 105 may provide a etiology determination at the CSG UI 110 in response to an instruction from the CSG algorithm 121. In an implementation, the cloud server(s) may execute CSG algorithm 121 to service CSG applications at the companion device 105 and provide etiology determination at CSG UI 110 at the companion device 105.

In an implementation, transmitting the etiology determination to the medical device(s) may include instructions for recording the etiology determination in a medical device data file for patient diagnosis and/or may include instructions for altering and/or initiating clinical intervention based on the etiology determination. For example, if CSG algorithm 121 identifies a drug intervention, the instructions may identify the drug as well as the dose and administration instructions.

In an implementation, sending the etiology determination to CSG UI 110 may include prompting for prompting the user to confirm the etiology determination and/or instructions to alter and/or initiate clinical intervention based on the etiology determination.

In an implementation, the CSG algorithm may also invoke a non-linear evaluation method at various stages of the method 500 described below (e.g., evaluate physiological parameters and update clinical interventions at stages 506, 521, 533, and 536, evaluate the evaluated physiological data to generate an etiology estimate at stage 555, identify supplemental clinical interventions based on the target data and optionally based on medical history at stage 565). The nonlinear evaluation of the plurality of physiological parameters may be used as a patient condition estimator, wherein the estimated patient condition corresponds to a particular intervention. For example, the estimated patient condition being hypoxia corresponds to an intervention to deliver supplemental oxygen to the patient.

One example of a patient condition estimator is kalman filtering. Typically, kalman filtering models linear systems with Gaussian distributions that may not be encountered in a physiological environment. Thus, at least one example of a patient condition estimator performs Extended Kalman Filtering (EKF) to address the problem of non-gaussian nonlinear filtering. EKF is based on the principle of linearizing measurement and evolution models using Taylor-series expansion. However, the series approximation in the EKF process may result in poor representation of the nonlinear function and probability distribution of interest. As a result, EKF may deviate. Thus, at least one example of a patient condition estimator performs unscented kalman filtering (kf) based on the assumption that it is easier to approximate a gaussian distribution than to approximate any nonlinear function. The UKF has been shown to bring more accurate results than the EKF, and generates a better estimate of the covariance of the state (the EKF generally appears to underestimate this amount). However, the limitation of UKF is that it is not applicable to general non-gaussian distributions, often as is the case with ECG spectral distributions.

Another example of a patient condition estimator is a sequential monte carlo process, also known as particle filtering. This example overcomes non-gaussian constraints and allows a posterior distribution of states to be represented entirely so that any statistical estimate, such as mean, mode, kurtosis, variance, etc., can be easily calculated. Thus, particle filtering can handle any nonlinearity or distribution. Particle filtering relies on importance sampling and as a result requires a design that can approximate the proposed distribution of the posterior distribution very reasonably. In general, it is difficult to design such suggestions. The most common strategy is to sample from a probabilistic model of state evolution (before transition). However, this strategy may fail if new measurements appear at the tail of the a priori, or if the likelihood is too high compared to the a priori.

Some other example patient condition estimators include estimator/predictor trajectory tracking techniques known as Unscented Particle Filtering (UPF), as well as other non-linear estimators, such as non-linear regression, neural networks, convolutional neural networks, and the like.

In some embodiments, the CSG algorithm may be based at least in part on a Hidden Markov Model (HMM) having as input a sequence of patient conditions and therapeutic intervention vectors. The state transition matrix may be developed using HMM techniques known to those skilled in the art. In particular, the basic patient states and the recommended therapeutic intervention primitives, as well as the sequences of condition and outcome intervention sentences, are modeled as Hidden Markov Models (HMMs), which are defined as variants of a finite state machine having a set of states Q, output alphabet O, transition probabilities a, output probabilities B, and initial state probabilities n. The current state is not observable. Instead, each state produces an output with a certain probability (B). In general, state Q and output O are understood, so HMM is called tri-state, λ= (a, B, n). Each value of the output alphabet O may be assigned a unique threshold and coefficient set. For example, as a result of training against a database or patient-specific training, the HMM will store transition probabilities therein, which indicates the "facts" of such understanding (i.e., therapeutic intervention grammars). For example, if a patient is given only one dose of vasopressor, the probability that the patient's blood pressure will drop beyond 20mmHg is very low: there must be intervention (blood pressure readings may be lost in noise) or alternatively blood pressure may decrease with sepsis, as a more likely estimate of the patient's underlying condition, where in this case the optimal therapeutic intervention would be to continue vascular compression, but also provide broad spectrum antibiotics for potential sepsis infections, and conduct point-of-care blood analysis to measure lactic acid.

Other techniques known in the art of HMM classification may be employed. For example, the discriminative training technique omits a pure statistical approach to HMM parameter estimation, but optimizes some of the class-dependent metrics of the training data. Some examples include the use of Maximum Mutual Information (MMI), minimum Classification Error (MCE), and Minimum Phoneme Error (MPE) and viterbi algorithms for finding the best path. Other techniques are to maintain a set of excellent candidates instead of just the best candidate, and score these excellent candidates using a better scoring function (re-scoring). The candidate set may be maintained as a list (N-best list method) or as a subset of models (lattice). Re-scoring may be performed to minimize bayesian risk.

In some embodiments, a so-called deep learning network may be employed. When no information about the object class labels is available, a deep network may be employed for unsupervised or generative learning to capture high-order correlations of observed or visible data for pattern analysis or synthesis purposes. Furthermore, deep networks can be used for supervised learning to directly provide discriminatory power for pattern classification purposes, typically by characterizing posterior distribution of classes conditional on visual data. Furthermore, hybrid depth networks may be employed in which the goal is to aid in discrimination with the results of a generative or unsupervised depth network. Other classification methods include, for example, deep Neural Networks (DNNs) and Recurrent Neural Networks (RNNs), convolutional Neural Networks (CNNs), limited Boltzman machines (RBMs), deep Belief Networks (DBNs), deep Boltzman Machines (DBMs), and the like.

Referring to fig. 33, a companion device configured to provide a device view user interface (which may be a remote control device for remotely controlling respiratory distress ventilator 4102 in some embodiments) is illustrated. Companion device 105 may be configured to provide a device view window 1315 such as shown in fig. 33. Another example of a device view window 1316 is shown in fig. 34 as discussed below.

The device view may improve care from a pair of caregivers and/or in a confusing emergency environment in which the picture of the medical device may not be easily accessed by all team members and/or may be inconveniently positioned for optimal viewing (e.g., under a gurney, on a mobile gurney, under an ambulance bench, etc.). For example, the first caregiver 103 may care for the victim 101 by assistance and treatment from the medical device (e.g., patient monitor/defibrillator, etc.) and the medical device display 310. The second caregiver 104 may prepare the medication or gurney, or handle another task without a view of the medical device/other display. In some scenarios, the second caregiver 104 may oversee a larger care team and possibly other victims. The second caregiver 104 can view the device view window 1315 on the companion tablet 105.

In some implementations, the companion device can display sensor data from one or more physiological sensors connected to the medical treatment device in real-time. In some examples, the companion device may display a visual representation of information displayed at the medical treatment device in the first display. This first display view (referred to as the device view) enables additional medical team members to participate in patient treatment without having to be in close proximity to the medical treatment device. For example, a rescue team supervisor (e.g., caregiver 104 in fig. 33) supervising and coordinating patient treatment during a critical patient care event (e.g., RD, chest pain, cardiac arrest, traumatic Brain Injury (TBI), RD, or critical care monitoring) may view the same waveforms and patient data displayed at the medical treatment device in real-time. This enables a supervisor or other medical team member to view both the rescuer treatment actions and the patient data simultaneously so that the supervisor can provide advice to further enhance patient treatment and coordinate the treatment of multiple rescuers. In some examples, the device view displays a visual representation of case information displayed at the medical treatment device.

The medical device data displayed in the device view of companion device 105 is a visual representation of information displayed at the display interface of medical/other device(s) 180 when one or more of the following visual aspects of the display interface of medical/other device(s) 180 are rendered in the device view: display layout, magnification of each data portion, physiological waveform selection, physiological digital readout selection, resolution, waveform duration, waveform size, text size, font, and display color. In some examples, the kit The visual rendering of the display of the medical/other device(s) 180 at the device 105 (which may include respiratory aspects) may accurately replicate the content displayed at the medical/other device(s) 180, or one or more of the visual aspects may be altered relative to the content displayed at the medical device(s) 180. In one example, the font and size of one or more items of the displayed case information may be enlarged and/or highlighted to attract the eyes of the user of companion device 105 to the corresponding case information. A certain type of waveform or other data may be amplified or color coded in a particular manner. For example, the ECG waveform may be similarly amplified (such as in a 12-lead analysis, etc.), or certain waveforms may be emphasized in terms of resolution, color, or other manner of reproduction. In some embodiments, a discontinuous physiological measurement (e.g., NIBP, spO) ₂ 、HR、EtCO ₂ ) The values of (c) may be shown in a similarly sized font or layout. In some cases, for example, the visual representation may be a copy of the information as presented on the display interface of the medical treatment device, or alternatively have minor variations thereof.

In some examples, the device view UI screen 1315 includes one or more selectable inputs at the display interface that cause more, different, or additional information to be displayed, cause one or more actions to be taken at the medical/other device(s) 180, or provide an additional user input interface screen that enables a user to submit information that may be transmitted to the medical/other device(s) 180. For example, device view 1315 may include one or more view selection tabs 1310, 1340, 1350, and 1370 that enable a user to switch between different display views for display at companion device 105. In one example, user selection of the selection tab 1310 causes a device view UI screen 1315 to be displayed at the companion device 105. The device view UI screen 1315 may display a plurality of waveforms and metrics indicative of the condition of the patient and/or the condition of the medical treatment being administered to the patient. For example, as shown in FIG. 33The device view window 1315 may display ECG waveforms 1320a and 1320b, pulse oximetry waveform 1320c and capnography waveform 1320d, and temperature 1320e, invasive blood pressures 1320f and 1320g, heart rate 1325a, pulse oximetry (SpO) ₂ ) Discrete measurement 1325b, end tidal carbon dioxide (EtCO ₂ ) Discrete measurement 1325c and non-invasive blood pressure (NIBP) 1325d.

In some examples, the visual representation may include an exact copy of the data displayed at the medical treatment device. In other examples, the visual representation may include data and format changes that may enhance the viewing and understanding of case information by the companion device user. In some examples, the display layout, magnification of the data portions, physiological waveform selection, physiological digital readout selection, resolution, waveform duration, waveform size, text size, font, and/or display color may be different from what is displayed at the medical treatment device(s).

In some implementations, the information displayed at the device view UI screen 1315 may be different from the information displayed at the display interface of the medical device(s) 180. In some examples, the differences between interfaces may include differences in the type of information displayed, display layout, or display format. For example, the magnification, resolution, size, and screen position of the data portions may vary between the device view UI screen 1315 and the display interface of the medical device(s) 180. Additionally, the relative waveform size and color, font, and text size may vary between device views 1315 at companion device 105. In one example, the device view UI screen 1315 may display the numerical values of all physiological case information in a waveform-free maximized large digital format. In some examples, the one or more items of case information displayed at the device view UI screen 1315 may be different from the case information displayed at the display of the medical device(s) 180.

In an implementation, the device view window 1315 may include a patient information control 1311. Activation of control 1311 may enable a user to enter patient identification information at companion device 105.

Referring to fig. 34, an example of a combined ventilation system/patient monitor-defibrillator device view user interface at a companion device is shown. In an implementation, one or more of the device view window 1315 and/or 1316, the work view window 1415, and the trend view window 1515 may include a device selection control 1399 (e.g., a patient monitor/defibrillator selection control 1399a, a ventilation system selection control 1399b, and a combination device selection control 1399 c). Control 1399 may enable a user to select data for display from a single medical/other device (e.g., patient monitor/defibrillator 285 or ventilation system 280, which may be a portable defibrillator or respiratory distress ventilator 4102), or to select a combined display. In one example, case information for each type of medical treatment device may be viewed at each individual display interface of the companion device. In another example, case information for different medical treatment devices may be combined within the same display interface screen at the companion device 105. In this way, the companion device user may customize the case information displayed at the companion device 105 as received from the medical/other device(s) 180.

The data provided in the example of the combined device view window shown in fig. 34 includes data collected by the patient monitor/defibrillator 285 through the ventilation system 280. For example, the ventilation system 280 may provide port information 1371, the fraction of inspired oxygen concentration (FiO ₂ ) Data 1372, peak Inspiratory Pressure (PIP) 1373, tidal Volume (VT) 1374, and breath count per minute (BPM) 1375. Additionally, ventilation system 280 may provide airway pressure waveforms (PAW) 1376. The device view window specific to the data collected by the patient monitor/defibrillator 285 may not include these values. The patient monitor/defibrillator 285 may provide HR 1380, spO ₂ Values 1381, invasive Blood Pressure (IBP) 1382, NIBP 1383, etCO ₂ 1384. ECG waveform 1385, spO ₂ Waveform 1386, etCO ₂ Waveform 1387 and IBP waveform 1376.

The patient monitor/defibrillator 285 or the ventilation system 280 may provide temperature data 1391. One or more of the patient monitor/defibrillator 285 and the ventilation system 280 may provide an alarm 1392.

Referring to fig. 35, an example of a medical device data screen is shown (which may be presented via a display of, for example, a respiratory distress ventilator 4102, CCM/defibrillator, tablet, or other device or system (which may include, for example, a device capable of remotely controlling respiratory distress ventilator 4102)). The medical device data screen 1660 may be a scrollable screen. The medical device data screen 1660 may be a scroll window such that a user may access a larger data set through a scroll gesture. In some implementations, companion device 105 may allow a user to customize the data displayed at medical device data screen 1660. For example, upon selection of the medical device data tab, companion device 105 may display a list of available medical device data for selection and/or deselection by the user based on viewing preferences. In some cases, data screen 1660 may be created and specifically customized during medical procedures by controls that allow viewers of companion device 105 to format medical device data at will. In an implementation, CSG algorithm 121 may subscribe to data screen 1660 based on a preference or disposition role of a user of the companion device

In an implementation, the medical device data screen 1660 may display physiological sensor data received from the medical/other device(s) 180. The medical device data screen 1660 may display the data as trends and/or waveforms (e.g., etCO ₂ 2238、SpO ₂ 2240. Airway data 2242, NIBP 2244, heart rate 2246, and ECG 2248). In some cases, the medical device data screen 1660 may be in a digital format (e.g., etCO ₂ 2250、SpO ₂ 2252. NIBP 2254 and HR 2256) and/or in a graphical format (e.g., etCO ₂ 2260、SpO ₂ 2261. Pulmonary resistance 2262, pulmonary elasticity 2263, NIBP 2264, and HR 2265) displays the physiological sensor data as discrete values.

In implementations, the display of physiological data can include one or more event markers (e.g., markers 2290, 2292, 2294, and 2296) superimposed on the physiological data and/or in another graphical or tabular format. In implementations, a caregiver can manually enter event marker data corresponding to certain types of medical interventions (e.g., administration of oxygen or drugs) at the companion device 105 and on the data screen 1660. In some examples, upon selection of the medical device data screen 1660, the companion device 105 may transmit the data request alone or as part of a bulk data transfer request to display event marker data on the data screen 1660. Upon selection of one of the event marker notes 2290, 2292, 2294, and 2296, the companion device 105 may cause display of details related to the selected event marker, such as energy in the applied electrical power, administered drug amounts, a display of defibrillator waveforms and/or ventilator data, and/or a snapshot view of data from the display interface of the medical/other device(s) 180 and/or device views 1315 and/or 1316 at the time associated with the selected event marker, and the like.

In an implementation, the medical device data screen 1660 may display an evaluation of the physiological sensor data by the CSG algorithm 121. The data screen 1660 may graphically provide these evaluations. For example, as schematically shown with various cross-hatched patterns, colors, fill levels of graphical symbols, etc., the ranges of various indicators may be indicated as low, normal, or high graphically distinguished. In an implementation, the data screen 1660 may provide an assessment of the physiological signal using, for example, an evaluation index shown as arrow 2279 positioned relative to the graphically provided range. Alternatively or additionally, the medical device data screen 1660 may provide a text indication of the assessment of the physiological signal (e.g., assessment indications 2270, 2271, 2272, 2273, 2274, and 2275).

Further, in some embodiments, the medical device data screen 1660 may provide a medical device status window 2280.CSG algorithm 121 may receive medical device condition information from a medical/other device as CSG input. CSG algorithm 121 may automatically receive this information according to a predetermined schedule in response to a detected clinical event and/or in response to a query or instruction from CSG algorithm 121 to medical/other device(s) 180.

Referring to fig. 36, an example of a mechanical ventilation device of a ventilation system, such as a respiratory distress ventilator 4102, etc., is illustrated. The mechanical ventilator 2740 may include a gas mover/flow generator 2741, the gas mover/flow generator 2741 configured to move oxygen from the oxygen source 2730 to the patient 101 through the inspiratory circuit 2743 via the patient interface 2744. The ventilation system 280 may use the gas mover 2741 to provide a range of therapeutic ventilation modes to provide various interventions such as those described with reference to fig. 27.

In some embodiments, the ventilation system 280 may provide ventilation during CPR and may, for example, be coupled and integrally operated with one or more critical care monitors (such as one or more patient monitors/defibrillators 285, etc.). In some embodiments, for example, during mask ventilation, unprotected airways, ventilation system 280 may deliver 2 breaths per 30 compressions as measured by the monitor. In some embodiments, for example, ventilation system 280 may deliver 10 breaths/minute continuously (asynchronously) independent of the compression rate when the airway is protected (e.g., endotracheal tube, combitube, etc.).

Fig. 36 illustrates an aspect of an example of a mechanical ventilation device for use in a ventilation system, such as a respiratory distress ventilator, for providing mechanical ventilation to a patient, including a controller 2750 and connected to an oxygen source 2730. Patient interface 2744 may include suitable gas delivery devices such as cannulas, masks, nasal cannulas, and the like. Mechanical ventilation 2740 also includes an exhalation circuit 2745 and an exhalation valve 2748. Both the inspiratory circuit 2743 and the expiratory circuit 2745 include a sensor 2747. The sensors 2747 may include, for example, but are not limited to, a respiratory rate meter 275, an airway pressure sensor 274, and a spirometer 276. The sensor 2747 enables the ventilation system 280 to measure the respiratory effort of the patient and the performance of the ventilation system 280 in providing mechanical respiratory assistance to the patient. The sensor 2747 may generate and provide data to the CSG processor module 120 including, but not limited to, flow rate, tidal volume and minute volume (Ve), respiratory mechanics (e.g., resistance and compliance), and spirometry, and may include forced spirometry (FVC), 1 second forced spirometry (FEV 1), and maximum expiratory flow rate (PEF or PEFR), for example. In addition, the patient monitor/defibrillator 285 or another medical device may provide, for example, capnography and/or pulse Blood oxygen data such as oxyhemoglobin and carboxyhemoglobin saturation, mainstream or other capnography data (such as end-tidal CO ₂ (EtCO ₂ ) Etc.), etc. The data may for example allow for the calculation of CO ₂ Elimination rate and volumetric capnography, which may include using flow data from ventilation system 280.

In some embodiments, for the need for oxygen supplementation (O ₂ ) The ventilation system 280 may provide a number of methods to support oxygenation through invasive and non-invasive ventilation. For example, one method may include using a permit slave O ₂ A small air storage bag system entrained by a fluid source. In some embodiments, in a first method, a user may monitor oxygen saturation (SpO) measured by the patient monitor/defibrillator 285 or another medical device ₂ ) Is to simultaneously manage O to patient ₂ And (3) delivery. The second method can utilize innovative intelligent O ₂ A valve (SOV) or module, which may be attached to the suction circuit 2743, high pressure O, for example ₂ Gas cylinder/source and patient monitor/defibrillator 285 or another medical device. This may for example use a Physiological Closed Loop Control (PCLC) to provide automatic control of oxygenation of the patient, wherein SpO ₂ The signal may be used to adjust the output of the SOV. The third method may provide portable O ₂ Functional integration of concentrator (POC), which may use PCLC to regulate POC's O, for example ₂ Output and input of O into ventilation system 280 ₂ And (5) carrying out entrainment.

Fig. 37 illustrates aspects of an example pneumatic system 2100 that may be used with a respiratory distress ventilator in accordance with an embodiment of the present invention. As shown, the pneumatic system 2100 includes an oxygen connector 2110, patient circuit tubing 2112, which may include proprietary protected inhalation and exhalation circuit components, an exhalation control valve 2114, a radial compressor 2108 or other gas movement components such as blowers, etc., an oxygen valve 2106, and aspects 2104 associated with control and/or measurement of oxygen pressure, oxygen flow, ambient pressure, intake pressure, and patient airway pressure, which may include Programmable Gain Amplifiers (PGAs), analog-to-digital converters (ADCs), and other components.

The oxygen valve 2106 and the compressor 2108 may provide the patient with an appropriate gas mixture during ventilation. The system 2100 may include a transducer for pressure measurement including an oxygen input supply and atmospheric pressure. The patient circuit tubing 2112 may include an inspiratory portion that provides gas to the patient and an expiratory portion that vents gas directly to atmosphere without returning to the ventilator 2000. The ventilator 2000 pneumatically controls the exhalation control valve 2114. Transducers within ventilator 2000 measure airway pressure during ventilation.

In some embodiments, a coaxial patient circuit may be used, wherein an exhalation hose surrounds an inhalation hose when present as a single hose or circuit. The gas chamber divides the gas path where the patient and the device are connected. In some embodiments, such patient circuit configurations may provide benefits that may include reduced dead space, reduced minimum available footprint, minimized weight/pull-on airways, and no need for assembly or troubleshooting based on a single part.

An external high pressure gas source is connected to ventilator 2000 using a high pressure oxygen input port. The source may be, for example, a medical grade oxygen system or an oxygen cylinder supply.

FIG. 38 illustrates aspects of an example external gas supply system 2200 that may be used with a respiratory distress ventilator 2208, according to an embodiment of the invention. The depicted aspects include an oxygen canister 2202 or other oxygen output 2204 (such as a high pressure hose used with an oxygen supply 2206), and an oxygen canister 2210 shown coupled to a respiratory distress ventilator 2208.

Fig. 39 illustrates aspects of an example patient circuit 2300 that may be used with a respiratory distress ventilator 2314, according to an embodiment of the invention. The depicted aspects include an adult circuit 2312 (which includes an inhalation line 2302 and an exhalation line 2306), and an infant/child circuit 2310 (which includes an inhalation line 2304 and an exhalation line 2308).

In fig. 40, components 2808, 2810, 2812, 2814, 2816, and 2818 are communicatively coupled with each other (directly and/or indirectly) for bi-directional communication. Similarly, components 2820, 2822, 2824, 2826, and 2828 are communicatively coupled to each other (directly and/or indirectly) for bi-directional communication.

In some implementations, the components 2808, 2810, 2816, and/or 2818 of the therapeutic medical device 2802 may be combined into one or more discrete components, and the components 2816 and/or 2818 may be part of the processor 2808. Processor 2808 and memory 2810 can include and/or be coupled to associated circuitry to perform the functions described herein. Additionally, the components 2820, 2822, and 2828 of the companion device 2804 may be combined into one or more discrete components, and the component 2828 may be part of the processor 2820. Processor 2820 and memory 2821 may include and/or be coupled to associated circuitry to perform the functions described herein.

In some implementations, the therapeutic medical device 2802 can include a therapy delivery control module 2818. For example, therapy delivery control module 2818 may be an electrotherapy delivery circuit that includes one or more high voltage capacitors configured to store electrical energy for pacing pulses or defibrillation pulses. The electrotherapy delivery circuit may also include resistors, additional capacitors, relays, and/or switches, bridges such as H-bridges (e.g., including multiple insulated gate bipolar transistors or IGBTs), voltage measurement components, and/or current measurement components. As another example, the therapy delivery control module 2818 may be a compression device electromechanical controller configured to control a mechanical compression device. As yet another example, the therapy delivery control module 2818 may be an electromechanical controller configured to control drug delivery, temperature management, ventilation, and/or other types of therapy delivery.

Therapeutic medical device 2802 may be incorporated and/or configured to couple to one or more patient interface devices 2830. The patient interface device 2830 may include one or more therapy delivery assemblies 2832a and one or more sensors 2832b. Similarly, the companion device 2804 may be adapted for medical use and may be incorporated and/or configured to couple to one or more patient interface devices 2834. The patient interface device(s) 2834 may include one or more sensors 2836. Sensor(s) 2836 may be substantially as described herein with respect to sensor(s) 2832b.

The sensor(s) 2832b and 2836 may include sensing electrodes (e.g., sensing electrode 2838), ventilation and/or respiration sensors (e.g., ventilation and/or respiration sensor 2840), temperature sensors (e.g., temperature sensor 2842), chest compression sensors (e.g., chest compression sensor 2844), and the like. In some implementations, the information obtained from the sensors 2832b and 2836 may be used to generate information displayed at the therapeutic medical device 2802 and at the same time at the display view at the companion device 2804 and as described above. In one example, the sensing electrode 2838 may include a cardiac sensing electrode. The cardiac sensing electrodes may be conductive and/or capacitive electrodes configured to measure changes in electrophysiological phenomena of the patient to measure ECG information of the patient. The sensing electrode 2838 may also measure the transthoracic impedance and/or heart rate of the patient. Ventilation and/or respiration sensors 2840 may include spirometry sensors, flow sensors, pressure sensors, oxygen and/or carbon dioxide sensors (such as pulse oximetry sensors, oxygenation sensors (e.g., muscle oxygenation/pH), O ₂ One or more of a gas sensor and a capnography sensor, an impedance sensor, and the like, as well as combinations thereof). The temperature sensor 2842 may include an infrared thermometer, a contact thermometer, a remote thermometer, a liquid crystal thermometer, a thermocouple, a thermistor, etc., and may measure patient temperature internally and/or externally. Chest compression sensor 2844 may include one or more motion sensors including, for example, one or more accelerometers, one or more force sensors, one or more magnetic sensors, one or more speed sensors, one or more displacement sensors, and the like. The chest compression sensor 2844 may provide one or more signals representing chest movement to the therapeutic medical device 2802 via a wired and/or wireless connection. Chest compression sensor 2844 may be, for example, but not limited to, a compression pad, a smart phone, a hand-held device, a wearable device, and the like. Chest compression sensor 2844 may be configured to detect a rescuer and/or an automatic chest compression device (e.g., belt system,Piston system, etc.) to impart chest motion. Chest compression sensor 2844 may provide signals indicative of chest compression data including displacement data, speed data, release speed data, acceleration data, force data, compression rate data, dwell time data, hold time data, blood flow data, blood pressure data, and the like. In an implementation, defibrillation and/or pacing electrodes may include or be configured to be coupled to an chest compression sensor 2844.

In various implementations, sensors 2832b and 2836 may include one or more sensor devices configured to provide sensor data including, for example, but not limited to, ECG, blood pressure, heart rate, respiration rate, heart sounds, lung sounds, breath sounds, end tidal CO ₂ Myooxygen Saturation (SMO) ₂ ) Oxygen saturation (e.g. SpO ₂ And/or PaO ₂ ) Cerebral blood flow, point-of-care laboratory measurements (e.g., lactate, glucose, etc.), temperature, electroencephalogram (EEG) signals, brain oxygen levels, tissue pH, interstitial fluid levels, images and/or video via ultrasound, laryngoscopy, and/or other medical imaging techniques, near infrared spectroscopy, pneumography, cardiography, and/or patient movement. The images and/or video may be two-dimensional or three-dimensional, such as various forms of ultrasound imaging, and the like.

The one or more treatment delivery assemblies 2832a may include an electrotherapy electrode (e.g., electrotherapy electrode 2838 a), one or more ventilation devices (e.g., ventilation device 2838 b), one or more intravenous devices (e.g., intravenous device 2838 c), one or more compression devices (e.g., compression device 2838 d), and the like. For example, electrotherapy electrodes 2838a may include defibrillation electrodes, pacing electrodes, and combinations thereof. The ventilation device 2838b may include tubing, masks, abdominal and/or chest presses (e.g., straps, chest nails, etc.), and the like, as well as combinations thereof. Intravenous device 2838c may include drug delivery devices, fluid delivery devices, and combinations thereof. The pressing device 2838d may include mechanical pressing devices such as an abdominal press, a chest press, a belt, a piston, combinations thereof, and the like. In various implementations, the therapy delivery component(s) 2832a may be configured to provide sensor data and/or be coupled to and/or incorporate sensors. For example, electrotherapy electrode 2838a may provide sensor data such as transthoracic impedance, ECG, heart rate, and the like. Further, the electrotherapy electrode 2838a may include and/or be coupled to an chest compression sensor. As another example, the ventilator 2838b may be coupled to and/or incorporate a flow sensor, a gas species sensor (e.g., an oxygen sensor, a carbon dioxide sensor, etc.), and/or the like. As another example, the intravenous device 2838c may be coupled to and/or incorporate a temperature sensor, a flow sensor, a blood pressure sensor, and the like. As yet another example, the compression device 2838d may be coupled to and/or incorporated into an chest compression sensor, a patient position sensor, or the like. The therapy delivery control module 2818 may be configured to couple to and control the therapy delivery component(s) 2832a, respectively.

The one or more sensors 2832b and 2836 and/or the therapy delivery assembly(s) 2832a may provide sensor data. Patient data provided at the display screens of the therapeutic medical device 2802 and the companion device 2804 may display sensor data. For example, therapeutic medical device 2802 may process signals received from sensor(s) 2832b and/or treatment delivery component(s) 2832a to determine sensor data. Similarly, the companion device 2804 can process signals received from the sensor(s) 2836 and/or sensor data received from the sensor 2832b via the therapeutic medical device 2802 to determine sensor data.

While certain embodiments have been described, these embodiments are presented by way of example only and are not intended to limit the scope of the invention. Indeed, the novel methods, apparatus and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions, and changes in the form of the methods, devices, and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover forms or modifications falling within the scope and spirit of the invention.

Claims

1. An apparatus for treating a patient experiencing respiratory distress, the apparatus comprising:

a respiratory distress management device, comprising:

a housing;

a mechanical ventilation device disposed within the housing for providing mechanical ventilation to a patient, the mechanical ventilation device comprising:

an airflow generator disposed within the housing, an

A gas delivery device disposed at least partially within the housing, coupled with the gas flow generator, the gas delivery device comprising a patient circuit extending from the housing and configured to be at least partially connected with a patient to deliver gas to the patient; and

a controller disposed within the housing, the controller comprising a processor and a memory, the controller configured to:

determining whether a failure mode condition exists at a particular time;

enabling control of the mechanical ventilation device of the respiratory distress management apparatus by at least one source to deliver mechanical ventilation to a patient, via a signal received by the controller from the at least one source, in the event that the failure mode condition is determined to not be present, and

the mechanical ventilation device of the respiratory distress management apparatus is controlled to deliver mechanical ventilation to a patient if the failure mode condition is determined to be present.

2. The apparatus of claim 1, wherein the controller controls the mechanical ventilation apparatus of the respiratory distress management device to deliver mechanical ventilation to a patient in accordance with previously stored ventilation control parameter values if it is determined that the failure mode condition exists at the particular time.

3. The apparatus of claim 1, wherein the controller controls the mechanical ventilation apparatus of the respiratory distress management device to deliver mechanical ventilation to a patient in accordance with a last received valid ventilation control parameter value previously stored if it is determined that the failure mode condition exists at the particular time.

4. The device of claim 1, wherein the controller is configured to:

determining whether the failure mode condition exists, wherein the failure mode condition is associated with the respiratory distress management device, and wherein the at least one source is separate from the respiratory distress management device.

5. The device of claim 1, wherein the controller is configured to:

determining whether a fault mode condition exists at a particular time, wherein the particular time is a first predetermined time;

Enabling control of the mechanical ventilator of the respiratory distress management device by at least one source to deliver mechanical ventilation to a patient upon determining that the failure mode condition does not exist for the first predetermined time via a signal received by the controller from the at least one source; and

the mechanical ventilation device of the respiratory distress management apparatus is controlled to deliver mechanical ventilation to a patient if it is determined that the failure mode condition exists at the first predetermined time.

6. The device of claim 5, wherein the controller is configured to:

determining whether a fault mode condition exists at a second predetermined time, wherein the second predetermined time is a time after a predetermined period of time has elapsed after the first predetermined time;

enabling control of the mechanical ventilator of the respiratory distress management device by at least one source to deliver mechanical ventilation to a patient upon determining that the failure mode condition does not exist for the second predetermined time via a signal received by the controller from the at least one source; and

the mechanical ventilation device of the respiratory distress management apparatus is controlled to deliver mechanical ventilation to a patient if it is determined that the failure mode condition exists at the second predetermined time.

7. The apparatus of claim 6, wherein the controller is configured such that the predetermined period of time is set prior to use of the respiratory distress management device.

8. The apparatus of claim 6, wherein the controller is configured such that the predetermined period of time is set to 1 second.

9. The device of claim 6, wherein the controller is configured such that the predetermined period of time is set to between 0.1 seconds and 1 second.

10. The device of claim 6, wherein the controller is configured such that the predetermined period of time is set to between 1 second and 10 seconds.

11. The apparatus of claim 6, wherein the controller is configured such that the predetermined period of time is set by a user of the respiratory distress management device.

12. The apparatus of claim 1, wherein the mechanical ventilation apparatus comprises:

at least one pressure sensor disposed within the mechanical ventilation device configured to sense a signal representative of a flow of gas within the gas delivery device; and

wherein the controller is configured to:

a signal representative of the air flow is received,

Generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received signal representative of the airflow, and

the respiratory parameter data is transmitted to a second device coupled to the respiratory distress management device, the respiratory parameter data being used to determine a respiratory condition of the patient.

13. The apparatus of claim 12, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying data related to the breathing condition of the patient on a graphical user interface of a display of the second device.

14. The apparatus of claim 13, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient.

15. The apparatus of claim 14, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a treatment recommendation provided to a user of the second device and related to a treatment delivered to the patient by the respiratory distress management device at least in part upon user selection of the treatment recommendation.

16. The apparatus of claim 15, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a therapy recommendation provided to a user of the second device and related to a therapy delivered to the patient by the respiratory distress management device at least in part upon user selection of the therapy recommendation, wherein the therapy includes mechanical ventilation.

17. The apparatus of claim 12, wherein the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter includes forced vital capacity, FVC, and forced expiratory volume, FEV.

18. The apparatus of claim 12, wherein the respiratory distress management device, the at least one source, and the second device are different devices and separate from but coupled to the respiratory distress management device.

19. The apparatus of claim 12, wherein the at least one source and the second device are the same and separate from but coupled to the respiratory distress management device.

20. The device of claim 1, wherein the mechanical ventilation device comprises at least one spirometer.

21. The device of claim 12, wherein the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation device.

22. The apparatus of claim 12, wherein the respiratory distress management device comprises a bronchodilator.

23. The apparatus of claim 1, wherein the controller determines whether the fault mode condition exists using one or more algorithms stored in a memory of the controller and executed by a processor of the controller.

24. The apparatus of claim 1, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a portable computing device.

25. The device of claim 24, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a tablet.

26. The apparatus of claim 1, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a critical care monitor.

27. The device of claim 1, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a defibrillator.

28. The device of claim 1, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises one or more aspects of a cloud-based computing system.

29. The apparatus of claim 1, wherein the controller is configured to enable control by the at least one source, wherein control by the at least one source comprises closed-loop ventilation control utilizing oxygen concentration measurements based on blood of a patient, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

30. The device of claim 29, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a critical care monitor, and wherein the at least one oxygen saturation sensor is part of a pulse oximeter of the critical care monitor.

31. The apparatus of claim 1, wherein the controller is configured to switch from enabling control of the mechanical ventilation by the at least one source to the controller controlling the mechanical ventilation if the failure mode condition is determined to exist.

32. The apparatus of claim 1, wherein the failure mode condition indicates that control by the at least one source will be unsafe.

33. The apparatus of claim 1, wherein the failure mode condition indicates that control by the at least one source will be unreliable with respect to receipt of mechanical ventilation control data by the controller from the at least one source.

34. The apparatus of claim 1, wherein the failure mode condition indicates that treatment with respect to a patient will be suboptimal with respect to control by the controller, control by the at least one source.

35. The apparatus of claim 1, wherein the failure mode condition relates to one or more unsafe patient physiological parameters.

36. The device of claim 1, wherein the failure mode condition indicates that ventilation control data received by the controller from the at least one source is invalid.

37. The apparatus of claim 1, wherein the failure mode condition indicates that ventilation control data received by the controller from the at least one source is corrupted.

38. The apparatus of claim 1, wherein the failure mode condition indicates that two or more items of ventilation control data received by the controller from the at least one source are inconsistent with one another.

39. The device of claim 1, wherein the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation device to operate in accordance with at least one ventilation parameter value that exceeds at least one range.

40. The apparatus of claim 39, wherein the at least one range includes a range associated with sufficient patient safety.

41. The apparatus of claim 39, wherein the at least one range comprises a range of flow rates.

42. The apparatus of claim 39, wherein the at least one range comprises a pressure range.

43. The device of claim 1, wherein the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation device to operate in accordance with values of at least two parameters, wherein a combination of the values will exceed a range of allowable combinations of values of the at least two parameters.

44. The apparatus of claim 43, wherein the values include a value of a flow rate and a value of a pressure.

45. The apparatus of claim 43, wherein the range of allowed value combinations is associated with sufficient patient safety.

46. The apparatus of claim 1, wherein the respiratory distress management device is configured such that upon resetting the controller after a controller process that occurs during control by the at least one source, the controller enables control by the at least one source in the presence of communication capability between the respiratory distress management device and the at least one source, the control by the at least one source including control according to current ventilation control data from the at least one source.

47. The apparatus of claim 1, wherein the respiratory distress management device is configured such that upon resetting the controller after a controller process that occurs during control of the at least one source, the controller controls the mechanical ventilation in accordance with one or more backup ventilation control parameter values stored in a memory of the controller in the absence of communication capability between the respiratory distress management device and the at least one source.

48. The apparatus of claim 1, wherein the controller is configured to perform a cyclic redundancy check on mechanical ventilation control data received from the at least one source.

49. The apparatus of claim 1, wherein the controller is configured to utilize task priority in optimization of controller processing operations.

50. The device of claim 1, wherein the controller is configured to process with data sampling protection.

51. The device of claim 1, wherein the controller is configured to utilize one or more histograms in data processing to minimize data noise.

52. The device of claim 1, wherein the controller is configured to process with a single threaded configuration.

53. The device of claim 1, wherein the controller is configured to process with a thread-safe operating system object.

54. The device of claim 1, wherein the controller is configured to process with a polling software process design to minimize processing delay.

55. The device of claim 1, wherein the controller is configured to perform a token count check on ventilation control data received from the at least one source.

56. The device of claim 1, wherein the controller is configured to disable software processing interrupts under one or more conditions.

57. The device of claim 1, wherein the controller is configured to process with priority regarding one or more aspects of communication with the at least one source.

58. The device of claim 1, wherein the controller is configured to conduct one or more checks related to ventilation control data reception rate from the at least one source.

59. The device of claim 1, wherein the controller is configured to process to maintain a minimum portion of unused memory to prevent potential data storage overload.

60. The device of claim 1, wherein the controller is configured to process with at least one of an acknowledgement, ACK, and negative acknowledgement, NACK, scheme to ensure that ventilation control data is received from the at least one source.

61. The device of claim 1, wherein the controller is configured to automatically reset if a software process is in a frozen or deadlocked condition.

62. The apparatus of claim 1, wherein continuous communication between the respiratory distress management device and the at least one source is utilized to continuously correct any data reception errors.

63. The apparatus of claim 1, wherein the controller is configured to check that the at least one source is properly configured for communication with the respiratory distress management device.

64. The device of claim 1, wherein the controller is configured to generate a user alert related to a particular detection condition.

65. The apparatus of claim 64, wherein the user alert comprises an alert to provide an early warning regarding potentially unsafe ventilation conditions.

66. The apparatus of claim 64, wherein the user alert comprises an alert to provide an early warning regarding potentially unsafe respiratory parameter values for the patient.

67. The apparatus of claim 64, wherein the user alert comprises an alert indication for display to a user of the respiratory distress management device on a graphical user interface separate from the respiratory distress management device.

68. The apparatus of claim 64, wherein the user alert comprises an alert related to a ventilation parameter value.

69. The apparatus of claim 64, wherein the user alert comprises an alert related to a ventilation parameter value related to control by the at least one source.

70. The apparatus of claim 64, wherein the user alert comprises an alert related to a physiological parameter of the patient.

71. The apparatus of claim 70, wherein the alarms related to the patient physiological parameter include one or more alarms related to a high respiratory rate of the patient.

72. The apparatus of claim 70, wherein the alarms related to the patient physiological parameter include one or more alarms related to incomplete exhalation conditions of the patient.

73. A system for treating a patient experiencing respiratory distress, the system comprising:

a respiratory distress management system, comprising:

a mechanical ventilation system for providing mechanical ventilation to a patient, the mechanical ventilation system comprising at least one pressure sensor configured to sense a signal representative of an airflow within the mechanical ventilation system; and

a controller comprising a processor and a memory, the controller configured to:

it is determined whether a fault mode condition exists at a particular time,

Enabling control of the mechanical ventilation system of the respiratory distress management system by at least one source to deliver mechanical ventilation to a patient, via a signal received by the controller from the at least one source, in the event that the failure mode condition is determined to not be present, and

the mechanical ventilation system of the respiratory distress management system is controlled to deliver mechanical ventilation to a patient if the failure mode condition is determined to be present.

74. The system of claim 73, wherein the controller is configured to:

determining whether the failure mode condition exists, wherein the failure mode condition is associated with the respiratory distress management system, and wherein the at least one source is separate from the respiratory distress management system.

75. The system of claim 73, wherein the controller is configured to:

a signal representative of the air flow is received,

the respiratory parameter data is transmitted to a device coupled to the respiratory distress management system, the respiratory parameter data being used to determine a respiratory condition of a patient.

76. The system of claim 75, wherein the controller is configured to transmit the breathing parameter data to the device for use by the device in displaying data related to the breathing condition of the patient on a graphical user interface of a display of the device.

77. The system of claim 76, wherein the controller is configured to transmit the breathing parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guidance related to treatment of a patient.

78. The system of claim 77, wherein the controller is configured to transmit the breathing parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including treatment recommendations provided to a user of the apparatus and relating to a treatment to be delivered by the respiratory distress management system at least in part upon user selection of the treatment recommendation.

79. The system of claim 77, wherein the controller is configured to transmit the breathing parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a therapy recommendation provided to a user of the apparatus and related to a therapy to be delivered by the respiratory distress management system upon user selection of the therapy recommendation, wherein the therapy includes mechanical ventilation.

80. The system of claim 75, wherein the respiratory distress management system, the at least one source, and the device are separate from one another.

81. The system of claim 75, wherein the at least one source and the device are identical and separate from but coupled to the respiratory distress management system.

82. The system of claim 75, wherein the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation system.

83. The system of claim 73, wherein the controller uses one or more algorithms stored in a memory of the controller and executed by a processor of the controller to determine whether the fault mode condition exists.

84. The system of claim 73, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a portable computing device.

85. The system of claim 73, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a critical care monitor.

86. The system of claim 73, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a defibrillator.

87. The system of claim 73, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises one or more aspects of a cloud-based computing system.

88. The system of claim 73, wherein the controller is configured to enable control by the at least one source, wherein control by the at least one source comprises closed-loop ventilation control utilizing oxygen concentration measurements based on blood of the patient, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

89. The system of claim 88, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a critical care monitor, and wherein the at least one oxygen saturation sensor is part of a pulse oximeter of the critical care monitor.

90. The system of claim 73, wherein the controller is configured to switch from enabling control of the mechanical ventilation by the at least one source to the controller controlling the mechanical ventilation if the failure mode condition is determined to exist.

91. The system of claim 73, wherein the failure mode condition indicates that control by the at least one source will be unsafe.

92. The system of claim 73, wherein the failure mode condition indicates that control by the at least one source will be unreliable for receipt of mechanical ventilation control data by the controller from the at least one source.

93. The system of claim 73, wherein the failure mode condition indicates that treatment with respect to a patient will be suboptimal with respect to control by the controller, control by the at least one source.

94. The system of claim 73, wherein the failure mode condition indicates that ventilation control data received by the controller from the at least one source is invalid.

95. The system of claim 73, wherein the failure mode condition indicates that ventilation control data received by the controller from the at least one source is corrupted.

96. The system of claim 73, wherein the failure mode condition indicates that two or more items of ventilation control data received by the controller from the at least one source are inconsistent with one another.

97. The system of claim 73, wherein the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation system to operate in accordance with at least one ventilation parameter value that exceeds at least one range.

98. The system of claim 97, wherein the at least one range includes a range associated with sufficient patient safety.

99. The system of claim 97, wherein the at least one range includes a range of flow rates.

100. The system of claim 97, wherein the at least one range includes a pressure range.

101. The system of claim 73, wherein the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation system to operate in accordance with values of at least two parameters, wherein a combination of the values will exceed a range of allowable combinations of values of the at least two parameters.

102. The system of claim 101, wherein the values include a value of a flow rate and a value of a pressure.

103. The system of claim 101, wherein the range of allowed value combinations is associated with sufficient patient safety.

104. The system of claim 73, wherein the respiratory distress management system is configured such that upon resetting the controller after a controller process that occurs during control by the at least one source, the controller enables control by the at least one source in the presence of communication capability between the respiratory distress management system and the at least one source, the control by the at least one source including control according to current ventilation control data from the at least one source.

105. The system of claim 73, wherein the respiratory distress management system is configured such that upon resetting the controller after a controller process that occurs during control of the at least one source, the controller controls the mechanical ventilation in accordance with one or more backup ventilation control parameter values stored in a memory of the controller in the absence of communication capability between the respiratory distress management system and the at least one source.

106. The system of claim 73, wherein the controller is configured to perform a cyclic redundancy check on mechanical ventilation control data received from the at least one source.

107. The system of claim 73, wherein the controller is configured to utilize task priorities in optimization of controller processing operations.

108. The system of claim 73, wherein the controller is configured to process with data sampling protection.

109. The system of claim 73, wherein the controller is configured to utilize one or more histograms in data processing to minimize data noise.

110. The system of claim 73, wherein the controller is configured to process with a single threaded configuration.

111. The system of claim 73, wherein the controller is configured to process with a thread-safe operating system object.

112. The system of claim 73, wherein the controller is configured to process using a polling software process design to minimize processing delay.

113. The system of claim 73, wherein the controller is configured to perform a token count check on ventilation control data received from the at least one source.

114. The system of claim 73, wherein the controller is configured to disable software processing interrupts under one or more conditions.

115. The system of claim 73, wherein the controller is configured to process with priority regarding one or more aspects of communication with the at least one source.

116. The system of claim 73, wherein the controller is configured to perform one or more checks related to ventilation control data reception rate from the at least one source.

117. The system of claim 73, wherein the controller is configured to process to maintain a minimum portion of unused memory to prevent potential data storage overload.

118. The system of claim 73, wherein the controller is configured to process with at least one of an acknowledgement, ACK, and negative acknowledgement, NACK, scheme to ensure that ventilation control data is received from the at least one source.

119. The system of claim 73, wherein the controller is configured to automatically reset if a software process is in a frozen or deadlocked condition.

120. The system of claim 73, wherein continuous communication between the respiratory distress management system and the at least one source is utilized to continuously correct any data reception errors.

121. The system of claim 73, wherein the controller is configured to check that the at least one source is properly configured for communication with the respiratory distress management system.

122. The system of claim 73, wherein the controller is configured to generate a user alert related to a particular detection condition.

123. The system of claim 122, wherein the user alert comprises an alert to provide an early warning regarding a potentially unsafe ventilation condition.

124. The system of claim 122, wherein the user alert comprises an alert to provide an early warning regarding potentially unsafe respiratory parameter values for the patient.

125. The system of claim 122, wherein the user alert comprises an alert indication for display to a user of the respiratory distress management system on a graphical user interface separate from the respiratory distress management system.

126. The system of claim 122, wherein the user alert comprises an alert related to a ventilation parameter value related to control by the at least one source.

127. The system of claim 122, wherein the user alert comprises an alert related to a ventilation parameter value related to control by the at least one source.

128. The system of claim 122, wherein the user alert comprises an alert related to a physiological parameter of the patient.

129. The system of claim 122, wherein the alarms related to the patient physiological parameter include one or more alarms related to a high respiratory rate of the patient.

130. The system of claim 122, wherein the alarms related to the patient physiological parameter include one or more alarms related to incomplete exhalation conditions of the patient.

131. A computer-implemented method for treating a patient experiencing respiratory distress, the method comprising:

a controller disposed within the respiratory distress management device determining whether a failure mode condition exists at a particular time, the controller comprising a processor and a memory, the failure mode condition being associated with the respiratory distress management device and at least one source separate from the respiratory distress management device;

in the event that the failure mode condition is determined to not be present, the controller enables control of a mechanical ventilation system of the respiratory distress management device by the at least one source to deliver mechanical ventilation to a patient via signals received by the controller from the at least one source; and

The controller controls the mechanical ventilation system of the respiratory distress management device to deliver mechanical ventilation to a patient if the failure mode condition is determined to be present.

132. The method of claim 131, comprising: the controller determines whether the failure mode condition exists, wherein the mechanical ventilation system comprises:

at least one pressure sensor disposed within a gas delivery system of the mechanical ventilation system configured to sense a signal representative of a flow of gas within the gas delivery system; and

wherein the controller:

a signal representative of the air flow is received,

133. The method of claim 132, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying data related to the respiratory condition of the patient on a graphical user interface of a display of the second device.

134. The method of claim 133, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient.

135. The method of claim 134, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including treatment recommendations provided to a user of the second device and relating to a treatment to be delivered by the respiratory distress management device at least in part upon user selection of the treatment recommendation.

136. The method of claim 135, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a treatment recommendation provided to a user of the second device and related to a treatment to be delivered by the respiratory distress management device when the user selects the treatment recommendation, wherein the treatment includes mechanical ventilation.

137. The method of claim 132, comprising: the controller determines whether the failure mode condition exists, wherein the respiratory distress management device, the at least one source, and the second device are different devices and separate from but coupled to the respiratory distress management device.

138. The method of claim 132, comprising: the controller determines whether the failure mode condition exists, wherein the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation system.

139. The method of claim 131, wherein the controller determines whether the fault mode condition exists using one or more algorithms stored in a memory of the controller and executed by a processor of the controller.

140. The method of claim 131, wherein the controller enables control by the at least one source, wherein the at least one source comprises a portable computing device.

141. The method of claim 131, wherein the controller enables control by the at least one source, wherein the at least one source comprises a critical care monitor.

142. The method of claim 131, wherein the controller enables control by the at least one source, wherein the at least one source comprises a defibrillator.

143. The method of claim 131, wherein the controller enables control by the at least one source, wherein the at least one source comprises one or more aspects of a cloud-based computing system.

144. The method of claim 131, wherein the controller enables control by the at least one source, wherein control by the at least one source comprises closed loop ventilation control utilizing oxygen concentration measurements based on blood of the patient, wherein the closed loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

145. The method of claim 144, wherein the controller enables control by the at least one source, wherein the at least one source comprises a critical care monitor, and wherein the at least one oxygen saturation sensor is part of a pulse oximeter of the critical care monitor.

146. The method of claim 131, wherein the controller switches from enabling control of the mechanical ventilation by the at least one source to the controller controlling the mechanical ventilation if the failure mode condition is determined to exist.

147. The method of claim 131, comprising: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that control by the at least one source will be insufficiently secure.

148. The method of claim 131, comprising: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that control by the at least one source will be unreliable with respect to receipt of mechanical ventilation control data by the controller of the respiratory distress management device from the at least one source.

149. The method of claim 131, comprising: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that the control by the at least one source will be suboptimal with respect to the control by the controller regarding the treatment of the patient.

150. The method of claim 131, comprising: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that ventilation control data received by the controller from the at least one source is invalid.

151. The method of claim 131, comprising: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that ventilation control data received by the controller from the at least one source is corrupted.

152. The method of claim 131, comprising: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that two or more items of ventilation control data received by the controller from the at least one source are inconsistent with one another.

153. The method of claim 131, comprising: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation system to operate in accordance with at least one ventilation parameter value that exceeds at least one range.

154. The method of claim 153, comprising: the controller determines whether the failure mode condition exists, wherein the at least one range includes a range associated with sufficient patient safety.

155. The method of claim 154, comprising: the controller determines whether the failure mode condition exists, wherein the at least one range includes a range of flow rates.

156. The method of claim 153, comprising: the controller determines whether the fault mode condition exists, wherein the at least one range includes a pressure range.

157. The method of claim 131, comprising: the controller determines whether the failure mode condition exists, wherein the failure mode condition indicates that enabling control by the at least one source will cause the mechanical ventilation system to operate in accordance with values of at least two parameters, wherein a combination of the values will exceed a range of allowable combinations of values of the at least two parameters.

158. The method of claim 157, comprising: the controller determines whether the fault mode condition exists, wherein the values include a value of a flow rate and a value of a pressure.

159. The method of claim 157, comprising: the controller determines whether the failure mode condition exists, wherein the range of allowed value combinations is associated with sufficient patient safety.

160. The method of claim 131, wherein upon resetting the controller after a controller process that occurs during control of the at least one source, the controller enables control by the at least one source in the presence of communication capability between the respiratory distress management device and the at least one source, the control by the at least one source including control according to current ventilation control data from the at least one source.

161. The method of claim 131, wherein upon resetting the controller after a controller process that occurs during control of the at least one source freezes, the controller controls the mechanical ventilation in accordance with one or more backup ventilation control parameter values stored in a memory of the controller in the absence of communication capability between the respiratory distress management device and the at least one source.

162. The method of claim 131, wherein the controller performs a cyclic redundancy check on mechanical ventilation control data received from the at least one source.

163. The method of claim 131, wherein the controller utilizes task priority in optimization of controller processing operations.

164. The method of claim 131, wherein the controller utilizes data sampling protection for processing.

165. The method of claim 131, wherein the controller utilizes one or more histograms in data processing to minimize data noise.

166. The method of claim 131, wherein the controller utilizes a single threaded configuration for processing.

167. The method of claim 131, wherein the controller utilizes a thread-safe operating system object for processing.

168. The method of claim 131, wherein the controller processes with a polling software process design to minimize processing delay.

169. The method of claim 131, wherein the controller performs a token count check on ventilation control data received from the at least one source.

170. The method of claim 131, wherein the controller disables software processing interrupts under one or more conditions.

171. The method of claim 131, wherein the controller processes with priority regarding one or more aspects of communication with the at least one source.

172. The method of claim 131, wherein the controller performs one or more checks related to ventilation control data reception rate from the at least one source.

173. The method of claim 131, wherein the controller processes to maintain a minimum portion of unused memory to prevent potential data storage overload.

174. The method of claim 131, wherein the controller processes with at least one of an acknowledgement, ACK, and negative acknowledgement, NACK, scheme to ensure that ventilation control data is received from the at least one source.

175. The method of claim 131, wherein the controller automatically resets if a software process freezes or deadlocks condition.

176. The method of claim 131, wherein any data reception errors are continuously corrected utilizing continuous communication between the respiratory distress management device and the at least one source.

177. The method of claim 131, wherein the controller checks that the at least one source is properly configured for communication with the respiratory distress management device.

178. The method of claim 131, wherein the controller generates a user alert related to a particular detection condition.

179. The method of claim 178, wherein the controller generates the user alert, wherein the user alert comprises an alert to provide an early warning regarding a potentially unsafe ventilation condition.

180. The method of claim 178, wherein the controller generates the user alert, wherein the user alert includes an alert to provide an early warning regarding potentially unsafe respiratory parameter values for a patient.

181. The method of claim 178, wherein the controller generates the user alert, wherein the user alert comprises an alert indication for display to a user of the respiratory distress management device on a graphical user interface separate from the respiratory distress management device.

182. The method of claim 178, wherein the controller generates the user alert, wherein the user alert comprises an alert related to a ventilation parameter value related to control by the at least one source.

183. The method of claim 178, wherein the controller generates the user alert, wherein the user alert comprises an alert related to a ventilation parameter value related to control by the at least one source.

184. The method of claim 178, wherein the controller generates the user alert, wherein the user alert comprises an alert related to a physiological parameter of the patient.

185. The method of claim 178, wherein the controller generates the user alert, wherein the alert related to the patient physiological parameter includes one or more alerts related to a high respiratory rate of the patient.

186. The method of claim 178, wherein the controller generates the user alert, wherein the alert related to the patient physiological parameter includes one or more alerts related to an incomplete exhalation condition of the patient.

187. An apparatus for treating a patient experiencing respiratory distress, the apparatus comprising:

a respiratory distress management device, comprising:

a housing;

an airflow generator disposed within the housing, an

A gas delivery device disposed at least partially within the housing, coupled with the gas flow generator, the gas delivery device including a patient circuit extending from the housing and configured to be at least partially connected with a patient to deliver gas to the patient,

At least one pressure sensor disposed within the mechanical ventilation device configured to sense a signal representative of a flow of gas within the gas delivery device, and

a controller disposed within the housing configured to:

a signal representative of the air flow is received,

transmitting the respiratory parameter data to a second device coupled to the respiratory distress management device, the respiratory parameter data being used to determine a respiratory condition of the patient,

wherein the controller is configured to enable control of the mechanical ventilation device by at least one source separate from the respiratory distress management device to deliver mechanical ventilation to a patient.

188. The device of claim 187, wherein the controller is configured such that:

the controller determining whether a failure mode condition exists at a particular time, the failure mode condition being associated with the respiratory distress management device and the at least one source separate from the respiratory distress management device;

in the event that it is determined that the failure mode condition is not present at the particular time, the controller enables control of the mechanical ventilator of the respiratory distress management device by the at least one source to deliver mechanical ventilation to a patient via signals received by the controller from the at least one source; and

The controller controls the mechanical ventilation device of the respiratory distress management apparatus to deliver mechanical ventilation to a patient if it is determined that the failure mode condition exists at the particular time.

189. The device of claim 187, wherein the controller is configured to enable control by the at least one source, wherein control by the at least one source comprises utilizing closed-loop ventilation control based on oxygen concentration measurements of the patient's blood, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

190. The apparatus of claim 187, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying data related to the breathing condition of the patient on a graphical user interface of a display of the second device.

191. The apparatus according to claim 190, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of the patient.

192. The apparatus of claim 191, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of the patient, the context-sensitive guide including a therapy recommendation provided to a user of the second device and relating to a therapy to be delivered by the respiratory distress management device at least in part upon user selection of the therapy recommendation.

193. The apparatus of claim 192, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a therapy recommendation provided to a user of the second device and related to a therapy to be delivered by the respiratory distress management device at least in part upon user selection of the therapy recommendation, wherein the therapy includes mechanical ventilation.

194. The device of claim 187 wherein the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter comprises forced vital capacity, FVC, and forced expiratory volume, FEV.

195. The device of claim 187, wherein the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilator device.

196. The device of claim 187, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a means having a graphical user interface configured to allow user input related to adjusting one or more ventilation control parameters.

197. The apparatus of claim 187, wherein the respiratory distress management device is configured to enable control of the mechanical ventilation apparatus in accordance with signals received by the controller of the respiratory distress management device from outside the respiratory distress management device.

198. The device of claim 197, wherein the controller is configured to determine whether to control the mechanical ventilation device at a particular time based on a signal received by the controller from outside of the respiratory distress management apparatus.

199. The device of claim 198 wherein the controller is configured to determine whether to control the mechanical ventilation device at the particular time based on a signal received by the controller from the at least one source from outside of the respiratory distress management apparatus.

200. The apparatus of claim 199, wherein the controller is configured to determine whether to control the mechanical ventilation apparatus at the particular time based on a signal received by the controller of the respiratory distress management device from an external source of the respiratory distress management device from the at least one source, wherein the at least one source is a critical care monitor.

201. The apparatus of claim 200, wherein the controller is configured to determine whether to control the mechanical ventilation apparatus at the particular time based on a signal received by the controller of the respiratory distress management device from an external source of the respiratory distress management device from the at least one source, wherein the at least one source is a defibrillator.

202. The apparatus of claim 199, wherein the controller is configured to determine whether to control the mechanical ventilation apparatus at the particular time based on a signal received by the controller of the respiratory distress management device from an external source of the respiratory distress management device from the at least one source, wherein the at least one source is a tablet.

203. The apparatus of claim 201, wherein the controller is configured to determine whether to control the mechanical ventilation apparatus at the particular time based at least in part on a signal received by the controller of the respiratory distress management device from the at least one source from outside the respiratory distress management device based on whether communication capability exists between the respiratory distress management device and a control source at the particular time.

204. The apparatus of claim 203, wherein the controller comprises software stored in memory configured to enable control of the mechanical ventilation apparatus in accordance with signals received by the controller of the respiratory distress management device from outside the respiratory distress management device.

205. The apparatus of claim 187, wherein the respiratory distress management device is configured to be coupled with at least one critical care monitor, and wherein the controller is configured to:

receiving signals representative of at least one physiological parameter of a patient from the at least one critical care monitor; and

respiratory parameter data corresponding to at least one respiratory parameter of the patient is generated based at least in part on the received signals.

206. The device of claim 205, wherein the controller is configured to receive a signal representative of at least one physiological parameter of the patient from the at least one critical care monitor, including receiving a signal representative of at least one physiological parameter of the patient from a defibrillator.

207. The device of claim 206, wherein the controller is configured to receive signals from the at least one critical care monitor representative of at least one physiological parameter of the patient, including receiving signals obtained at least in part via oximetry.

208. The device of claim 207, wherein the controller is configured to receive signals representative of at least one physiological parameter of the patient from the at least one critical care monitor, including receiving signals obtained at least in part via capnography.

209. The apparatus of claim 187, wherein the respiratory distress management device is configured to operate in a first mode that does not include delivering mechanical ventilation to the patient or in a second mode that includes delivering mechanical ventilation to the patient.

210. The apparatus of claim 187, wherein the airflow generator comprises a blower.

211. The apparatus of claim 210, wherein the blower is operable to produce between 40 and 70 decibels of sound at one meter.

212. The apparatus of claim 187 wherein the airflow generator comprises a turbine.

213. The apparatus of claim 187, wherein the airflow generator comprises a compressor.

214. The apparatus of claim 187 wherein the housing of the respiratory distress management device has a volume of between 5.0 and 27 liters.

215. The apparatus of claim 187 wherein the housing of the respiratory distress management device has a volume of between 1.0 and 5.0 liters.

216. The apparatus of claim 187 wherein the housing of the respiratory distress management device has a volume of between 0.5 and 1.0 liters.

217. The apparatus of claim 187 wherein the housing of the respiratory distress management device has a volume of between 0.15 and 0.5 liters.

218. The apparatus of claim 187 wherein the housing of the respiratory distress management device has a volume of between 0.125 and 0.15 liters.

219. The apparatus of claim 187 wherein the respiratory distress management device has a weight of between 2.0 and 5.0 kilograms.

220. The apparatus of claim 187 wherein the respiratory distress management device has a weight of between 1.0 and 2.0 kilograms.

221. The apparatus of claim 187 wherein the respiratory distress management device has a weight of between 0.3 and 1.0 kg.

222. The apparatus of claim 187 wherein the respiratory distress management device has a weight of between 0.2 and 0.3 kilograms.

223. The apparatus of claim 187, wherein the respiratory distress management device is sized such that none of a length, a height, and a width of the respiratory distress management device is greater than 300mm.

224. The apparatus of claim 187, wherein the respiratory distress management device is sized such that none of a length, a height, and a width of the respiratory distress management device is greater than 150mm.

225. The apparatus of claim 187, wherein the respiratory distress management device is sized such that none of a length, a height, and a width of the respiratory distress management device is greater than 100mm.

226. The apparatus of claim 187, wherein the respiratory distress management device is sized such that none of a length, a height, and a width of the respiratory distress management device is greater than 60mm.

227. The apparatus of claim 187, wherein the respiratory distress management device is configured to be portable.

228. The apparatus of claim 187, wherein the respiratory distress management device is configured for patient treatment within a vehicle.

229. The apparatus of claim 187, wherein the respiratory distress management device is configured for off-hospital patient treatment.

230. The device of claim 187, wherein the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter comprises at least one of respiratory compliance and respiratory resistance.

231. The apparatus of claim 187, wherein the respiratory distress management device is configured to deliver non-invasive mechanical ventilation to the patient.

232. The apparatus of claim 187, wherein the respiratory distress management device is configured to deliver non-invasive mechanical ventilation including continuous positive airway pressure, CPAP, ventilation to the patient.

233. The apparatus of claim 187, wherein the respiratory distress management device is configured to deliver non-invasive mechanical ventilation including bi-level ventilation to the patient.

234. The apparatus of claim 187, wherein the respiratory distress management device is configured to deliver non-invasive mechanical ventilation to the patient including high flow nasal cannula ventilation, HFNC ventilation.

235. The apparatus of claim 187, wherein the respiratory distress management device is configured to deliver invasive mechanical ventilation to the patient.

236. The apparatus of claim 187, wherein the respiratory distress management device is configured to deliver invasive mechanical ventilation to the patient including assisted control ventilation, AC ventilation.

237. The apparatus of claim 187, wherein the respiratory distress management device is configured to deliver invasive mechanical ventilation including synchronous intermittent forced ventilation, SIMV, to the patient.

238. The apparatus of claim 187, wherein the respiratory distress management device is configured to deliver to the patient invasive mechanical ventilation including ventilation synchronized with cardiopulmonary resuscitation chest compressions, CPR chest compressions, being delivered to the patient.

239. The apparatus of claim 187, wherein the respiratory distress management device is coupled with an oxygen source for delivering gas to the patient.

240. A system for treating a patient experiencing respiratory distress, the system comprising:

a respiratory distress management system, comprising:

a controller comprising a processor and a memory, the controller configured to:

a signal representative of the air flow is received,

transmitting the breathing parameter data to a device coupled to the respiratory distress management system, the breathing parameter data being used to determine a respiratory condition of a patient,

Wherein the controller is configured to enable control of the mechanical ventilation system by at least one source separate from the respiratory distress management system to deliver mechanical ventilation to a patient.

241. The system of claim 240, wherein the controller is configured such that:

the controller determining whether a failure mode condition exists at a particular time, the failure mode condition being associated with the respiratory distress management system and the at least one source separate from the respiratory distress management system;

in the event that it is determined that the failure mode condition is not present at the particular time, the controller enables control of the mechanical ventilation system of the respiratory distress management system by the at least one source to deliver mechanical ventilation to a patient via signals received by the controller from the at least one source; and

the controller controls the mechanical ventilation system of the respiratory distress management system to deliver mechanical ventilation to a patient if it is determined that the failure mode condition exists at the particular time.

242. The system of claim 240, wherein the controller is configured to enable control by the at least one source, wherein control by the at least one source comprises utilizing closed-loop ventilation control based on oxygen concentration measurements of the patient's blood, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

243. The system of claim 240, wherein the controller is configured to transmit the breathing parameter data to the device for use by the device in displaying data related to the breathing condition of the patient on a graphical user interface of a display of the device.

244. The system of claim 243, wherein the controller is configured to transmit the breathing parameter data to the apparatus for use by the apparatus in displaying user-interactive context-sensitive guidance related to treatment of a patient.

245. The system of claim 244, wherein the controller is configured to transmit the breathing parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including treatment recommendations provided to a user of the apparatus and relating to a treatment to be delivered by the respiratory distress management system at least in part upon user selection of the treatment recommendation.

246. The system of claim 245, wherein the controller is configured to transmit the breathing parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a therapy recommendation provided to a user of the apparatus and related to a therapy to be delivered by the respiratory distress management system upon user selection of the therapy recommendation, wherein the therapy includes mechanical ventilation.

247. The system of claim 240, wherein the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within a gas delivery system of the mechanical ventilation system.

248. The system of claim 240, wherein the controller is configured to enable control by the at least one source, wherein the at least one source comprises a device having a graphical user interface configured to allow user input related to adjusting one or more ventilation control parameters.

249. The system of claim 240, wherein the respiratory distress management system is configured to enable control of the mechanical ventilation system in accordance with signals received by the controller of the respiratory distress management system from outside the respiratory distress management system.

250. The system of claim 249, wherein the controller is configured to determine whether to control the mechanical ventilation system at a particular time based on signals received by the controller from outside of the respiratory distress management system.

251. The system of claim 250, wherein the controller is configured to determine whether to control the mechanical ventilation system at a particular time based on signals received by the controller from the at least one source from outside the respiratory distress management system.

252. The system of claim 251, wherein the controller is configured to determine whether to control the mechanical ventilation system at the particular time based on signals received by the controller of the respiratory distress management system from outside the respiratory distress management system from the at least one source, wherein the at least one source is a critical care monitor.

253. The system of claim 252, wherein the controller is configured to determine whether to control the mechanical ventilation system at the particular time based on signals received by the controller of the respiratory distress management system from outside the respiratory distress management system from the at least one source, wherein the at least one source is a defibrillator.

254. The system of claim 251, wherein the controller is configured to determine whether to control the mechanical ventilation system at the particular time based on signals received by the controller of the respiratory distress management system from outside the respiratory distress management system from the at least one source, wherein the at least one source is a tablet.

255. The system of claim 253, wherein the controller is configured to determine whether to control the mechanical ventilation system at the particular time based at least in part on a signal received by the controller of the respiratory distress management system from the at least one source from outside the respiratory distress management system based on whether communication capability exists between the respiratory distress management system and the at least one source at the particular time.

256. The system of claim 255, wherein the controller comprises software stored in the memory, the software configured to enable control of the mechanical ventilation system based on signals received by the controller of the respiratory distress management system from outside the respiratory distress management system.

257. The system of claim 240, wherein the respiratory distress management system is configured to be coupled with at least one critical care monitor, and wherein the controller is configured to:

receiving a signal from the critical care monitor representative of at least one physiological parameter of a patient; and

258. The system of claim 257, wherein receiving a signal from the critical care monitor representative of at least one physiological parameter of the patient comprises: a signal representative of at least one physiological parameter of a patient is received from a defibrillator.

259. The system of claim 258, wherein receiving a signal from the critical care monitor representative of at least one physiological parameter of the patient comprises: a signal obtained at least in part via oximetry is received.

260. The system of claim 259, wherein receiving a signal from the critical care monitor representative of at least one physiological parameter of a patient comprises: a signal obtained at least in part via capnography is received.

261. The system of claim 240, wherein the respiratory distress management system is configured to operate in a first mode that does not include delivering mechanical ventilation to the patient or in a second mode that includes delivering mechanical ventilation to the patient.

262. The system of claim 240, wherein the mechanical ventilation system comprises an airflow generator that includes a blower.

263. The system claimed in claim 262 and wherein said blower is operable to produce between 40 and 70 decibels of sound at one meter.

264. The system of claim 240, wherein the mechanical ventilation system comprises an airflow generator that includes a turbine.

265. The system of claim 240, wherein the mechanical ventilation system comprises an airflow generator comprising a compressor.

266. The system of claim 240, wherein the housing of the respiratory distress management system has a volume between 5.0 and 27 liters.

267. The system of claim 240, wherein the housing of the respiratory distress management system has a volume between 1.0 and 5.0 liters.

268. The system of claim 240, wherein the housing of the respiratory distress management system has a volume between 0.5 and 1.0 liters.

269. The system of claim 240, wherein the housing of the respiratory distress management system has a volume between 0.15 and 0.5 liters.

270. The system of claim 240, wherein the housing of the respiratory distress management system has a volume between 0.125 and 0.15 liters.

271. The system of claim 240 wherein the respiratory distress management system has a weight of between 2.0 and 5.0 kilograms.

272. The system of claim 240 wherein the respiratory distress management system has a weight of between 1.0 and 2.0 kilograms.

273. The system of claim 240 wherein the respiratory distress management system has a weight of between 0.3 and 1.0 kilograms.

274. The system of claim 240 wherein the respiratory distress management system has a weight of between 0.2 and 0.3 kilograms.

275. The system of claim 240, wherein the respiratory distress management system is configured to be portable.

276. The system of claim 240, wherein the respiratory distress management system is configured for patient treatment within a vehicle.

277. The system of claim 240, wherein the respiratory distress management system is configured for off-hospital patient treatment.

278. The system of claim 240, wherein the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter includes at least one of respiratory compliance and respiratory resistance.

279. The system of claim 240, wherein the respiratory distress management system is configured to deliver non-invasive mechanical ventilation to the patient.

280. The system of claim 240, wherein the respiratory distress management system is configured to deliver non-invasive mechanical ventilation including continuous positive airway pressure, CPAP, ventilation to the patient.

281. The system of claim 240, wherein the respiratory distress management system is configured to deliver non-invasive mechanical ventilation including bi-level ventilation to the patient.

282. The system of claim 240, wherein the respiratory distress management system is configured to deliver non-invasive mechanical ventilation to the patient including high flow nasal cannula ventilation, HFNC ventilation.

283. The system of claim 240, wherein the respiratory distress management system is configured to deliver invasive mechanical ventilation to the patient.

284. The system of claim 240, wherein the respiratory distress management system is configured to deliver invasive mechanical ventilation to the patient including assisted control ventilation, AC ventilation.

285. The system of claim 240, wherein the respiratory distress management system is configured to deliver invasive mechanical ventilation to the patient including synchronous intermittent forced ventilation (SIMV).

286. The system of claim 240 wherein the respiratory distress management system is configured to deliver to the patient invasive mechanical ventilation including ventilation synchronized with cardiopulmonary resuscitation chest compressions, CPR chest compressions, being delivered to the patient.

287. The system of claim 240, wherein the respiratory distress management system is coupled with an oxygen source for delivering gas to the patient.

288. A computer-implemented method for treating a patient experiencing respiratory distress, the method comprising:

a controller including a processor and a memory disposed within a respiratory distress management device, the respiratory distress management device including a mechanical ventilation system for providing mechanical ventilation to a patient and including at least one pressure sensor configured to sense a signal representative of airflow within the mechanical ventilation system:

a signal representative of the air flow is received,

wherein the controller is capable of enabling control of the mechanical ventilation system by at least one source separate from the respiratory distress management device to deliver mechanical ventilation to a patient.

289. The method of claim 288, wherein the controller enables control by the at least one source, wherein control by the at least one source comprises: closed-loop ventilation control utilizing oxygen concentration measurements based on blood of a patient, wherein the closed-loop ventilation control comprises: the method includes monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor, and adjusting oxygen delivery during delivery of mechanical ventilation to the patient to maintain the oxygen concentration of the blood of the patient at a desired level or range.

290. The method of claim 288, comprising:

in the event that it is determined that the failure mode condition is not present at the particular time, the controller enables control of the mechanical ventilation system of the respiratory distress management device by the at least one source to deliver mechanical ventilation to a patient via signals received by the controller from the at least one source; and

The controller controls the mechanical ventilation system of the respiratory distress management device to deliver mechanical ventilation to a patient if it is determined that the failure mode condition exists at the particular time.

291. The method of claim 290, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying data related to the respiratory condition of the patient on a graphical user interface of a display of the second device.

292. The method of claim 291, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient.

293. The method of claim 292, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including treatment recommendations provided to a user of the second device and relating to a treatment to be delivered by the respiratory distress management device at least in part upon user selection of the treatment recommendation.

294. The method of claim 293, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a treatment recommendation provided to a user of the second device and related to a treatment to be delivered by the respiratory distress management device when the user selects the treatment recommendation, wherein the treatment includes mechanical ventilation.

295. The method of claim 288, comprising: the controller receives a signal representative of the flow of gas, wherein the at least one pressure sensor is coupled to or part of at least one pneumotach disposed within a gas delivery device of the mechanical ventilation system.

296. The method of claim 288, comprising: the controller allows control of the mechanical ventilation system of the respiratory distress management device to deliver ventilation to a patient in accordance with signals received by the respiratory distress management device from the at least one source separate from the respiratory distress management device.

297. The method of claim 288, comprising:

the controller determining whether communication capability exists between the respiratory distress management device and the at least one source separate from the respiratory distress management device at a particular time to allow control of the mechanical ventilation system by the at least one source;

in the event that it is determined that the communication capability exists at the particular time, the controller allows control of the mechanical ventilation system by the at least one source; and

the controller controls the mechanical ventilation system if it is determined that the communication capability is not present at the particular time.

298. The method of claim 297, comprising: the controller allows control of the mechanical ventilation system by the at least one source if it is determined that the communication capability is present at the particular time, wherein control by the at least one source includes utilizing one or more algorithms stored at least in part on the at least one source.

299. The method of claim 297, comprising: in the event that it is determined that the communication capability is present at the particular time, the controller allows control of the mechanical ventilation system by the at least one source, the control by the at least one source having no user input.

300. The method of claim 297, comprising: in the event that it is determined that the communication capability is not present at the particular time, the controller controls the mechanical ventilation system using one or more algorithms stored at least in part on the controller.

301. The method of claim 300, comprising: in the event that it is determined that the communication capability is not present at the particular time, the controller controls the mechanical ventilation system without user input.

302. The method of claim 297, comprising: the controller allows control of the mechanical ventilation system by the at least one source, where the at least one source includes a portable computing device, if it is determined that the communication capability exists at the particular time.

303. A method according to claim 302, comprising: the controller allows control of the mechanical ventilation system by the at least one source, wherein the at least one source comprises a tablet computer, if it is determined that the communication capability is present at the particular time.

304. The method of claim 297, comprising: the controller allows control of the mechanical ventilation system by the at least one source, where the at least one source includes a critical care monitor, if the communication capability is determined to be present at the particular time.

305. The method of claim 297, comprising: the controller allows control of the mechanical ventilation system by the at least one source, wherein the at least one source comprises a defibrillator, if it is determined that the communication capability exists at the particular time.

306. The method of claim 288, wherein the respiratory distress management device is coupled with a critical care monitor, and wherein the controller generates the respiratory parameter data based at least in part on signals received from the critical care monitor.

307. An apparatus for treating a patient experiencing respiratory distress, the apparatus comprising:

a respiratory distress management device, comprising:

a housing;

an airflow generator disposed within the housing, an

determining whether a communication capability exists between the respiratory distress management device and at least one source separate from the respiratory distress management device at a particular time to allow control of the gas delivery device of the mechanical ventilator by the at least one source to deliver mechanical ventilation to a patient, enabling control of the gas delivery device of the mechanical ventilator by the at least one source to deliver mechanical ventilation to a patient if the communication capability is determined to exist,

in the event that the communication capability is determined to be absent, controlling the gas delivery device of the mechanical ventilation device to deliver mechanical ventilation to a patient,

wherein allowing control by the at least one source comprises allowing closed-loop ventilation control based on oxygen concentration measurements of the patient's blood, wherein the closed-loop ventilation control comprises:

monitoring an oxygen concentration of blood of a patient with at least one oxygen saturation sensor coupled to the patient, an

Oxygen delivery is adjusted during mechanical ventilation to the patient to maintain the oxygen concentration of the patient's blood at a desired level or range.

308. The apparatus of claim 307, wherein the mechanical ventilation apparatus comprises:

at least one pressure sensor disposed within the gas delivery device of the mechanical ventilation device configured to sense a signal representative of a flow of gas within the gas delivery device; and

wherein the controller is configured to:

a signal representative of the air flow is received,

309. The apparatus according to claim 308, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying data relating to the breathing condition of the patient on a graphical user interface of a display of the second device.

310. The apparatus of claim 309, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of the patient.

311. The apparatus of claim 310, wherein the controller is configured to transmit the breathing parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a therapy recommendation provided to a user of the second device and related to a therapy to be delivered by the respiratory distress management device at least in part upon user selection of the therapy recommendation.

312. The apparatus of claim 311, wherein the controller is configured to transmit the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a therapy recommendation provided to a user of the second device and related to a therapy to be delivered by the respiratory distress management device at least in part upon user selection of the therapy recommendation, wherein the therapy includes mechanical ventilation.

313. The device of claim 308, wherein the controller is configured to generate breathing parameter data corresponding to at least one breathing parameter of the patient, wherein the at least one breathing parameter comprises a forced vital capacity parameter, FVC, parameter and a forced expiratory volume parameter, FEV, parameter.

314. The apparatus of claim 308, wherein the respiratory distress management device, the at least one source, and the second device are different devices and separate from each other but coupled to each other.

315. The device of claim 308, wherein the mechanical ventilation device comprises at least one spirometer.

316. The device of claim 308, wherein the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilator device.

317. A system for treating a patient experiencing respiratory distress, the system comprising:

a respiratory distress management system, comprising:

mechanical ventilation system for providing mechanical ventilation to a patient, and

a controller comprising a processor and a memory, the controller configured to:

determining whether communication capability exists between the respiratory distress management system and at least one source separate from the respiratory distress management system at a particular time to allow control of the mechanical ventilation system by the at least one source to deliver mechanical ventilation to a patient,

in the event that it is determined that the communication capability is present at the particular time, enabling control of the mechanical ventilation system by the at least one source to deliver mechanical ventilation to the patient,

Controlling the mechanical ventilation system to deliver mechanical ventilation to the patient if it is determined that the communication capability is not present at the particular time;

318. The system of claim 317, wherein the mechanical ventilation system comprises:

wherein the controller is configured to:

a signal representative of the air flow is received,

319. The system of claim 318, wherein the controller is configured to transmit the breathing parameter data to the device for use by the device in displaying data related to the breathing condition of the patient on a graphical user interface of a display of the device.

320. The system of claim 319, wherein the controller is configured to transmit the respiratory parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guidance related to treatment of a patient.

321. The system of claim 320, wherein the controller is configured to transmit the breathing parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guidance related to treatment of a patient, the context-sensitive guidance including a therapy recommendation provided to a user of the apparatus and related to a therapy to be delivered by the respiratory distress management system at least in part upon user selection of the therapy recommendation.

322. The system of claim 321, wherein the controller is configured to transmit the respiratory parameter data to the apparatus for use by the apparatus in displaying a user-interactive context-sensitive guidance related to treatment of a patient, the context-sensitive guidance including a therapy recommendation provided to a user of the apparatus and related to a therapy to be delivered by the respiratory distress management system when the therapy recommendation is selected by the user, wherein the therapy includes mechanical ventilation.

323. The system of claim 318, wherein the respiratory distress management system, the at least one source, and the device are different devices and separate from each other but coupled to each other.

324. The system of claim 318, wherein the at least one source and the device are identical and separate from, but coupled to, the respiratory distress management system.

325. The system of claim 318, wherein the at least one pressure sensor is coupled to or is part of at least one pneumotach disposed within the mechanical ventilation system.

326. A computer-implemented method for treating a patient experiencing respiratory distress, the method comprising:

a controller including a processor and a memory disposed within a respiratory distress management device including a mechanical ventilation system for providing mechanical ventilation to a patient determines whether a communication capability exists between the respiratory distress management device and at least one source separate from the respiratory distress management device at a particular time to allow control of the mechanical ventilation system by the at least one source to deliver mechanical ventilation to the patient;

In the event that it is determined that the communication capability is present at the particular time, the controller allows control of the mechanical ventilation system by the at least one source to deliver mechanical ventilation to the patient;

in the event that it is determined that the communication capability is not present at the particular time, the controller controls the mechanical ventilation system to deliver mechanical ventilation to the patient,

327. The method of claim 326, wherein the mechanical ventilation system comprises:

at least one pressure sensor disposed within a gas delivery system of the mechanical ventilation system configured to sense a first signal representative of a flow of gas within the gas delivery system, and

the method comprises the following operations by the controller:

A first signal representative of the airflow is received,

generating respiratory parameter data corresponding to at least one respiratory parameter of the patient based at least in part on the received first signal representative of the airflow, and

328. The method of claim 327, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying data related to the respiratory condition of the patient on a graphical user interface of a display of the second device.

329. The method of claim 328, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient.

330. The method of claim 329, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including treatment recommendations provided to a user of the second device and relating to a treatment to be delivered by the respiratory distress management device at least in part upon user selection of the treatment recommendation.

331. The method of claim 330, comprising: the controller transmits the respiratory parameter data to the second device for use by the second device in displaying a user-interactive context-sensitive guide related to treatment of a patient, the context-sensitive guide including a treatment recommendation provided to a user of the second device and related to a treatment to be delivered by the respiratory distress management device when the user selects the treatment recommendation, wherein the treatment includes mechanical ventilation.

332. The method of claim 327, comprising: the controller allows control by the at least one source, wherein the respiratory distress management device, the at least one source, and the device are different devices and separate from each other but coupled to each other.

333. The method of claim 327, comprising: the controller receives a signal representative of the flow of gas, wherein the at least one pressure sensor is coupled to or part of at least one pneumotach disposed within the mechanical ventilation system.

334. The method of claim 327, comprising: the controller performs the following operations:

Receiving a second signal from the critical care monitor representative of at least one physiological parameter of the patient; and

respiratory parameter data corresponding to at least one respiratory parameter of the patient is generated based at least in part on the received first signal and the received second signal.

335. The method of claim 334, comprising: the controller receives the second signal from the intensive care monitor, wherein the intensive care monitor is a defibrillator.

336. The method of claim 334, comprising: the controller receives a second signal representative of at least one physiological parameter of the patient, wherein the at least one physiological parameter includes an blood oxygen concentration parameter.

337. The method of claim 336, comprising: the controller receives a second signal representative of at least one physiological parameter of the patient, wherein the at least one physiological parameter is obtained using oximetry.

338. The method of claim 336, comprising: the controller receives a second signal representative of at least one physiological parameter of the patient, wherein the at least one physiological parameter is obtained using capnography.

339. The method of claim 327, comprising: the controller transmits the breathing parameter data to the second device, the breathing parameter data being used to determine a breathing condition of the patient, wherein the breathing condition is for display on a graphical user interface of the second device.

340. The method of claim 339, comprising: the controller transmits the respiratory parameter data to the second device, wherein the second device includes a critical care monitor.

341. The method of claim 339, comprising: the controller transmits the breathing parameter data to the second device, wherein the second device comprises a tablet computer.

342. The method of claim 339, comprising: the controller transmits the respiratory parameter data to the second device, wherein the second device comprises an aspect of a cloud-based computing system.