Group Design

On 2020-07-09 14: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.
> 

Okay, so they aren't actually doing anything productive. That does tend 
to limit product liability. ;)

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

torsdag den 9. juli 2020 kl. 21.31.10 UTC+2 skrev Phil Hobbs:
> On 2020-07-09 14: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.
> > 
> 
> Okay, so they aren't actually doing anything productive. That does tend 
> to limit product liability. ;)
> 

I guess they just like to feel they are doing "something"

https://en.wikipedia.org/wiki/Displacement_(psychology)

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 downside of groups is folks tend to have narrow "specialties"
and there often are not "generalists" who can look at the entire
project and see where (function) responsibilities could better
be shifted.

(I worked on a 30-man project where one developer designed a ~80 sq in
PCB populated entirely with DIP switches -- cuz it didn't occur to him
that the processor could make those settings more economically and in
a more user-friendly manner than he -- with no MCU experience -- had
ever considered)

> 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.

If the goal is just to develop a proof-of-principle prototype *or*
to develop something for second/third world markets, this MIGHT work.
But, in the US (and I imagine similarly in the EU), there is a strong
emphasis on PROCESS... not just "results".  How does anyone know
that it will ALWAYS work??  And, under which conditions it won't?

A continuous ventilator is probably a Class II device.  (Class III
being the most stringent requirements)

cGMPs tend to center around having a thorough (documented!) process
and good papertrail to show that you took the effort "seriously".  If
you don't have a written spec BEFORE you start the design, how do you
know WHAT you are designing ("Did you make this up, as you went?")?
And, how can you evaluate whether or not you have met your design goals?

What tests did you run?  What were the results?  What did you do to
remedy substandard behaviors?  Did these efforts achieve the desired
result (did you even BOTHER to rerun the tests after those changes?)

There is no one at the FDA who is going to evaluate your schematics,
check your code for errors or even check that your device does what it
claims to do!  They typically don't have the resources nor expertise to
do so.  *You* make those assertions and convince them of your sincerity
and diligence with your papertrail/process (and reputation).

[And, of course, expose yourself to future litigation if things
go tits up!]

Bottom line, any manufacturer who would consider producing the device
would want the same sort of assurances (from you) that the FDA wants as
they would be putting THEIR reputation (and assets) on the line.  They're
likely NOT going to opt for an "Arduino" as a key component unless
they have some assurances that the module will remain available for
a considerable amount of time AND won't change (i.e., no firmware
upgrades as they'd require the product to be revalidated)

OTOH, if you're trying to *hack* together something for disadvantaged
third-world countries (pandemic or otherwise), they'll likely be
grateful for whatever they can get their hands on.  And, you'll likely
want to use components that can be easily acquired instead of
requiring some significant design or purchasing investment.

On Thursday, July 9, 2020 at 6:36:33 PM UTC-4, lasselangwad...@gmail.com wrote:
> torsdag den 9. juli 2020 kl. 21.31.10 UTC+2 skrev Phil Hobbs:
> > On 2020-07-09 14: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.
> > > 
> > 
> > Okay, so they aren't actually doing anything productive. That does tend 
> > to limit product liability. ;)
> > 
> 
> I guess they just like to feel they are doing "something"
> 
> https://en.wikipedia.org/wiki/Displacement_(psychology)

They are doing something.  Redesign does not mean starting over.  Every time a second rev of a design is produced it is a redesign.  

What will be interesting is if they can get a working design that can work in all modes of operation.  Most projects don't even attempt that.  That will be a design worth reworking to meet approvals.  

There seem to be lot more replies to this thread as soon as an opportunity to offer something negative was presented.  That says a lot about this group I would say... or maybe just people in general.  

I was starting to think I was posting in s.e.d.

-- 

  Rick C.

  --+ Get 1,000 miles of free Supercharging
  --+ Tesla referral code - https://ts.la/richard11209

On Thursday, July 9, 2020 at 9:34:04 PM UTC-4, Don Y wrote:
> 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 downside of groups is folks tend to have narrow "specialties"
> and there often are not "generalists" who can look at the entire
> project and see where (function) responsibilities could better
> be shifted.
> 
> (I worked on a 30-man project where one developer designed a ~80 sq in
> PCB populated entirely with DIP switches -- cuz it didn't occur to him
> that the processor could make those settings more economically and in
> a more user-friendly manner than he -- with no MCU experience -- had
> ever considered)

How can a design group operate with so little communication that this could happen??? 


> > 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.
> 
> If the goal is just to develop a proof-of-principle prototype *or*
> to develop something for second/third world markets, this MIGHT work.
> But, in the US (and I imagine similarly in the EU), there is a strong
> emphasis on PROCESS... not just "results".  How does anyone know
> that it will ALWAYS work??  And, under which conditions it won't?
> 
> A continuous ventilator is probably a Class II device.  (Class III
> being the most stringent requirements)
> 
> cGMPs tend to center around having a thorough (documented!) process
> and good papertrail to show that you took the effort "seriously".  If
> you don't have a written spec BEFORE you start the design, how do you
> know WHAT you are designing ("Did you make this up, as you went?")?
> And, how can you evaluate whether or not you have met your design goals?

Yes, I have tried to get a spec done for selection a new processor (without doing it all myself), but the inputs were thin.  The one software developer started talking about how much better the tools are with ST micros and tossing part numbers out so that is what was picked. 

Much is being made up as we go along.  When it was decided to go with I believe it is called "assisted" mode ventilation, that puts a whole different set of requirements on the system including the plumbing and the main circuit board.  

If a design is produced that works, and can be shown to work by the methods required, why would the lack of documentation of the process be a stumbling block? 

> What tests did you run?  What were the results?  What did you do to
> remedy substandard behaviors?  Did these efforts achieve the desired
> result (did you even BOTHER to rerun the tests after those changes?)

Not sure what you are getting at here.  The tests must be met by a finished unit. 


> There is no one at the FDA who is going to evaluate your schematics,
> check your code for errors or even check that your device does what it
> claims to do!  They typically don't have the resources nor expertise to
> do so.  *You* make those assertions and convince them of your sincerity
> and diligence with your papertrail/process (and reputation).

That seems like even more work than any other method of verification.  In DOD it's all about passing the acceptance test.  Of course there are requirements on the process, but that is mostly about developing the requirements and tests. 


> [And, of course, expose yourself to future litigation if things
> go tits up!]
> 
> Bottom line, any manufacturer who would consider producing the device
> would want the same sort of assurances (from you) 

No, not from us.  That is ally their baby. 


> that the FDA wants as
> they would be putting THEIR reputation (and assets) on the line.  They're
> likely NOT going to opt for an "Arduino" as a key component unless
> they have some assurances that the module will remain available for
> a considerable amount of time AND won't change (i.e., no firmware
> upgrades as they'd require the product to be revalidated)

Not THE Arduino, the processor and basic design.  The Arduino really is nothing more than a power supply and a processor with a crystal.  I think there is a USB debugger chip.  


> OTOH, if you're trying to *hack* together something for disadvantaged
> third-world countries (pandemic or otherwise), they'll likely be
> grateful for whatever they can get their hands on.  And, you'll likely
> want to use components that can be easily acquired instead of
> requiring some significant design or purchasing investment.

Yeah, that was one of the goals, but the case is a custom design of stainless steel sheet metal and a custom plastic overlay for the front panel.  Of course the main board is a custom design and there are components used that will be sole sourced... the O2 sensor, the pressure sensors, the gear motor.  I think there are some plexiglass pieces for pressing on the bag and that will be one design since variations may well cause changes in how the pressure varies with force from the motor, volume, etc.  Then there will be specific parts indicated for the external plumbing.  So while anyone can build one, it won't be a simple matter of going to the hardware store to get the parts. 

One of the trickier parts is the air flow sensor.  They are measuring the differential pressure across an orifice.  Most of the use will be at the low end where the response is not linear and sensitivity is not good.  I found they are using a commercial product to calibrate their 3D printed device.  Why not just buy the commercial device, the look almost the same.  The 3D printed device has a socket for the O2 sensor...  

-- 

  Rick C.

  -+- Get 1,000 miles of free Supercharging
  -+- Tesla referral code - https://ts.la/richard11209

On 7/9/2020 7:01 PM, Rick C wrote:
> On Thursday, July 9, 2020 at 9:34:04 PM UTC-4, Don Y wrote:
>> On 7/7/2020 6:46 PM, Rick C wrote:
>> The downside of groups is folks tend to have narrow "specialties" and
>> there often are not "generalists" who can look at the entire project and
>> see where (function) responsibilities could better be shifted.
>> 
>> (I worked on a 30-man project where one developer designed a ~80 sq in PCB
>> populated entirely with DIP switches -- cuz it didn't occur to him that
>> the processor could make those settings more economically and in a more
>> user-friendly manner than he -- with no MCU experience -- had ever
>> considered)
> 
> How can a design group operate with so little communication that this could
> happen???

Who *should* take responsibility for that sort of decision, other than
the Project Manager?  Should his competencies include ALL of the areas
of expertise for the team?  Should each team member question the
requirements imposed on himself by other team members' aspects of the
project?

You start off with the assumption that folks are (nominally) competent.
If you question each assertion/demand, then you spend all of your time
asking "Why" instead of assuming that there is a Good Reason "why"
and, other than your own insecurity or curiosity, there's no need for
you to KNOW all of those details ("Why is the machine painted beige?
Why are we using steel instead of aluminum?  Why HiNIL instead of CMOS?
Why Motogorilla instead of Intel?")

Most folks don't have much experience outside of their own narrow field
of expertise.  So, it doesn't dawn on them that the design constraints
COULD be different.

I designed a CPU many years ago.  My best friend was writing the code to
execute on it.  When we installed the code on the prototype processor,
NOTHING worked!  We were each infinitely confident in the OTHER'S abilities
so immediately assumed the mistake lie in our own efforts.  Eventually,
we each realized there were no errors that we could identify in our own
efforts.  So, started looking at each other.  It turned out, my friend
(being a software person) instinctively thought in terms of "bytes".
I, in a hardware role, had designed the processor to operate on WORDS
(it was not possible to address individual bytes).  So, all of the
addresses in his code were off by a factor of two!

"Didn't you think it unusual that ALL of your address fields were EVEN??"

Neither of us had even considered this would be something that we'd have
to agree upon; it was "obvious" to both of us, individually -- just not
the same assumptions!  :<

The (hardware) guy designing the DIP switch board knew that he had to
have a bunch of user-specified parameters for his circuit to operate.
So, he relied on the "usual" means of getting parameters into a
hardware circuit:  switches/jumpers/etc.  Because no one was actively
overseeing his design ("trust the designer"), it never occurred to
anyone (other than me) to suggest "there's a better way!"

But, I was only involved because of my own personal curiosity as to
what his circuit did and how it did it.  The project manager (a MechE)
was completely clueless...

>> cGMPs tend to center around having a thorough (documented!) process and
>> good papertrail to show that you took the effort "seriously".  If you
>> don't have a written spec BEFORE you start the design, how do you know
>> WHAT you are designing ("Did you make this up, as you went?")? And, how
>> can you evaluate whether or not you have met your design goals?
> 
> Yes, I have tried to get a spec done for selection a new processor (without
> doing it all myself), but the inputs were thin.  The one software developer
> started talking about how much better the tools are with ST micros and
> tossing part numbers out so that is what was picked.

Regulatory agencies don't care that he "picked" an ST device instead of
a GI device.  What they want to see is that there was a formal specification
of what was needed and a VERIFICATION that the chosen device met those
requirements.

You can implement a multiplication operator many different ways.  The
regulators don't care WHICH way you choose -- just that the chosen
way satisfies the stated requirements.

> Much is being made up as we go along.  When it was decided to go with I
> believe it is called "assisted" mode ventilation, that puts a whole
> different set of requirements on the system including the plumbing and the
> main circuit board.
> 
> If a design is produced that works, and can be shown to work by the methods
> required, why would the lack of documentation of the process be a stumbling
> block?

FDA is all about process.

When you (personally) design something, I'd wager that you do lots of
testing WHILE putting the design together, evolving its requirements, etc.
Even if that testing is informal, shirt-sleeve sort of effort.  Why do
you do it?  Why not just wait until you're done and test "end-to-end"?
Ans:  the testing gives you increased confidence in the design at various
levels WITHIN the design.

I can design/implement an HVAC system and verify that it keeps the house
at 72 degrees, "exactly".  But, if I notice that the furnace is running
continuously and it's 71 degrees outside, I don't have much faith in that
design/implementation!  Is the furnace not generating the required amount
of heat?  Is the blower running too slowly?  Are there air leaks?  etc.

How confident (put a NUMBER on this!) would I be that it could maintain
that 72 degrees if it was 20 degrees outside?

How confident would you be that the ventilator would work against an
increased back pressure?  Or, at a lower desired flow rate/volume?
Or, with a "low mains" voltage?  Can you test EVERY possible operating
condition?

>> What tests did you run?  What were the results?  What did you do to remedy
>> substandard behaviors?  Did these efforts achieve the desired result (did
>> you even BOTHER to rerun the tests after those changes?)
> 
> Not sure what you are getting at here.  The tests must be met by a finished
> unit.

Testing occurs at two levels (at least -- a developer can always do his
own "experiments" off on the side).  There's an "inner loop" that consists
of "specify, design, implement, VERIFY" that can potentially be repeated
many times.  (but, each time it is a FORMAL process... an ENDORSED spec,
documented test suite, documented results, documented triage)  Each of
these iterations becomes part of the Design History File (DHF) -- a
written record of how you adhered to your process (which was FORMALLY
codified *before* you started all of this!).

Once you think you are "done", your design is formally VALIDATED.
This is when you prove that it meets the intended design goals/user
requirements.  If you fail the validation step, you reenter the above
iteration sequence until you think you're ready to try again.

VALIDATION is typically "expensive" (time/labor) so you don't want to
undertake it casually.  By contrast, VERIFICATION is largely an
internal effort that YOUR PROCESS has control over (who can perform
the activities, how they are controlled, logged, etc.).  So, its
less expensive than validation but more expensive than a lone
developer "tinkering" with some aspect of his design "off the books".

Once validated, the design and implementation are frozen.  You can't
replace multiply() with an "equivalent" version without requiring
revalidation.  You may THINK that all that matters is the "product"
produced by that routine but may discover (in a validation) that
there are unintended side-effects that compromise the design...
maybe the addresses of some routines/variables have been altered,
slightly (though "equivalently") and a bug has been uncovered
that was masked by the previous address bindings!  Or, maybe the
routine is faster and it exposes a race that had previously been
"biased" advantageously.

Remember, the product is not the *abstract* representation that
exists on your design documents (schematics, source code, etc.)
but, rather, the ACTUAL reification that "Manufacturing" churns
out the loading dock.  So, change the compiler switches and you
end up with a new binary --> revalidate!  Change the compiler
and you end up with a new binary --> revalidate!  Change the
processor (because it had an internal bug that has been fixed
in the latest mask) --> revalidate.

Or, engage in a *more* complex analysis that PROVES that the
change(s) have no impact on the design -- at all levels IN the design!

>> There is no one at the FDA who is going to evaluate your schematics, check
>> your code for errors or even check that your device does what it claims to
>> do!  They typically don't have the resources nor expertise to do so.
>> *You* make those assertions and convince them of your sincerity and
>> diligence with your papertrail/process (and reputation).
> 
> That seems like even more work than any other method of verification.  In
> DOD it's all about passing the acceptance test.  Of course there are
> requirements on the process, but that is mostly about developing the
> requirements and tests.

My experience with DoD has only been as a Manufacturing Engineer.  I
recall lots of "useless paperwork" (in the eyes of a teenager) that had
to document each change I made (even if it was obvious:  "The hole is
tapped for #6-32 and the parts list calls out a #4-40"), every
"defective" component that I replaced (along with SAVING the
actual component for later analysis), how I uncovered the fault,
how long it took to diagnose, repair, retest, etc.  None of these
activities make *this* unit operate better; but, they can be
insightful to folks (bean counters) behind the scenes revising
the design, preparing courseware, etc.

But, I can't imagine there isn't a similar set of controls over process,
behind the scenes.

>> [And, of course, expose yourself to future litigation if things go tits
>> up!]
>> 
>> Bottom line, any manufacturer who would consider producing the device 
>> would want the same sort of assurances (from you)
> 
> No, not from us.  That is ally their baby.

But THEY have to make these assurances to the regulators.

I've only dealt with one product that had *direct* exposure to patients
(all of the others were indirect -- diagnostic, etc.).  But, it was
a proof of concept design that was never intended to be manufactured
"as is".  Instead, we had to flesh out the design to show ONE WAY
that the desired functionality could be provided, "reliably".  The
commissioned goal was a "dog-and-pony" that executives/investors
could poke at to decide if it was a worthwhile product to develop
(that THEY would then take on with their armies of STAFF) as the
half-dozen of us had neither the resources (manufacturing) nor
desire (the IDEA is where all of the fun lies!) to undertake FOR
them.

So, we could employ all sorts of "undisciplined" design methodologies
to get to that point -- something that they couldn't do due to their
adherence to all of that formal structure.

I've worked on other projects where we made a very deliberate effort
to produce a product that was "a step away from manufacturing" (including
hundreds of kilobucks of machined stainless steel parts, custom designed
mechanisms, electronics, software, etc.) only to see the design scrapped
when brought to REAL production.  (when you try to make a REAL product,
instead of an approximation, you identify lots of little issues that
seriously impact manufacturability -- in that case, the mechanism was
incredibly elegant but would be hard to reliably produce in volume)

>> that the FDA wants as they would be putting THEIR reputation (and assets)
>> on the line.  They're likely NOT going to opt for an "Arduino" as a key
>> component unless they have some assurances that the module will remain
>> available for a considerable amount of time AND won't change (i.e., no
>> firmware upgrades as they'd require the product to be revalidated)
> 
> Not THE Arduino, the processor and basic design.  The Arduino really is
> nothing more than a power supply and a processor with a crystal.  I think
> there is a USB debugger chip.

No firmware onboard?  Toolchain never revised?  Libraries?  No mask
revisions in the processor?  Die shrinks?  Layout changes?

They are interested in making a product hobbyists/hardware-challenged
want to buy so are concerned with cost/profit and features.  They likely
don't expect any of their customers to complain because they trimmed
a clock cycle off of some particular opcode in the processor.  Or,
increased the amount of onboard RAM, or supported USB3, etc.

>> OTOH, if you're trying to *hack* together something for disadvantaged 
>> third-world countries (pandemic or otherwise), they'll likely be grateful
>> for whatever they can get their hands on.  And, you'll likely want to use
>> components that can be easily acquired instead of requiring some
>> significant design or purchasing investment.
> 
> Yeah, that was one of the goals, but the case is a custom design of
> stainless steel sheet metal and a custom plastic overlay for the front
> panel.  Of course the main board is a custom design and there are components
> used that will be sole sourced... the O2 sensor, the pressure sensors, the
> gear motor.  I think there are some plexiglass pieces for pressing on the
> bag and that will be one design since variations may well cause changes in
> how the pressure varies with force from the motor, volume, etc.  Then there
> will be specific parts indicated for the external plumbing.  So while anyone
> can build one, it won't be a simple matter of going to the hardware store to
> get the parts.

So, the idea that it's an "affordable" design suited for "less resourceful"
environments is no longer the case.

> One of the trickier parts is the air flow sensor.  They are measuring the
> differential pressure across an orifice.  Most of the use will be at the low
> end where the response is not linear and sensitivity is not good.  I found
> they are using a commercial product to calibrate their 3D printed device.
> Why not just buy the commercial device, the look almost the same.  The 3D
> printed device has a socket for the O2 sensor...

<shrug>  Despite their possible motivations, it really looks like this is
just a glorified hobbyist exercise -- being able to tell themselves they
are doing something "worthwhile" when, in fact, they are throwing away
their time/resources.

There was a group, here, that wanted to build "little houses" for The Homeless.
Lots of energy, excitement, press coverage, etc.  But, totally lacking in
the skills needed to actually BUILD little houses!  They'd have done more
good if they had flipped burgers at McDonald's for all the hours they
spent meeting and talking about it... and donated the monies to the
first homeless person they encountered on a street corner!

I think the idea of a low-cost, third-world ventilator would be admirable.
It's a "market" that doubtless won't be addressed (go where the money is!).
And, can likely avoid all of the effort/tedium/expense/legalese that selling
into first-world markets would entail.

It's also a much more challenging project!  Not just coming up with a
reproducible design but, also, looking past that to MAINTAINING the
design in environments that don't have easy access to the same sorts
of technology that we are accustomed to.  E.g., imagine every component,
individually, breaking.  How would you replace them if you were in
Sudan?  Yemen?  Ethiopia?  What do you do if you have a single "15A"
branch circuit powering an entire ward?  How many of these can you
support in addition to the other "required" equipment?  How will
your design fare if power fails/fluctuates often?  etc.

[I've had to "dumb down" designs, in the past, to ensure they could be
maintained in places hat are off-the-beaten-track.  It's really hard
to imagine how LITTLE you actually NEED when you are accustomed to having
more-than-enough!]

Good luck!

(BTW, if you're interested in the FDA issues in greater detail, chase
down Title 21 of the FDA's CFR 820.30 to get a general overview)

There is presently a decision being made about various methods of detecting end of travel for the back stroke of the motor.  One of the selection criteria is "simplicity", 1 to 3.  I don't see that as an objective value, rather a subjective rating of what they think of each approach.  Cost is rated from 1 to 3 without any real consideration of a dollar (or pound) figure.  The three methods that use a detector each are rated 1 on cost (because there is some) and two methods are rated 3 on cost because they use timing (guessing) or motor current on reaching a mechanical stop.  

So do Hall effect sensors have any real issues such as magnetic interference?  They work off of a magnetic field, but not a rapidly varying field (the motor output is single digit RPM in use) so will local magnetic effects impact it, like the motor current?  The sensor will probably be 9 inches away.  Is a magnet built into Hall effect sensors or is that required to be added?  

Another choice is an optical sensor.  They list as a disadvantage optical interference!  That seems rather unlikely in a closed box especially.  There are openings, but not large.  For some reason this one is listed as poorest in simplicity.  Seems simple to me.  

They list circuit boards as being needed for those two and a micro switch.  I know these can be mounted on cables, but is there a reason why that would be a bad idea for reliability?  I recall in my very early days in engineering seeing front panels with switches and LEDs being wired up by hand via ribbon cable and heat shrink tubing.  That was equipment for a NASA ground station, forty years ago.  Likely they would not accept that now?  

There is also the option of the motor shaft encoder, but that is significantly more expensive and I recall there was a strong dislike of the $15 price.  I suggested they include a couple of the options in the circuit board and after development is done leave out the one you don't use.  They seem to think they can make all the decisions without knowing for sure how this will need to be designed. 

-- 

  Rick C.

  -++ Get 1,000 miles of free Supercharging
  -++ Tesla referral code - https://ts.la/richard11209

On 10/7/20 11:36 am, Rick C wrote:
> On Thursday, July 9, 2020 at 6:36:33 PM UTC-4, lasselangwad...@gmail.com wrote:
>> torsdag den 9. juli 2020 kl. 21.31.10 UTC+2 skrev Phil Hobbs:
>>> On 2020-07-09 14: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.
>>>>
>>>
>>> Okay, so they aren't actually doing anything productive. That does tend
>>> to limit product liability. ;)
>>>
>>
>> I guess they just like to feel they are doing "something"
>>
>> https://en.wikipedia.org/wiki/Displacement_(psychology)
> 
> They are doing something.

But not something that will be useful to anyone who actually needs a 
ventilator.

The entire design of the Puritan Bennett 560 current-model approved 
ventilator from Medtronic was released under a permissive license way 
back in March. Why does your group think they can (or should?) do better.

> There seem to be lot more replies to this thread as soon as an opportunity to offer something negative was presented.

You get criticism most of the because you spend most of your time 
prevaricating. Change your default mode of response to match that of any 
vaguely reasonable person and you'll find discussion much more productive.

CH

On Friday, July 10, 2020 at 2:17:22 AM UTC-4, Clifford Heath wrote:
> On 10/7/20 11:36 am, Rick C wrote:
> > 
> > They are doing something.
> 
> But not something that will be useful to anyone who actually needs a 
> ventilator.

Sorry, that's just your BS.  Nothing to reply to. 


> The entire design of the Puritan Bennett 560 current-model approved 
> ventilator from Medtronic was released under a permissive license way 
> back in March. Why does your group think they can (or should?) do better.

Yes, I've looked at that design and it is very complex and uses a EOL CPU.  They have a sensing circuit to detect power going to the piezo sounder.  Not sure that sort of robustness is required.


> > There seem to be lot more replies to this thread as soon as an opportunity to offer something negative was presented.
> 
> You get criticism most of the because you spend most of your time 
> prevaricating. Change your default mode of response to match that of any 
> vaguely reasonable person and you'll find discussion much more productive.

Thank you for your input.  I look forward to your next reply.  Oh, and please trim your posts. 

-- 

  Rick C.

  +-- Get 1,000 miles of free Supercharging
  +-- Tesla referral code - https://ts.la/richard11209

On 7/9/2020 10:48 PM, Rick C wrote:
> There is presently a decision being made about various methods of detecting
> end of travel for the back stroke of the motor.  One of the selection
> criteria is "simplicity", 1 to 3.  I don't see that as an objective value,
> rather a subjective rating of what they think of each approach.  Cost is
> rated from 1 to 3 without any real consideration of a dollar (or pound)
> figure.  The three methods that use a detector each are rated 1 on cost
> (because there is some) and two methods are rated 3 on cost because they use
> timing (guessing) or motor current on reaching a mechanical stop.

A "binding" mechanism will fail to achieve its goal in a fixed period
of time AND will likely indicate a higher current draw, prematurely.
How *important* is that indication to the proper operation of the device?

How regularly do you expect the device to be maintained/serviced?
What sort of skill level do you expect from the parties doing that servicing?
(this goes to my previous comments re: third-world applications; first-world
likely have staff on-hand to maintain ALL of the kit that they utilize -- as
well as equipment suitable for those tasks)

> So do Hall effect sensors have any real issues such as magnetic
> interference?  They work off of a magnetic field, but not a rapidly varying
> field (the motor output is single digit RPM in use) so will local magnetic
> effects impact it, like the motor current?  The sensor will probably be 9
> inches away.  Is a magnet built into Hall effect sensors or is that required
> to be added?

Typically added if you're trying to monitor the presence of an
object (motor shaft) in a particular location.

> Another choice is an optical sensor.  They list as a disadvantage optical
> interference!  That seems rather unlikely in a closed box especially.  There
> are openings, but not large.  For some reason this one is listed as poorest
> in simplicity.  Seems simple to me.

What about dust/crud/*critters* interfering with the emitter (or detector)?

> They list circuit boards as being needed for those two and a micro switch.

You can put a HE sensor on the end of a cable.  Ditto for an optical sensor.
But, mounting to a PCB -- and affixing a cable to *that* -- may be easier
to manufacture/service (imagine having to reattach a pigtail to a bare
sensor)

> I know these can be mounted on cables, but is there a reason why that would
> be a bad idea for reliability?  I recall in my very early days in
> engineering seeing front panels with switches and LEDs being wired up by
> hand via ribbon cable and heat shrink tubing.  That was equipment for a NASA
> ground station, forty years ago.  Likely they would not accept that now?

Adding strain relief to a bare sensor becomes problematic.  A sensor mounted
on a PCB is reasonably robust.  And, even a cable fabricated from a set of
individual wires can have an improvised strain relief (loop it through a
set of holes before leaving the PCB).

(Again, how will this be serviced?  How likely are folks to be
tinkering around INSIDE the enclosure?  How skilled are those folks
likely to be?)

> There is also the option of the motor shaft encoder, but that is
> significantly more expensive and I recall there was a strong dislike of the
> $15 price.  I suggested they include a couple of the options in the circuit
> board and after development is done leave out the one you don't use.  They
> seem to think they can make all the decisions without knowing for sure how
> this will need to be designed.

What are you hoping to monitor with the shaft encoder?  Are you hoping to
resolve a fraction of a rotation?  Or, count *numbers* of rotations?
In the latter case, you can use a very crude encoder with one or two
pulses per revolution -- a "home" sensor and "index" pulses.

We manufactured a maritime radar unit, many years ago.  You need to
know the actual position of the antenna to synchronize it with the
display.  The "obvious" solution was a fine-pitch shaft encoder
where each discernible antenna "position" was directly indicated by
the encoder.

Another company *copied* our basic design.  But, made several improvements
to increase manufacturability.  One such change was replacing the fine
(photographically produced!) encoder with a very coarse encoder -- mounted
on the antenna motor shaft BEFORE the gear reduction assembly!  So, their
encoder rotated at a much faster rate -- but, would output pulses at the
exact same rate as ours!  "D'oh!"