Change Control Procedure

Do you need help in making the Flow chart ?.

Every time there is an exception you add a decision box.

Your description is very vague, You must define exactly What is a 'Large change' and what is a 'small change'. The definitions become your decision boxes.

i.e A small change does not affect the functionality of the tool.

You would have a decision box; Does the change affect the functionality of the tool?

A 'Yes' response would take the path of a large change. A 'No' response would take the path of a small change.

Your end places in 3,4 ,5, and 6 are similar so they should be on the same branch. Your decision boxes should differentiate between the three.

Example;

Is it a functional change? Yes - do IQ,

Does it affect safety? Yes- do OQ then next decision; No = done

Does the change affect more then 25% of current application? yes - do PQ then next decision. ; No = done

Is it a completely New Design? Yes - do PV then done,No = done

For your rough draft ,start with cards or yellow stickies. on a board.

For final presentation you can use excel or power-point, Visio, or any program designed to make flowcharts

Techno, thanks for your response. No, I do not require help with making the flow chart, thats the easy bit - its actually the content of the chart that I am struggling with.

I would like to attach the draft flow chart but I am unaware how to do this so please forgive me if my description of my draft flow chart does not read well.

My starting point is a decision box with "Is this a GxP system change" if No then just record the change. If Yes then the next decision box is "Does change affect sterility of product" if Yes then Complete re-validation effort. If No then the next decision box is "Product Quality Affected" if No then perhaps just carry out a simple test script. If Yes then is the change a HW, SW, HW&SW, Labelling, DMR, Process, Process Flow etc type of change. It is at this point that I am struggling.

Defining what is a "Small Change" and what is a "Large Change" is difficult - a small engineering change could be considered by QA to be a huge change and vica versa. I may/will change my approach from what I was thinking and base it on the risk posed by the proposed change and not the physical change itself - however I still think I will be asked for guidance on what to do. If I could take one change at a time then I would be able to give guidance but to give guidance on future (and unknown) changes is proving difficult. I do not want the situation whereby high risk changes are brought in without giving them due care and attention.

If I could assign a "risk number" (perhaps based on ISO 14971) to each change then I could use this to decide on what should be performed - what do you think of that approach ?

Thanks again for your response it has helped me look at this problem in a slightly different way.

Kind Regards

Mr. W.A Snow

"If I could assign a "risk number" (perhaps based on ISO 14971) to each change then I could use this to decide on what should be performed - what do you think of that approach ?"

Using a standard is a good idea. For the average worker, a number is subjective. You must define, or state in plain language the tests or decisions that arrive at the risk level. Basically everyone does not have time to read your book or the details of every standard. They want a summary. If the test does not stand up for every occasion, it is either too vague (and unusable), not detailed enough, or you have not found the critical decision points.

The other respondents have a good Idea with the form. If you simply add the instructions on the form it will make it clear and usable. i.e beside a yes check box, put requires a validation.

On another note, the most important and least done in change management, is the history. You will find that a chronological history, of each device, that is accessible by everyone will minimize circular and repetitive changes that don't work. Everyone assumes that every change improves a product (so why look back). Stick around long enough and you will see the same mistake happen over and over again.

This sounds like a huge waste of time, generated by someone trying to save money or cut corners.

You probably already have a change procedure...use it.

Any change should incur full re-validation, or a report explanig/justifying why this is not neecessary signed and agreed by the relevant signatories.

There is no other way around it, else you will get any buffoon saying.'Oh well it's a minor software change we don't need to re-test'

Whereas we all know it's the irrelevant minor changes that invariable screw things up.

Tell whoever asked you to do this that he is an arse.

( I reserve the right to get pilloried on this)

Del

Del the Cat, thanks for your response.

You reserved the right to get pilloried on this so here we go:

I take it that you are unfamiliar with the regulations governing the Pharmaceutical and Medical Device industries. What is being asked of me is what the FDA would consider to be "the least burdensome approach".

There is no logical reason to carry out a full validation for all changes. Perhaps I could point you in the direction of "GAMP 5 A Risk Based Approach to Compliant GxP Computerized Systems", there are also many other relevant document in this field.

You are incorrect in saying that the irrelevant changes are the ones that screw things up - what screws things up is when changes are not given appropriate scrutiny and appropriate testing is not perfomed - note the scrutiny and testing bit.

You seem to believe that you either perform a full re-validation or else nothing - well this is just "arse" (to quote your good self).

Kind Regards

Mr. W.A Snow

I have designed medical devicices and gained full FDA approval on one of them.

I suggest you re-read my post more carefully as I do NOT suggest a full validation on all changes...

I say the lack of full validation must be justified.

what screws things up is when changes are not given appropriate scrutiny and appropriate testing is not perfomed - note the scrutiny and testing bit.

Exactly..and when does this happen? ...when someone considers the change minor or irrelevant.

Del

Del the Cat, before this gets into a "I'm right, your wrong" type of thread I would like to draw your attention to the following:-

One of they biggest inhibitors to change within the medical device and pharmaceutical industries is the level of non-value added paper work that is forced upon companies by those who have a vested interested in doing so (or by those who believe that the bigger the validation folder then the better the validation effort). This is not my view, I believe in focusing attention on the critical areas and less on those areas that are not so critical. Note I said less. Not all paperwork activities are non-value added.

The change control procedure should have the ability to cater for all types of changes (from building a new sterile facility, to changing an SOP etc) and whether you carry out a full validation or not - there should be no necessity to generate reports signed off by the world and her mother to justify why a full validation was not performed. The majority of changes carried out by our company (and perhaps other companies) would be considered minor in nature (from an engineering and financial point of view)

If you have worked in this industry then you will know what I mean.

If we do not try and push the boundaries and we let ourselves be dictated too by those in QA etc then we, as an engineering group, have failed our companies.

These are just my opionins on this matter and I respect yours - this does not mean that I agree with them 100%

Kind Regards

Mr. W.A. Snow

Just an Engineer, thanks for your reply. Actually what you explain is exactly what we have in place (perhaps not to the same level of maturity) - our change control also happens to be two A4 pages long and it also has the questions/ prompts that you refer too -anything longer and it becomes a pain to fill out.

What the requestors/orginators (and this maybe due to experience or lack thereof) are requesting is an additional document that will give them an indication/guidance on what level of testing/validation woud be required for their proposed change - this guidance document would give them an indication of the resources required to execute the change.

I only suggested the flow chart idea but it would not necessarily have to be a flow chart. Hopefully you will see what is being requested.

Again thank you for your considered response.

Kind Regards

Mr W.A. Snow

We too have a 2 part proposal/change much as you describe but it has only been in place for a year or so & we are still having to persuade people to use it properly. I would love to see your 30 point check list.

Does anyone use a 2 tier system that has a simple change procedure during product development & a more formal system one once a design is finalised? I've been considering the introduction of such a system recently to track design changes. I feel it is necessary because we often work on projects with other organisations contributing to the design process.

Nice...

Too often systems can just be a 'going through the motions' exercise, yours sounds good.

Where I am it's pretty much down to me, and if I try and action anyone else the response is usually tumbleweed rolling silently across the shop floor.

I can't even get anyone else to do testing..and testing your own stuff is a recipe for missing stuff.

This thread seems to be opening up some good issues.

Del (I promise to play nicely)

Although this is probably off subject, it's an area that often causes huge difficulties.

Why has a change been made?

If the Form Fit OR Function has not been changed then the Build Level has not changed.

Changes which are required because of say component (or package) obsolescence, do not need to be made to existing product, but confirming that the new design has exactly the same functionality as the old one may still require a lot of testing.

So: before ascertaining how much testing to do: you need to work out the extent to which you are just testing new functionality, and, the extent to which you are testing that no existing functionality has been compromised.

Thanks all for the positive feedback. I was worried that the note was getting alittle long and did abbreviate it somewhat. It seems that "more info req'd" is happening so please read on.

ALL changes in our organisation are "originated" by staff who understand the relevant stages of new product/project launch and so are familiar with the expectations of the system and the customers.

How this happens is that any idea/suggestion from outside that group is allocated a "sponsor" (usually from Quality Assurance) who will assist the transition from an idea into a true request for change.

In Engineering (and I would also hope medical) it would be a utopian ideal to believe that someone without appropriate skills could be placed into a position of responsibility beyond their scope. That is why I use the word "sponsor" for the engineer appointed to the initial request phase.

We use this system to control changes to operational works instruction, routings, assembly sequences, new projects, equipment purchases and so on.

I'm on holidays for a couple of days, but when I get back, I'll post something like our checklist. It originated as a list of the steps that a new product launch goes through (as that seems to be our most complex task). and then added a few others that came up in international issues. There are some jargon terms in it that may be unfamiliar to general observers. Do the terms FMEA, DFMA PCP make sense or should I explain them when I put out the document?

The main thing is that the system ensures appropriate skill to prepare the request, appropriate management review and authority for changes.

FMEA & DFMA I know but PCP?

Your system sounds just like the one we have implemented, I look forward to seeing your next post, have a good break.

Randall,

Changes occur in our company for numerous reasons, operators noticing that something can be done better, sublte changes in product make up, changes due to parts/ components becoming obselete, new products being introduced etc. The people who come up with the ideas may not know how to execute all the relevant steps in order to make the change happen, therefore they rely on the expertise of other groups within our organisation: engineering, production, QA, Regulatory Compliance etc

Our facility (probably like every other medical device and pharmaceutical facility) operates as described by Just an Engineer.

What has happenned in our facility is that people go throught the change control process and nearing the end they then find out that it requires a full re-validation (and the costs and headache associated with this) - this is probably a failing in the change control process. In some cases it is does not make business sense to make the change (say due to a back log in orders etc). It may be easier to live with an issue rather than to take the equipment out of production to make the change and validate.

Had they known or had an idea what was required from a validation viewpoint then perhaps they could adjust the change to cater for this or be prepared for the validation effort. This is the reason that they would like guidance on this.

It may not be possible to do what I have been asked but I am sure I will learn alot in the process - I have already learned somethings from this thread.

Kind Regards

Mr W.A Snow

"I know you think you understood what I meant to say, but, I don't think you realise that what I said is not what I meant."

When I said "Why has a change been made?": I wasn't really asking the question I was suggesting that it's one of the questions that needs to be asked in order to assess the level of testing.

Hi,

I have also introduced a Change Management System in my project team (aerospace business) some years ago. When a change request was generated, this was done on a change request form sheet (sorry, software support was not so good at that times ;-)). The request sheet contained a number of standard questions which had to answered, or the appropriate check box had to be checked before the change request was further processed. One of the topics was: Effects of the requested change: certification (in your case I guess it would be validation), delivery time, cost, price, interfaces, ...

This means that the person requesting the change had at least to investigate the potential effects. When approving / rejecting the change request, the relevant information - or at least an early "warning" that such vital issues could be affected -was already available and could be taken into account during the decision process.

In the case that the information on the change request was too poor, the Change Control Board could return the request to the author asking for more detailed information as e.g. a quantification of the expected overall cost for a re-certification.

Of course, no engineering work on a change request could be started without an approved change request! I know, it appears a little bit bureaucratic, but it worked well.

Hope this will help you!

nudnik

Why dont you refer to modern management tech. many software for select, like erpII, project etc.

there are many models for reference.

you are difficult to select a threshold value in the practise. in engineering we use Normal filter.

I'm back on line. Following are some of the items on our checklist. It really runs to 40 lines where each item has answer options of yes, no or not applicable.

This originated as a new product launch checklist, then it was realised that any change was equivalent to a new launch, just that we already may have a very close clone that we are producing.

I'll explain the process in detail for one line, then let you imagine how the others work.

Obviously there is a heading line linking part number, description and some other detail.

First item listed "Design FMEA reviewed". Changing the sell price has no impact on design, so "Not applicable" could be a valid answer to this question, changing a photograph in a process instruction to operators has not impact on the design, so "no" could be a valid answer, but any change to design will mean that the Design FMEA needs to be reviewed to determine whether the DFMEA already deals with issues the change could cause. There will be occasions where a DFMEA will not need to be altered and so the word "reviewed" is used for this question. If the answer is "yes" then the originator is required to note the FMEA number and it's location. (This provides evidence that they are capable of reviewing the document and enables management to review it during their decision process if they wish.)

The next question is "DFMEA revised". Again, the answer could be not applicable, no or yes. If the answar is yes, then the originator records the revision date relevant for this request. Management now have available the FMEA number and location from question 1 and the revision history specific to this change from question 2.

The documents ARE NOT attached as evidence, since management expect (require) us to perform our duties correctly.

There are then similar questions about PFMEA.

We also have similar questions about tooling FMEA (Something that we do that may not be in the normal books out there in the world.)

Similar for CAD models, drawings and design control documents. If yes, then attach relevant forms and hand marked drawings/sketches.

PCP's is a jargon that we use. Basically it's a manufacturing flow chart, broken into finite steps (usually representing a single operator task) that defines the steps the operator performs, the tools that they use and the care points for them to check. It also include the "control" points for the quality system. (PCP = Process Control Plan, or "how we intend to control the process".) There are variations of this that are used as our on line instructions.

Routings and BOMs come next.

Internal packaging and material handling considerations.

External packaging and material handling considerations.

Consideration of the need for customer authorisation and "breakpoint" notification when the change is implemented. (We've actually had one change many years ago that would have saved 25% of product cost rejected by the customer because the packaging would not fit their warehouse layout.)

Is a detailed timing plan required. If yes, then attach it.

Tooling modifications.

On line jigs and fixtures.

Do we need to run a verification build?

Test validation requirements. If not applicable or no, then attach justification as to why NOT, otherwise attach the test plan.

Customer submission (for approval) required?

Service and spare parts considerations.

Stock control issues. (Do you use up existing stock or do you expedite the change and dump the stock or negotiate a common changeover with the customer, or can stock be reworked/modifed into the new condition?)

Costing criteria broken down to material, labour and overheads and scrap. (Each with yes/no or N/A answer.) (Done as a piece price value and then calculated per annual budget volume.)

Once this "request" is completed, management can then review it and understand the consequences of authorising the change including tooling costs, sell price, scrap, testing and some understanding of the support needed from other departments included in the timing plan.

It's good, but still not bulletproof. People do occasionally take shortcuts and promise to "follow up with the paperwork later" (usually management) and its mostly those occasions that create uncomfortable outcomes because only portions of the process were considered.

Sorry to be so long, but some indicated a desire to see a more complete listing and without compromising IP requirements this is what I can send.

Thanks for the comprehensive post, it's useful to compare how we do things to the methods other people use. We seem to be using basically the same procedure which gives me some confidence that we have got it right. Our process is a little simpler because we make a low volume product, nobody buys it for stock, our products range from a few £1000s each to £¼million each so they tend to be used straight away. On the other hand, we often have customers deeply involved in the design process so we have to control that end closely.

From your description of the items that you handle, it's more important to "get it right" since the cost of the "research" is low compared to the unit cost.

Our challenge (almost always) is to justify the time and effort spent "getting it right" for product that sells in the $5 region.

By the way, our finished goods stock holding (including freight in transit) is around 7 days. (Including material that we sell into North America and Europe.) Typical volume is around 200 units per day across a few hundred product lines.

Our customers are HEAVILY involved in the design and development as they bear the brunt of end user warranty and complaints. Our product is also some of the "in your face" styling material for their end product, so they want to be involved.

Just an Engineer, May I ask if you are involved in the medical device/ pharmaceutical sector.

Kind Regards

Mr W.A Snow

Yes, we certainly need to get it right, especially as a lot of our sales are custom made 'one-offs'.

We also get involved in some interesting design where nobody knows if it will work or how good it will be, there's always a bit of a thrill in those.

There is a matrix that you can build based on criticality and complexity of the system from which you can then "determine" the type and depth of testing and validation needed, UAT, IQ, OQ, PQ. The bigger issues are in consistant application of the approach and approval by QA of the methods.

I developed this many times before (over 400 systems) and it is the standard approach used in the pharma bio company that I worked for.

If you want to discuss further you can reach me at pwheeler@integrity.us.com

Regards,

Patrick

Push the envelope so that you don't get dictated to by QA, sounds like a passport to hell. 30 years in Medical Devices here, and a good part of that in companies after having been recruited to help them get out of trouble with FDA. Del is right, justify why a validation isn't necessary, if you have good people, who think things through- this is fairly easy task- if they can't justify why a reval isn't necessary then they don't know enough about the device or the change-- oh and while you're so afraid that the QA people will be unreasonable just remember all 483 observations start with...

the quality system is inadequate in that-

its never R&D's fault

its never productions fault

its never mfg. engineerings fault

its always the fault of the QUALITY SYSTEM