Turning any bed into an intensive care unit with the Internet of things and artificial intelligence technology. Presenting the enhanced mechanical ventilator

Ventilator’s general description

A programmable device like BeagleBone Black (BBB) is the local brain of the system, synchronizing the sensors (inputs) and the actuator (output). This local brain interchanges information with the Amazon Web Service (AWS)[1] that allocates the ANN and returns operating configurations. The BBB and the AWS use an ESP32 chip as a data gateway with a universal asynchronous receiver transmitter (UART) to connect the BBB and TCP/IP on the side of the ANN. Using a homemade API, the gateway also pushes the estimated operation points, and the patient’s vitals to the Evalu@ service.¹² Since medical applications do not admit information lost (insufficient information or delayed data due to packets lost will affect the decision stage and eventually the patient’s health), we sacrificed speed and preferred reliability by choosing TCP instead of the user datagram protocol (UDP). Recall that UDP is a faster protocol with no recovery mechanisms in case information packets are corrupted or lost.¹³ The firmware is written in C, ensuring faster operation than other programming platforms.¹⁴ See a general diagram of the AI-based ventilator in Figure 1.

Figure 1. General diagram of the mechanical ventilator.  The system has access to Amazon Web Service (AWS) for on-demand intelligent setup and Evalu@ for warning and reporting purposes to the side of the specialists and patient's relatives. ANN, UART, DB, and L# stand for artificial neuronal network, universal asynchronous receiver-transmitter, Database, and Lambda specification in AWS, respectively.

Device mechanics and interfaces

We designed the core structure of the ventilator with a plastic resin to provide resistance to the mobile parts while making the device portable and durable. A servomotor connected to the scissors-like levers activates the degree of freedom associated with the scissors’ opening angle that ultimately presses a flexible container. A predefined rotation setup exerted by the servomotor pushes the needed air to the pumping container, thus, to the patient. The system controls the air’s volume and delivery frequency with this arrangement. The ventilator has a buzzer, lighting, and a 16x2 matrix screen to account for in-site alarms and state displaying. See the ventilator’s physical appearance in Figure 2.

Figure 2. Front (panel A) and superior (panel B) views of the mechanical ventilator.

Device’s Sensors

The MPX2010 differential pressure sensor, developed by Freescale semiconductors ®, has a linear transfer function f = 2.5/1[mV/KPa], and an output voltage span of [0-25 mV].¹⁵ The sensor yields a pressure value (P_i) by subtracting the input (P1_i) – connected indirectly through the pumping system to the patient’s airways – from the value exerted in the vacuum input (P2_i). An adjusting factor Af = 0.17 affects every P_i in the P array to translate the readings from KPa to MBAR units (See Equation 1).

The patient’s pulmonary pressure is calculated from the maximum values in the P array.

Regarding the heart rate (HR) and oxygen saturation, the MAX30100 chip developed by Maxim Integrated ®, reads both variables. It uses a visible red light (660 nm) and a receptor to capture intensity reflections after hemoglobin changes due to heart pulsation.¹⁶ As for the oxygen saturation, the chip implements a second source of light working at the near-infrared spectrum (880 nm). The module determines the absorption spectrum of oxygenated and deoxygenated hemoglobin with the two light sources that produce interchange reflection peaks at the respective wavelengths. The MAX30100 digitizes the reflections of both light beams with a resolution of V cc/2¹⁶ and returns the sensed variables in human-readable format through the Inter-Integrated Circuit (I2C) interface.

Artificial neural network construction

We designed a six-layered ANN (See Figure 3). The input layer has three nodes to receive the heart rate, oxygenation percentage, and respiratory pressure. The output layer consists of one node, which provides the dynamic operation setup for the servomotor and ultimately controls the oxygen yield to the patient. The training data consisting of 1000 formulations with the three used features, and the supervising variable is available online here.¹⁷ The training data was gathered from ICU records performed by Instituto de Genetica (Genesis S.A.S). The data is fully anonymized and respect the health insurance portability and accountability act (HIPAA)¹⁸ directives.

Figure 3. Artificial neural network (ANN) architecture.

The initial layer receives the three vitals of the patient, and the output node returns the operation point that controls the amount of delivered oxygen.

The ANN uses two activation functions, namely Sigmoid and Identity, consequently, the system has a dynamic input/output ratio. The activation functions simulate the evoked potential that controls the release of neurotransmitters within the neurons in alive subjects. In the ANN context, the identity function is a mathematical activation model governed by the expression f(x) = x; therefore, it transfers the input to the output in a range ($\infty$,$\infty$). The sigmoid or logistic activation function, also known as a binary transfer, is governed by the expression $f\left(x\right)=\frac{1}{1+e^{-x}}$ and its range is (0, 1). The training process consists in adjusting the nodes’ outputs, so the combined work of the network yields numbers close to the supervising values. Backpropagation with a controlled gradient descent was implemented to modify the weights in the internal ANN layers while searching for optimization. The controlled gradient descent is accomplished using the Levenberg-Marquard strategy (trainlm)¹⁹ that converges fast to optimization even when a wrong initial optimization guess is selected and provides mechanisms to avoid oscillations around the optimal value. The trainlm, is a distance minimization algorithm that receives an initial guess from the user and interactively updates a variable β. The method is fully implemented in python and is available in https://github.com/jjhartmann/Levenberg-Marquardt-Algorithm

Data collection and integration

Sharing and processing the sensor data between the ESP32 and the AWS was accomplished through the lambda specification.²⁰ We start by provisioning a Virtual Private Cloud (VPC)²¹ with the necessary utilities to connect and display the reports of the services to be consumed. Within the VPC architecture, one lambda triggers the microservice to establish the connection and feed the ANN with the three patient vitals. A second lambda triggers the microservice to obtain the ventilator setup yield by the ANN, which is delivered to the device’s hardware.

Data storage

Patients’ data and actions taken by the ANN are sent to the Evalu@ service for storing, querying, analysis and reporting. This centralizer allows custom reports creation and online analysis through intuitive Excel templates, providing the flexibility to produce, in real-time, material to healthcare providers and relatives of the patients as well. A copy of the control values yielded by the ANN is also stored in the Dynamo DB service²² of the AWS.

Testing process

After establishing the ANN architecture, we ran a standard validation process by comparing the supervisor factors with the outputs yielded by the ANN. For the validation, we performed a three-folded exercise using 30% on the training data referred to in section Artificial neural network construction. We randomly selected the data for each folding. We obtained a 95.79% accuracy during these testing sessions using a Sigmoid activation function. The accuracy index decreased to 94.01% when using the Rectified Linear Unit (ReLU),²³ and the best performance regarding accuracy appeared when using a combination of Sigmoid and Identity functions among the ANN layers.

Evalu@ configuration

The Evalu@ service (here) provides an intuitive mechanism to configure any tracking/monitoring scheme. The platform interprets the entries of three editable Excel files to create containers for the items to be evaluated, the tracking instruments, and the analysis that should be performed with the gathered data. Figure 4 presents the configuration files for the current application and Evalu@’s starting interface once the setup is finished.

Figure 4. Evalu@ configuration.

Panels A, B, and C show the configuration files used to create the containers, the tracking instruments, and the indexes’ visualization, respectively. Panel D displays the main screen after setup completion.

Evalu@ is needed to present the data appealingly to users other than developers. It can also allocate the services executed now in AWS. However we leave this to further developments. Readers can now reproduce our methods using AWS and the provided code. If requiring the use of Evalu@, code C08 in the Zenodo repository displays the API to do so, and users testing the presented methods can use the Evalu@ service for free.

ANN performance and solution timings

The Table 1 shows the performance of the python ANN implementation with the selected configuration, using a combination of Sigmoid and Identity functions among the ANN layers.

We ran data processing tests on the services exposed on the ESP32 (gateway) regarding the AWS and Evalu@ services. The records in Table 2 are the response times for one ventilator.

With the records in Table 2, we estimated the bursting capacity of the solution by simulating 200 concurrent users, adding to a total latency of 12 seconds. Recall that Internet connectivity in residences, where this development is intended to work, can allocate a maximum of 254 devices; however, since wifi performs like having the devices connected through a hub, latency can exponentially deteriorate when the technical limit of connections is reached.

AWS records on a patient

The VPC at AWS presents an interface to visualize the system’s architecture and implemented jobs. Figure 5 shows the AWS API gateway flow map for processing the breathing frequency.

Figure 5. Architecture of the system from the Amazon Web Service perspective to yield the breathing frequency.

The AWS produces control values to set the ventilator’s operation. We store the control setups produced by the ANN in the Dynamo DB as shown in Figure 6.

Figure 6. In panel A, the configuration of the table in the AWS Dynamo DB to store the estimated operation points. In Panel B, some operation point records.

Evalu@ records on healthy volunteer

Although AWS can intuitively present the generated information, their displaying schemes are intended for development and debugging. Not to mention the commercial strategy that charges the user after reaching an established quota. Instead, Evalu@ has mechanisms to present the data to non-specialized users. We employ Evalu@ to present physicians and patients’ relatives with real-time information on vitals and control variables (see Figure 7).

Figure 7. Evalu@ displaying vitals and the control signal in the timeline.

The vitals are presented without alarm levels. The control signal has all the levels activated. It generates mail alarms – in addition to those generated in-site – when the control signal is above or below the established levels.

Ventilator operation without exceptions

The Figure 8 resumes one loop operation of the system and provides step-by-step linking to the code deposited in https://doi.org/10.5281/zenodo.7400986. The system starts by configuring the ports and screen (C01). Then, it will read and process the patient’s vitals (C02-C03). The ventilator sends the vitals to the AWS using the ESP32 and the API (C04). The AWS uses the lambda specification to feed the ANN with the vitals and recovers the breathing-frequency variable (C05), which is saved in the DynamoDB (C06). The ESP consumes the API (C07) to recover the breathing frequency used by the ventilator to update the duty cycle of the Ambu system. The ESP also sends the vitals and control variables to the Evalu@ service using the API presented in C08. The authors encourage using the AWS S3 service, which will be enough to reproduce the results presented in this document. If an interface is needed to show the results to non-technical users, the authors warrant using Evalu@ at no cost for this particular application.

Figure 8. One loop run for a single ventilator.

The rounded symbols refer to code supporting the functionality that has been presented as complementary material to assert reproducibility.