markmichalski
Joined 10 years ago
Joined 10 years ago
All that being said in the situation where this is deployed I think it would be a risk most providers would take.
Perhaps check this out as well; someone used a common valve from a hardware store to titrate pressures up and down: https://www.youtube.com/watch?v=eSVbwWANqRI&feature=youtu.be.
I've been thinking about how we might increase ventilation to one part of the circuit if the pCO2 drops too badly--any thoughts there?
I work with 3-4 MDs that chose not to practice who are now working on defining software/ML product feature requirements; their MD experience makes them solid product specialists for clinical solutions that hopefully will help a lot of people...not having to stare down the barrel on loan payments may help people make these kind of career moves that may ultimately progress the system.
All that being said, we (obviously) need good docs at the bedside.
Like everyone, I’m finding that I’m in an increasingly disparate set of tools with diverging interface design choices to get my jobs done. The cognitive dissonance that all these different interfaces presents me with feels like it’s getting out of hand, and is growing non-linearly.
Emacs is a arcane tool, and is dated in so many ways, but I don’t know that I can find another solution that allows me to counter the ever-growing complexity of software productivity solutions that I presented with both in my personal and professional life. I know I’m not alone.
As someone who’s not a developer nor a full-time product person, (actually a doctor that wandered into tech), I often wonder why I can’t choose my own front end, and why am forced to use interfaces that don’t work very well for me. Emacs helps me escape some of that (at the cost of a huge relative learning curve, granted)