Quality Manual - Where does Revision History Section go?

[MissTSmith]

I have taken a Quality Manual over from someone else. My question is does the Revision History section go in the front or the back of the document? I'm used to putting in up close to the title page before the TOC, but others have mentioned it should go at the back which is what we do with SOPs and WIs.

Thanks.

 

[Mike S.]

Wherever you want it to go. I've seen both.

 

[JimS]

I agree, I've seen both, as well. I prefer at the end but as with so many things, it's all in what works for you. I would suggest that all document types be as consistent as possible, however, so people know where to look.

Technically, the revision history doesn't even have to be on the document, as long as you have a clear and convenient way to get to it in your DMS. We actually use a link to the change record in the footer instead of a revision table and it's working fine. And it doesn't clutter up the last pages with tables (especially on printed forms). This certainly isn't for everyone but don't be afraid to think outside the box and just make it work for your environment.

 

[John C. Abnet]

Good day @MissTSmith ;
Keep in mind that an actual "revision" level is not necessary. There are many ways to show whether or not a document is current issue or not. For example, some organizations simply have a discrete sequential number in the change point control data base/tracking log. For instance...

CPC# Reason for change Result of change Approved by Date Implemented
CPC -0012 blah blah blah blah blah blah blah blah blah blah blah blah
CPC-0013 blah blah blah blah blah blah blah blah blah blah blah blah
CPC-0014 blah blah blah blah blah blah blah blah blah blah blah blah

This method ensures that the CPC # on the document provides tracing back to all the necessary history/tracking information, without needing to maintain all that information on the document itself.

Any way you choose (as mentioned by others) is acceptable as long as it provides this type of historical information.

Hope this helps.
Be well.

 

[Cari Spears]

I like to put things that the reader needs to know in order to understand the document at the beginning - such as the scope and purpose, and definitions and abbreviations that will be used. Other stuff - like referenced documents and the revision history - I put at the end.

I get annoyed at having to scroll through pages of revision history in some of our customers' documents.

 

[Randy]

1st - To start with, there's no requirement for a history section on the document
2nd - There's no requirement for the document
3rd - So whatever you want to do, and however you want to do it, is dealers choice

Just be consistant
Just maintain control

 

[Ninja]

We kept our revision history outside of the document, in the form of old copies in a file folder (typically pdf, sometimes paper in a hanging file no one ever looked at).

The standard does not require that you have the doc (as Randy said)...but many customers do require that you have it and send them a copy (that they then put in a file folder and never look at).

Since it was mainly a thing to send to customer's SQE's, we found no value in incorporating a rev history...it simply would have been more fuel to the fire.

 

[hogheavenfarm]

I keep ours in the front, mainly because customer SQE's typically ask "when was it revised last?" so I made it easy to find. Apparently if you havent revised it recently enough, they get worried...

 

[JimS]

We put a code in our footer that has the number of the DCR (Document Change Request) releasing the current revision and the date (MMYY) that it was released. The DCR number is an active link to the actual DCR where the change data is listed. So the code might look like "422-1220" if it was released this month via DCR #422. The date tells you at a glance how old the revision is and the link gives you direct access to the change information. Everyone seems happy with this and it looks clean on the documents.

We have a separate tool that tells us when a document hasn't been revised or reviewed in 11 months, then 12 months (our SOP says we review all docs annually). The tool then lets you either accept as-is, resetting the clock, or revise it if it needs it. This gives the evidence that we have checked the document for validity, etc even if the date in the footer says it's three years old.