Quality Manual Change History - Can I eliminate the revision record from the manual?

[Mark Smith]

The ISO standard states that the changes to the Quality Manual should be available for review by the use of attachments or visible on the page itself "where Practicable". My quality manual INCLUDES all of the quality system SOP's as part of the manual and each time one of these is revised it must be reflected on the change record page of the manual. My question is this "can I eliminate the revision record from the manual itself and keep all changes available for review in my Change Notice files (ECO's)?" Any change as in the past needs to be approved through the document change system anyway and the revision record in the manual is redundent!

 

[Kim]

Hmmmm, interesting question. I would say that you should talk with your registrar. I would think that the revision record is not optional. Even if it were, I would keep it anyway. It never hurts to CYA.
Then again, I'm a packrat

 

[Kevin Mader]

Mark,

I believe that this is a personal preferrence your documentation person must make (perhaps you). I keep a database online with changes made to documents under control. As my personal preferrence, I keep the change details separate from the details I want the reader to read and act on. Reduced clutter and increased understanding I think.

Regards,

Kevin

 

[Dawn]

I don't put revisions in the manual. I only reference the SOP number. This number never changes regardless of how many revisions we go through. The SOP table of Contents states the revision. Hope this helps.

 

[Richard K]

In our manual we footnote the latest revision only, and refer to the files for a full revision history. In our opinion it is both impractical and redundant to retain a complete revision history in the manual itself, and our registrar has not had a problem with this.

 

[John C]

Why do we keep the record? It's to facilitate the requirement of 4.5.3, paragraph 1, ie; those doing the review and approval (and, not stated but more important, the guy making the change) should ensure that the change does what it is intended to do without diminishing other aspects of the procedure.
So you need to keep it. "Where practicable", put it in the document or attachments. Where this is not practicable, or you have some other method which is more practicable, then do what you like. But be able to explain why. And don't lose sight of the basic intention of the requirement of the clause. (as above)
If procedures are to be good, they should state the important thing, not the obvious or mundane thing - we'll manage that anyway. The most important thing, when changing a procedure, is to understand how and why the procedure got to be the way it is. Otherwise you may be re-introducing problems already eliminated or undermining basic principles behind the design of the original procedure.
To make the information easily accessible helps ensure it is used. To document the need and (if necessary) say where the information is available, is a simple, but critical piece of documentation. Show this and explain it and no registrar can have anything but respect for the way you deal with the issue.
rgds, John C

 

[ALM]

I never, ever, ever, ever, ever, ever show the "nature of the revision" within the documents of our Quality System.

Our docs simply detail the revision level of the document. If anyone, including a registrar wants to see the revision history, they can page through my book of DCO's (Document Change Orders) which contain the change request and details, and a marked up copy of the previous version (appropriately labeled as OBSOLETE).

I have never had a problem with our registrar(s).

ALM

 

[Marc]

Our docs simply detail the revision level of the document. If anyone, including a registrar wants to see the revision history, they can page through my book of DCO's (Document Change Orders) which contain the change request and details, and a marked up copy of the previous version (appropriately labeled as OBSOLETE).

If a rgistrar asks for more than that they should be challanged.

 

[ALM]

Marc wrote: If a rgistrar asks for more than that they should be challanged.

My reply: They have been! (LOL).

We should start a new thread that asks for the "oddest" "requirement" that an auditor ever looked for. My experience has been that more of the funnies come from customer-auditors and not third-party registrars.

Maybe I'll start that topic.

ALM

 

[John C]

You're all hung up on auditors and certification. The documented system is there to be used by the people implementing and developing the process and should be designed as such. For the sake of efficiency and clarity, the best place for the change history is in the document to which it refers, not in the Quality Manual and not in a separate document. Regards the ECN record; Well my preference is not to use an ECN to make a document change but we are still using a hard copy through the development/change stage. Maybe if we were fully paperless, then the ECN would be the best way, though I think I would still go for a brief change description on a history page. It's the easiest to use, which encourages it's use.
An unnecessary document is waste, and so is the time spent maintaining, retrieving and handling it. All waste should be eradicated from the system.
Also; Auditors come in all shapes and sizes, just like other people, and about one in 400 is going to be totally insufferable. The rest are struggling human beings like the rest of us and will respond in kind to kindliness and consideration, with resultant benefits all round. Why butt up against them over something which is, at worst, a debatable issue? Why risk a critical observation and bad feeling? By all means, be prepared to draw a line in the sand, but why draw it here?
rgds,
John C