Documentation requirements have been emphasized time and again in the previous posts with reference to regulatory expectations, product and process requirements, process design and process validation etc. Starting from this post we will systematically start developing a pharma/biopharma documentation system.
A
good documentation system shall emphasize on:
Traceability
Clarity
Applicability
Process
based approach
The core of
documentation system is written
procedures which shall meet the above four requirements. Procedures can be
in the form of protocols, instructions, manuals etc. However, SOP (Standard Operating Procedure) is a
universally acceptable form of written procedure. In documentation system
everything roots to SOP. In fact SOP on SOP is the first document in
documentation list.
Parts of SOP:
Conceptually SOP is divided
into two parts:
Instructions:
A stepwise instructions to perform a task
Record
Forms:
Generally provided as annexure to record pre-activity, activity and post activity data.
If not included as an annexure to SOP, the SOP shall have
a reference of where to record the data of activity such as logbook or other associated record form. For example,
a production process SOP shall have
the reference to BMR Number/ Section where the data shall be recorded and BMR shall have reference number of SOP followed to execute the step (two way
traceability).
Who writes SOP?
While drafting a SOP process based approach shall be
adopted. Remember it is a good process which makes a good product which meets
or exceed the quality requirements.
There has been too
much Quality Assurance influence or interference in development of a quality
documentation system which mostly end up overlooking the process and overdoing
the clerical. This leads to non compliance in future and source of warning
letters due to process not documented properly or followed properly. Remember
all the noncompliances are either for
process or product and its better to
leave process, product and documentation to manufacturing and quality control departments;
they are the experts in their field not QA documentation manager. In fact having
a Quality Assurance department is not a direct regulatory requirement, policing
can never ensure quality; quality should be integrated in the system and is
responsibility of the process owner.
If
we break down Quality Assurance department into sub-functions we can very well
see the fact:
Quality Assurance
Sub departments
|
Functions
|
Actual Responsibility
|
Change
control
|
Manages
changes in process and facility
|
Process
and facility owner (such as manufacturing, QC, Warehouse etc)
|
CAPA
|
Manages
corrective and preventive actions in processes
|
Process
owner shall plan and implement CAPA
|
Deviation
and Non Conformance
|
Manages
process deviations and non conformance (OOS)
|
Process
owner, deviation in manufacturing process, Non conformance in QC testing
|
Audits
and Inspections
|
Manages
internal and external audits
|
Audits
are for processes and process owner faces the audit and satisfies compliance
|
Manufacturing
QA/
In
process QA
|
Manages
in process activities
|
Process
owner performs the process and QC tests the samples
|
Trainings
|
Coordinates
training
|
User
department shall aces the training need and subject matter expert impart the
training
|
Documentation
Management
|
Centralized
document management, kind of a library
|
Document
belongs to process owner
|
Validations
and Calibrations
|
Manages
validation and calibration
|
Process
owner performs the impact assessment and engineering/ validation expert
performs the validation and calibrations
|
Batch
and Lot release
|
Release
of batch
|
Production
manufactures product as per laid down procedures and QC tests and release
|
There
are many fancy sub functions and one can have many but ultimate quality is assured and maintained by process owner.
|
||
To have a compliant
system the process owner shall be authorized to implement scientific approach
to process management and control than just having a bureaucratic or clerical control. The sole purpose of regulatory
requirements, pharmacopeal expectations and high level Quality Standards requirements
is to have a scientific and knowledge based
approach which unfortunately is ignored resulting in non compliance and
warning letters.
Instead of Quality
Assurance department, a company shall have a quality improvement group of 4 to 5 diversely experience personnel
in regulatory, process and testing who perform continuous quality assessment of system and look for gaps and
improvement opportunities.
To summarize, in general Quality Assurance department performs
only the bureaucratic/ clerical functions and in no way can influence or exceed
the quality requirements of the product. In fact the hiring/ recruiting officers
shall give precedence to process
knowledge and understanding than knowledge of some clerical functions and
formalities. The discussion does not advocate throwing Quality Assurance
department out of the window but to look more closely to the
responsibilities and authorities in a quality management system and awarding them
to process owner.
So it is beyond doubt
that if document are being created, process
owner shall have the responsibility and authority to create the documents.
The first page, Approval page of SOP
has columns for Prepared by and Reviewed/ Approved by and Authorized by and
shall have the following requirements:
Prepared by:
The person who writes the SOP shall have
relevant experience in that
activity or field and shall have knowledge of the organizational structure.
Reviewed/Approved by:
The person who technically reviews the SOP for completeness
shall have a relevant experience in the
activity or the field and shall have knowledge of the organizational
structure.
Authorized by:
The SOP after the review cycle shall be authorized by Management Representative (or Head Quality) keeping in mind
the regulatory requirement and Quality Management System.
Characteristics of Good SOP:
SOP being a method of communication shall have requirements
like any other document. As documents have moved from paper to electronic
version these requirements become even more important and are discussed below:
Legibility
Readability
Legibility:
Legibility is primarily the concern of the typeface designer, to ensure
that each individual character or glyph is unambiguous and distinguishable from
all other characters in the font.
Legibility is also in part the concern of the typographer to select a typeface with appropriate clarity of design
for the intended use at the intended
size.
Legibility is the degree to which glyphs (individual
characters) in text are understandable or recognizable based on
appearance. "The legibility of a typeface is related to the
characteristics inherent in its design ... which relate to the ability to
distinguish one letter from the other." Legibility includes factors such
as "x-height, character shapes, stroke contrast, the size of its
counters, serifs or lack thereof, and weight.
Readability:
Readability is the ease
with which text can be read and understood. Various factors to measure
readability have been used, such as "speed of perception,"
"perceptibility at a distance," "perceptibility in peripheral
vision," "visibility," "the reflex blink technique,"
"rate of work" (e.g., speed of reading), "eye movements,"
and "fatigue in reading."
A reader should be assisted in navigating around
the information with ease, by optimal inter-letter, inter-word and particularly
inter-line spacing, coupled with appropriate line length and position on the
page, careful editorial “chunking” and choice of the text architecture of
titles, folios, and reference links.
This can be achieved by:
1. The
sentences must be well formed syntactically
2. The
sentences must not exceed a certain length
3. The
sentences should not be below a minimum length
4. Recursion
must be kept to a minimum
5. The choice of words
should vary
For further details
see reference 2.
Both these
requirements shall be well thought and addressed in the guidance for preparation
of the SOP.
References:
1. Wikipedia: Typography (http://en.wikipedia.org/wiki/Typography)
2. Technical Writing
made easier, rev. 1.1, March 2002 by Bernhard Spuida, bernhard@icsharpcode.net
