EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Group Design

Started by Rick C July 7, 2020
Rick C <gnuarm.deletethisbit@gmail.com> writes:
> I had a friend who worked on medical devices for a while before > getting out. He said they required that you "prove" your design will > not hurt the patient in any way. Hard to do with a ventilator.
There are different levels of approval for medical devices in the US. The lowest level would be for something like crutches, which can't really hurt the patient unless you do something really dumb, so you basically prove that you followed established practices instead of doing something dumb. More invasive devices like pacemakers or ventilators need much more intense testing and approval. One thing I remember being told was that you have to document the design and development (including the software) every step of the way. There was a guy here on c.a.e. some years ago who did that stuff and I learned some things from him. It is one of the reasons I got interested in Ada.
On 2020-07-08 Rick C wrote in comp.arch.embedded:
> On Wednesday, July 8, 2020 at 1:00:04 PM UTC-4, Stef wrote: >> On 2020-07-08 Rick C wrote in comp.arch.embedded: >> > On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote: >> >> On 2020-07-08 Rick C wrote in comp.arch.embedded: >> >> > Wow! Designing in a group is strange. I'm helping with the design of a ventilator and it is a unique experience. We have people of many skill levels and talents, many I don't even know. >> >> >> [...] >> >> [Is there a way you could limit your line length to a more usenet friendly >> number?] > > Not without copying messages to some other editor and then pasting back into Google groups. I know there is a spec for this, but I've switched newsreaders several times over the years and I'm just tired of trying to find tools that last the test of time. So I've settled for ease of use over strict adherence to the spec. > > Why is your newsreader intolerant of longer line length? >
Slrn may be a bit ancient, but so is usenet. ;-) Slrn can handle long lines, but after quoting it does not wrap them anymore, so I need to shift the screen to view the entire line. Luckily the editor for replying does still wrap those. But hey, it's a minor inconvenience, just asking.
> >> > It seems the UK has an abbreviated set of requirements for response to COVID-19 and that is what they are mostly working with. I forget the name of it. >> >> How long will this last? If you look at the new cases curves, the UK is well >> over the initial peak. https://www.nytimes.com/ has nice graphs of world >> cases on the front page. > > As was the case for much of the US... until they started to open things up again. My crystal ball is not working so well these days. Seems it needs a lubricant that is also used in making protective gear and is in short supply. > > >> > They do get advice from time to time from professionals in the field. My main concern is a direction they are currently going in where more and more valves, pressure relief, etc. is being added to the tubing right at the patient. I'm not sure how it all will be held in place. That and how they plan to get this through the approval process. >> > >> >> Sounds like they are moving to more and more features instead of sticking to a >> simple emergency use device. Feature creep is not uncommon when getting advise >> from several medical professionals. ;-) > > Don't know about "more and more" or "feature creep". They are responding to the issue that virtually every other piece of gear is doing the same limited job of ventilating an unconscious patient because it is easier. Kennedy promoted the space race to the moon "not because it is easy, but because it is hard". So why not take on the harder task of being not just more useful, but safer. I don't recall all the terms, but when the patient is only assisted in breathing there is less risk of harm from use of the machine. So this is not just a less often implemented feature, it is an important feature. > > In particular, it was in a conversation with a medical professional that this need was pointed out.
So the aim is to create a new type of ventilator, not to cope with immediate shortages? This is very big task indeed. This sort of thing usually takes years of development and and clinical testing. They have certainly gone for "not easy, but hard".
> >> > I had a friend who worked on medical devices for a while before getting out. He said they required that you "prove" your design will not hurt the patient in any way. Hard to do with a ventilator. >> > >> >> That is not entirely true, it is more a risk/benefit analysis. Otherwise you >> could not even get a scalpel approved, it will always hurt the patient. > > That is a bogus comparison. So nothing to discuss there.
I don't agree. ;-) The scalpel example is a bit extreme of course. But for every medical device there wil be a risk/benefit analysis. There are medical devices that do some harm to a patient, but as long as the benefits outweigh the harm it may still be a good thing to use those devices. A ventilator is never good for your lungs, so it will do some damage, the aim is to keep the damage as minimal as possible and as short term as possible.
> >> > I don't mind working on the team. It's seeing them go in odd directions that bugs me. This thing will probably cost hundreds of dollars in the final BOM without anything like profit or overhead added in. People were arguing against adding $0.10 for more pins on a processor. Then later they decided to not only go with the larger pin count, but bump from an 8 bit AVR to an ARM CM4F adding several dollars. That sort of inconsistency drives me nuts. "Every dollar counts!" Yes it does, so you need to justify the cost *rationally*. >> > >> >> Does every dollar count in this case? If this is for solving short term >> ventilator shortages, should development speed not count more than dollars? > > It's not about rushing to the finish line for sure. None of the goals are clearly stated. That's my point.
Well, get that point across and try to get the goals clear before proceeding.
> We meet using video tools and Zoom seems to work the best. I have various latency and bandwidth issues and was not able to participate yesterday. That's really frustrating, especially when everyone is missing an important point. Today we had a one on one to test Google Meet and compare to Zoom (Google was a second runner). So I had a chance to make clear what is and is not a problem in the plumbing. Understanding what I was saying he agreed so the plumbing next to the patient is less cumbersome now. > > Maybe more 1 on 1s will help.
Good luck. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) root rot
On Wednesday, July 8, 2020 at 5:35:53 PM UTC-4, Stef wrote:
> On 2020-07-08 Rick C wrote in comp.arch.embedded: > > On Wednesday, July 8, 2020 at 1:00:04 PM UTC-4, Stef wrote: > >> On 2020-07-08 Rick C wrote in comp.arch.embedded: > >> > On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote: > >> >> On 2020-07-08 Rick C wrote in comp.arch.embedded: > >> >> > Wow! Designing in a group is strange. I'm helping with the design of a ventilator and it is a unique experience. We have people of many skill levels and talents, many I don't even know. > >> >> > >> [...] > >> > >> [Is there a way you could limit your line length to a more usenet friendly > >> number?] > > > > Not without copying messages to some other editor and then pasting back into Google groups. I know there is a spec for this, but I've switched newsreaders several times over the years and I'm just tired of trying to find tools that last the test of time. So I've settled for ease of use over strict adherence to the spec. > > > > Why is your newsreader intolerant of longer line length? > > > Slrn may be a bit ancient, but so is usenet. ;-) > Slrn can handle long lines, but after quoting it does not wrap them anymore, > so I need to shift the screen to view the entire line. Luckily the editor for > replying does still wrap those. But hey, it's a minor inconvenience, just > asking.
I wish Google was amenable to requests regarding their software. As far as I can tell they ignore any feedback and happily ignore rules for newsgroups as if they invented them. I think it was Al Gore who invented the Internet, no? So we can blame him perhaps for giving Google a license to drive on the cyber-highway. Thanks for understanding.
> >> > It seems the UK has an abbreviated set of requirements for response to COVID-19 and that is what they are mostly working with. I forget the name of it. > >> > >> How long will this last? If you look at the new cases curves, the UK is well > >> over the initial peak. https://www.nytimes.com/ has nice graphs of world > >> cases on the front page. > > > > As was the case for much of the US... until they started to open things up again. My crystal ball is not working so well these days. Seems it needs a lubricant that is also used in making protective gear and is in short supply. > > > > > >> > They do get advice from time to time from professionals in the field. My main concern is a direction they are currently going in where more and more valves, pressure relief, etc. is being added to the tubing right at the patient. I'm not sure how it all will be held in place. That and how they plan to get this through the approval process. > >> > > >> > >> Sounds like they are moving to more and more features instead of sticking to a > >> simple emergency use device. Feature creep is not uncommon when getting advise > >> from several medical professionals. ;-) > > > > Don't know about "more and more" or "feature creep". They are responding to the issue that virtually every other piece of gear is doing the same limited job of ventilating an unconscious patient because it is easier. Kennedy promoted the space race to the moon "not because it is easy, but because it is hard". So why not take on the harder task of being not just more useful, but safer. I don't recall all the terms, but when the patient is only assisted in breathing there is less risk of harm from use of the machine. So this is not just a less often implemented feature, it is an important feature. > > > > In particular, it was in a conversation with a medical professional that this need was pointed out. > > So the aim is to create a new type of ventilator, not to cope with immediate > shortages? This is very big task indeed. This sort of thing usually takes > years of development and and clinical testing. They have certainly gone for > "not easy, but hard".
I would not say "a new type". This is what commercial vents do. But being the hard part, most of the quick turn projects leave it out. I expect it will be the hardest to get approvals for too.
> >> > I had a friend who worked on medical devices for a while before getting out. He said they required that you "prove" your design will not hurt the patient in any way. Hard to do with a ventilator. > >> > > >> > >> That is not entirely true, it is more a risk/benefit analysis. Otherwise you > >> could not even get a scalpel approved, it will always hurt the patient. > > > > That is a bogus comparison. So nothing to discuss there. > > I don't agree. ;-) > The scalpel example is a bit extreme of course. But for every medical > device there wil be a risk/benefit analysis. There are medical devices > that do some harm to a patient, but as long as the benefits outweigh > the harm it may still be a good thing to use those devices.
The trade off issues for a ventilator are well known, not something to be negotiated. So there is no point in comparing to scalpels. The rules are the rules and it will be hard to get approvals. I'm sure it costs lots of money, not unlike FCC approval. I believe the plan is to find a manufacturing partner to turn this design over to who will bear the brunt of approvals. This is not impossible, but I think that should be one of the early steps so they have some input to the process, guiding what comes out at the end rather than simply having to redesign it all over again potentially.
> A ventilator is never good for your lungs, so it will do some damage, > the aim is to keep the damage as minimal as possible and as short term > as possible. > > > > >> > I don't mind working on the team. It's seeing them go in odd directions that bugs me. This thing will probably cost hundreds of dollars in the final BOM without anything like profit or overhead added in. People were arguing against adding $0.10 for more pins on a processor. Then later they decided to not only go with the larger pin count, but bump from an 8 bit AVR to an ARM CM4F adding several dollars. That sort of inconsistency drives me nuts. "Every dollar counts!" Yes it does, so you need to justify the cost *rationally*. > >> > > >> > >> Does every dollar count in this case? If this is for solving short term > >> ventilator shortages, should development speed not count more than dollars? > > > > It's not about rushing to the finish line for sure. None of the goals are clearly stated. That's my point. > > Well, get that point across and try to get the goals clear before > proceeding.
I have provided my input and the project moves forward. The rev 1 of the main board is full of issues mostly because the guy doing it is donating his time while continuing to work full time. There was no design review I assume because there was no one to conduct it with but also I think because no one recognizes the need. "It's just an Arduino" plus some interfacing circuitry. The design includes window comparators for alarm settings. I found that according to the labels and the polarity of the outputs the alarms will be guaranteed to be on all the time. Fortunately the prototype uses pots for the set points so the max can be set to the min value and vice versa. I'm also concerned about the board layout. The board is not at all dense but there are several parts that need copper area for heat sinking. They are using a linear regulator to drop 12+ volts to 5V and 3.3V. The back lights for the LCDs draw 300 mA! So the 5V regulator gets quite warm, 70&deg;C!!! There is a motor controller that has to handle several amps of current. Both of these parts had thermal breaks on the thermal pads on the rev 1 board. So virtually no heat sinking.
> > We meet using video tools and Zoom seems to work the best. I have various latency and bandwidth issues and was not able to participate yesterday. That's really frustrating, especially when everyone is missing an important point. Today we had a one on one to test Google Meet and compare to Zoom (Google was a second runner). So I had a chance to make clear what is and is not a problem in the plumbing. Understanding what I was saying he agreed so the plumbing next to the patient is less cumbersome now. > > > > Maybe more 1 on 1s will help. > > Good luck.
Thanks. No small part of the problem is I don't have a defined roll. Someone is doing the electronic design part time and I get to figure out what is wrong once in a while. Not enjoyable really. -- Rick C. ++ Get 1,000 miles of free Supercharging ++ Tesla referral code - https://ts.la/richard11209
Rick C <gnuarm.deletethisbit@gmail.com> writes:
> also I think because no one recognizes the need. "It's just an > Arduino" plus some interfacing circuitry. ...
Frankly this project sounds like amateur hour. If US FDA approval works the way it's been explained to me, there is no chance of the device ever getting it. Other countries' mileage may vary. There are other devices that they could build that would be much less dangerous (therefore easier to get approval for), but that fill a need. For example, polysomnography machines for sleep studies, or other diagnostic equipment. Compared to a vent, they are pretty safe, since they only measure your body functions (heart and breathing rate, etc.) rather than being an invasive intervention. But having more of them available could help people with underdiagnosed conditions like sleep apnea.
On 2020-07-08 10:19, Rick C wrote:
> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote: >> On 2020-07-08 Rick C wrote in comp.arch.embedded: >>> Wow! Designing in a group is strange. I'm helping with the >>> design of a ventilator and it is a unique experience. We have >>> people of many skill levels and talents, many I don't even know. >> >> That is the good part of designing with a group. You can have many >> more talents and skills than can be combined in a single person. >> For a medical product like this you need medical, software, >> hardware, mechanical and lots more skills. Not something that can >> be found in one person very often. >> >> <snip, some project frustrations etc.> >> >>> I literally have no idea how they are ever going to get this >>> thing past any sort of approval process. No one working on the >>> project even seems to understand what is required. >>> >> >> This is very worrying. As David already explained, documentation >> and approval is a very large part of medical device development. >> There is this famous Boeing quote about the weight of the paperwork >> required for a plane. I think you can extend this to medical >> devices as well. >> >> Did they at least have a look at some standards that apply to >> ventilators to check what will be required? I would start off with >> IEC 60601-1, IEC 62304 and ISO 80601-2-12, make sure you use the >> latest versions. But there will be more. >> >> And this should have been done before the first schematic was drawn >> or line of code was written. Some standards put requirements on the >> development process and you can not comply with those if you start >> your certification efforts after the development is completed. >> >> >>> I guess I'm a bit frustrated by the lack of organization. I'd >>> like to step away, but the person acting as a leader seems to >>> want me in the group. >>> >>> There is some work of my own I should do, so maybe I'll stick >>> around to get to rev 2 of the board and then step out. >>> >> >> If there has indeed been done nothing on the certification side, my >> feeling would be to step away as well. >> >> >>> I guess I'm used to working on my own. >>> >> >> Yes, than all is in your own hands. ;-) >> >> But the advantage of a team is that you can concentrate on what you >> are good at and let others do what they are good at. And if the >> team is diverse and skilled enough (and properly led) the end >> result will be better that that of a single developer. >> >> And I think a lot of medical device stuff can not be done by a >> single person. There are many cases where you need an (expert) >> reviewer in the process. Reviewing your own work is less than >> optimal. ;-) > > It seems the UK has an abbreviated set of requirements for response > to COVID-19 and that is what they are mostly working with. I forget > the name of it. > > They do get advice from time to time from professionals in the field. > My main concern is a direction they are currently going in where more > and more valves, pressure relief, etc. is being added to the tubing > right at the patient. I'm not sure how it all will be held in place. > That and how they plan to get this through the approval process. > > I had a friend who worked on medical devices for a while before > getting out. He said they required that you "prove" your design will > not hurt the patient in any way. Hard to do with a ventilator.
IANAL, but the liability implications of that would be interfering with my sleep. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
On 08/07/2020 16:19, Rick C wrote:
> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote: >> On 2020-07-08 Rick C wrote in comp.arch.embedded: >>> Wow! Designing in a group is strange. I'm helping with the >>> design of a ventilator and it is a unique experience. We have >>> people of many skill levels and talents, many I don't even know. >> >> That is the good part of designing with a group. You can have many >> more talents and skills than can be combined in a single person. >> For a medical product like this you need medical, software, >> hardware, mechanical and lots more skills. Not something that can >> be found in one person very often. >> >> <snip, some project frustrations etc.> >> >>> I literally have no idea how they are ever going to get this >>> thing past any sort of approval process. No one working on the >>> project even seems to understand what is required. >>> >> >> This is very worrying. As David already explained, documentation >> and approval is a very large part of medical device development. >> There is this famous Boeing quote about the weight of the paperwork >> required for a plane. I think you can extend this to medical >> devices as well. >> >> Did they at least have a look at some standards that apply to >> ventilators to check what will be required? I would start off with >> IEC 60601-1, IEC 62304 and ISO 80601-2-12, make sure you use the >> latest versions. But there will be more. >> >> And this should have been done before the first schematic was drawn >> or line of code was written. Some standards put requirements on the >> development process and you can not comply with those if you start >> your certification efforts after the development is completed. >> >> >>> I guess I'm a bit frustrated by the lack of organization. I'd >>> like to step away, but the person acting as a leader seems to >>> want me in the group. >>> >>> There is some work of my own I should do, so maybe I'll stick >>> around to get to rev 2 of the board and then step out. >>> >> >> If there has indeed been done nothing on the certification side, my >> feeling would be to step away as well. >> >> >>> I guess I'm used to working on my own. >>> >> >> Yes, than all is in your own hands. ;-) >> >> But the advantage of a team is that you can concentrate on what you >> are good at and let others do what they are good at. And if the >> team is diverse and skilled enough (and properly led) the end >> result will be better that that of a single developer. >> >> And I think a lot of medical device stuff can not be done by a >> single person. There are many cases where you need an (expert) >> reviewer in the process. Reviewing your own work is less than >> optimal. ;-) > > It seems the UK has an abbreviated set of requirements for response > to COVID-19 and that is what they are mostly working with. I forget > the name of it. > > They do get advice from time to time from professionals in the field. > My main concern is a direction they are currently going in where more > and more valves, pressure relief, etc. is being added to the tubing > right at the patient. I'm not sure how it all will be held in place. > That and how they plan to get this through the approval process. > > I had a friend who worked on medical devices for a while before > getting out. He said they required that you "prove" your design will > not hurt the patient in any way. Hard to do with a ventilator.
I have worked on the side-lines of a few medical-related devices. The requirements and approval process is hard. On a board I worked with, the prime function - the top priority function that must not fail - was to turn off all outputs and make sure it did not interfere with manual use of the system when auto mode was not enabled. Running the motor was a secondary function that could be done if enabled and all is well, but having everything off was still classified as "working correctly". It's a weird way to think about things.
> > I don't mind working on the team. It's seeing them go in odd > directions that bugs me. This thing will probably cost hundreds of > dollars in the final BOM without anything like profit or overhead > added in. People were arguing against adding $0.10 for more pins on > a processor. Then later they decided to not only go with the larger > pin count, but bump from an 8 bit AVR to an ARM CM4F adding several > dollars. That sort of inconsistency drives me nuts. "Every dollar > counts!" Yes it does, so you need to justify the cost *rationally*. > >
On 7/7/2020 6:46 PM, Rick C wrote:
> Wow! Designing in a group is strange. I'm helping with the design of a ventilator and it is a unique experience. We have people of many skill levels and talents, many I don't even know. The design seems to ping pong around based on the hot button issue of the day. They already have someone to do board level design, but he has a day job, so the work gets done a bit helter skelter. I mostly try to identify potential bugs. > > Most of the people are in the UK with a couple in the EU. I'm in the US along with one other person. > > We have semiweekly meetings on zoom or other sites. There is no strong organization. > > I'm surprised as much is getting done as it has been. The original design used an Arduino and once the lack of I/Os became a hindrance we are switching to an ARM, but nothing remotely like a proper spec was generated and the processor initially picked is now out of pins. The first rev of the main board has many issues including the isolation of the heat sink tabs by thermal relief connections. > > I literally have no idea how they are ever going to get this thing past any sort of approval process. No one working on the project even seems to understand what is required. > > I guess I'm a bit frustrated by the lack of organization. I'd like to step away, but the person acting as a leader seems to want me in the group. > > There is some work of my own I should do, so maybe I'll stick around to get to rev 2 of the board and then step out. > > I guess I'm used to working on my own. >
That all sounds frustrating. For sale to the US, you'll need to satisfy some specific FDA requirements and be prepared to prove it, including dotting Is/crossing Ts in just the right way. You have an international crew so you'll probably have to satisfy certain other international requirements. I'd float the idea of getting an FDA expert on your team as soon as possible. You'll need that kind of talent, otherwise your efforts will be wasted. JJS
On Thursday, July 9, 2020 at 4:25:32 AM UTC-4, Phil Hobbs wrote:
> On 2020-07-08 10:19, Rick C wrote: > > On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote: > >> On 2020-07-08 Rick C wrote in comp.arch.embedded: > >>> Wow! Designing in a group is strange. I'm helping with the > >>> design of a ventilator and it is a unique experience. We have > >>> people of many skill levels and talents, many I don't even know. > >> > >> That is the good part of designing with a group. You can have many > >> more talents and skills than can be combined in a single person. > >> For a medical product like this you need medical, software, > >> hardware, mechanical and lots more skills. Not something that can > >> be found in one person very often. > >> > >> <snip, some project frustrations etc.> > >> > >>> I literally have no idea how they are ever going to get this > >>> thing past any sort of approval process. No one working on the > >>> project even seems to understand what is required. > >>> > >> > >> This is very worrying. As David already explained, documentation > >> and approval is a very large part of medical device development. > >> There is this famous Boeing quote about the weight of the paperwork > >> required for a plane. I think you can extend this to medical > >> devices as well. > >> > >> Did they at least have a look at some standards that apply to > >> ventilators to check what will be required? I would start off with > >> IEC 60601-1, IEC 62304 and ISO 80601-2-12, make sure you use the > >> latest versions. But there will be more. > >> > >> And this should have been done before the first schematic was drawn > >> or line of code was written. Some standards put requirements on the > >> development process and you can not comply with those if you start > >> your certification efforts after the development is completed. > >> > >> > >>> I guess I'm a bit frustrated by the lack of organization. I'd > >>> like to step away, but the person acting as a leader seems to > >>> want me in the group. > >>> > >>> There is some work of my own I should do, so maybe I'll stick > >>> around to get to rev 2 of the board and then step out. > >>> > >> > >> If there has indeed been done nothing on the certification side, my > >> feeling would be to step away as well. > >> > >> > >>> I guess I'm used to working on my own. > >>> > >> > >> Yes, than all is in your own hands. ;-) > >> > >> But the advantage of a team is that you can concentrate on what you > >> are good at and let others do what they are good at. And if the > >> team is diverse and skilled enough (and properly led) the end > >> result will be better that that of a single developer. > >> > >> And I think a lot of medical device stuff can not be done by a > >> single person. There are many cases where you need an (expert) > >> reviewer in the process. Reviewing your own work is less than > >> optimal. ;-) > > > > It seems the UK has an abbreviated set of requirements for response > > to COVID-19 and that is what they are mostly working with. I forget > > the name of it. > > > > They do get advice from time to time from professionals in the field. > > My main concern is a direction they are currently going in where more > > and more valves, pressure relief, etc. is being added to the tubing > > right at the patient. I'm not sure how it all will be held in place. > > That and how they plan to get this through the approval process. > > > > I had a friend who worked on medical devices for a while before > > getting out. He said they required that you "prove" your design will > > not hurt the patient in any way. Hard to do with a ventilator. > > IANAL, but the liability implications of that would be interfering with > my sleep.
I guess you don't sleep well very often. There will be no liability issues. This group is not going to produce the machines. They will hand the design off to a manufacturer who will produce, market and obtain approvals for the machine. Liability will be all theirs. Most likely the machine will be totally redesigned anyway for cost reduction and to obtain approvals. As a group this is not a highly knowledgeable design group. I can't imagine this design will fly without rework. -- Rick C. --- Get 1,000 miles of free Supercharging --- Tesla referral code - https://ts.la/richard11209
Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Most likely the machine will be totally redesigned anyway for cost > reduction and to obtain approvals. As a group this is not a highly > knowledgeable design group. I can't imagine this design will fly > without rework.
It's a medical device, so I think you mean cost enlargement rather than reduction ;-). But, if the design group doesn't know what it's doing and is producing something that can't be used, then why are they bothering in the first place? What do they hope to contribute, and what do they hope to gain?
On 09/07/20 19:37, Rick C wrote:
> On Thursday, July 9, 2020 at 4:25:32 AM UTC-4, Phil Hobbs wrote: >> On 2020-07-08 10:19, Rick C wrote: >>> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote: >>>> On 2020-07-08 Rick C wrote in comp.arch.embedded: >>>>> Wow! Designing in a group is strange. I'm helping with the design >>>>> of a ventilator and it is a unique experience. We have people of >>>>> many skill levels and talents, many I don't even know. >>>> >>>> That is the good part of designing with a group. You can have many more >>>> talents and skills than can be combined in a single person. For a >>>> medical product like this you need medical, software, hardware, >>>> mechanical and lots more skills. Not something that can be found in one >>>> person very often. >>>> >>>> <snip, some project frustrations etc.> >>>> >>>>> I literally have no idea how they are ever going to get this thing >>>>> past any sort of approval process. No one working on the project >>>>> even seems to understand what is required. >>>>> >>>> >>>> This is very worrying. As David already explained, documentation and >>>> approval is a very large part of medical device development. There is >>>> this famous Boeing quote about the weight of the paperwork required for >>>> a plane. I think you can extend this to medical devices as well. >>>> >>>> Did they at least have a look at some standards that apply to >>>> ventilators to check what will be required? I would start off with IEC >>>> 60601-1, IEC 62304 and ISO 80601-2-12, make sure you use the latest >>>> versions. But there will be more. >>>> >>>> And this should have been done before the first schematic was drawn or >>>> line of code was written. Some standards put requirements on the >>>> development process and you can not comply with those if you start your >>>> certification efforts after the development is completed. >>>> >>>> >>>>> I guess I'm a bit frustrated by the lack of organization. I'd like >>>>> to step away, but the person acting as a leader seems to want me in >>>>> the group. >>>>> >>>>> There is some work of my own I should do, so maybe I'll stick around >>>>> to get to rev 2 of the board and then step out. >>>>> >>>> >>>> If there has indeed been done nothing on the certification side, my >>>> feeling would be to step away as well. >>>> >>>> >>>>> I guess I'm used to working on my own. >>>>> >>>> >>>> Yes, than all is in your own hands. ;-) >>>> >>>> But the advantage of a team is that you can concentrate on what you are >>>> good at and let others do what they are good at. And if the team is >>>> diverse and skilled enough (and properly led) the end result will be >>>> better that that of a single developer. >>>> >>>> And I think a lot of medical device stuff can not be done by a single >>>> person. There are many cases where you need an (expert) reviewer in the >>>> process. Reviewing your own work is less than optimal. ;-) >>> >>> It seems the UK has an abbreviated set of requirements for response to >>> COVID-19 and that is what they are mostly working with. I forget the >>> name of it. >>> >>> They do get advice from time to time from professionals in the field. My >>> main concern is a direction they are currently going in where more and >>> more valves, pressure relief, etc. is being added to the tubing right at >>> the patient. I'm not sure how it all will be held in place. That and how >>> they plan to get this through the approval process. >>> >>> I had a friend who worked on medical devices for a while before getting >>> out. He said they required that you "prove" your design will not hurt >>> the patient in any way. Hard to do with a ventilator. >> >> IANAL, but the liability implications of that would be interfering with my >> sleep. > > I guess you don't sleep well very often. There will be no liability issues. > This group is not going to produce the machines. They will hand the design > off to a manufacturer who will produce, market and obtain approvals for the > machine. Liability will be all theirs. > > Most likely the machine will be totally redesigned anyway for cost reduction > and to obtain approvals. As a group this is not a highly knowledgeable > design group. I can't imagine this design will fly without rework.
That doesn't make sense on so many levels that it isn't even worth refuting it!

Memfault Beyond the Launch