Design Inputs and Design Control


Hello Everyone,
I recently joined a medical device company that manufactures class IIa medical devices for North American And European Market. I am new to the regulatory world, and do not have a lot of knowledge around design regulations/requirements. Our company adopted their design in early 2000s from another parent company but after parting ways, they did not have the design documents and have been controlling any form of design change through change control. And since their conformity route was annex V under MDD, they were "exempt" from a lot of design documentation. But during their MDR TD assessment, the assessor explicitly asked for design documents and design inputs as of ISO 13485 7.3.3, and on explaining the company history, they said we should take year when we starting maintaining design documents as year 0 and start from there. Now given this scenario, I have a few questions:
1. Can we still control our design changes via change control or do we need need to fill in design input, design output documents every time?
2. And for every design change do we need to have a separate design transfer protocol/checklist?
3. For design Inputs, is it always necessary to define functional, performance, usability and safety requirements, according to intended use? Even if the design change does not affect them?

Thank you for any kind of input!


Quite Involved in Discussions
I'm surprised this hasn't come up in audits. Yes, you should have and maintain records of your design inputs, outputs and the rest of the design history file/design documentation and in alignment with shimonv, I would look for help from someone with experience created a DHF because it sounds like you need to retrospectively create one (which is not easy). Without knowing the design inputs for the product, how are you assessing the changes?
1. Once you have them, design documents need to be updated based on the scope of a change - if you're changing the supplier of a component, it might only be an update to the purchasing information, but if you're changing the intended use environment, you'll likely have to update each of your design controls documents.
2. You have to have a procedure for design transfer; this might say that (e.g.) when we change the supplier of a component, we don't do anything for design transfer because normal incoming inspection and FIFO/traceability is sufficient or it might say enhanced incoming inspection or it might say clear the line of old components and replace with new ones - it depends on the change and the manufacturing methods.
3. Yes, your design inputs for the product should include functional, performance, usability and safety requirements, but as above, they only need to be changed when they are affected by a change.

Ed Panek

QA RA Small Med Dev Company
Super Moderator
"1. Can we still control our design changes via change control or do we need to fill in design input, and design output documents every time?"

Your design Plan should indicate how the device will evolve. Once the initial release is completed and V&V done you can use the Change Control process to make further changes, however, the trace for DI DO needs to be updated with references to design changes.

Our Change Control Form has check boxes for:

  • Trace updated?
  • Design Review needed?
  • Risk memo
  • Regulatory memo
  • Data Privacy Impact
  • Training Impact
  • Inventory Impact (WIP, RMA, etc.)
  • etc
Considering any other documents you need to update.

C. Tejeda

2. And for every design change do we need to have a separate design transfer protocol/checklist?

Yes. It's like an assessment for each change.

You can have some sort of engineering change procedure where you integrate design controls and risk management.

In most companies I've work with this is part of change control procedure. However, in your case, your change control procedure may be insufficiente because it may be overlooking typical design and risk control records like: a) traceability matrixes for design and usability, b) design inputs and outputs, c) design V&V records, d) risk management file parts related to product design and usability requirements.
Top Bottom