Change Control - Minimum Requirements and Unhappy Staff

JoshuaFroud

Involved In Discussions
#1
Good Morning

I'm currently in the middle of a very difficult situation I would greatly appreciate some guidance on.

I work for a small but growing Medical Device company, we hold both 9001 and 13485 certifications. I started here December last year and have been updating their quality systems since.

The situation I am currently in is as follows;
About 3 years ago the company implemented a very low-level electronic document management system. At this time they re-wrote the change request procedure to exclude all Quality Documentation held within it, stating that the software handled this. The software allows any management level user to edit a document without prior request and only requires approval. There is a way to request a change but it can only go to the document owner. This, however, is not used. I did not agree with this but let it lie until I had cause to edit the document.

I was re-writing the change request procedure recently for a different unrelated reason and at this time amended the procedure to require the Change Request form be used for change approval for the Quality documents. Once the change was approved the form is filed and the electronic workflow takes over. This was approved and has gone live.

The problem I have encountered is one fairly senior member of staff is outright refusing to comply with the procedure saying it is a huge step backwards and has asked to be written out of the quality system as they are unwilling to follow the new procedure.

I have spoken to senior management about this and was told along the lines of "you need to work it out with them, if not we can discuss this further at management review and Top Management will make a ruling". Being the Senior Quality Representative for the organisation it has somewhat grated that my point of view may be overruled by length of service.

I would greatly appreciate is some guidance and references to applicable standards to back the procedure I have written (or someone on here with great knowledge than myself telling me I'm wrong). I'd be happy with either.
 

Candi1024

Involved In Discussions
#3
We never used change requests. Granted, it may have been nice to have. They are a really good way to assist someone in making changes when they do not control the document. It provides for a way to track requested changes, and document if the changes were completed along with a reasoning.

However, as long as the document is being approved by the appropriate roles, it doesn't matter who makes the changes. And as long as the changes are tracked and documented in something like a revision log, I don't see why a change request would be required by any standards.
 

JoshuaFroud

Involved In Discussions
#4
As it stands, the reason for the form is the procedure states there must be one.

This was implemented to address the requirement for change management and allow for pre-change authorisation rather than what the electronic system allows. Which is for any changes to be made and approved after the change has been made (prior to implementation). There is nothing stopping someone from spending many hours updating documentation which is instantly rejected upon submission for approval.

It is not so much about the form itself but about pre-change approval. I'm indifferent as to the actual format this takes, be it, paper form or otherwise. My thoughts were that it is better to have pre-change authorisation in addition to post change approval. For what is 5 minutes work to raise the paperwork to potentially save hours of time rolling back a rejected change.
 
#5
I would tell my next auditor who comes in, or simply direct them to the change control you know is not completed correctly, that way it is not you who is trying to change things but your Notified Body or a customer.

Or you could raise a non-conformity at internal audit.

Either works
 

pbojsen

Involved In Discussions
#6
If I understand this correctly, a senior person wants what he does in the QMS to be excluded on a personal basis? Is this correct? If so, he is likely miffed that he wasn't consulted on the change to the system, at least that's been my experience with these types of coworkers. If he's a senior person, maybe you start with that. Unfortunately, one has to appeal to various personalities and egos, especially if you're doing something they're not aligned to, even if you're correct. You have to bring them along. I wouldn't make this a you-know-what match. If you lose, your authority / support goes out the window. Sit down and find out his concerns, and see if you can work with it. Maybe you can, maybe you can't. If not, do you really want to continue to work there? I know you didn't ask for advice on this, but there you are.

Otherwise, if it's a QMS document, ISO 3485:2016 clause 4.2.4 pretty much dictates that documents have to be reviewed and approved for adequacy prior to use. If he's excluded, then who is going to either review or approve his changes for the above? Someone has to approve the change, he just can't willy-nilly change QMS documents. Audit findings galore, and possible revocation of any certifications may follow. We've mandated change requests in the past because many time people want to make changes that the process owner did not approve. It wastes time. However, the way we did it was that the process/document owner had to give permission for the document to be checked out for changes. That way, changes could be discussed beforehand.

I may be misunderstanding the situation. If so, apologies!
 

mihzago

Quite Involved in Discussions
#7
I actually agree with the senior QMS person, who eliminated unnecessary bureaucracy, and second what Candi1024 said.

The ISO or QSR require that documentation is reviewed and approved prior to use (which the software apparently does), but there is no requirement to per-approve someone's intention to begin making the changes.


Change requests for documentation may have their place in large organizations or ones with multiple dedicated functions (e.g. design QA, supplier QA, manufacturing QA, RA, engineering, etc.) where each of these functions must weigh in on a changed document to make sure all aspects and impacts are adequately assessed.

However, in a small organization, you rarely have more than a handful of people who communicate with each other (or at least they should) and are aware of the changes being made, and so a simple review and approval of the document is typically sufficient.


Tip: Use the change history field of the document to describe the reason for the changes, any impact on other documents, any applicable reviews or validation, and training.
 

Candi1024

Involved In Discussions
#8
I would greatly appreciate is some guidance and references to applicable standards to back the procedure I have written (or someone on here with great knowledge than myself telling me I'm wrong). I'd be happy with either.
Maybe I'm misunderstanding the question. Based on what I have quoted above, you are looking for standards that require some sort of pre-change approval.

Is this correct?
 
Last edited:
#9
As others have pointed out there is no explicit ISO requirement mandating a "change request".

That being said, there may still be value in doing so within your organization, and it is ultimately an internal decision to make.

For us, we use the term "change plan" instead. Because there are certain changes that affect multiple documents (not to mention processes, products, etc.), for us it is important that a plan be made detailing impact assessment, all items affected, and estimate of resources involved. These are the minimal information management needs to approve a change prior to committing the resources. As such we've determined that there is indeed value to including this step as part of the process.

...About 3 years ago the company implemented a very low-level electronic document management system. At this time they re-wrote the change request procedure to exclude all Quality Documentation held within it, stating that the software handled this....
I'd suggest the procedure should define your general requirements regardless the solution you adopt (software, or otherwise). For example, if you DO want to include a "change request" as part of your process, you might say:

- A change request shall be issued for all changes
- Change requests shall document:
--- Name of person requesting change/responsible party
--- Date of request
--- Description of change and reason for change
- Change requests shall be approved prior to commencing change activities

Does the software meet these requirements? If so great! Does a paper form do the same job? Good too! ...you have options... and no need to complicate things by excluding certain types of documents, or making exceptions...
 
Last edited:
#10
Take off your quality hat and put your business hat on. Does the change request in general make things easier and more efficient? Do you need it because one time something got rejected at approval -- while the 99 other time, no problem (don't manage the remote exceptions). Come up with the business reason for the change request, you'll get more favorable treatment. Good luck.
 


Top Bottom