Design input/output traceability for mechanical parts
- Thread starter shimonv
- Start date
Elsmar Forum Sponsor
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...).
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...).
$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.
I´d sign that.
And as long as audits show compliance there´s always "bigger problems" and "it works - so what do you want?"
In our case the winds changed over time: with the first approaches of production to upscale and automatise it became then obvious that "compliance" of documentation does not necessarily mean "kind of good documentation" - not least in terms of "every possible new question that arises in that new context is covered therein".
It was a tough time with many approaches to ignore existing (=documented) knowledge for the sake of "getting things done".
Apparently we outgrew this situation because now we handle these issues in a much more civilisied manner in proper change procedures.
And as long as audits show compliance there´s always "bigger problems" and "it works - so what do you want?"
In our case the winds changed over time: with the first approaches of production to upscale and automatise it became then obvious that "compliance" of documentation does not necessarily mean "kind of good documentation" - not least in terms of "every possible new question that arises in that new context is covered therein".
It was a tough time with many approaches to ignore existing (=documented) knowledge for the sake of "getting things done".
Apparently we outgrew this situation because now we handle these issues in a much more civilisied manner in proper change procedures.
Hi, I would like to take up this topic again as I still do not find the answers fully satisfactory.
ISO 13485:2016 subclause 7.3.2 states "During design and development planning, the organization shall document: e) the methods to ensure traceability of design and development outputs to design and development inputs"
As I understand this subclause, it would be mandatory that each and every design output (technical (mech. & el.) drawings, architecture documents, detailed design documents, ...) must be traceable to one or more design and development inputs. However, as discussed earlier in this thread, companies do not (need to) do that and still comply with ISO 13485:2016. What they do is, also as mentioned earlier, verify that the set of design outputs meets all design inputs, through verification activities (which is required in subclause "7.3.6 Design and development verification" of ISO 13485:2016).
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?
ISO 13485:2016 subclause 7.3.2 states "During design and development planning, the organization shall document: e) the methods to ensure traceability of design and development outputs to design and development inputs"
As I understand this subclause, it would be mandatory that each and every design output (technical (mech. & el.) drawings, architecture documents, detailed design documents, ...) must be traceable to one or more design and development inputs. However, as discussed earlier in this thread, companies do not (need to) do that and still comply with ISO 13485:2016. What they do is, also as mentioned earlier, verify that the set of design outputs meets all design inputs, through verification activities (which is required in subclause "7.3.6 Design and development verification" of ISO 13485:2016).
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?
Can anyone explain why 7.3.2 e) does require each and every design output to be traceable to one or more design inputs?
Traceability of design and development outputs [plural] to design and development inputs [plural] is not the same as Traceability of each and every design output to one or more design inputs.
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.
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.
Last edited:
That is correct.
No.
"Document methods to ensure traceability..." is just a fancy way of saying that you have a written procedure that requires you to make explicit (in writing) what design outputs satisfy each design input requirement. Verification activities and their results are the evidence that your claims of such satisfaction are true.
The common method is a "traceability matrix", which is just a fancy name for a table / index that lists what design outputs (or more useful - what verification activities) demonstrate that each design input requirement has been satisfied (or met, if you prefer that word).
Cool?
The simplest is a spreadsheet of few columns.
It will help if you can capture the bigger inputs and then have the next stage inputs for each, as well as any customer specific inputs. There could be several company standard inputs and its correspnding outputs all together as your organization standard that you may use if such inputs are not specific. This can also be a biproduct of your design risk assessment.
We use an XLS with something like the following:
User Requirement 1 (UR01)
The device must be comfortable to wear for 1 hour
Design Requirement 1 (DR001) to meet UR 001
The device in total must weigh less than 1 Kg.
Design Output Reference
Whatever you internally call your device
Verification Reference
A test report building several devices and weighing them
Validation reference
A test report with users wearing the device.
Relevant Standard
IEC 60601-1-6 Usability
User Requirement 1 (UR01)
The device must be comfortable to wear for 1 hour
Design Requirement 1 (DR001) to meet UR 001
The device in total must weigh less than 1 Kg.
Design Output Reference
Whatever you internally call your device
Verification Reference
A test report building several devices and weighing them
Validation reference
A test report with users wearing the device.
Relevant Standard
IEC 60601-1-6 Usability
