Hi,
I worked on this project and have a couple comments to address the issues people are raising.
- There are established medical protocols to treat COVID-19 patients with BiPAP machines, including the addition of a viral filter to mitigate aerosolizing the virus. People are using these protocols now and we link to them from the site.
- There are two separate firmware hacks presented. The first one modifies ~20 bytes and provides UI access to BiPAP code left in the existing binary, which would allow the more common CPAP machines to fulfill the same limited function. The second is a PoC of a 'full ventilator' mode.
- The manufacturer's CPAP and BiPAP lines have identical mainboard designs and a near identical array of sensors, which provide realtime data including tidal volume calculations. This project exists as a PoC to show that it would be possible - simple, even - for the manufacturer to convert CPAPs to BiPAPs via an OTA update - or, with significantly more effort, to fully featured ventilators. It is likely that they are reluctant to acknowledge this is possible in fear of destroying the market for the BiPAP machines.
- If you are a SleepyHead/OSCAR developer, or have access to an AirCurve S10 and an ST programmer, I would love to talk.
I don't know anything about the devices in question, but from what I know of engineering of medical devices, stating "near identical" makes me listen up.
If these devices malfunction, they could hurt people. I expect a device like this to have an extensive array of sensors and a lot of extra hardware for constant self-monitoring. If the two lines of devices don't have exactly identical hardware, the differences need to be checked carefully. The lower tier device may be missing some capabilities because of that.
Also, it is not obvious that the main development effort for a medical device often isn't about making a device perform its primary function, but to make it incapable of doing anything else. That includes automatic detection of malfunction and appropriate safe modes (simply turning it off may not be safe!). Of course, all of that needs to be tested and validated very thoroughly. If you ever want to use a hacked device on a patient, you will have to prove that it is up to the same engineering standards. That is no simple task, but it beats hurting or killing people because of bugs.
In short, this isn't a job for the regular basement-dwelling hacker, the kind who is happy to have his Roomba drive around with a hacked up firmware. This needs some serious and methodical engineering effort to become practical.
You're being exceedingly uncharitable in characterizing the team that is working on this the way you do in the last paragraph. The article is littered with disclaimers about the current state of the project. They're very quick to point out that this is only a proof-of-concept, that expert review is ongoing and not complete, and that FDA approval needs to be sought before this can be used to treat COVID-19 patients.
It's also at least implied that they're not necessarily hoping that this project specifically is used to treat COVID-19 patients; it seems the outcome they're hoping for is that this will publicly pressure manufacturers (presumably beyond just Airsense) to release their own firmware update to convert their CPAP machines to BiPAP.
In other words, far from being a semi-organized group of "basement-dwelling hacker"s, ths project has the appearance of being a very well-thought-out one with a clear roadmap.
No, I am not implying that this specific project is handled particularly unprofessionally. I want to warn people off who might think that they could just hack devices and put them to use on patients. This stuff requires serious expertise and if you don't have access to it, your effort is for entertainment only.
Hospitals are already pressing CPAP machines into service in this way, this firmware hack is only making the devices more fitting for the role they're being asked to fulfill in exigent circumstances.
> If these devices malfunction, they could hurt people.
I think that the circumstances under which these are being developed are a special emergency; the alternative to using such a less-safe, makeshift device here would be no ventilator at all, i.e. near-certain death.
In this specific circumstance, I think this sort of criticism should be withheld. I don't think anyone's talking about reflashing CPAPs to be life support outside of a temporary C19 emergency shortage.
The YouTube channel Real Engineering has a great video breaking down why that might not actually be true. The possibility that makeshift devices could cause barotrauma and make things worse seems quite significant. You can check it out here if your interested: https://www.youtube.com/watch?v=7vLPefHYWpY
I just watched the video. I'm not sure what outcome is worse than "you need a ventilator, but we are out of all of the safe, high-quality ones, and so you will now suffocate and die". In that circumstance I am certain that very nearly 100% of patients would accept potential barotrauma versus the alternative.
If we're to keep it real, my understanding is that, if you have COVID-19 and need ventilation but can't get it, you're all but guaranteed to die. So, assuming a real ventilator is not available, then avoiding makeshift measures due to worries about barotrauma seems to me to be somewhat akin to saying that people shouldn't administer CPR because it's likely to break ribs.
In these circumstances, this kind of criticism is especially necessary. It's easy to feel like you're doing the right thing and that you're helping people when you set out to hack medical devices. The truth is that you should only even think of doing it as a team with a leadership that understands the full engineering requirements for such a device completely and is very professional about it, including following strict processes (testing separated from development, test documentation, etc...). The consequences of sloppy work in that field can be extreme.
I'm not going to put up with "it helps if it saves lives" as a /blanket/ excuse. It fall apart when it saves some and kills others that could have survived.
> I don't know anything about the devices in question,
Since, by your own admission, you nothing about the details here, maybe it would be prudent to dig into the details and to not spread Fear, Uncertainty, and Doubt (FUD) just because you’ve been bitten while working on circuits where “nearly identical“ components often aren’t.
It’s fair to point out for medical equipment, how critical it is that the proper QA be done, to prevent severe injury and possibly death, but the ad-homonym name calling is unnecessary. In fact, there’s a shelter-in-place order in effect in many places, so engineering is being forced to happen in the open, in non-traditional places, including basements.
Like you said, it will have to certified that it’s up to the standards of the FDA before being used in a hospital by a medical professional, so I’m not sure I even see where you’re coming from. We’re not drinking aquarium cleaner here.
> I expect a device like this to have an extensive array of sensors and a lot of extra hardware for constant self-monitoring. If the two lines of devices don't have exactly identical hardware, the differences need to be checked carefully. The lower tier device may be missing some capabilities because of that.
This argument came up in the topic of using ventilators for two patients. It came up again in the topic of using home-built devices.
Of course using untested or under-tested equipment is a last resort. In a situation where there are no alternatives and a patient is dying, we do use unapproved drugs under “compassionate use” with much less testing than is otherwise be necessary. Using hacks like this with only some minimum of clinical testing is similar.
I think all your concerns are addressed in the article. They say it’s a proof of concept that needs more validation, as you would expect.
- There are established medical protocols to treat COVID-19 patients with BiPAP machines, including the addition of a viral filter to mitigate aerosolizing the virus. People are using these protocols now and we link to them from the site.
- There are two separate firmware hacks presented. The first one modifies ~20 bytes and provides UI access to BiPAP code left in the existing binary, which would allow the more common CPAP machines to fulfill the same limited function. The second is a PoC of a 'full ventilator' mode.
- The manufacturer's CPAP and BiPAP lines have identical mainboard designs and a near identical array of sensors, which provide realtime data including tidal volume calculations. This project exists as a PoC to show that it would be possible - simple, even - for the manufacturer to convert CPAPs to BiPAPs via an OTA update - or, with significantly more effort, to fully featured ventilators. It is likely that they are reluctant to acknowledge this is possible in fear of destroying the market for the BiPAP machines.
- If you are a SleepyHead/OSCAR developer, or have access to an AirCurve S10 and an ST programmer, I would love to talk.