Group Design

On 2020-07-08 Rick C wrote in comp.arch.embedded:
> 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:

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

I don't think you got mu point here. I just commented on your (friends)
statement '"prove" your design will not hurt the patient in any way'. That
is simply not true. There is always a risk/benefit and as long as the
benefits outweigh the risks, some risk may be deemed acceptable. This
presentation highlights how important risk/benefit is in the new MDR (EU
medical deviceregulation).
https://www.bsigroup.com/meddev/LocalFiles/en-US/roadshow-resources-2017-fall/bsi-mdr-risk-and-clinical-requirements.pdf

And this goes for all medical devices, from complex (like ventilators or
MRI scanners) to simple. The scalpel being an example of the latter, not
a comparison to the ventilator.

> 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'm not familiar with FCC, but if it's anything like EU CE marking to get
(non medical) electronic devices approved for sale, you might be in for a
shock when it comes to electronic medical devices, especially those that
include software.


> I believe the plan is to find a manufacturing partner to turn this design over to who will bear the brunt of approvals.  

Like has been said multiple times. You should start (preparation for) the
approval process before/during the design, not after.

And any idea who this manufacturing partner will be? It will need to be
a partner already familiar with medical devices, preferrably with
ventilators. And you have to come with something they could not have
done themselves.

[...]
>
> 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°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. 
>

One hand, these problems are only minor and can be solved by any capable
electronics engineer. On the other this sort of thing would get me worrying
about the skills of the team. But if their skills are in medical and
regulations, an electronics engineer would be a good supplement to the team.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

The whole earth is in jail and we're plotting this incredible jailbreak.
		-- Wavy Gravy

On Friday, July 10, 2020 at 2:53:56 AM UTC-4, Don Y wrote:
> 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?

The machine has measurements of pressure and volume.  If the pressure is not relieved adequately the next stroke will have aberrant pressure/volume measurements.  


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

What part of the machine do you think can be used without someone trained in operating and maintaining it?  That is inherent no matter what country it is used in.  These are not wind up toys.  A ventilator requires a very knowledgeable person operating it.  The maintenance is simple compared to that I think and would be part of their training. 


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

Not sure what that means.  Yes, the idea is to detect the position of the arm at the end of the backwards stroke.  I'm asking if the device includes a magnet.  If not a magnet would need to be added.  I know they don't work from disturbances of the earth's magnetic field. 


> > 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)?

What about it?  Do you think that is likely?  The arm will break the beam on every cycle.  How much crud could accumulate?  Maybe after months or years of use.  This unit will have periodic maintenance and cleaning the opto would be part of that. 


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

"Reattach"????  If it breaks the sensor and cable are a replaceable unit.  Where have you been for the last 30 years?  If it breaks the most likely point of breaking is flush with the detector, no reattach practical. 


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

It is???  Strain relief on most connectors is totally absent.  I've made many cables using heat shrink as strain relief as well as clamping the cable next to the device it is attached to.  A simple clamp takes all the strain. 


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

So much the same as without a 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?)

Why are you asking this question?  Repair beyond normal replaceable components require proper repair, by a trained repair person.  What do you expect???  Are you thinking it is intended to be used and maintained by unskilled people?  I don't think any ventilators meet that goal. 


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

A shaft encoder measures position of the shaft.  The shaft doesn't even make a half rotation in use. 


> 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!"

But fails to provide absolute position and only provides relative position.  To get absolute position requires a stop or a limit switch.  If we have the limit switch we don't need the shaft encoder.  If we use the stop, we don't need any of the other devices. 

The encoder would allow more accurate info on the position of the arm, so it could be positioned more accurately to the point where it starts to push on the bag... with different bags.  But it seems there is little interest in supporting multiple bag sizes and types.  

I'm going to recommend that we provide a 4 pin connector and a circuit that works with the opto, the hall effect sensor and a switch.  That won't be hard to do.  Then we can experiment with each.  The encoder will be a bit more complex, I think it uses SPI, but I don't recall. 

-- 

  Rick C.

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

On 2020-07-10 Rick C wrote in comp.arch.embedded:
> On Friday, July 10, 2020 at 2:17:22 AM UTC-4, Clifford Heath wrote:
>
>> 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.

This sensing circuit is most probably a risk control that has been
implemented as the result of a design risk analysis. The sounder is
probably used for a medical alarm, which puts a lot of requirements on
performance of the sounder circuit.

You can only be sure that sort of robustness is desired if you perform a
design risk analysis.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Riffle West Virginia is so small that the Boy Scout had to double as the
town drunk.

On 7/10/2020 1:15 AM, Rick C wrote:
> On Friday, July 10, 2020 at 2:53:56 AM UTC-4, Don Y wrote:
>> On 7/9/2020 10:48 PM, Rick C wrote:
>> 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)
> 
> What part of the machine do you think can be used without someone trained in
> operating and maintaining it?  That is inherent no matter what country it is
> used in.  These are not wind up toys.  A ventilator requires a very
> knowledgeable person operating it.  The maintenance is simple compared to
> that I think and would be part of their training.

Most of the devices (medical and otherwise) that I've designed can
be USED/operated by people who would be completely CLUELESS as to
how to service/maintain them!  Every local hospital has its own crew
of techs that service/maintain ALL of the equipment on-site (barring
some devices that need support out of the factory).

Define "maintenance" vs. "service".  Are these folks expected to
be capable of DIAGNOSING and replacing to the FRU level?  Will
there be a depot accessible to them?

You've not defined where these are intended to be used.  Nor the conditions
under which they are expected to be used (e.g., in a pandemic, I suspect
you'll find lots of "untrained" people being MARGINALLY trained just to
address personnel shortages).

I've designed products that are deployed in jungles, on mountain tops
(one product was hauled on an oxen-drawn cart!) away from "civilization".
Replacement parts are DAYS away.  So, it is crucial that the sorts
of things that MIGHT fail can easily and intuitively be repaired
on-site by somewhat unskilled labor (a crude soldering iron, a pair
of wire strippers, basic screwdrivers, etc.)

*I've* had to service kit designed by others and had to rely on
next day air shipments to parts of the *USA* (spend several hours
driving out to the airport to meet an incoming flight) because there
wasn't ANY supplier within driving distance.

If, OTOH, you're expecting to deploy your kit in downtown LA or NYC,
then you have a different set of resources (personnel/parts) available.

>>> 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.
> 
> Not sure what that means.  Yes, the idea is to detect the position of the
> arm at the end of the backwards stroke.  I'm asking if the device includes a
> magnet.  If not a magnet would need to be added.  I know they don't work
> from disturbances of the earth's magnetic field.

As I said:  "Typically ADDED if you're trying to monitor..."

>>> 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)?
> 
> What about it?  Do you think that is likely?  The arm will break the beam on
> every cycle.

That's the case if you use an optical INTERRUPTER.  But, "optical"
doesn't necessarily imply "interrupter".  You can locate a reflective
sensor (emitter+detector) and passively monitor position from a distance,
without requiring anything to pass "between" the two.

Regardless, if the detector becomes obstructed by "cruft", it won't
matter whether it is reflective or not!

Can you guarantee that it will always be "clean"?  Can you design the
product to detect when this "event" was detected as "missing" (and
shut down the device due to that failure)?

> How much crud could accumulate?  Maybe after months or years
> of use.  This unit will have periodic maintenance and cleaning the opto
> would be part of that.

So, part of the cost of using an optical sensor is having to ensure it
is periodically cleaned.  Note that there is no way that you can verify this.
You can only detect when it HASN'T been cleaned (and now fails).

>>> 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)
> 
> "Reattach"????  If it breaks the sensor and cable are a replaceable unit.
> Where have you been for the last 30 years?  If it breaks the most likely
> point of breaking is flush with the detector, no reattach practical.

What if there is no depot accessible?  Do you wait for the next boat
to come down the river, give the skipper a message to bring "back to
civilization", then wait for him to RETURN with the replacement part?

Or, do you take your (crude) soldering iron and use the village genset
to repair the broken wire/connection?

Again, you haven't defined your application environment.

Why bother replacing a cable assembly?  Why not just replace the entire
UNIT??  It's cheap enough, right?
     "The Fedex man will be there tomorrow morning.  He will hand
     you a package containing a new unit.  Take the unit out of
     the package, place the old/broken one IN the package and
     hand it back to the Fedex man.  He'll ensure it gets back
     to the factory for refurbishment."
[The last medical instrument I designed was supported this way!
If you design reliably, then you can afford to bear this cost
for your customer.  And, your customer is happy because HE doesn't
have to support that piece of equipment!]

I.e., I can take ANY possible attitude towards after-sale support
given that you haven't defined your environment.  Where have YOU
been for the past 30 years??  Do you think you can diagnose, repair,
recertify a piece of equipment faster than a next-day air replacement?
Do you think that "trained staff" is just sitting, WAITING to
repair YOUR device and ONLY your device?

>>> 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.
> 
> It is???  Strain relief on most connectors is totally absent.

YOu don't put ANY connector on the circuit board.  Solder the conductors
onto the board and "thread" them through a pair of oversized holes to
be cinched with a ty-wrap.  Your concern is only that the individual
conductors develop breaks.

>  I've made
> many cables using heat shrink as strain relief as well as clamping the cable
> next to the device it is attached to.  A simple clamp takes all the strain.

Then the cable never fails.  So, why are you bothering to stock them
as replacement FRUs?

>> 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).
> 
> So much the same as without a 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?)
> 
> Why are you asking this question?

BECAUSE YOU HAVEN'T DEFINED YOUR ENVIRONMENT!

> Repair beyond normal replaceable
> components require proper repair, by a trained repair person.  What do you
> expect???  Are you thinking it is intended to be used and maintained by
> unskilled people?  I don't think any ventilators meet that goal.

If you were targeting third-world applications, then YES, I would expect
unskilled people to maintain the product -- because there would be more
demand for the product than there would be "trained people" to support it!

If you intend to target Massachusetts General Hospital, I suspect
they already have "trusted" providers that they work with.

>>> 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?
> 
> A shaft encoder measures position of the shaft.  The shaft doesn't even make
> a half rotation in use.

So, there's a gearbox involved?  Or, does the "motor" only turn a fraction
of a revolution?

The position of the radar antenna I mentioned has to be resolved to ~1 degree.
But, as I said, that can be accomplished with a 360 slot encoder wheel *or*
a 4 slot wheel on the high side of a 90:1 gearbox.  Or, many combinations
between.

Chances are, there is some mechanical gain/attenuation SOMEWHERE in that
mechanism.  Pick a point that is easiest to monitor with the most tolerant
technology.

>> 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!"
> 
> But fails to provide absolute position and only provides relative position.
> To get absolute position requires a stop or a limit switch.

Yes.  Note "home" and "index", in my above comment.  In our case, you need
an independent reference to tell you when the antenna is pointed directly
at the bow (cuz the top of the radar "scope" is associated with that
reference).  So, silly to add an ABSOLUTE shaft encoder that lets you
resolve the angular position STATICALLY (the antenna never stops rotating
and you can afford to wait ~1/2 rotation before you sync up; you don't
ever FORGET that once you've detected it!)

> If we have the
> limit switch we don't need the shaft encoder.  If we use the stop, we don't
> need any of the other devices.

If ALL you are interested in is an "end of travel" indication
(and don't care to notice if the shaft is "in motion"), then you can
put a reflective/magnetic sensor on it and detect when it is in the
correct rotational orientation.

But, in each case, you have to be watching for events that can't
NORMALLY happen (i.e., shaft is NOT rotating; shaft has taken too
long to rotate; etc.).  Can you afford to wait for a complete
cycle before detecting a fault?  Do you have to provide a backup
sensing technology in case the primary fails or proves to be
unreliable?  Or, can you afford to replace the entire ventilator with
another (while this one is serviced)?

Having a formal specification BEFORE starting on the design would
answer all of these questions for you so all you had to do was
worry about MEETING those goals.

If I lost track of the position of the turret on a rotary tablet press,
I had to stop the process immediately -- because I can't attest to the
quality of the tablets being produced (up to 75 of which might be in
partial states of formulation at any given time).  The cost of the
"product" that would then be discarded can be significant -- especially
if you have to wait (on average) half a rotation to "know" where the
turret is (home + index) -- yet another batch of discarded product!

> The encoder would allow more accurate info on the position of the arm, so it
> could be positioned more accurately to the point where it starts to push on
> the bag... with different bags.  But it seems there is little interest in
> supporting multiple bag sizes and types.
> 
> I'm going to recommend that we provide a 4 pin connector and a circuit that
> works with the opto, the hall effect sensor and a switch.  That won't be
> hard to do.  Then we can experiment with each.  The encoder will be a bit
> more complex, I think it uses SPI, but I don't recall.

On Thu, 9 Jul 2020 19:01:28 -0700 (PDT), Rick C
<gnuarm.deletethisbit@gmail.com> wrote:

>On Thursday, July 9, 2020 at 9:34:04 PM UTC-4, Don Y wrote:
>
>> 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. 

In general the USFDA expects vendors to validate their own products.
They will presume that whatever it is works for its intended purpose
[else why bring it to them?] and, in my experience,they will be more
interested in documentation of trials proving effectiveness and in
production controls than in the details of designs or formulas, etc.


I worked on software for a diagnostic imaging system to render CT and
MRI volumes as holograms on film.  It was expected that - as with xray
- surgeons would rely on these films to plan interventions, but the
FDA examiners seemed less interested in image accuracy than in whether
developer fluid could leak from the automatic film processor.

Separately I worked on several machine vision QA/QC systems that were
used in pharmaceutical production: checking consistency of powders and
fluid mixtures, looking for tablets damaged in handling, checking that
packages were filled correctly, etc.  The FDA was concerned mainly
with consistency of our inspection results - correctness and/or
usefulness of our systems being left to the users (pharma companies)
to evaluate.


It's not easy to predict what examiners will focus on. YMMV.

George

On Friday, July 10, 2020 at 5:36:59 PM UTC-4, George Neuner wrote:
> On Thu, 9 Jul 2020 19:01:28 -0700 (PDT), Rick C
> <gnuarm.deletethisbit@gmail.com> wrote:
> 
> >On Thursday, July 9, 2020 at 9:34:04 PM UTC-4, Don Y wrote:
> >
> >> 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. 
> 
> In general the USFDA expects vendors to validate their own products.
> They will presume that whatever it is works for its intended purpose
> [else why bring it to them?] and, in my experience,they will be more
> interested in documentation of trials proving effectiveness and in
> production controls than in the details of designs or formulas, etc.
> 
I was part of a CT manufacturing start up. what I learned is that
The key in FDA boils down to:
* Define your process.  (Say what you do to ensure quality)
* Build your design.    (do what you planned)
* V&V your design and process. (document all steps along the way)

It comes down to documentary evidence.

> 
> I worked on software for a diagnostic imaging system to render CT and
> MRI volumes as holograms on film.  It was expected that - as with xray
> - surgeons would rely on these films to plan interventions, but the
> FDA examiners seemed less interested in image accuracy than in whether
> developer fluid could leak from the automatic film processor.

You actually created film holograms from CT data?
Is there any published information about how you did that?

There are standard image quality tests you would perform and
report the results. If those passed, they would be pretty confident
in your imaging process and would focus on anything less well
documented.

> 
> Separately I worked on several machine vision QA/QC systems that were
> used in pharmaceutical production: checking consistency of powders and
> fluid mixtures, looking for tablets damaged in handling, checking that
> packages were filled correctly, etc.  The FDA was concerned mainly
> with consistency of our inspection results - correctness and/or
> usefulness of our systems being left to the users (pharma companies)
> to evaluate.
> 
> 
> It's not easy to predict what examiners will focus on. YMMV.
> 
> George

True. My experience is limited, so I'll leave it at that except:
Having worked on a product under FAA review recently,
I would say I prefer the FDA process much better.

HTH,
   Ed

On Tue, 14 Jul 2020 11:09:22 -0700 (PDT), Ed Prochak
<edprochak@gmail.com> wrote:

>On Friday, July 10, 2020 at 5:36:59 PM UTC-4, George Neuner wrote:
> 
>> I worked on software for a diagnostic imaging system to render CT and
>> MRI volumes as holograms on film.  It was expected that - as with xray
>> - surgeons would rely on these films to plan interventions, but the
>> FDA examiners seemed less interested in image accuracy than in whether
>> developer fluid could leak from the automatic film processor.
>
>You actually created film holograms from CT data?
>Is there any published information about how you did that?

I'm not aware of any:  I was a contractor on the project, implementing
a proprietary process.

I can say what was known publicly: that the process used multiple
"slice" exposures to create a master film, which then was used as an
exposure filter to create the final hologram films.  But I can't talk
about any processing that was done to prepare the volume imagery.


The process is owned by Holorad (http://holorad.com) and medical 
imaging systems are distributed by VOXEL (http://voxel.us).  There is
no technical information on their websites, but they may provide
something if you contact them.

George

On 07/08/20 23:20, Rick C wrote:

> 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°C!!!

You should be concerned. The whole thing about safety critical kit is
that it should be conservatively designed, with all parts running well
within their ratings. If the hw bod is happy with a regulator running
at 70c, he must be clueless. Sorry, but it needs to be said.

If you care about your professional career and any litigation
issues, you should either have enough influence on the project
direction to stop design errors like that, or just walk away from it...

Chris

On Thursday, August 6, 2020 at 7:01:55 PM UTC-4, Chris wrote:
> On 07/08/20 23:20, Rick C wrote:
> 
> > 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°C!!!
> 
> You should be concerned. The whole thing about safety critical kit is
> that it should be conservatively designed, with all parts running well
> within their ratings. If the hw bod is happy with a regulator running
> at 70c, he must be clueless. Sorry, but it needs to be said.
> 
> If you care about your professional career and any litigation
> issues, you should either have enough influence on the project
> direction to stop design errors like that, or just walk away from it...
> 
> Chris

It was a prototype board before I came on board.  I am involved in the design review of the next rev and I will be pushing for a design review of the layout as well.  Not sure how well that will be received.  

The project leader has indicated numerous times that he wants to get the board rolling in spite of us not having good requirements.  He brought someone on board to help with that, but this is very different from what I am accustomed to.  My experience with requirements analysis was on DOD projects and it had lots of formalities with each requirement being linked to a test.  

We just had a meeting today with the guy who has written a systems level requirements document.  He has indicated that he will be breaking requirements down further for the software, but not for the hardware.  I asked why and time was cited, not enough time to do that.  What???  

I don't have any specific duties at the moment.  I might participate in a design review of the schematic and layout, but I won't be doing any further design work.  

I just think it is crazy to try to push this design to completion without knowing what it is supposed to do in detail.  There seems to be an obsession with turning the machine off even though it has battery backup which would be depleted in an hour if left connected or in a couple of months if not.  There is an alarm for when the machine is unplugged and running off battery.  So what should turning the machine off do exactly?  I can't get an answer, but we need to complete the board design. 

Yeah, we are nearing the end of this road. 

-- 

  Rick C.

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

On 2020-08-06 19:01, Chris wrote:
> On 07/08/20 23:20, Rick C wrote:
> 
>> 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°C!!!
> 
> You should be concerned. The whole thing about safety critical kit is
> that it should be conservatively designed, with all parts running well
> within their ratings. If the hw bod is happy with a regulator running
> at 70c, he must be clueless. Sorry, but it needs to be said.
> 
> If you care about your professional career and any litigation
> issues, you should either have enough influence on the project
> direction to stop design errors like that, or just walk away from it...
> 
> Chris

Hmm, interesting.  Most linear regulators I'm familiar with are rated to 
125 C junction temperature, and some higher.  What safety or regulatory 
issues have you run into that were caused by running some part 55C below 
its rated temperature?

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