Since documentation is one of the cornerstones of Pharmaceutical Quality Systems, EU GMP Volume 4 dedicates a full chapter (Chapter 4) in defining and describing the different document types and their requirements, content-wise.
Since the topic I try to write about came to me not once but twice in the recent past, let's compare the specifications and procedures.
As always, let's start with the definitions.
Specifications: 'Describe in detail the requirements with which the products or materials used or obtained during manufacture have to conform. They serve as a basis for quality evaluation.'
Procedures: '(Otherwise known as Standard Operating Procedures, or SOPs), give directions for performing certain operations.'
Okay, so both document types are instruction-like, what is there to compare at all? For the sake of simplicity, let's consider only the product specifications as specifications.
The difference lies within their lifecycle, and the relation to the product.
What is the SOP's lifecycle? you established a process, you implement it. Great. But (also as a part of continual improvement) you want to finetune your process, updating the related SOP. So what to do?
Draft
-> Review
-> Approve
-> Train
-> Make it effective
And from the moment the new version is effective, your personnel is to forget the last version, and start to use the new one. In your electronic Document Management System, you may also have the tools to 'hide' the previous version, so the people have access only to the current version. You won :)
What is specification lifecycle? again, you have your specification. Either it contains the related analytical methods, or not, whatever feel more comfortable for your QC department. But you have it. And, yes, again, you want to update your specification. Now what to do?
The first step is to initiate a Change control, where you can evaluate with all your stakeholders what the actual impact is on your quality system (and also maybe regulatory files). You can build up your timelines, consider analytical revalidations, running stability studies, etc. And then:
Draft
-> Review
-> Approve
-> Train (? - in fact, training is not necessary on the specification set itself)
-> Make it effective. But how?
If you have a company that has larger capacity on manufacturing batches, you may have a great chance you will have on-going tests in your lab from the product you are trying to update the specification of. What to do with those samples? To answer this question, let's think stone age style, when everything is on paper.
Let's think about the beginning of the QC-process. Initially QC does the sampling of the batch - based on a sampling protocol that is related to the specification. In other words, at the first moment of the sampling, the specification gets stuck to that batch. You would need to print out every sampling instruction, every analytical method form for the samples, and give them to the lab with the samples. And the lab will do their tests and QC-decisions based on those papers - so on the version of specification that may be realized as obsolete in your documentation system.
But don't let yourself confused: even if your electronic documentation system says the old version is obsolete, it's not! Only the upcoming samples will get stuck with a newer version of the specification.
If you have LIMS in your hands, it can definitely help you out: in the moment of creating a sample, the system generates all tests from the current master data that won't change in the future, whatever you update on the masterdata later.
Of course, you can overwrite this concept, but you need to do it with a case-by-case evaluation, in your change control. Otherwise the Qualified Person won't be able to decide which is the specification they need to make the release decision against.
Comments