SBS - The best value in QMS software

Design/Change Control Procedure - How to cope with Changes during Development?

Aphel

Involved In Discussions
#1
hello everybody,

Meanwhile i have read a lot about the requirements regarding change control, but it is difficult to find a practical way for realising them.
According to QSIT the change control procedure or procedures must meet "pre-production design changes" and "post-production design changes".
So the first requirement means design changes during the development of a medical device, the second requirement means design changes after the development has finished and the product is launched to the market.

We established a change control procedure for post-production changes, but not for changes during the development. Management is of the opinion, during the development of a product we have to stay "flexible" without strong rules for changes... At the moment i have no idea, how i can create a simple and effective, but also correct procedure for that issue.

What are your experiences with changes during development, how do you cope with the daily problems? How do you meet this requirement of §820.20?

Thank you very much for your help and your answeres!

best regards,
Aphel
 
Elsmar Forum Sponsor

harry

Super Moderator
#2
Re: design change control procedure

Welcome to the Cove.

Pending replies, please scroll down the page to see discussions on the same in the 'similar discussions' box.
 
T

The Specialist

#3
A method of control which provides ‘flexibility’ is:

During product development phase, simply provide a ‘change history’ that can be noted on (e.g.) drawings/documents etc. as an interim to full revision e.g.:

(THIS IS ONLY AN EXAMPLE!)

‘Draft’ product drawing is hand-marked and notes added to reference each change

Revision A of the drawing is produced at a time that major product design decisions have been made (milestone). This drawing can continue to be ‘marked-up’ in the same manner as the draft, using a 'change history' table/section on the drawing

Revision B (c, d etc…) can be produced to incorporate marked-up changes as they are agreed and determined (successful through review etc)

Revision 1 is produced at a point in time when you initiate a ‘Design Freeze’

At this point… start to control the drawing (or document) using change control process (where minimal/less frequent changes are likely to occur) and up-rev to ‘Revision 2’ when changes have been made.

Alternatively, if major reviews and re-design is required (for whatever reason as detailed in the change control) you can revert to ‘draft/history control’ method introducing:

Revision 1a, 1b, 1c… etc until you are ready to re-freeze design at Rev 2, where you would again make changes through the change control process.
 
#4
Thanks Specialist, that re-confirms our approach as well.

As Aphel suggests trying to control designers is like trying to herd cats!

I think that the key thing in all controlled development is that of traceability. That is being able to show how a requirement that is shown in the original specification is tracked through development to the eventual verification.

We have key documents, such as the product specification, device hazard analysis, software requirements spec etc that each have a "Document History" box at the end which is used to show the difference between each revision and eventual issue. It is relatively painless.
 

somashekar

Staff member
Super Moderator
#5
Thanks Specialist, that re-confirms our approach as well.

As Aphel suggests trying to control designers is like trying to herd cats!

I think that the key thing in all controlled development is that of traceability. That is being able to show how a requirement that is shown in the original specification is tracked through development to the eventual verification.

We have key documents, such as the product specification, device hazard analysis, software requirements spec etc that each have a "Document History" box at the end which is used to show the difference between each revision and eventual issue. It is relatively painless.
Without stopping the innovative and the curious research kid from his applications, you have to look at the design review stages and put a freeze level in your (draft) provisional documentation say P1 and continue with this steps from P1 to P2 >> P3 >> Px until release and get that to say level 00. From then on it becomes your ECN process that takes it to levels 01 >> 02 >> xx
Each freeze level can have a minutes of meeting of design and development review.
All the Px's will constitute your design history.
 

yodon

Staff member
Super Moderator
#6
I like to look at the problem from the perspective of impact. If you have a downstream stakeholder (e.g., internal 'customer') that is making decisions and taking direction based on what you provide them, then if you don't control those changes, you're going to pull the rug out from under them. If you have no downstream stakeholders or if they aren't making decisions based on your material, then you can defer the change control process.

I like to take a software example to illustrate the point. Say you have 2 groups working on independent portions of the software and they have a communication interface. They're free to change all they want within their independent code areas but if they need to change the interface, they need to do so in a controlled manner to ensure the other group can continue to communicate with them. The interface has to be controlled at an earlier stage than the independent software portions.
 

sagai

Quite Involved in Discussions
#7
Very much agree with somashekar.
In a very very extreme case, you can have only one revision at the time of the one and only design review just prior design transfer to manufacturing.
So, it is depends on you, how to specify milestones and design review points.
br
Sz.
 

Aphel

Involved In Discussions
#8
Hello everybody,

Thank you for all the answeres and guesses...

The problem i have, is not to control changes in single documents (e.g. drawings), therefor we have a nice procedure (document controls).

But what are your solutions (procedures) if you have for example the following change during development:

Imagine, you just went through the milestone design freeze, you have already startet design verification. And now - during design verification you realise, that you are not able to pass a certain requirement and you are forced to make a change to a functional design input requirement.

What are your design change procedures saying in such cases?
How do you organise, manage and document such necessary changes?


Best regards,
Aphel
 

sagai

Quite Involved in Discussions
#9
Imagine, you just went through the milestone design freeze, you have already startet design verification.
Fine.

And now - during design verification you realise, that you are not able to pass a certain requirement and you are forced to make a change to a functional design input requirement.
When "you are not able to pass a certain requirement" means there is a missing implementation of the already existing requirement. It is a "normal case", there is no problem with that, this deviation logged and as part of the resolution of this problem it will we implemented, than re verified.


I have an interpretation problem with this:
"not able to pass a certain requirement and you are forced to make a change to a functional design input requirement"

Is it means, instead of implement the requirement, you are about to remove the corresponding functional design requirement?

Actually, for me would be good to understand to relation between "requirement" and "functional design input requirement".

br
Sz.
 

Aphel

Involved In Discussions
#10
Hello,

o.k., i will try to explain it another way.

During design verification you are doing a lot of tests.
Sometimes you have situations, when a test fails for example due to
incorrrect product design. Then you must change the product design to
pass the test.
Or during design validation you have a problem that shows, you are not able meet certain customer requirements. This problem also may lead to a design change, so that you are conform to customer requirements.
I was talking about these kind of design changes.

Are my guesses too theoratically - then i will try bring up an example...

Again, thank you very much for your help...

Best regards,
Aphel
 
Thread starter Similar threads Forum Replies Date
A UDI and Design Controls - Labeling change via the Design Control process 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 1
D Design/Change Control Form Example and Advice Design and Development of Products and Processes 13
T Design and Development: 7.1.4 - Change Control - What is a good change control system Design and Development of Products and Processes 7
J Significant change related to design and intended use EU Medical Device Regulations 3
U NOC - What is considered a "design change" EU Medical Device Regulations 5
S Requirement to Conduct New Shelf-life Testing? (re-do testing for design change) EU Medical Device Regulations 3
S MDR Delay - MDD design Change? (before new MDR DOA) EU Medical Device Regulations 8
H New 510K VS Documents about design change. Other US Medical Device Regulations 1
R Explain what "design change" is to people new to the industry ISO 13485:2016 - Medical Device Quality Management Systems 9
T Closing out CAR while waiting for design change Nonconformance and Corrective Action 12
L Managing design projects: New Medical Device Project or Change Design and Development of Products and Processes 1
T How to Document Risk Effects on Design Change(s) ISO 14971 - Medical Device Risk Management 3
I Another design change or new product? IVD device ISO 13485:2016 - Medical Device Quality Management Systems 6
S Engineering change order versus a design change request ISO 13485:2016 - Medical Device Quality Management Systems 1
Q PPAP - How to determine the "Design Record Change Level" APQP and PPAP 2
S Verification and Validation of Post Market Design Change Design and Development of Products and Processes 2
A Reporting of Design Changes (Color Change Only) EU Medical Device Regulations 5
Q 510K Checklist that considers every Design Change 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 8
A Medical Device DHF (Design History File) - One per Design Change? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 17
V Product Evaluation Requirements for Change in Manufacturing Facility/Change in Design 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 12
S Design Change vs. Intellectual Property Design and Development of Products and Processes 9
J What should be included in the Design Change Document 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
S External or Internal Design Change and Responsibilities Document Control Systems, Procedures, Forms and Templates 3
C Design Change needed for Changing an Angle in existing Product from 15-25 degrees? ISO 13485:2016 - Medical Device Quality Management Systems 11
S Design Change Drawing Reviews and Customer Approval Process Document Control Systems, Procedures, Forms and Templates 5
A Design Review OR Design Change - Software development company ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
R Procedure for "Customer Acceptance of a design or process change" Design and Development of Products and Processes 12
B Severity Reduction by Product or Process Design Change? Seeking Good Example Design and Development of Products and Processes 2
S FMEA Severity Rating - Will a Process Design Change also Change the Severity Rating? FMEA and Control Plans 21
L Outsourced Design with Internal Design Change Design and Development of Products and Processes 2
J When does an engineering change become a design change? Design and Development of Products and Processes 7
A Engineering change validation - Companies that have no design responsibility Design and Development of Products and Processes 5
R Is design change applicable (7.3.7)? Design and Development of Products and Processes 2
M Reducing both Detection and Occurance in a Design FMEA WITHOUT a Design Change FMEA and Control Plans 8
N What are the VDA requirements for Design change? VDA Standards - Germany's Automotive Standards 2
K FMEA - Reduce Occurance of a Failure (or its cause) by Design Change FMEA and Control Plans 6
N Example for design and development planning,input,output,review,verification,validation and transfer Misc. Quality Assurance and Business Systems Related Topics 4
A 8.6 Release of products and services, 8.3 Design and development - evidence required ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 9
C Stress / Challenge Conditions for Design Verification Testing to Reduce Sample Size 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 11
S Traceability of requirements to design and risk Design and Development of Products and Processes 3
Q PPT used as Design Review ISO 13485:2016 - Medical Device Quality Management Systems 3
D Design Verification Sample Size vs Repeats Statistical Analysis Tools, Techniques and SPC 9
A Design and development procedure for API Spec Q2 Oil and Gas Industry Standards and Regulations 6
D Design controls - Inputs, outputs, V&V, DHF, DMR ISO 13485:2016 - Medical Device Quality Management Systems 10
LostLouie Manufacturer divorced from Design process, is he justified in design process deficiencies? ISO 13485:2016 - Medical Device Quality Management Systems 9
R DFA & DFM - Examples for Design for assembly and design for manufacturability Lean in Manufacturing and Service Industries 2
D Using Laboratory Notebooks in R&D and Design and Development ISO 13485:2016 - Medical Device Quality Management Systems 3
D ISO 13485 - 7.3.6 Design and development verification - Do most folks create a separate SOP? ISO 13485:2016 - Medical Device Quality Management Systems 4
K Joint approval between OEM and Manufacturer on Design Documents ISO 13485:2016 - Medical Device Quality Management Systems 4
M API 4F/7K/8C Design Package Validation Oil and Gas Industry Standards and Regulations 2

Similar threads

Top Bottom