hammockman / breather Goto Github PK

https://apps.dtic.mil/dtic/tr/fulltext/u2/a189723.pdf

What do we want our device to cost? Note that this is parts only - we assume labour and plans come for free.

Jo and Ra had a talk yesterday and worked on a valve solution where either:

• air and O2 supplies are available
• or another module supplies air with increased O2 (like an oxygen concentrator).

We thought about finding components in three grades: medical, cheap, repurposed. The repurposed option is where people take components from household items - e.g. washing machines.

Jo is looking into components. The parts list was:

@hammockman, can you come up with a concept, quite different to #3, and fill in here? Would ideally like to choose between them on 26th.

Jo, I think u mentioned solenoid valve on outlet might not be a goer. Was it diff pressure? Can u elaborate, esp useful to @hammockman

Currently there's nothing to tell the operator when the UI is not getting messages from the ventilator.

The breath counter used to serve this role.

Maybe the besty thing is to pop up a warning if no mqtt message is received for more than a 15s period?

There were some errors using write_byte yesterday (from bmp085.py).

Not a major worry now - this issue is just for reporting further occurrences (need to copy error messages next time!).

Changes to bpm from GUI are registered on MQTT but breathe.py doesn't seem to update. can you check this out @hammockman ?

mosquitto_sub -h localhost -t breathe/inputs/bpm
20
16

We probably need some humidity control.

From wikipedia: "According to that standard, the minimum water content of inspired respiratory gas is ca. 33 mg/dm³ and the maximum respiratory gas temperature is ca. 42 °C."

A bubble humidifier seems like the simplest solution.

• We measure the humidity after the humidifier, and info is sent to the user by the computer.
• The operator is responsible for changing water, including changing temperature to modify water entrainment
• Can we have a simple control of the air coming into the humidifier - i.e. small bubbles instead of large?
• Do we need a water trap after the dehumidifier?

This is an issue to deal with design of the controller software, and which hardware it has to interface to. Specific bugs should have their own issues.

We are using a Raspberry Pi 3B+ with a separate LCD screen.

The software has to read various sensors and control 2-6 valves. It also has to have at least two major modes:

1. Timed breathing
2. Patient triggered breathing, with a timed override

There are many variations on these modes, but keeping things simple at this stage is a must.

Here are some is a plot of typical pressures and times (lots more on the web):

From Andrew Ewens, Waitemata DHB:

This looks like a very good solution and a very impressive use of low cost gear for a sophisticated problem. Well done!

We generally have piped air and O2 with different fittings depending on the country of origin of the equipment.

I am not sure what the pressure is at the wall.

Some of the ventilators run on oxygen only and entrain air. These are on cylinders or from the wall supply.

The Raspberry Pi wireless solution is great as a future proofing solution. The software is the expensive bit for the commercial ventilators which also run their own screens and inputs.

In any other time, taking a prototype into a hospital environment and plugging it into the supplies might be the next step.

Simulating a patient’s lungs, cough, spontaneously assisted ventilation would be a refinement.

It could be a very easy CPAP circuit, which has been found to be useful in COVID-19 experience overseas, preventing full ventilation.

To get us going, let's just get the system controlling the volume of air in the pipework between the insiration valve, v_i, and the expiration valve, v_e. This includes the patient's lungs which are compliant, so the volume changes during the cycle.

In each mode below the system has two pressure set points - inspiration pressure, p_i, and exhalation pressure, p_e. The other operator settings are tidal volume V_t, and breaths per minute BPM (which gives breath time in seconds t_b = 60/BPM).

In all cases there are a number of monitored variables with alarm conditions.

A wee status for today:

• We've got the basics of the prototype working. Here is a photo, and there are some videos floating around.

• We have a display and control system that transmits over the local wifi network, so a web browser can display the readings and control settings (today's version below). Having multiple viewers is possible (phones, tablets, central PCs).

Sensor status (planned sensors):

To do:

1. Improve on what is shown on "screen"
2. Electrical connections of installed sensors
3. Install exhaust valve = either 230v solenoid valve (not pilot operated we don't think) with a 12/230v relay, or the irrigation valve we modified this morning
4. Install and connect humidity sensor
5. Make and install bubble humidifier
6. Install Oxygen line with valve. Use Argon for starters, then get an O2 bottle from Phil.

Notes:

• It looks like a single pressure sensor in the inspiration line can also be used to measure and control BEEP. This is only if there is no flap valve at the Y-connection
• It would be nice to have a control pressure measurment - not for the design but for the prototype setup and verification. This would ideally be placed near the patient

We are currently using DHT11, but reading shows DHT22 is a better choice for low/high relative humidities (0-20%, 80-100%).

Have hooked up Pressure/temp sensor, AD lines, 12v power supply and bus-like thing, and 12v relay. Photo shown below - the valve seems to switch ok up to 5 Hz, haven't tried higher.

Out of here now for the avo and probably evening as it is Kylie's brithday.

To do tomorrow:

• Connect humidity sensor
• Hookup rest of bus and cables to valves
• Connect ai0 to flow sensor
• Test O2 sensor and hopefully hookup to ai1
• Connect second pressure/temp sensor and see how it works when encased in silicone

Variable speed duct fan (rangehood's, extractor fans, ...) + pressure/flow sensors + control computer + one-way and blow-off valves.

MQTT probably a simple way forward.

On raspberry:

sudo apt install -y mosquitto mosquitto-clients
sudo systemctl enable mosquitto.service

For python use paho-mqtt should be enough

Probably two topics - one for data out from breather, another for changing settings.

Notes from a quick discussion with Rob Everitt (ICU, Waitemata DHB)

1. Can you imagine hospitals or make shift hospitals buying or making tens or hundreds of such a device?

• not 1st world, others could do. outside med.

2. Can you see any technical issues with the device, and if so which ones are most important?

• current ventilators are 60-80k (Hamilton C6) - modes galore, most not used.
• it is easy to vent dead/fake person.
• ventilated patients usually sedated but "awake". can cough and interact with machine. patient is either syncrhonised or desynchronised with machine. to keep sync need to trigger on patient breath but also allow more breath on that intake. a patient that tries to start a breath and can't, or tries to continue a breath but can't, becomes uncomfortable and needs to be put well under or be taken off ventilation (neither are desirable).

3. How do large makeshift wards work in terms of ratios (doctors : nurses : patients)?

• In 1st world there is 1:1 nurse to patient ratio. 100% of the time. coz ventilated patients are unstable, and hypoxic patient can die in <60s if tube comes off or similar.
• All bets are off as to how these ratios would work in 2nd/3rd world. Even on flash ventilators many would die without 1:1 ratio

4. Can the "remote operation" of the device help w.r.t 3?

• Probably, although hard to imagine from 1st world perspective

While running overnight (>6000 breaths) the following error resulted. Probably not worrying about now, except to report further incidences here.

Traceback (most recent call last):
  File "breathe.py", line 73, in <module>
p
    M.publish('breathe/sensors/current', json.dumps(deque2dict(S.current_values)), retain=True)
  File "breathe.py", line 38, in deque2dict
    for d in q:
RuntimeError: deque mutated during iteration
pi@manawa-ora-1:~/breather/Design/Final/Code $ 

• Ventilator graphics

Hot wire anemometers can't distinguish flow direction (sign) so computing tidal volume from their output requires making assumptions. Not such a great idea. Improve?

After a talk to Lance:

1. Patients with Covid are battling ARDS which (partly) means they will need more O2 that air has
2. If FiO2 > 50% then definitely need humidfication
3. If FiO2 < 50% then humidification not necessary
4. If intubated then also intravenously sedated, and IV can be used to keep hydration of body. This reduces need for humidifcation (Lance, does this include hydration of lungs?)
   1 Just humidifiying the O2 line might be a good option.

Humidifiers are standard medical components, so we should design our humidifier with same interface. Any takers to investigate this?

The competition puts emphasis on 3D printing. This is limiting as 3D printing tech is not common in many parts of the world. So our "farming equipment" version has merit.

What about if we provide STL files for either each (1") fitting we use, or combination parts? This would allow people to either buy from their local shop, and/or print their own bits.

The FAQ sheet says a fully functioning prototype needs to be finished by March 31st. With the lockdown this means we might have to buy/order parts tomorrow, and/or modify our design to accommodate the lockdown. This is a) a hassle and b) realistic in terms of designing and building something that can be built in such a situation.

rather than operating over normal network the ui-broker-ventilator comms should run over a secure vpn. feasibility? complexity? fragility?

The current app has security/safety holes. Many, many of them.

1. prevent breathe.py being able to be run more than once
2. check on values in UI before sending (via MQTT broker) to app
3. allow only one UI client to change settings
4. prevent unauth publishing of breathe/# messages to broker
5. etc...

@racleave, there's a bare bones version of the app pushed at 0a26576. It uses three threads:

1. a main thread that as yet does very little but will run the breathing profile and control the valves
2. a sensor thread that tries to update a dict of sensor values at a fixed sampling rate
3. a messaging thread that eats MQTT messages and makes data available to the main thread to react to.

I've not tried running it on manawa-ora-1 yet (its not talking to me, off maybe?) but start it up with

$ python3 breathe.py

and kill it by

$ mosquitto_pub -t breathe/runstate -m quit

Take a squiz asap and let me know if this is what you were imagining.

Just saw Joseph's 5 concepts. 

1. This is what we have in issue #3. It seems mainly good to me although I think we could dispense with flow and O2 meters on the exhaust side...and maybe pressure? We should have the bits for this once deliveries come through

2. I think a downside of this is that the common line with the pressure sensors will risk the patient redrawing their last breath - although if there is a flap valve at the Y-connector this problem is much reduced as only a small volume has "incorrect" air. It requires a flap valve in a third party component though, which is not exactly prudent.

3. This is smart. Pros: Doesn't need air supply, motor acts as valve and positive supply, and if we know motor rotation can give precise delivery profiles, and effectively a volume measurement. Cons: Less simple than solenoid valves, and no O2 enrichment

4. Also smart. Can probably be ranked w.r.t 3 according to number, cost of parts and complexity. How can we make these motors uber cheap/accessible?

5. Similar to 4, yes? But even simpler.

I think the 3-5 variants are better than 1, and I'd rate 2 the lowest. Ranking 3-5 should be able to be done using a matrix.

Questions:

1. Can we use a simple 12v solenoid and a beam to do the see-saw shutoff of concept 4?

2. Can we use 3 solenoid valves in place of the motor cam valve? Then we get 3!=6 settings, or 7 if one includes all closed.

Well done on shopping everybody :)

John is going to start an inventory spreadsheet, so we know what we have in parts. We know vaguely what I have in the shed.

I think we should add to the inventory approximate costs of things. Rather than detailing everything, what about each item over $20 gets a price tag in the inventory, and other things get nothing or maybe a group amount.

Comments welcome!

The O2 sensor I bought is 2-wire. I wish I'd bought the 3 or 4 wire version, as the 2-wire version doesn't have a heater and they need to come up to 300 deg C before they work.

Will look at pulling one out of a local car (Jon's, Kylie's, Steffan's, Jo's, in that order).

Until then we can use the 2-wire one as the mechanical template.

breathe needs to be able to be restarted/monitored by both JH and in Mourea.

Either:

1. daemonize
2. run in a multi-view fashion