$1 invested in upfront consultation may save $10 or $100 wasted in straying and later in fixing. Unfortunately 95% of managements don't get that.Hi, I am new in this forum and I want to share that I know the described hardware=software approach from experience and I absolutely agree that it should be avoided whatever it takes…
Back in the days when the company I work for (in the R+D-department) was much more startup-like we set sails to be certified according ISO 13485. Therefore we set up the documentation for a complex enough diagnostic platform. We figured out the how-to on the go because we had close to no clue or best practice available and ended up with much unnecessary complexity: We found a software tool to help us with the required documentation (the QMS grew accordingly in the same time). A predefined set of configuration was available - designed to comply with SW-regulations for medical devices. So besides the help it provided for our SW-documentation it very much inspired also the concepts for documentation of hardware (mechanical parts), reagents and all other subcomponents of the products.
We did not know better at that time and here we go. With the learning curve over the past years - If I ever had to setup a system from scratch again I would definitely cut out a lot of the complexity in the hardware-documentation and focus much more on the risk management in general. Since the risk management plays such an important role when it comes to changes, CAPAs etc. anyway. Streamlining such a system while it is up and running is not what you prefer to do (and it is hard to get the necessary budget from management...).
Can anyone explain why 7.3.2 e) does require each and every design output to be traceable to one or more design inputs?Can anyone explain why 7.3.2 e) does not require each and every design output ot be traceable to one or more design inputs? Or are there other clauses that lift from the requirement to trace each and every design output to design inputs?
My reasoning was, that if each and every Design Output is traceable to a Design Input, also the complete set is traceable. However, I am aware that this is not required, which is why I asked the question in this forum=). There must be other "methods to ensure traceability of design and development outputs to design and development inputs". I am looking for an example of such a method.Can anyone explain why 7.3.2 e) does require each and every design output to be traceable to one or more design inputs?
That is correct.I can imagine that is is possible to verify that all Design Inputs are satisfied by using only a subset of Design Outputs.
No.Are the verification activities the "methods to ensure traceability of design and development outputs to design and development inputs"?
The simplest is a spreadsheet of few columns.Thank you for your answer! I would appreciate if you could elaborate a bit? Could you perhaps explain what requirement is expressed by 7.3.2 e), possibly with an example, and how it could be met?
As you mentioned earlier, it is required that "the whole of the Design Output (plural) satisfies the whole of the Design Input". Since you used the word "satisfy" and not "traceable", I assumed you refer to verification activities. Are the verification activities the "methods to ensure traceability of design and development outputs to design and development inputs"? I can imagine that is is possible to verify that all Design Inputs are satisfied by using only a subset of Design Outputs.
My reasoning was, that if each and every Design Output is traceable to a Design Input, also the complete set is traceable. However, I am aware that this is not required, which is why I asked the question in this forum=). There must be other "methods to ensure traceability of design and development outputs to design and development inputs". I am looking for an example of such a method.