CONTROLLING THE OPERATION OF A VENTILATOR

A ventilator, comprising: a manual resuscitator; a motor; a compression plate that is mechanically coupled to the motor, wherein operation of the motor causes the compression plate to periodically compress the manual resuscitator against a resuscitator plate; and one or more operational parameter adjustment controls, wherein operation of the motor is adjusted in response to a value of a particular operational parameter being changed using the one or more operational parameter adjustment controls.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1sets forth a first perspective of internal components of a ventilator in accordance with some embodiments of the present disclosure.

FIG. 2sets forth a second perspective of internal components of a ventilator in accordance with some embodiments of the present disclosure.

FIG. 3sets forth a diagram of a ventilator in accordance with some embodiments of the present disclosure.

FIG. 4Asets forth a flow chart illustrating an example method of operating a ventilator400in accordance with some embodiments of the present disclosure.

FIG. 4Bsets forth a flow chart illustrating an additional example method of operating a ventilator400in accordance with some embodiments of the present disclosure.

FIG. 5is a diagram of an example of a system to generate one or more trained models that are used in conjunction with controlling a ventilator in accordance with some examples of the present disclosure.

FIG. 6AandFIG. 6Bcollectively illustrate an example of a method of cooperative execution of a genetic algorithm and an optimization trainer to generate an autoencoder in accordance with some embodiments of the present disclosure.

FIG. 7illustrate an example of a system for using an autoencoder to monitor one or more devices for operational anomalies in accordance with some embodiments of the present disclosure.

DESCRIPTION OF EMBODIMENTS

Example ventilators, methods for controlling the operation of a ventilator, and products for controlling the operation of a ventilator in accordance with some embodiments of the present disclosure are described with reference to the accompanying drawings, beginning withFIG. 1.FIG. 1sets forth a first perspective of internal components of a ventilator100in accordance with some embodiments of the present disclosure. Readers will appreciate that in order to illustrate the internal components of the ventilator100, some components of ventilators in accordance with some embodiments of the present disclosure are omitted fromFIG. 1. In some embodiments, however, the ventilator100may also include a housing, one or more transparent portions of a housing, a handle, user interfaces, interfaces to some of the components depicted inFIG. 1, and other components.

The ventilator100depicted inFIG. 1includes a plurality of components that are depicted in this example as being mounted on a horizontal mount plate102and a plurality of components that are depicted in this example as being mounted on a vertical mount plate104. For example, the ventilator depicted inFIG. 1includes a manual resuscitator106and a motor108. The manual resuscitator106depicted inFIG. 1may be embodied, for example, as a bag valve mask (BVM), sometimes known by the proprietary name Ambu bag. The manual resuscitator106may be a device that is often used to provide positive pressure ventilation to patients who are not breathing (or not breathing adequately). In some embodiments, the manual resuscitator106may include a flexible air chamber (i.e., the bag) that can be attached to an attached to a face mask via a shutter valve, such that breathing assistance may be provided to a patent that is wearing the face mask by compressing the flexible air chamber, which reinflates when the bag is not being compressed. In some embodiments, the manual resuscitator106can deliver breathing assistance to a patient without the use of a face mask, as the manual resuscitator106may utilize an alternative airway adjunct such as, for example, an endotracheal tube or a laryngeal mask airway.

The motor108depicted inFIG. 1may be embodied, for example, as an electric motor that converts electrical energy into mechanical energy. For example, the motor108may be embodied as a windshield wiper motor that runs on 12V of electricity, which may be provided by the power supply110depicted inFIG. 1.

In the example depicted inFIG. 1, the motor108may be mechanically coupled to a compression plate112. The motor108may be mechanically coupled to a compression plate112, for example, through the use of one or more movable linkages. In such an example, operation of the motor108may cause the compression plate112to move via the linkages such that the compression plate112operates as a piston that moves back and forth along an axis. In such an example, due the positioning of the compression plate112, the manual resuscitator106, and a fixed resuscitator plate114, operating the motor may cause the compression plate112to periodically compress the manual resuscitator106against a resuscitator plate114. As described above, through compression (when the compression plate112is positioned so as to compress the manual resuscitator106against a resuscitator plate114) and reinflation of the manual resuscitator106(when the compression plate112is positioned so as to not compress the manual resuscitator106against a resuscitator plate114), breathing assistance may be delivered to a patient.

The ventilator100depicted inFIG. 1also includes a motor controller116for controlling the operation of the motor108, as will as one of more computer processors118and a user interface120. The motor controller116and the one of more computer processors118may be part of a larger ventilator control system that may include computer program instructions (referred to herein as a motor control model) that may be executed on the one of more computer processors118. The motor control model may include, for example, one or more modules of computer program instructions that, when executed, can impact the extent to which power is delivered to the motor108from a power supply110. The motor control model may be configured, for example, to influence the manner in which power is delivered to the motor108to improve the function or longevity of ventilator, to influence the manner in which power is delivered to the motor108to deliver improved breathing assistance to a patient, and so on. The motor control model, including the creation thereof through machine learning techniques, will be described in greater detail below.

For further explanation,FIG. 2sets forth a second perspective of internal components of a ventilator100in accordance with some embodiments of the present disclosure. The perspective depicted inFIG. 2includes an illustration of the linkage system202that is used to couple the motor108to the compression plate112. The linkage system202may be embodied, for example, as an assembly of bodies connected to manage forces and movement of the compression plate112. In such an example, as the motor108, the motor generates a torque that is used to move the linkage system202. Because the compression plate112is fixed to one or more components of the linkage system202, moving the linkage system202causes the compression plate112.

In the example depicted inFIG. 2, the ventilator100also includes a linkage guide and mount204that controls the direction that the linkage system202and the compression plate112are moved. When the compression plate112is moved towards the fixed resuscitator plate114, the compression plate112exerts a force on the bag of the manual resuscitator106, thereby causing compression of the manual resuscitator106. When the compression plate112is moved away from the fixed resuscitator plate114, the compression plate112exerts less force on the bag of the manual resuscitator106, thereby enabling the bag to reinflate.

In some embodiments, ventilators may include additional components beyond those that are depicted inFIG. 1andFIG. 2. For example, ventilators in accordance with some embodiments of the present disclosure may include one or more operational parameter adjustment controls. The one or more operational parameter adjustment controls may be embodied, for example, as a mechanical device such as a button, a knob, or other device that enables an operator of the ventilator to adjust one or more operating parameters associated with the ventilator. The one or more operational parameter adjustment controls may be used to set or change the operating mode for the ventilator, to set or change the number of compressions of per unit of time of the manual resuscitator106that should occur, to set or change the inspiratory to expiratory ratio for the manual resuscitator106, to set or change the tidal volume for the manual resuscitator106, and others. In other embodiments, the one or more operational parameter adjustment controls may be embodied in other ways such as through the use of icons on a touchscreen display. Readers will appreciate that the operation of the motor108may be adjusted in response to a value of a particular operational parameter being changed using the one or more operational parameter adjustment controls. For example, the operation of the motor108may be adjusted to perform a different number of cycles per unit of time, the operation of the motor108may be adjusted to deliver more torque, and so on.

Ventilators in accordance with some embodiments of the present disclosure may also include one or more sensors. In general, the sensors may be broken up into two broad categories of sensors. A first category of sensors relates to sensors whose outputs can monitor the health of the patient and can be used to control the operation of the ventilator to improve the health of the patient. Such sensors can include, for example, a pressure sensor, a patient pulse oximeter, an inline oxygen flow meter, a mass flow sensor, an electrical sensor, a humidity sensor, a temperature sensor, other sensors, and combinations of such sensors. These sensors may be located on the ventilator itself (or some portion thereof), such as being placed along the airway between the manual resuscitator and the patient's face mask.

A second category of sensors relates to sensors whose outputs can monitor the health of the ventilator and can be used to for predictive maintenance or prescriptive maintenance purposes as described in greater detail below. Through the usage of such sensors and artificial intelligence enabled solutions, ventilators may be created relatively quickly and at a relatively low cost with easily obtained components as compared to traditional ventilators. These artificial intelligence enabled ventilators may operate as reliably or even more reliably than their traditional counterparts, through the pairing of the ventilator with predictive maintenance solutions and other solutions as described in greater detail below.

In some embodiments, the one of more computer processors118may be configured to execute computer program instructions that adjust the operation of the ventilator100in response to sensor data received from the one or more sensors. For example, a pressure sensor that is located between a face mask worn by a patient and an inspiratory valve of the manual resuscitator106may be utilized to capture data, where sensor data that is output by the pressure sensor may be used to detect irregularities with the patient's ventilation and adjust the operation of the ventilator100(e.g., by changing the operation of the motor108) automatically and without user intervention, as will be described in greater detail below.

In other embodiments, the one of more computer processors118may be configured to execute computer program instructions that generate alerts in response to sensor data that is received from the one or more sensors. Continuing with the example in which a pressure sensor is located between a face mask worn by a patient and an inspiratory valve of the manual resuscitator106may be utilized to capture data, sensor data that is output by the pressure sensor may be used to detect a mechanical malfunction of the ventilator100. For example, a pressure reading may indicate that there is a leak or blockage in some portion of the ventilator100, a pressure reading may indicate that the motor108has failed, and so on. In response to detecting the occurrence of such an event, alerts may be taken, although in other embodiments corrective actions (e.g., power cycling the motor108) may be taken.

For further explanation,FIG. 3sets forth a diagram of a ventilator300in accordance with some embodiments of the present disclosure. Although different details of the ventilator300are illustrated inFIG. 3, the ventilator300depicted inFIG. 3may be similar to the ventilators described above with reference toFIG. 1andFIG. 2as the ventilator300may also include the components described above. The ventilator300depicted inFIG. 3includes an electric motor304, a power supply352, a memory312, and one or more operator controls328(e.g., the operational parameter adjustment controls) that are coupled to one or more processors320. Readers will appreciate that although only a single power supply352is depicted for ease of explanation, additional sources of electrical power (e.g., a backup battery) may actually be included in the ventilator300.

The ventilator300depicted inFIG. 3also includes one or more sensors318configured to generate sensor data324that may be used to create operation data336for the ventilator300. The operation data336can include sensor data324describing the operation of the ventilator300, sensor data324describing the condition of a patient, some other form of sensor data324, or a combination thereof. The operation data336can also include control inputs330generated from the operator controls328, such that the operation data336can include a combination of data generated from sensors and data generated in response to an operator332(e.g., a nurse, a doctor) interacting with the ventilator300. Such operation data336may be received, for example, through the use of an operation data interface322.

The ventilator300depicted inFIG. 3also includes a memory312that is coupled to one or more processors320. The one or more processors320may include one or more single-core or multi-core central processing units (CPUs), one or more digital signal processors (DSPs), one or more graphics processing units (GPUs), or any combination thereof. In this example, the memory312and the one or more processors320are incorporated in an electronic control module350(“ECM”) that is coupled to the electric motor304, the sensors318, and the one or more operator controls328. In some implementations, the memory312includes volatile memory devices, non-volatile memory devices, or both, such as one or more hard drives, solid-state storage devices (e.g., flash memory, magnetic memory, or phase change memory), a random-access memory (RAM), a read-only memory (ROM), one or more other types of storage devices, or any combination thereof. Although the memory312and the one or more processors320are depicted within the electronic control module350, in other implementations, one or both of the memory312and the one or more processors320may be external to the electronic control module350.

The memory312depicted inFIG. 3includes one or more trained models314. The one or more trained models314(e.g., trained machine learning models) may be executable by the one or more processors320to initiate, perform, or control various operations of the ventilator300. The one or more trained models314inFIG. 3may include, amongst other models, a motor control model316.

The motor control model316may be embodied, for example, as one or more modules of computer program instructions that, when executed, can control the operation of the motor304. For example, the motor control model316may be configured to operate the electric motor304in such a way so as to cause a compression plate to periodically compress a manual resuscitator against a resuscitator plate and, responsive to receiving a signal (in the form of the operation data336), adjust the operation of the electric motor304. The motor control model316may be further configured to control the operation of the motor304, for example, in order to adjust the operation of the ventilator300in response to detecting a possible malfunction with the ventilator300, in order to adjust the operation of the ventilator300to adjust the manner in which the ventilator300assists the breathing of a patient, or for other reasons. The motor control model316may control the operation of the motor304through the use of a control signal interface340that can send a control signal338to the electric motor304. The motor control model316, including the creation thereof through machine learning techniques, will be described in greater detail below.

For further explanation,FIG. 4Asets forth a flow chart illustrating an example method of operating a ventilator400in accordance with some embodiments of the present disclosure. Although depicted in less detail, the ventilator400ofFIG. 4Amay be similar to the ventilators described elsewhere in the present disclosure and may contain the same, additional, or fewer components described elsewhere in the present disclosure. In fact, the example method depicted inFIG. 4Amay be carried out by an apparatus such as an ECM that is included in the ventilator400as described above.

The example method depicted inFIG. 4Aincludes operating402an electric motor408. Operating402an electric motor408may be carried out, for example, by delivering power to the electric motor through a battery, a power supply, or another power source. Once the electric motor408is powered up, a control signal may be sent to the electric motor to begin operation of the electric motor408. In such an example, the initial operating state of the electric motor (e.g., how many cycles per unit of time that the motor is performing, the amount of torque generated by the motor) may be set in a variety of ways. For example, the electric motor408may operate in accordance with its most recently used performance settings, the electric motor408may operate in accordance with its default performance settings, or the electric motor408may operate in accordance with some other settings, including settings that were determined by a trained model.

Consider an example in which a model was trained using data describing various ventilator related settings that were utilized for patients of a certain age, patients of a certain weight range, patients with certain conditions, and so on. In such an example, information describing how the patients responded to various ventilator related settings may also be utilized to generate a model that can identify optimal ventilator related settings for a particular patient, based on the characteristics of that patient. In such an example, this trained model may be supported by the ECM (or by some other execution environment) such that providing the trained model with information describing a particular patient may cause the trained model to generate, as output, information describing the anticipated best ventilator settings for that patient. In other words, the trained model may be used to determine one or more initial operating parameters for the ventilator based on information describing a patient. For example, if a particular patient was a male between the ages of 48-52 with a body mass index between 18-20, the model may determine (based on analyzing large volumes of data describing patient's historical responses to various ventilator settings), that the ventilator should initially be set to support a respiratory rate of 27 beats per minute with a tidal volume of 525 mL. In such an example, the electric motor may be configured to deliver a particular torque at a particular rate that would cause the manual resuscitator to support a respiratory rate of 27 beats per minute with a tidal volume of 525 mL. Although not depicted inFIG. 4A, the electric motor408may be mechanically coupled to a compression plate, wherein operation of the motor causes the compression plate to periodically compress the manual resuscitator against a resuscitator plate, as described above.

The example method depicted inFIG. 4Aalso includes, responsive to receiving a signal410, adjusting404the operation of the electric motor408. In the example method depicted inFIG. 4A, the signal410may be received in response to a value of a particular operational parameter being changed using the one or more operational parameter adjustment controls412. Consider an example in which the operational parameter adjustment controls412include one or more buttons through which an operator can adjust the tidal volume to be delivered by the ventilator. In such an example, if an operator presses such buttons to change the tidal volume settings associated with the ventilator, the operation of the electric motor408can be adjusted404so as to cause the compression plate to periodically compress the manual resuscitator against a resuscitator plate with a force that will cause the manual resuscitator to produce a tidal volume that corresponds to the adjusted setting. In other embodiments, the signal410may be generated in response to the analysis of sensor data by a trained model, or in some other way. In such an example, adjusting404the operation of the electric motor408may be carried out through the use of a control signal406as described in other portions of the present disclosure.

For further explanation,FIG. 4Bsets forth a flow chart illustrating an additional example method of operating a ventilator400in accordance with some embodiments of the present disclosure. Although depicted in less detail, the ventilator400ofFIG. 4Bmay be similar to the ventilators described elsewhere in the present disclosure and may contain the same, additional, or fewer components described elsewhere in the present disclosure. In fact, the example method depicted inFIG. 4Bmay be carried out by an apparatus such as an ECM that is included in the ventilator400as described above. The example method depicted inFIG. 4Bis similar to the example method depicted inFIG. 4A, as the example method depicted inFIG. 4Balso includes operating402an electric motor408and, responsive to receiving a signal410, adjusting404the operation of the electric motor408.

In the example method depicted inFIG. 4B, the ventilator includes one or more sensors414. The one or more sensors may include a pressure sensor that detects feedback from patient's breathing, thereby enabling the adjustment of the ventilator400to an appropriate pressure to improve a patient's breathing. Likewise, the pressure sensor may be used to detects mechanical malfunction of the ventilator400as described above. The one or more sensors may also include a patient pulse oximeter that measures oxygenation level of the patient's blood and pulse rate. If oxygenation levels are too low, for example, operation of the ventilator400may be adjusted to improve a patient's oxygenation level. The one or more sensors may also include an inline oxygen flow meter to detect the level of oxygen being supplemented to the patient and, using pulse oximeter readings, throttle air flow as needed. The one or more sensors may also include a mass flow sensor to gather improved breath tracking for data more accurate understanding of patient's breathing cycle, which may in turn be used to adjust the operation of the ventilator400to improve a patient's breathing. The one or more sensors may also include an electrical sensor for anticipatory breathing assistance if patient is not in a medically induced coma, a humidity sensor to control a humidifier system, a temperature sensor for air quality and humidifying calculations, and other sensors in accordance with embodiments of the present disclosure. Readers will appreciate that the ventilators described herein may also implement various combinations of the sensors described above and may even package groups of sensors such that ventilators with a variety of designs and complexity may be utilized as needed.

The example method depicted inFIG. 4Balso includes receiving418, from the one or more sensors414, sensor data416corresponding to a condition of one or more components of the ventilator400. As described above, data from a pressure sensor may be used to indicate that some component of the ventilator400is comprised as low-pressure readings may indicate, for example, that the ventilator has a leak, that the compression plate is not compressing the manual resuscitator against a resuscitator plate as expected or may be otherwise indicative of a failure with one or more components of the ventilator400. In accordance with embodiments of the present disclosure, other sensors may also be used to monitor the condition of one or more components of the ventilator400. For example, a temperature sensor may be used to monitor the motor408and detect that the motor is overheating, a force sensor may be used to verify that a force exerted by the compression plate is as expected, and so on. As such, sensor data416may be received and the sensor data may be analyzed by a trained model to determine that the sensor data416corresponds to a known condition (e.g., an ‘operating properly’ condition, an ‘operating improperly’ condition, a ‘disabled’ condition, an ‘offline’ condition, a ‘failing’ condition) of one or more components of the ventilator400. In such an example, this sensor data416may be used to evaluate whether one or more components of the ventilator400are operating as expected.

The example method depicted inFIG. 4Balso includes determining420, using a trained model, whether the one or more components of the ventilator400are operating in an acceptable manner. Determining420whether the one or more components of the ventilator400are operating in an acceptable manner may be carried out, for example, using a trained model that evaluates sensor data416to determine whether components have failed, are about to fail, or otherwise are not operating as expected. In such an example, the model may be trained using historical sensor data to identify components that have failed, are about to fail, or otherwise are not operating as expected. In other embodiments, determining420whether the one or more components of the ventilator400are operating in an acceptable manner may be carried by a simple comparison between one or more sensor values and one or more specifications, to identify sensors that are recording operational characteristics that are not within expected specifications.

The example method depicted inFIG. 4Balso includes, responsive to affirmatively422adetermining that the one or more components of the ventilator400are not operating in an acceptable manner, generating424a signal410to adjust operation of the electric motor408. Consider an example in which sensor data indicates that the that the tidal volume of being produced by the ventilator is 525 mL but the ventilator400is configured so as to produce a tidal volume of 650 mL. In such an example, it may be determined420above the bag for the manual resuscitator is not operating as expected based on measurements of the amount of force that is being applied to the bag by the compression plate, as applying such a force would be expected to produce a tidal volume of 650 mL. In such an example, a signal410may be generated424to adjust the operation of the motor408in such a way that the compression plate exerts additional pressure on the bag in an effort to achieve the desired tidal volume.

The example method depicted inFIG. 4Balso includes, responsive to affirmatively422bdetermining that the one or more components of the ventilator400are not operating in an acceptable manner, generating426an alert428. The alert428may be generated, for example, for presentation on a display associated with the ventilator400, to produce a noise to alert medical personal to the problem, to illuminate an indicator light, or in some other way. In some embodiments, the alert428may include information describing a projected failure of one or more components of the ventilator400. The projected failure may be identified through the use of one or more trained models that are configured to identify potential failures based on sensor data or some other data. As such, in order to address a projected failure, the ventilator400may be repaired or replaced so as to avoid placing the patient a situation where there are without breathing assistance.

For further explanation,FIG. 5sets forth an example of a system500for generating a machine learning data model, such as one or more of the trained models that can be used by the one or more processors, the ECM, or the ventilator as described above. AlthoughFIG. 5depicts a particular example for purpose of explanation, in other implementations other systems may be used for generating or updating one or more of the trained models.

In some examples, the system500, or portions thereof, may be implemented using (e.g., executed by) one or more computing devices, such as laptop computers, desktop computers, mobile devices, servers, and Internet of Things devices and other devices utilizing embedded processors and firmware or operating systems, etc. In the illustrated example, the system500includes a genetic algorithm510and an optimization trainer560. The optimization trainer560is, for example, a backpropagation trainer, a derivative free optimizer (DFO), an extreme learning machine (ELM), etc. In particular implementations, the genetic algorithm510is executed on a different device, processor (e.g., central processor unit (CPU), graphics processing unit (GPU) or other type of processor), processor core, and/or thread (e.g., hardware or software thread) than the optimization trainer560. The genetic algorithm510and the optimization trainer560are executed cooperatively to automatically generate a machine learning data model (e.g., one of the trained models described above and referred to herein as “models” for ease of reference), such as a neural network or an autoencoder, based on the input data502. In this example, the system500performs an automated model building process that enables users, including inexperienced users, to quickly and easily build highly accurate models based on a specified data set.

In some implementations, during configuration of the system500, a user specifies the input data502. In some implementations, the user may also specify one or more characteristics of models that can be generated. In such implementations, the system500constrains models processed by the genetic algorithm510to those that have the one or more specified characteristics. For example, the specified characteristics may constrain allowed model topologies (e.g., to include no more than a specified number of input nodes or output nodes, no more than a specified number of hidden layers, no recurrent loops, etc.). In some examples, constraining the characteristics of the models can reduce the computing resources (e.g., time, memory, processor cycles, etc.) needed to converge to a final model, can reduce the computing resources needed to use the model (e.g., by simplifying the model), or both.

In some implementations, a user can configure aspects of the genetic algorithm510via input to graphical user interfaces (GUIs). For example, the user may provide input to limit a number of epochs that will be executed by the genetic algorithm510. Alternatively, the user may specify a time limit indicating an amount of time that the genetic algorithm510has to execute before outputting a final output model, and the genetic algorithm510may determine a number of epochs that will be executed based on the specified time limit. To illustrate, an initial epoch of the genetic algorithm510may be timed (e.g., using a hardware or software timer at the computing device executing the genetic algorithm510, and a total number of epochs that are to be executed within the specified time limit may be determined accordingly. As another example, the user may constrain a number of models evaluated in each epoch, for example by constraining the size of an input set520of models and/or an output set530of models.

In some implementations, a genetic algorithm510represents a recursive search process. Consequently, each iteration of the search process (also called an epoch or generation of the genetic algorithm510has an input set520of models (also referred to herein as an input population) and an output set530of models (also referred to herein as an output population). The input set520and the output set530may each include a plurality of models, where each model includes data representative of a machine learning data model. For example, each model may specify a neural network or an autoencoder by at least an architecture, a series of activation functions, and connection weights. The architecture, also referred to herein as a topology, of a model includes a configuration of layers or nodes and connections therebetween. The models may also be specified to include other parameters, including but not limited to bias values/functions and aggregation functions.

For example, each model can be represented by a set of parameters and a set of hyperparameters. In this context, the hyperparameters of a model define the architecture of the model (e.g., the specific arrangement of layers or nodes and connections), and the parameters of the model refer to values that are learned or updated during optimization training of the model. For example, the parameters include or correspond to connection weights and biases.

In a particular implementation, a model is represented as a set of nodes and connections therebetween. In such implementations, the hyperparameters of the model include the data descriptive of each of the nodes, such as an activation function of each node, an aggregation function of each node, and data describing node pairs linked by corresponding connections. The activation function of a node is a step function, sine function, continuous or piecewise linear function, sigmoid function, hyperbolic tangent function, or another type of mathematical function that represents a threshold at which the node is activated. The aggregation function is a mathematical function that combines (e.g., sum, product, etc.) input signals to the node. An output of the aggregation function may be used as input to the activation function.

In other implementations, the model is represented on a layer-by-layer basis. For example, the hyperparameters define layers, and each layer includes layer data, such as a layer type and a node count. Examples of layer types include fully connected, long short-term memory (LSTM) layers, gated recurrent units (GRU) layers, and convolutional neural network (CNN) layers. In some implementations, all of the nodes of a particular layer use the same activation function and aggregation function. In such implementations, specifying the layer type and node count fully may describe the hyperparameters of each layer. In other implementations, the activation function and aggregation function of the nodes of a particular layer can be specified independently of the layer type of the layer. For example, in such implementations, one fully connected layer can use a sigmoid activation function and another fully connected layer (having the same layer type as the first fully connected layer) can use a tanh activation function. In such implementations, the hyperparameters of a layer include layer type, node count, activation function, and aggregation function. Further, a complete autoencoder is specified by specifying an order of layers and the hyperparameters of each layer of the autoencoder.

In some implementations, a genetic algorithm510may be configured to perform speciation. For example, the genetic algorithm510may be configured to cluster the models of the input set520into species based on “genetic distance” between the models. The genetic distance between two models may be measured or evaluated based on differences in nodes, activation functions, aggregation functions, connections, connection weights, layers, layer types, latent-space layers, encoders, decoders, etc. of the two models. In an illustrative example, the genetic algorithm510may be configured to serialize a model into a bit string. In this example, the genetic distance between models may be represented by the number of differing bits in the bit strings corresponding to the models. The bit strings corresponding to models may be referred to as “encodings” of the models.

In some implementations, after configuration, a genetic algorithm510may begin execution based on the input data502. Parameters of the genetic algorithm510may include but are not limited to, mutation parameter(s), a maximum number of epochs the genetic algorithm510will be executed, a termination condition (e.g., a threshold fitness value that results in termination of the genetic algorithm510even if the maximum number of generations has not been reached), whether parallelization of model testing or fitness evaluation is enabled, whether to evolve a feedforward or recurrent neural network, etc. As used herein, a “mutation parameter” affects the likelihood of a mutation operation occurring with respect to a candidate neural network, the extent of the mutation operation (e.g., how many bits, bytes, fields, characteristics, etc. change due to the mutation operation), and/or the type of the mutation operation (e.g., whether the mutation changes a node characteristic, a link characteristic, etc.). In some examples, the genetic algorithm510uses a single mutation parameter or set of mutation parameters for all of the models. In such examples, the mutation parameter may impact how often, how much, and/or what types of mutations can happen to any model of the genetic algorithm510. In alternative examples, the genetic algorithm510maintains multiple mutation parameters or sets of mutation parameters, such as for individual or groups of models or species. In particular aspects, the mutation parameter(s) affect crossover and/or mutation operations, which are further described below.

In some implementations, for an initial epoch of a genetic algorithm510, the topologies of the models in the input set520may be randomly or pseudo-randomly generated within constraints specified by the configuration settings or by one or more architectural parameters. Accordingly, the input set520may include models with multiple distinct topologies. For example, a first model of the initial epoch may have a first topology, including a first number of input nodes associated with a first set of data parameters, a first number of hidden layers including a first number and arrangement of hidden nodes, one or more output nodes, and a first set of interconnections between the nodes. In this example, a second model of the initial epoch may have a second topology, including a second number of input nodes associated with a second set of data parameters, a second number of hidden layers including a second number and arrangement of hidden nodes, one or more output nodes, and a second set of interconnections between the nodes. The first model and the second model may or may not have the same number of input nodes and/or output nodes. Further, one or more layers of the first model can be of a different layer type that one or more layers of the second model. For example, the first model can be a feedforward model, with no recurrent layers, whereas the second model can include one or more recurrent layers.

In some implementations, a genetic algorithm510may automatically assign an activation function, an aggregation function, a bias, connection weights, etc. to each model of the input set520for the initial epoch. In some aspects, the connection weights are initially assigned randomly or pseudo-randomly. In some implementations, a single activation function is used for each node of a particular model. For example, a sigmoid function may be used as the activation function of each node of the particular model. The single activation function may be selected based on configuration data. For example, the configuration data may indicate that a hyperbolic tangent activation function is to be used or that a sigmoid activation function is to be used. Alternatively, the activation function may be randomly or pseudo-randomly selected from a set of allowed activation functions, and different nodes or layers of a model may have different types of activation functions. Aggregation functions may similarly be randomly or pseudo-randomly assigned for the models in the input set520of the initial epoch. Thus, the models of the input set520of the initial epoch may have different topologies (which may include different input nodes corresponding to different input data fields if the data set includes many data fields) and different connection weights. Further, the models of the input set520of the initial epoch may include nodes having different activation functions, aggregation functions, and/or bias values/functions.

In some implementations, during execution, a genetic algorithm510performs fitness evaluation540and evolutionary operations550on the input set520. In this context, fitness evaluation540includes evaluating each model of the input set520using a fitness function542to determine a fitness function value544(“FF values” inFIG. 5) for each model of the input set520. The fitness function values544are used to select one or more models of the input set520to modify using one or more of the evolutionary operations550. InFIG. 5, the evolutionary operations550include mutation operations552, crossover operations554, and extinction operations556, each of which is described further below.

In some implementations, during a fitness evaluation540, each model of the input set520is tested based on the input data502to determine a corresponding fitness function value544. For example, a first portion504of the input data502may be provided as input data to each model, which processes the input data (according to the network topology, connection weights, activation function, etc., of the respective model) to generate output data. The output data of each model is evaluated using the fitness function542and the first portion504of the input data502to determine how well the model modeled the input data502. In some examples, fitness of a model is based on reliability of the model, performance of the model, complexity (or sparsity) of the model, size of the latent space, or a combination thereof.

In some implementations, fitness evaluation540of the models of the input set520is performed in parallel. To illustrate, the system500may include devices, processors, cores, and/or threads580in addition to those that execute the genetic algorithm510and the optimization trainer560. These additional devices, processors, cores, and/or threads580can perform the fitness evaluation540of the models of the input set520in parallel based on a first portion504of the input data502and may provide the resulting fitness function values544to the genetic algorithm510.

In some implementations, a mutation operation552and a crossover operation554are highly stochastic under certain constraints and a defined set of probabilities optimized for model building, which produces reproduction operations that can be used to generate the output set530, or at least a portion thereof, from the input set520. In a particular implementation, the genetic algorithm510utilizes intra-species reproduction (as opposed to inter-species reproduction) in generating the output set530. In other implementations, inter-species reproduction may be used in addition to or instead of intra-species reproduction to generate the output set530. Generally, the mutation operation552and the crossover operation554are selectively performed on models that are more fit (e.g., have higher fitness function values544), fitness function values544that have changed significantly between two or more epochs, or both).

In some implementations, an extinction operation556uses a stagnation criterion to determine when a species should be omitted from a population used as the input set520for a subsequent epoch of the genetic algorithm510. Generally, the extinction operation556is selectively performed on models that are satisfy a stagnation criterion, such as modes that have low fitness function values544, fitness function values544that have changed little over several epochs, or both.

In accordance with the present disclosure, cooperative execution of a genetic algorithm510and an optimization trainer560is used arrive at a solution faster than would occur by using a genetic algorithm510alone or an optimization trainer560alone. Additionally, in some implementations, the genetic algorithm510and the optimization trainer560evaluate fitness using different data sets, with different measures of fitness, or both, which can improve fidelity of operation of the final model. To facilitate cooperative execution, a model (referred to herein as a trainable model532inFIG. 5) is occasionally sent from the genetic algorithm510to the optimization trainer560for training. In a particular implementation, the trainable model532is based on crossing over and/or mutating the fittest models (based on the fitness evaluation540) of the input set520. In such implementations, the trainable model532is not merely a selected model of the input set520; rather, the trainable model532represents a potential advancement with respect to the fittest models of the input set520.

In some implementations, an optimization trainer560uses a second portion506of the input data502to train the connection weights and biases of the trainable model532, thereby generating a trained model562. The optimization trainer560does not modify the architecture of the trainable model532.

In some implementations, during optimization, an optimization trainer560provides a second portion506of the input data502to the trainable model532to generate output data. The optimization trainer560performs a second fitness evaluation570by comparing the data input to the trainable model532to the output data from the trainable model532to determine a second fitness function value574based on a second fitness function572. The second fitness function572is the same as the first fitness function542in some implementations and is different from the first fitness function542in other implementations. In some implementations, the optimization trainer560or portions thereof is executed on a different device, processor, core, and/or thread than the genetic algorithm510. In such implementations, the genetic algorithm510can continue executing additional epoch(s) while the connection weights of the trainable model532are being trained by the optimization trainer560. When training is complete, the trained model562is input back into (a subsequent epoch of) the genetic algorithm510, so that the positively reinforced “genetic traits” of the trained model562are available to be inherited by other models in the genetic algorithm510.

In implementations where the genetic algorithm510employs speciation, a species ID of each of the models may be set to a value corresponding to the species that the model has been clustered into. A species fitness may be determined for each of the species. The species fitness of a species may be a function of the fitness of one or more of the individual models in the species. As a simple illustrative example, the species fitness of a species may be the average of the fitness of the individual models in the species. As another example, the species fitness of a species may be equal to the fitness of the fittest or least fit individual model in the species. In alternative examples, other mathematical functions may be used to determine species fitness. The genetic algorithm510may maintain a data structure that tracks the fitness of each species across multiple epochs. Based on the species fitness, the genetic algorithm510may identify the “fittest” species, which may also be referred to as “elite species.” Different numbers of elite species may be identified in different embodiments.

In some implementations, a genetic algorithm510uses species fitness to determine if a species has become stagnant and is therefore to become extinct. As an illustrative non-limiting example, the stagnation criterion of the extinction operation556may indicate that a species has become stagnant if the fitness of that species remains within a particular range (e.g., +/−5%) for a particular number (e.g., 5) of epochs. If a species satisfies a stagnation criterion, the species and all underlying models may be removed from subsequent epochs of the genetic algorithm510.

In some implementations, the fittest models of each “elite species” may be identified. The fittest models overall may also be identified. An “overall elite” need not be an “elite member,” e.g., may come from a non-elite species. Different numbers of “elite members” per species and “overall elites” may be identified in different embodiments.”

In some implementations, an output set530of the epoch is generated based on the input set520and the evolutionary operation550. In the illustrated example, the output set530includes the same number of models as the input set520. In some implementations, the output set530includes each of the “overall elite” models and each of the “elite member” models. Propagating the “overall elite” and “elite member” models to the next epoch may preserve the “genetic traits” resulted in caused such models being assigned high fitness values.

In some implementations, the rest of the output set530may be filled out by random reproduction using the crossover operation554and/or the mutation operation552. After the output set530is generated, the output set530may be provided as the input set520for the next epoch of the genetic algorithm510.

In some implementations, after one or more epochs of a genetic algorithm510and one or more rounds of optimization by an optimization trainer560, the system500selects a particular model or a set of models as the final model (e.g., a model that is executable to perform one or more of the model-based operations ofFIGS. 1-4B). For example, the final model may be selected based on the fitness function values544,574. For example, a model or set of models having the highest fitness function value544or574may be selected as the final model. When multiple models are selected (e.g., an entire species is selected), an ensemble can be generated (e.g., based on heuristic rules or using the genetic algorithm510to aggregate the multiple models. In some implementations, the final model can be provided to the optimization trainer560for one or more rounds of optimization after the final model is selected. Subsequently, the final model can be output for use with respect to other data (e.g., real-time data).

Although the examples described above are largely described in the context of a single ventilator whose operation may be controlled and monitored by one or more trained models, in other embodiments the techniques described herein may be applied across a fleet of ventilators. In such an embodiment, a centralized resource may be communicatively coupled (directly or indirectly) to each of the ventilators that the centralized resource is responsible for controlling and monitoring. The centralized resource may be embodied, for example, as one or more modules of computer program instructions executing on physical or virtualized computer hardware. For example, the centralized resource may be embodied as one or more computing systems that are supporting the execution of a predictive maintenance product such as SparkPredict™ from SparkCognition™.

In such an example, each of the ventilators may be equipped with one or more sensors as described above, and sensor data may be gathered and ultimately communicated to the centralized resource. Upon receiving the sensor data from the ventilators, the centralized resource may use sensor data (as well as other data related to the ventilators such as age, amount of time in use, information describing specific components of each ventilator, and more) to evaluate the health of the ventilator, to generate alerts that some maintenance event is predicted to be needed, and so on. Such sensors can include not only the sensors described above, but may also include additional sensors that are coupled to the ventilator itself, such as a temperature sensor to monitor the temperature of various components with the ventilator, a vibration sensor to monitor vibrations within the sensor, and other sensors as will occur to those of skill in the art. As such, failures or problems may be predicted before the actual occurrence of the failure or problem, such that remedial actions can be taken prior to the occurrence of an event that would cause the ventilator to cease operating as desired.

Readers will appreciate that in order to generate predictive maintenance models, training may take place to classify operating states or learning what is “normal behavior” of the ventilator based on sensor output, such that the models can flag anomalies or flag other deviations from normal behavior. When an alert is generated by these models, a review can be conducted to identify which features (i.e., sensors) contributed most to the alert and a determination may be made as to whether a failure actually occurred, or an anomalous state was entered into. In some examples, the features contributing most to the alert may be automatically determined using relative feature importance estimation or other techniques. Furthermore, a label may be provided for the failure/state and a decision may be reached as to whether the models should be trained to identity that condition in the future (in which case the condition could be identified with even more lead time by virtue of having included in the training data a time series of sensor values leading up to the alert). In addition, if there are specific solution steps that worked to fix the problem, those solution steps could be linked to this now predictable condition, thereby enabling not just predictive maintenance but also prescriptive maintenance. Additional information related to the models and workflows that can enable predictive maintenance and prescriptive maintenance may be found in U.S. Ser. No. 63/014,678 (hereafter, ‘the parent application’), all of which is incorporated by reference into the present disclosure.

In some embodiments, the ability to perform predictive maintenance may be developed, at least in part, through the usage of one or more trained autoencoders. The one or more trained autoencoders may be generated and trained in a variety of ways, include through the use of automated model building systems and methods that cooperatively use a genetic algorithm and selective optimization training to generate and train an autoencoder to monitor one or more devices for anomalous operational states, as described in greater detail in the parent application. In such embodiments, combining a genetic algorithm with selective optimization training as enables generation of an autoencoder that is able to detect anomalous operation significantly before failure of a monitored device (in this case a ventilator), where the cooperative use of the genetic algorithms and optimization training is faster and uses fewer computing resources than training a monitoring autoencoder using backpropagation or genetic algorithms alone, although those individual techniques may also be used alone in some embodiments. Such autoencoders may have symmetric or asymmetric topologies, as further described herein and in the parent application.

In accordance with the described techniques, a combination of a genetic algorithm and an optimization algorithm (such as backpropagation, a derivative free optimizer (DFO), an extreme learning machine (ELM), or a similar optimizer) may be used to generate and then train an autoencoder. As used herein, the terms “optimizer,” “optimization trainer,” and similar terminology, is not to be interpreted as requiring such components or steps to generate literal optimal results (e.g., 100% prediction or classification accuracy). Rather, these terms indicate an attempt to generate an output that is improved in some fashion relative to an input. For example, an optimization trainer that receives a trainable autoencoder as input and outputs a trained autoencoder may attempt to decrease reconstruction losses of the trainable autoencoder by modifying one or more attributes of the trainable autoencoder.

For further explanation,FIG. 6AandFIG. 6Bcollectively illustrate an example of a method of cooperative execution of a genetic algorithm and an optimization trainer to generate an autoencoder in accordance with some embodiments of the present disclosure. The example method depicted here may be performed in a system as described in greater detail in the parent application. The method600may start, at602, and may include generating a randomized input population of models based on an input data set, at604. Each model may include data representative of an autoencoder and each of the models may be part of an input set.

The method600may also include determining, based on a fitness function, a fitness value of each model of the input population, at606. For example, the fitness of each model of the input set may be determined based on the first portion of the input data. The method600may further include determining a subset of models based on their respective fitness values, at608. The subset of models may be the fittest models of the input population, e.g., “overall elites.” For example, “overall elites” may be determined as described with reference to the parent application.

The method600may also include performing multiple sets of operations at least partially concurrently. Continuing to626(inFIG. 6B), the method600may include performing at least one genetic operation with respect to at least one model of the subset to generate a trainable autoencoder. For example, the crossover operation, the mutation operation, or both, may be performed with respect to the “overall elites” to generate the trainable autoencoder.

The method600may also include sending the trainable model to an optimization trainer (e.g., a backpropagation trainer) for training based on a second portion of the input data, at628. For example, an optimization trainer may train the trainable autoencoder based on the second portion of the input data to generate the trained autoencoder, as described with in the parent application.

Returning toFIG. 6A, the genetic algorithm may continue while optimization training occurs. For example, the method600may include grouping the input population of models into species based on genetic distance, at610, and determining species fitness of each species, at612. To illustrate, the models of the input set may be grouped into species and species fitness may be evaluated as described in the parent application.

Continuing to614, species that satisfy a stagnation criterion may be removed. At616, the method600may include identifying a subset of species based on their respective fitness values and identifying models of each species in the subset based on their respective model fitness values. The subset of species may be the fittest species of the input population, e.g., “elite species,” and the identified models of the “elite species” may be the fittest members of those species, e.g., “elite members.” For example, species fitness values, “elite species,” and “elite members” may be determined.

The method600may include determining an output population that includes each “elite member,” the “overall elites,” and at least one model that is generated based on intra-species reproduction, at618. For example, the models of the output set may be determined, where the output set includes the overall elite models, the elite members (including the elite member model), and at least one model generated based on intra-species reproduction using the crossover operation and/or the mutation operation.

The method600may include determining whether a termination criterion is satisfied, at620. The termination criterion may include a time limit, a number of epochs, or a threshold fitness value of an overall fittest model, as illustrative non-limiting examples. If the termination criterion is not satisfied, the method600returns to606and a next epoch of the genetic algorithm is executed, where the output population determined at618is the input population of the next epoch. As described herein, while the genetic algorithm is ongoing, the optimization trainer may train the trainable autoencoder to generate a trained autoencoder. When training is complete, the method600may include receiving the trained autoencoder from the optimization trainer, at630(inFIG. 6B). The trained autoencoder may be added to the input set of an epoch of the genetic algorithm, as shown inFIG. 6B. When the termination criterion is satisfied, at620, the method600may include selecting and outputting a fittest model, at622, and the method600may end, at624. In some implementations, the selected model may be subjected to a final training operation, e.g., by the optimization trainer or by another trainer, before being output.

It is to be understood that the division and ordering of steps inFIGS. 6A and 6Bis for illustrative purposes only and is not to be considered limiting. In alternative implementations, certain steps may be combined and other steps may be subdivided into multiple steps. Moreover, the ordering of steps may change. For example, the termination criterion may be evaluated after determining the “overall elites,” at608, rather than after determining the output population, at618.

For further explanation,FIG. 7illustrate an example of a system700for using an autoencoder to monitor one or more devices for operational anomalies in accordance with some embodiments of the present disclosure. In this particular example the system700uses a non-hourglass autoencoder720, although other autoencoders such as a non-mirrored autoencoder may also be used. In some implementations, the non-hourglass autoencoder720, a non-mirrored autoencoder, or both, are generated using the system described in the parent application.

The system700includes a computer system702including a processor710and memory704. The memory704stores instructions706that are executable by the processor710to monitor sensor data746from one or more devices742and to generate an anomaly detection output734based on the sensor data746.

The computer system702also includes one or more interface devices750which are coupled to one or more sensors744, the device(s)742, one or more other computer devices (e.g., a computing device that stores a maintenance schedule738), or a combination thereof. In the example illustrated here, the interface(s)750receive the sensor data746(in real-time or delayed) from the sensor(s)744. The sensor data746represents operational states of the device(s)742. For example, the sensor data746can include temperature data, pressure data, rotation rate data, vibration data, power level data, or any other data that is indicative of the behavior or operational state of the device(s)742.

The interface(s)750or the processor710generate input data752based on the sensor data746. For example, the input data752can be identical to the sensor data746, of the input data752can be generated by modifying the sensor data746. Examples of modifications that can be used to convert the sensor data746into the input data752include filling in missing data (e.g., by extrapolation), dropping some data, smoothing data, time synchronizing two or more sets of data that have different time signatures or sampling intervals, combining data with other information to generate new data (e.g., calculating a power value based on measured current and voltage values), etc.

The processor710provides the input data752to an autoencoder (e.g., the non-hourglass autoencoder or other form of autoencoder). An encoder portion of the autoencoder720dimensionally reduces the input data752to a latent space. A decoder portion of the autoencoder720then attempts to recreate the input data using the dimensionally reduced data. Output data from the decoder side is compared to the input data752to determine reconstruction error730. A comparator732compares the reconstruction error730to an anomaly detection criterion708to determine whether the sensor data746corresponds to an anomalous or abnormal operational state of the device(s)742. To illustrate, the autoencoder is720may be trained to detect deviation from “normal” behavior, and such deviation may correspond to relatively large amounts of reconstruction error730. The comparator732generates the anomaly detection output734when the reconstruction error730satisfies the anomaly detection criterion708. In a particular example, the anomaly detection criterion708is satisfied when the reconstruction error730is greater than a threshold specified by the anomaly detection criterion708. In another particular example, the anomaly detection criterion708is satisfied when an aggregate or average value of the reconstruction error730is greater than a threshold specified by the anomaly detection criterion708. Other anomaly detection criteria708can also, or in the alternative, be used.

Generally, the reconstruction error730is relatively low in response to the sensor data746representing normal operational states of the device(s)742and is relatively high in response to the sensor data746representing anomalous or abnormal operational states of the device(s)742. For example, when the autoencoder720is generated using the system700, the cooperative use of the genetic algorithm with the first portion of the input data and the optimization trainer with the second portion of the input data ensures that the autoencoder720has a wide range for reconstruction errors730depending on whether the sensor data746represent normal or abnormal operational states of the device(s)742.

The anomaly detection output734can be sent to another device, such one or more other computers systems748, to the device(s)742, etc. For example, when the other computer system(s)748stores or maintains a maintenance schedule738for the device(s)742, the anomaly detection output734can include or correspond to a maintenance action instruction736that causes the other computer system(s)748to update the maintenance schedule738to schedule maintenance for the device(s)742. As another example, the anomaly detection output734can include or correspond to a control signal740that is provided to the device(s)742or to a control or control system associated with the device(s)742to change operation of the device(s)742. For example, the control signal740may cause the device(s)742to shut down, to change one or more operational parameters, to restart or reset, etc.

InFIG. 7, the non-hourglass autoencoder720includes a plurality of layers, including a first layer712having a first count of nodes722, a second layer714having a second count of nodes724, and a third layer716having a third count of nodes726. The first, second, and third layers712,714,716are adjacent to one another in either the encoder portion of the non-hourglass autoencoder720or the decoder portion of the non-hourglass autoencoder720. If the first, second, and third layers712,714,716are in the encoder portion of the nonhourglass autoencoder720, the second count of nodes724is greater than the first count of nodes722. For example, as illustrated in the parent application, the first layer712may correspond to the input layer, the second layer714may correspond to the first hidden layer, and the third layer716may correspond to the second hidden layer. If the first, second, and third layers712,1214,716are in the decoder portion of the non-hourglass autoencoder720, the second count of nodes724is greater than the third count of nodes726.

Thus, the second layer714is a hidden layer that has more nodes than would be present in an hourglass architecture. The additional nodes of this hidden layer provide useful convolution of the data being processed which improves discrimination between sensor data746representing normal and abnormal operational states of the device(s)742. For example, the additional data convolution provided by the second layer714may decrease reconstruction error730associated with sensor data746representing normal operational states of the device(s)742, may increase reconstruction error730associated with sensor data746representing abnormal operational states of the device(s)742, or both.

In the examples described herein, sensor values may be monitored not only for the purposes of predicting that maintenance needs to be performed or identifying solution steps that may be taken, but sensor values may also be monitored for adherence to regulatory rules, best practices, or some predetermined operational requirement. For example, sensor values may be used to determine whether some component (e.g., the manual resuscitator, the motor) are operating within predetermined device specifications.

Readers will further appreciate that while predictive maintenance operations may be performed by the centralized resource, other forms of monitoring or controlling the ventilators may also be performed by the same centralized resource or by another centralized resource. For example, a centralized resource may be responsible for receiving sensor data related to the health of the patient and may make recommendations or actually change the operation of a ventilator based on the sensor data. For example, if the set of sensors includes an oximeter and data from the oximeter indicates that the oxygen saturation of a patient's blood is below a desired level, the centralized resource may generate an alert that is displayed on the ventilator itself, sent to a medical professional, or otherwise distributed. Alternatively, the centralized resource may be configured to adjust the operation of the ventilator (e.g., adjusting the operating to increase the tidal volume) in an effort to improve the patient's condition.

Although the embodiments described above largely relate to embodiments where the operation of a ventilator is monitored and controlled, in other embodiments the techniques described above may be applied to other medical devices. In fact, any medical devices whose operation may be monitored through the usage of sensors or other device that is capable of quantifying aspects related to a medical device's operation may also be monitored and controlled in a similar fashion. Such medical devices may include, as a non-limiting list of examples, anesthetic devices, dialysis machines, sleep diagnostic devices, sleep apnea therapy devices, infusion pumps, oxygen concentrators, and many others.

The systems and methods of the present disclosure may be embodied as a customization of an existing system, an add-on product, a processing apparatus executing upgraded software, a standalone system, a distributed system, a method, a data processing system, a device for data processing, and/or a computer program product. Accordingly, any portion of the system or a module or a decision model may take the form of a processing apparatus executing code, an internet based (e.g., cloud computing) embodiment, an entirely hardware embodiment, or an embodiment combining aspects of the internet, software, and hardware. Furthermore, the system may take the form of a computer program product on a computer-readable storage medium or device having computer-readable program code (e.g., instructions) embodied or stored in the storage medium or device. Any suitable computer-readable storage medium or device may be utilized, including hard disks, CD-ROM, optical storage devices, magnetic storage devices, and/or other storage media. As used herein, a “computer-readable storage medium” or “computer-readable storage device” is not a signal.

Systems and methods may be described herein with reference to screen shots, block diagrams and flowchart illustrations of methods, apparatuses (e.g., systems), and computer media according to various aspects. It will be understood that each functional block of a block diagrams and flowchart illustration, and combinations of functional blocks in block diagrams and flowchart illustrations, respectively, can be implemented by computer program instructions.

Although the disclosure may include a method, it is contemplated that it may be embodied as computer program instructions on a tangible computer-readable medium, such as a magnetic or optical memory or a magnetic or optical disk/disc. All structural, chemical, and functional equivalents to the elements of the above-described exemplary embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the present claims. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the present disclosure, for it to be encompassed by the present claims. Furthermore, no element, component, or method step in the present disclosure is intended to be dedicated to the public regardless of whether the element, component, or method step is explicitly recited in the claims. As used herein, the terms “comprises,” “comprising,” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

In this written description, common features are designated by common reference numbers throughout the drawings. As used herein, various terminology is used for the purpose of describing particular implementations only and is not intended to be limiting. For example, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It may be further understood that the terms “comprise,” “comprises,” and “comprising” may be used interchangeably with “include,” “includes,” or “including.” Additionally, it will be understood that the term “wherein” may be used interchangeably with “where.” As used herein, “exemplary” may indicate an example, an implementation, and/or an aspect, and should not be construed as limiting or as indicating a preference or a preferred implementation. As used herein, an ordinal term (e.g., “first,” “second,” “third,” etc.) used to modify an element, such as a structure, a component, an operation, etc., does not by itself indicate any priority or order of the element with respect to another element, but rather merely distinguishes the element from another element having a same name (but for use of the ordinal term). As used herein, the term “set” refers to a grouping of one or more elements, and the term “plurality” refers to multiple elements. In the present disclosure, terms such as “determining,” “calculating,” “estimating,” “shifting,” “adjusting,” etc. may be used to describe how one or more operations are performed. It should be noted that such terms are not to be construed as limiting and other techniques may be utilized to perform similar operations. Additionally, as referred to herein, “generating,” “calculating,” “estimating,” “using,” “selecting,” “accessing,” and “determining” may be used interchangeably. For example, “generating,” “calculating,” “estimating,” or “determining” a parameter (or a signal) may refer to actively generating, estimating, calculating, or determining the parameter (or the signal) or may refer to using, selecting, or accessing the parameter (or signal) that is already generated, such as by another component or device. As used herein, “coupled” may include “communicatively coupled,” “electrically coupled,” or “physically coupled,” and may also (or alternatively) include any combinations thereof. Two devices (or components) may be coupled (e.g., communicatively coupled, electrically coupled, or physically coupled) directly or indirectly via one or more other devices, components, wires, buses, networks (e.g., a wired network, a wireless network, or a combination thereof), etc. Two devices (or components) that are electrically coupled may be included in the same device or in different devices and may be connected via electronics, one or more connectors, or inductive coupling, as illustrative, non-limiting examples. In some implementations, two devices (or components) that are communicatively coupled, such as in electrical communication, may send and receive electrical signals (digital signals or analog signals) directly or indirectly, such as via one or more wires, buses, networks, etc. As used herein, “directly coupled” may include two devices that are coupled (e.g., communicatively coupled, electrically coupled, or physically coupled) without intervening components.