Ten Rules for Pharmaceutical
■ By Craig Wylie, PA Consulting Group
An introduction to building an architecture for control documents
The pharmaceutical industry is overloaded with regulatory documents, such as policies, standard operating procedures (SOP) and working prac- tices, and needs a robust, understandable and
effective architecture model to drive compliance. Once the
architecture is clearly defined, it’s important that the documents themselves should be easy to use and lead to compliance. Remember, compliance is achieved through simplicity
and clarity, not complexity or extensive detail.
The pharmaceutical industry could not function without
all of its regulated documents, and there is nowhere where
this is truer than in a manufacturing site. The globalization
The policy lays out the commitment of the business to compliance;
it is an essential part of any QMS and it demonstrates the com-
mitment of the senior executive management to delivery of high
quality. It is not in itself a regulated document, but it is a critical
component of the control document architecture
There are so many SOPs in a typical pharma company environment
that there is a need for a very limited number of driving SOPs. Each
of the critical business processes (as defined by the QMS) has a driv-
ing SOP that lays out the end to end process and then references
any supporting material (including other SOPs). As an example the
core processes for a QA group might be Audit, CAPA and Knowledge
Non-core processes include processes that drive administration, rather
than the operations, of the function. In our hypothetical QA group
non-core processes might include, on boarding, document archival
and retrieval, access to computer systems.
Guidance documents generally cover the way in which certain activities
are to be carried out and recorded. They do not necessarily cover every
aspect of the process but focus on those that are complex or where a
specific approach is needed. Good examples include the way in which
complex products might be encoded in a license management system,
standard language to be used in particular circumstances or the master
data to be used in entering a record in a computer system
How to execute a specific task, detailed step by step directions on
how to execute a particular task. Useful for complex systems.
of manufacturing has led to a situation where a single site
maybe releasing product to tens of different markets, and
it needs policies and procedures that are sufficient to the
task. Therefore, there are three fundamental requirements
for the For the successful management of the control documents in a manufacturing environment, there are fundamental requirements: you need a clear architecture to define
what does and does not go into different documents with a
set of rules to keep the documents easily understood, and
there needs to be a robust change control process to keep
it all in line. Since change control is something usually covered at manufacturing locations, let’s focus on the rules.
RULES TO KEEP DOCUMENTS UNDERSTOOD
In writing the control documents, there are ten rules to
guide the creation and management of controlling documents. Ultimately, the guidance is that the documents themselves should be clear, easy to use and lead to compliance.
1. Aim for simplicity and clarity, avoiding complexity and the drive to cover all eventualities. Organizations
must seek opportunities to reduce complexity as this will
enhance the likelihood that people will comply, and result
in fewer errors. When organizations try to cover every possible situation, the documentation becomes so complex it
becomes practically impossible to remain compliant with it.
2. Be outcome oriented. Building on the first rule, it is important to define the outcome required, not the input expected.
When organizations define the input, or activity, then the process can be adhered to without meeting the regulatory obligations set by the regulator. When the outcome is defined, then
the tasks become those that are required to meet the outcome,
and compliance is not achieved unless the outcome is right.
3. Don’t aim for perfection; use a risk-based model. The
goal is to develop a good system that is fit for the purpose without a lot of complexity. Inevitably there will be circumstances
that are not catered for within the documents; do not expect
every possible eventuality to be covered. High frequency risks
must be covered but low frequency high-impact risks are better
managed by people reacting to the crisis rather than trying to
mandate behavior a priori for every possible event. Good controlled document architecture requires a risk based approach.
4. Make processes role based, not job title based. While
organizational restructuring happens frequently, organizations must build processes around roles, which will expe-