If simple ventilators (such as BiPAP machines with new firmware, or other new designs) go into use, they need another device to give them some of the functions of ventilators, such as screens, user interfaces and more. I suggest this be done with a suitable (used) laptop computer connected to the ventilators over USB or other protocol. The software would be written to operate on Linux or similar free OS, then places on a flash card, USB stick or replacement drive to give a uniform enviroment.

(This is a sidebar to the article on converting smart CPAPs to ventilators.

Generally, this system would not be life-critical, in that the ventilator, once set up, could operate without the monitor, displaying what it can on the limited displays in these devices, and allowing simple input on their few buttons. While typically the ventilators would signal alarms to the monitor computer, if they did not detect the monitor handling them, the ventilators could also make what sounds they can make.

Here are some functions that this software should have:

User Interface

A UI, similar to other ventilators, for setting ventilation mode, and the parameters of that mode, such as base pressure (PEEP,) tidal volumes, max pressure, alert thresholds etc. In addition, there will be UI for some of the non-ventilator functions, like transmission of data to a central server. These settings would be transmitted to the ventilator, but it probably would not act on them without local confirmation, for security.

Monitoring and display

The monitor would receive a constant stream of data (over USB) from the ventilator telling everything it knows -- streams of data on pressure and volume, data from any other sensors in the device, such as sound or temperature, O2 saturation etc. It would display this data on the screen in a way doctors are used to, with graphs and numbers.

It would also receive any alarms from the ventilator, and act on them, relaying them to central stations, or making audible alarms at the bedside.

It would receive a "heartbeat" signal from the ventilator to assure that ventilator is operating. It would also send a heartbeat signal to the ventilator to keep it assured the monitor is operating. It would also send a heartbeat to the central monitoring server, as well as data streams of relevant data.

It would record this data and allow the history to be perused.

Use of additional sensors

The computer may use additional sensors, probably connected by USB. These can include microphones listening to sounds from the patient (like grunts and gurgles) and on-body microphones listening to the lungs and heart. It may be able to get EKG data, or pulse-oximetry. It may be able to talk to smartwatches via bluetooth which can read some of this data.

The data can be recorded and seen locally or at the remote stations. In addition, the microphones can allow remote doctors to listen to patients and their internal sounds.

Finally, a webcam can be pointed at the patient to allow remote monitors to watch and listen to the patient at any time.

Fail-over support

Some patients would get two modified CPAP ventilators. Due to the lower cost of these machines, reliability is less well established. In this case, both devices will be connected with a Y tube and valves, so either can provide pressure to the patient. Both would be connected to the monitor. Should the monitor detect the failure of one machine, it could then switch on the second machine and command it to start therapy at the right time as the failing machine is shut down (if it hasn't shut down itself.)

This would also signal an alert locally and at the monitoring station. This would cause a staffer to be dispatched to find out the cause of the failure and replace the failed machine as needed.

Oxygen control

Due to the lack of O2 control in lower cost devices, it may be necessary to have other oxygen mixing equipment, ideally under computer control. This is a life-critical function, however, so great care must be taken if this function is to be controlled by this computer.

Central server

Monitors would stream there data to a central server which is assisting in monitoring the whole ward. At medical stations, regular computers could connect to this server (via web browsers probably) to receive alerts, and display data. They would allow remote medical staff to observe patients and the current and past data. They may possibly allow remote changing of settings, though for security reasons that might require somebody visiting the patient.

The central server would receive "heartbeat" messages from each monitor, and indirectly each ventilator. It would alert if the heartbeats did not arrive. Medical station browsers would also alert if they did not get updates from the central server.

A redundant design may be advised, where there are 2 or more central servers and each monitor broadcasts data to all of them. This allows any one to fail and staff can switch to the backups.

Medical station client

While security is an issue, in order to have rapid development the medical station would probably use a browser connecting (authenticated) to the central server in order to get monitoring displays on patients and do any commands. In particular there would be a master display of all patients and their status, with the ability to put up some small subset of patients in small windows to see more details, or see full details on a patient. Monitoring stations may use multiple screens or computers because there is a lot to display. Phones could also connect in with their browsers, again only authenticated. I don't like the security implications of this architecture but this is the only one for which tools for rapid development and deployment are available. Browsers should need certificates which are renewed frequently, and possibly only be talked to if on the LAN.

Security

Ventilators should not be on the internet. We would even like to avoid that for the monitor. Connections should possibly be over ethernet directly, with the exception of connection from clients to the central server.

For security, it will not be possible to change settings on a machine via remote command. Instead, a staffer must be dispatched to the bedside, where the settings can be received remotely, but must be displayed and confirmed by the bedside caregiver before the machine changes parameters. Orders to change parameters from doctors should be digitally signed, and the confirmation of the signature should be displayed at the bedside monitor, or perhaps even inside the vent if it has enough screen. This is ideal, as otherwise an attacker could hijack the monitor to display what looks like the desired settings when it has actually sent bad ones to the vent.

AI

There is the ability for this system to gather training data for neural networks, and later to run these networks to help with monitoring patients. For example, the settings, pressure/volume data and patient outcomes can be recorded to train a network. The doctors known to be the best and tuning machines to treat patients would be most watched to provide this training data. In addition, with any adverse (or positive) patient event, historical data can be used to train networks to see if there is anything in the historical data which predicts the upcoming event. Past AI experiments in medicine have shown this to sometimes be the case.

The data logs should be anonymized as much as possible and made available to approved researchers attempting to build these neural networks. Once good ones are built, they can be loaded into the machines. The networks would not alter patient treatment, but would signal alerts for staff, and make recommendations on action, ideally with reasons behind those recommendations.

Hardware

Linux runs very well on old laptops, which are found in high quantities in the closets of the world. They would be happily donated. It may make sense to install a small reliable SSD in these laptop. There are so many laptops that it can be possible to limit the donated hardware to just a few brands (such as Thinkpads, Macbooks, Dell, HP etc.) to assure everything can be tested on the supported hardware models.

It is also not impossible to consider a monitor which is implemented for a phone. However, I believe that laptops are plentiful. They also come with built in battery backup and all needed interfaces, large screens, keyboards etc.