Architecture Suggestion; Decoupling of the Hardware and Software #86
Comments
|
In my opinion, even in an "emergency situation product", the control over the hardware should be clearly anchored in the device. Patient safety should have a certain focus, even with such a device. What happens in chaotic situations with the connected PCs? What happens if they are unplugged by mistake? What happens if 0815 office PCs with consumer operating systems go down, crash etc.pp.? In a normal situation, such a combination would most probably not receive approval from the authorities - with good reasons. |
|
1. With regards to possible disconnection of the USB cable. That does need
to be addressed but that is a solvable problem.
2. With regards to stability of the laptop OS: there is precedent for use
of Linux in medical devices. SUSE has a track record in this area:
https://www.zdnet.com/article/suse-offers-free-enterprise-linux-support-to-medical-devices-manufacturers/
In general, I think turning this ventilator production problem, as much as
possible, into an open-source software development has very
significant benefits. As I mentioned in the initial comment, it will open
the flood gates to developers far and wide who will bring every perspective
and expertise to bear. The attention of the limited groups who develop
the hardware can thus be more focused.
…On Sun, Mar 29, 2020 at 12:44 PM timafh ***@***.***> wrote:
In my opinion, even in an "emergency situation product", the control over
the hardware should be clearly anchored in the device. Patient safety
should have a certain focus, even with such a device.
What happens in chaotic situations with the connected PCs? What happens if
they are unplugged by mistake? What happens if 0815 office PCs with
consumer operating systems go down, crash etc.pp.?
In a normal situation, such a combination would most probably not receive
approval from the authorities - with good reasons.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#86 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQNNVRUCI7CGYXJTBSVYULRJ53GHANCNFSM4LWAPLZQ>
.
|
|
I have been a medical device engineer for over 10 years now. From my point of view such a system architecture is not quite logical for a self-built system. But maybe I have to adapt my inner requirements to the situation. I don't want to grumble against ideas here, but rather give my experience as input. Shortly to your link: Even a Linux system doesn't automatically make the whole thing better if you as a manufacturer don't have it under control. If removing the PC should have no effect, then the device itself must be able to take over the control, regulation, measurement and alarms in this situation. For me this leads to the result that I do not realize which advantages the PC solution would have at all. There is nothing to be said against developing algorithms with PC technology and transferring them to the microcontroller platform. Apart from that, one of the goals should be to make the system very easy to use, to make as few mistakes as possible and to treat as many patients as possible in parallel. And all this at the lowest possible price and with "off-the-shelf" parts. The more complicated the operation becomes, the more distant these goals become. I don't think that we are in a position here to create a "full-blown" ventilation system with the full functionality of professional systems - that cannot be the goal of such a project. |
|
I think the mentality should be that you are striving for bench-top
prototype with loose ends rather than a nice setf-enclosed product. If
it gets to the point where such a device is ever tried clinically, it will
presumably need revisions which will be easier on the computer. Also,
from my limited discussions with clinicians, they need to see pressure/flow
measurements - preferably in graphical form.
|
|
Visualization is something different than control. Of course you can integrate an interface that exports the current values. But then the PC does not take over any direct critical tasks - and that would be fine. Even a device/prototype "with loose ends" should have a feasible basic architecture. Otherwise the effort to make something useful out of such a prototype is enormous in the end. |
|
An ER doc has published a requirements document for ventilators:
https://docs.google.com/document/d/1FNPwrQjB1qW1330s5-S_-VB0vDHajMWKieJRjINCNeE/edit
<https://docs.google.com/document/d/1FNPwrQjB1qW1330s5-S_-VB0vDHajMWKieJRjINCNeE/edit>
The question then is whether this type of functionality can be readily
implemented without a computer.
…On Mon, Mar 30, 2020 at 2:45 AM timafh ***@***.***> wrote:
Visualization is something different than control. Of course you can
integrate an interface that exports the current values. But then the PC
does not take over any direct critical tasks - and that would be fine.
Even a device/prototype "with loose ends" should have a feasible basic
architecture. Otherwise the effort to make something useful out of such a
prototype is enormous in the end.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#86 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQNNVSXCPYITUQ2DT42SW3RKA5YNANCNFSM4LWAPLZQ>
.
|
|
Also, here is another requirements document for ventilators, slightly
different:
https://www.gov.uk/government/publications/coronavirus-covid-19-ventilator-supply-specification/rapidly-manufactured-ventilator-system-specification
…On Mon, Mar 30, 2020 at 11:13 AM Peter Yim ***@***.***> wrote:
An ER doc has published a requirements document for ventilators:
https://docs.google.com/document/d/1FNPwrQjB1qW1330s5-S_-VB0vDHajMWKieJRjINCNeE/edit
<https://docs.google.com/document/d/1FNPwrQjB1qW1330s5-S_-VB0vDHajMWKieJRjINCNeE/edit>
The question then is whether this type of functionality can be readily
implemented without a computer.
On Mon, Mar 30, 2020 at 2:45 AM timafh ***@***.***> wrote:
> Visualization is something different than control. Of course you can
> integrate an interface that exports the current values. But then the PC
> does not take over any direct critical tasks - and that would be fine.
>
> Even a device/prototype "with loose ends" should have a feasible basic
> architecture. Otherwise the effort to make something useful out of such a
> prototype is enormous in the end.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#86 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AFQNNVSXCPYITUQ2DT42SW3RKA5YNANCNFSM4LWAPLZQ>
> .
>
|
|
This may be a naive concept but we can use a pumpjack (used in oil wells) mechanism-based system. although it would require proper calibration. furthermore, we must effectively automate the manual ventilation system it seems to have worked during the Spanish flu during which volunteers took turns? read it somewhere but there is another story of an Indian farmer who lived on manual ventilation for 18 full days and nights where The farmer’s mother and brother took turns. please check this: http://news.mit.edu/2010/itw-ventilator-0715 this may work in case of places with logistical challenges etc, and just in case of a worst-case scenario.
|
|
@peteryim
The connected PC only has the task of visualization - it receives the sensor and current control values from the master via a serial interface. A display shows the critical values at any time on the device itself. The simplest setting options are buttons / encoders etc. on the device itself. However, the settings can also be sent via the serial interface - and just like the input values, they are verified by the master and only then actually used for control. Things like the watchdog to create redundant safety should not be missing. With an appropriate bootloader on the master controller, system updates can also be installed on the microcontroller via the serial interface to the PC. The advantage of this architecture is that the PC itself does not have to be part of the device, since the tasks of the PC are not safety-critical. This means that a PC is not necessarily required, which reduces the cost factor for the device. |
|
I think the question is whether the ventilator can be built with
off-the-shelf parts or easily-made parts. Are you saying that it is
realistic to access massive quantities of that type of pump?
…On Mon, Mar 30, 2020 at 3:18 PM timafh ***@***.***> wrote:
@peteryim <https://github.com/peteryim>
That would be an architecture I would think of first for such a device:
[image: image]
<https://user-images.githubusercontent.com/386320/77952008-4765c180-72cb-11ea-9822-fe2c662d6a8c.png>
The connected PC only has the task of visualization - it receives the
sensor and current control values from the master via a serial interface.
A display shows the critical values at any time on the device itself.
The simplest setting options are buttons / encoders etc. on the device
itself. However, the settings can also be sent via the serial interface -
and just like the input values, they are verified by the master and only
then actually used for control.
Things like the watchdog to create redundant safety should not be missing.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#86 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFQNNVSN74M5T2ICQIFDISDRKDWAHANCNFSM4LWAPLZQ>
.
|
|
Its not about the pump its about the mechanism that will be used for automating the system of manual ventilation this mechanism(pumpjack)can easily be duplicated and will require less usage of high end parts moreover if there are provisions for high end parts then their is a lot of relaibility and less complicacies with the requirement of less resources like if you have to control the bpm say slow them down slow down the motor etc more over in case of non availability of sensors only one measuring device(sensor) per parameter can be used to measure the behaviour of the ventilator to certain speeds e.g at this rpm of motor and suspending this amount of weight from the bag side the recorded beats are x and the measured tidal volume was y . Hence by changing the rpm/ weight we can change the values and measure them before hand and record them for particular values even though it would be tedious to measure the behaviour of the device to different arrangements but if rest of the devices are made with same dimensions materials etc they should also behave the same this sort of mass manufacturing is required. |
Why not move the regulation of pressure/flow to usb-connected laptop platform? That would significantly amplify capabilities/contributors. In that case, the hardware developers would just offer a usb interface to the computer that includes pressure measurement, flow measurement, flow rate control, alarms etc. In my brief dialog with clinicians on ventilator function, they see relatively sophisticated flow/pressure control as a key factor in patient survival in ARDS. Here is link my dialog with a physician in Italy and others:
https://www.dailykos.com/comments/1931839/76844056#comment_76843138
The text was updated successfully, but these errors were encountered: