Document Change Log

Quality_Goblin

Involved In Discussions
Hi All,

It was recently suggested that we create/keep a log for our document change requests. Currently we just have a change request form that gets filled out and reviewed by me (Doc Control) and the Chief Quality Officer. Then I save the change request form in a folder.

It was suggested in order to keep things a bit tidier, that in addition to the Change Request Form (which can be used to change multiple docs at once), that we include a Document Change Number (DCN) with the changes so it can be better identified and save the record by its DCN. And then have a log referencing all the changes per DCN. We like this idea, so I am wondering who else uses a log to record your document changes and what columns do you include on your log? So far I have the following:

Document Change Number
Documents that are changed
Change Description
Reviewed By
Approved By
Approved Date
Release Date.

Is there anything else I should add? I figure if anyone wants more info, they can actually pull up the document.
 

Kronos147

Trusted Information Resource
While I am a big fan of a centralized log, my first impression is that you have an opportunity to simplify. Some questions you may ask are:

Can the log replace the document (DCN)?

Does the change need a number?

Is there a need for the approval AND the release date?

I do like how you are thinking of related documents. If one change (document or log entry) can apply to many documents, that is slick. The reason for the change is the one that so many skip, and then must compare documents to determine the reason for or the change itself.
 

Nichole F

Involved In Discussions
This type of log can be super simple if you are just looking for basic DCR information. A more robust log can provide an opportunity for data analysis that can help streamline your processes. DCR number, date initiated, document number, current doc. rev., new doc. rev., change description, doc. type (e.g.. drawing, form, SOP, etc.). approval date, effective date, DCR status (open, closed, on hold, cancelled) and a number of days open field are what I have seen previously used. Some of these fields you can set up with formulas to minimize data entry.

A simple Pivot Table allows you to see which DCR types were taking the longest to process and provides an opportunity to streamline the process. It also shows if there is a trend of cancelled DCRs. This would be an opportunity to work with the initiators to plan their projects in a manner that did not create extra work. The DCR log can also be used to keep track of the DCR numbers. Whatever is next on the log is the next number.
 

Chrisx

Quite Involved in Discussions
Generally, an eQMS makes a log unnecessary. For small organizations this may not be financially feasible. At a certain point, the advantages of having a document management system outweigh the costs. Things like electronic approval and distribution, approval status visibility and various other features may be worth considering at some point, instead of creating a log that someone has to maintain.
 

Quality_Goblin

Involved In Discussions
Generally, an eQMS makes a log unnecessary. For small organizations this may not be financially feasible. At a certain point, the advantages of having a document management system outweigh the costs. Things like electronic approval and distribution, approval status visibility and various other features may be worth considering at some point, instead of creating a log that someone has to maintain.
I would loooove to work with an eQMS or something like Master Control. However, my company is rather small and like you said, it isn't financially feasible. Maybe someday!!
 

Quality_Goblin

Involved In Discussions
This type of log can be super simple if you are just looking for basic DCR information. A more robust log can provide an opportunity for data analysis that can help streamline your processes. DCR number, date initiated, document number, current doc. rev., new doc. rev., change description, doc. type (e.g.. drawing, form, SOP, etc.). approval date, effective date, DCR status (open, closed, on hold, cancelled) and a number of days open field are what I have seen previously used. Some of these fields you can set up with formulas to minimize data entry.

A simple Pivot Table allows you to see which DCR types were taking the longest to process and provides an opportunity to streamline the process. It also shows if there is a trend of cancelled DCRs. This would be an opportunity to work with the initiators to plan their projects in a manner that did not create extra work. The DCR log can also be used to keep track of the DCR numbers. Whatever is next on the log is the next number.
Yes! I am thinking of keeping it simple - something to look at for basic information and then if the viewer or auditor wants more information, they can pull up that actual DCR document. For now this will be just for processes (SOPs) and documents. Other changes - such as to drawings or routers usually get changed in real time and we don't use a change request form.
 

Tidge

Trusted Information Resource
Yes! I am thinking of keeping it simple - something to look at for basic information and then if the viewer or auditor wants more information, they can pull up that actual DCR document. For now this will be just for processes (SOPs) and documents. Other changes - such as to drawings or routers usually get changed in real time and we don't use a change request form.

I think you identified the key reason for maintaining a log: the log should be the first place people look to understand a change (to a print, a process, whatever). Change logs are convenient for auditors, because auditors tend to use pareto/histogram-thinking. Change logs are convenient for internal users for understanding.
 

Quality_Goblin

Involved In Discussions
I think you identified the key reason for maintaining a log: the log should be the first place people look to understand a change (to a print, a process, whatever). Change logs are convenient for auditors, because auditors tend to use pareto/histogram-thinking. Change logs are convenient for internal users for understanding.
Thank you for your insight Tidge. That was helpful.
 

FRA 2 FDA

Involved In Discussions
I use a log and have found it very helpful for referring back to in investigating past doc changes and for tracking metrics, as @Nichole F mentioned. Mine is quite simple, including only the information I find useful.
DCN NumberDocuments CoveredStatusDate InitiatedInitiatorDate of Release
 
Top Bottom