Revision History - How Specific?

[Marla Diaz]

How specific should a reason for a revision in a procedure or work instructions manual be?
Is a handwritten revision history acceptable? What I do is type it, print and distribute to copyholders. If the last page if half-filled, then I retrieve all old copies and issue that same page with new reasons for revisions. Is this much better?
What do others write in the revision history?
SUbject/section, reason, effectivity date & approving authority. Did I miss anything?

Thanks,
Marla Diaz

 

[Kevin Mader]

Marla,

It sounds to me that you have chosen to place revisional change history directly into your documents. That is fine. The description of the change should be as specific as it needs to be. For instance: if you go back to a document in a year's time, will you have trouble figuring out why you revised the document? You shouldn't.

Hand written changes are also acceptable provided that they are identical in all distributed copies and are legible. Neatness counts here and for all quality records.

Your revision history categories are fine.

As far as what others include in revision history I can't say.

As a personal preference, I choose not to include revisional history directly in the document. Instead, I use a database system to document all the changes I make. I do this for a number of reasons. The two biggest are: presentation and unlimited revisional history space. I try to keep my procedures from becoming too busy and lengthy. This can happen if you tag three years of changes onto the end. Using the database provides me with the space necessary to write a detailed explanation of the change. This way I don't short change myself by trying to keep revisional change history to a line or two if four are necessary. I hope this helps a bit. Good Luck!

 

[Leslie Garon]

Marla,

I have seen all sorts of ways to show revision history and have implemented several different methods myself. It doesn't matter if its computerized or manual, in the document or in a separate location. All that does matter is that you can track the changes from revision to revision and that the information is accessable to the user.
A method I tend to like is a limited history in the document, like the last 3 revisions, and the rest on saved files of the old document. This works when you have the document history saved electronically. You can leave only the most recient changes on the latest document and earlier changes are found by looking up the obsoleted past revisions on the system in a history file.

Bottom line is this, as long as you can see what changes were made to the document with each revision, it is communicative and kept up to date, you've satisfied the requirement. Don't forget, who made the change must also be documented.

 

[Dawn]

For process sheets, I make a Reason for Change on the bottom of the page and in a sentence I note what the latest change was. These changes stay on the sheets up to 6 months, then they can be removed. (This is noted in the procedure).A copy of the changes are all filed when new ones are created.
For procedures, work instructions, etc. I have a small table which states revision, reason for change, and revision date. This works very well, and only takes up about an inch of space for each revision. It is also nice, because employees know right where the change has been made in the procedure. Hope this is helpful. If you would like to see a sample, let me know and I will e-mail you.

 

[Marla Diaz]

Dawn,
You mean you don't have a separate revision history section in your manuals? Would the auditors accept that? So the revisions would have to written on last portion of the affected document.
Would appreciate if you could e-mail me a sample of the table you use.
Thanks.

 

[Dawn]

I have a Master Revision List (it is the table of contents).
It states revision A, B,C, etc.
The reason for the revision is on the procedure itself. The Table of Contents must be updated every time the Manual is updated, which is not a big problem, because you get pretty much into the habit if you revise the Table of Contents every time you add a revised procedure. But you do have to keep an eye on it so you don't forget to change the revision letter in the Table of Contents.

 

[Don Winton]

Marla,

The posts thus far are examples of very good suggestions for compliance. I will just toss in my two cents worth anyway.

The system I use is basically a hybrid of the above. Each document change is recorded on a Document Change Notice (DCN). The DCN details the nature and reason for the change. The document and DCN are circulated for approval by affected parties. Once approved, the obsolete documents are removed and replaced by the revised documents at all points of issue. The DCN remains in the Document Master Record (DMR) to maintain the history. An example would be: Procedure XYZ is at revision D. Revision D is issued and maintained in the DMR and all previous revisions are removed and destroyed. The DCN's for Revision A, B and C are also maintained in the DMR. The DMR contains a master list of all documents pertinent and the latest revision number of the document. As a redundant (sort of) backup, all changes and the reasons for the change are maintained in the MS Word document via the Track Changes tool and comment fields.

This is sorta overkill in some aspects, but my company is also FDA regulated, and some (not all) Government auditors can be such ( o )'s.

I try to avoid placing revision history and reasons on the document itself. Tends to clutter it. There is nothing wrong with this method. I just try to avoid it as a personal preference.

Regards,
Don