S
Stef
- Jan 1, 1970
- 0
In comp.arch.embedded,
That depends on the software risk class. If the software imposes no risk
(risk mitigated in hardware for example), I don't think they would care.
Indeed, you need to have procedures in place for changes and lifecycle
management.
I guess that was a safety critical (isolation?) transformer then.
Depending on the available paperwork and test data that could require
re-testing some parts. But re-certing the whole device sounds a bit
too much, but I don't know the circumstances.
What can also happen is that an old medical device was certified
under the 1st edition of the european 60601 standard. If you then
change something, chances are that you need to re-cert for the 2nd
edition.
At least that was until the release of the 3rd edition. That now
requires that everything you sell is certified under the 3rd edition,
not only changed devices. A huge re-certing effort for all older
devices, changed or not.
Yes, that is where having (and using!) procedures and standards is
a real benefit.
I understand that those markets have strict requirements. But it surprises
me that their only answer to (minor) changes would be: recertify the
entire device. Instead of: Show us the changes and their effect and we'll
then see if we need full re-cert or just partial.
In my experience, in medical device you can sometimes do changes without
re-certification, but certainly not always. Thats why I started with "That
is not always true".
Joerg said:I really doubt they would agree if a code re-compilation was required to
make this work. With code and firmware they have become very careful
because there have been to many mishaps.
That depends on the software risk class. If the software imposes no risk
(risk mitigated in hardware for example), I don't think they would care.
Most of the time the notified bodies or even the FDA do not care much
about the code, they care about your process. So then the onus is on the
company, and there mostly on the VP of Quality Control. He or she will
normally not take a re-compile lightly, or as something that can be
brushed under the carpet as "not too risky".
Indeed, you need to have procedures in place for changes and lifecycle
management.
It is the same with some hardware. I went through a whole re-cert once
just because we had to switcher the manufacturer for one little transformer.
I guess that was a safety critical (isolation?) transformer then.
Depending on the available paperwork and test data that could require
re-testing some parts. But re-certing the whole device sounds a bit
too much, but I don't know the circumstances.
What can also happen is that an old medical device was certified
under the 1st edition of the european 60601 standard. If you then
change something, chances are that you need to re-cert for the 2nd
edition.
At least that was until the release of the 3rd edition. That now
requires that everything you sell is certified under the 3rd edition,
not only changed devices. A huge re-certing effort for all older
devices, changed or not.
The bottomline is that in the unlikely but possible situation where
something bad happens you need to be prepared. Then there will be a
barrage of request for documents from the regression testing and all
that. Woe to those who then don't have them.
Yes, that is where having (and using!) procedures and standards is
a real benefit.
There are many other markets with similar requirements. One of them is
railroad electronics, especially for countries like Germany.
I understand that those markets have strict requirements. But it surprises
me that their only answer to (minor) changes would be: recertify the
entire device. Instead of: Show us the changes and their effect and we'll
then see if we need full re-cert or just partial.
In my experience, in medical device you can sometimes do changes without
re-certification, but certainly not always. Thats why I started with "That
is not always true".