SubscribeSynopsis QA in the consultant firm. NNE® has chosen to integrate preparation of system documentation in the company's project management tool - the PAM model.
This integration ensures a uniform and complete documentation that lives up to current standards within the pharmaceutical industry. All employees thus have the same unambiguous picture of how to prepare adequate and clear documentation with regard to level of detail, contents, and wording. Furthermore, the PAM-model ensures QA involvement in all part of the projects.
Introduction
System documentation constitutes a part of a new pharmaceutical plant as necessary and important as the plant itself. This is substantiated by the two essential functions of the documentation, i.e. to make sure that customer and regulatory requirements are fulfilled and to establish traceability with regard to what has been done, who has done it and when it was done. Or expressed in different terms: the documentation must make up the foundation for quality, traceability and history both for the individual document and for the entire system documentation. It is thus extremely important that the documentation is well arranged, easy to read and adequate - no more no less.
The present article describes how NNE* makes certain that the documentation lives up to these simple guidelines - particularly the documentation that constitutes the input to quality management activities carried out in new construction projects. Furthermore, the focus will be on the advantages early and strong QA involvement in the projects gives for the whole project organisation.
The PAM model
The foundation for adequate and well-arranged system documentation is laid in the preceding engineering phase as the requirements for preparing good documentation are closely connected with the models that the engineering activities build on. System planning and good documentation go hand in hand. The company makes sure that this does indeed happen by making preparation of the documentation an integral and predefined part of the company's engineering management tools - the so-called PAM model or the Project Activity Model (fig. 1).
Activities connected with major new construction works as well as smaller reconstruction works are structured according to the PAM model. The model is the tool that dictates the engineering activities, defining the different project phases and the planning, quality and construction activities connected with the project phases. Furthermore, the PAM model ensures that international guidelines as ISPE’s “Baseline Commissioning and Qualification” and “GAMP” are followed in all project phases due the incorporation of the guidelines in the PAM model. The PAM model is thus a necessary and integral part of the company quality management system - also called QMS (Quality Management System).
The function of the PAM model is also to ensure implementation of the company's policy of using the modular engineering concept and to ensure ongoing exchange of experience through extended and controlled reuse through "Better Practices". "Better Practices" are available under the PAM to be used for solving specific, technical issues. Guidelines and specifications are available for the different technical disciplines such as automation and process, as are examples of prepared documents for e.g. IQ protocols and requirement classifications.
The PAM model is the most important tool used for managing the system documentation. In addition to specifying what types of documents are to be prepared for the different project phases, the model includes standardised templates to be used for the different document types. ”Better Practices” available under the PAM and extensive use of generic documents in connection with modular engineering (cf. Basic Design later in this article) make it easier to prepare the project documentation.
Fig. 1 - The PAM model
The PAM model is based on proven traditional practices collected by the project managers, which have used practice with success. In addition, the model has continuously been improved through the reuse of Better Practices and modular engineering practice. Thus, using this model it is not necessary to invent new methods for every new project sparring time and reducing costs. PAM model activity diagrams for time, risk, economy and project organisation ensure optimal activity succession and make clear roles for all participants in the early project phases as well as in the progressive project.
Furthermore, the activity diagrams are useful tools for fixing the scope of the project for the whole project organisation and - what seems even more important - for the customer. And from aQuality Assurance point-of-view using the PAM model gives the great advantage, that quality for all part of the project is build into both product and process.
QA in the consultant firm’s part
An important fellow player in the preparation of good documentation is QA who, anchored in the PAM model, plays a central part during the entire course of the project, from the early Conceptual Design phase and all the way to the concluding Handover phase. In its capacity of consulting contractor, NNE has its own QA department that handles both GMP consultancy and approval of documentation. The consultant QA works in close contact with the customer's QA at all times.
The PAM describes consultant QA participation in the establishment of project quality activities and preparation and approval of the different project documents. During the course of the project, QA in the consultant firm manages two functions - one being the technical cGMP consultant and fellow player in the various project packages where QA works closely with the technically responsible disciplines, and the other being the party responsible for the final approval of the various quality documents prepared by the project packages. As a consequence, the QA in the consultant firm function is divided into two independent areas: "QA Classic" handling approvals of the project documentation, and "Qualification and Validation" primarily handling cGMP consulting activities and preparation of miscellaneous documents.
The present article focuses on the part of the documentation that is of particular interest seen from a quality management point of view.
Conceptual Design
A project begins with preparation of a Conceptual Design. The documentation output from this phase is moderate although extremely necessary and essential for the further progress of the project. During this project phase the general, overall lines are established for the project, e.g. the overall strategy for quality, CIP, building, and automation. The PAM model's contribution to this phase primarily consists of document templates for project proposals, risk assessments, guidelines and similar general document types. QA in the consultant firm's role in this phase is primarily that of an advisor in connection with the preparation of strategies to be adapted to the individual project. None of the documents prepared during this phase require approval from QA in the consultant firm or the customer's QA.
Basic Design
The Basic Design phase is the project phase during which the specific guidelines for preparing and handling the quality documentation are established. Consequently, it is during this phase that the most important of all the quality documents is prepared, i.e. the QAP (Quality Activity Plan)
The QAP stipulates the concrete framework for all quality activities to be carried out during the rest of the project and is thus the document, which, for the individual project, provides the foundation for ensuring that both customer and regulatory requirements are fulfilled. The QAP is also the document that translates the overall guidelines for quality, as specified in the QMS and international regulations, into practical activities falling under the individual project. The quality level of the project is stated in the QAP and the QAP defines the activities required to achieve the stated quality level.
The QAP describes e.g. the document types that must necessarily be prepared to ensure the quality, the responsibility distribution between QA in the consultant firm and the personnel responsible for the different technical disciplines, as well as between user/customer, vendor and possibly sub-contractors. Guidelines are also specified for handling of non-conformities, naming of documents, and setting up file structures. Education of personnel is another issue described in the QAP, as many projects have specific requirements for education in e.g. Good Test Practice and Good Documentation Practice. There may also be requirements for managing all documentation via databases such as Documentum.
The QMS system includes a number of general instructions that back up the QAP by ensuring correct version management of documents and use of a change log. The system also provides guidelines for who reviews/approves the different document types, i.e. QA in the consultant firm and/or the personnel responsible for the different technical disciplines. The project manager prepares the QAP but with QA as a sparring partner so that, already at an early point in the project, QA partakes in establishing guidelines for the quality management work. By using QA, as a partner also the time horizon for the project quality activities will be established, otherwise the scope and duration of these activities are often underestimated.
Another important control document is the OBS (Object Breakdown Structure), which through the controlled breakdown of the project into manageable modules provides a clear, organised picture of the project. As such, the OBS not only becomes the foundation for Modular Engineering but also establishes the document structure for the project, as it stands to reason to let the document structure follow the OBS. Great benefits are achieved in the form of reuse of documents prepared for related modules, e.g. columns or storage vessels.
An impact assessment is performed in parallel with preparation of the OBS to assess the individual modules and to determine whether the module has a direct impact, an indirect impact or no impact on the final quality of the product. PAM follows ISPE's guideline for assessing the impact of modules, which means that only modules with direct impact and the interfaces between the modules undergo qualification, whereas modules with indirect impact and no impact undergo commissioning. Working with the OBS thus requires a clear definition of the interfaces between the modules.
Based on the structure of the OBS it is possible to identify and delimit the individual modules in relation to connected "up-stream" and "down-stream" modules. A module is typically delimited based on its functionality so that each module constitutes a separate module. Separate requirement specifications are worked out for each module/unit including a description of functionality and interfaces; these specifications constitute the input to preparing protocols during the Detailed Design phase. The description of modules or equipment in these specifications is worded as a number of testable requirements that can be directly transferred to test protocols in connection with subsequent validation (cf. the section on Qualification and Commissioning). A classification approved by consultant QA is performed at the same time with a view to determining whether a requirement is a Commissioning requirement or a Qualification requirement.
Detailed Design
In this phase drafts of the engineering documentation is produced. The engineering documentation is a necessary input to the Construction phase when the physical construction activities take place. This phase also produces protocols for:
- IQ (Installation Qualification)
- OQ (Operational Qualification)
- Commissioning documentation
These are all documents that create the basis for further test activities during C&Q (Commissioning & Qualification) when fulfilment of requirements listed in the aforementioned requirement specifications is demonstrated. Preparation of the protocols is described in this section, preceded however by a description of the test plans included in the protocols.
When the protocols are prepared, two types of test plans can be defined to be included in the protocols:
- Generic test plans, which is a constituting part of the QMS.
- Specific test plans
Generic test plans are characterized by being test plans that are not connected to a specific system but apply generally to all systems. This could be test plans dealing with configuration management as well as test reports that ensure that all reports included in the release of a product cover the specified data, and that all data, single data, calculated data and graphical data are correct.
QA in the consultant firm and the Project Engineer/Technology group should be involved in the preparation of generic test plans for IQ and OQ. This procedure makes certain that a test plan is prepared containing both the technical and quality-related level of detail necessary to performing the test.
The consequence of having only QA prepare the test plan is that it may not become discipline-specific. One could imagine a scenario where the definition of how the test must be performed and the expected result are not adequately explained and thus not clear to the person performing the test. Having only the project engineer prepare the test might result in a lack of attention to any would-be cGMP requirements. Sparring between the two parties is therefore essential to achieve both the technical and the quality-related level of detail required. In the worst-case scenario, the consequence of not doing this could be a number of unnecessary non-conformities demonstrated during the test and originating from misunderstandings that result from an inadequate test plan.
It is worth mentioning however that even though the test plans are generic they must be presented to the customer, and minor changes may have to be made so that the test plans are adapted to the individual project.
Specific test plans are characterized by being test plans that are specific/unique for the individual module. They describe a test sequence of events as stated in the operational specifications. The tests are described in test plans (test cases) and these specify which functions must be tested and which observations must be documented. It is essential that the test cases describe in detail how fulfilment of requirements for the test steps is to be demonstrated, be it through screen dumps or approval by the test personnel. Fulfilment of requirements for test steps covering Qualification requirements must be demonstrated through screen dumps or other computer-generated documentation, whenever possible. The documentation must clearly show that the requirement has been fulfilled.
When the specific test plans for the OQ protocols and the protocol itself are being prepared, it is again important that QA from the consultant firm be involved. Having QA and the project engineer for the package prepare the test plan together produces a test plan that ensures a correct transferral of requirements and an accurate description of the method of demonstrating that the requirements have been fulfilled.
Common to IQ, OQ and Commissioning protocols is the description of the requirements to be tested. In addition to the requirements, the protocols will include a description of:
- Method for demonstrating fulfilment of requirements
- Expected observation.
Personnel performing the test must write the specific observation themselves and confirm this with a notation of "accepted"/"not accepted". Making sure that the individual test clearly indicates how to perform the test and what the expected result should be minimises the risk of the test personnel making unintentional errors. Furthermore, all protocols should contain a complete list of test plans to be used, including the total number of pages of these plans, to achieve full traceability.
The test plan must also clearly state requirements for the documentation to be enclosed before a test can be considered as being completed. The documentation could consist of screen dumps, PI diagrams, calibration sheets, etc.
For both IQ and OQ it is an advantage to involve QA in writing the protocols, letting QA ensures correct transferring of requirements from Requirement Documents to the protocol test plans making a clear line between requirement and teststep. Furthermore, QA makes certain that test plans are designed for easy and quick testing according needed observations (what is the accept criteria? – what is the observation? - is it fulfilled?) and to fulfil Good Documentation Practice (make it easy to remember to write down the necessary observations and signatures). By not doing so, you could end up with a protocol and test plans that only the project engineer is able to read.
The purpose of the Installation Qualification(IQ) is to demonstrate that the system was constructed/installed as specified in the module specifications. To ensure that only released equipment is used as well as pertaining components it is a prerequisite that the equipment and components have been subjected to a receiving inspection that ensures full traceability.
The IQ protocol constitutes the basis for the installation qualification of Qualification requirements specified in the Installation Requirement Specification given by the customer and in the installation part of the Requirement Specification, worked out in Basic Design. The protocol also defines the scope and contents of the various tests to be covered by the Installation Qualification. The IQ protocol also verifies that the established installations fulfil the validation-relevant requirements and that the validation is performed according to the Validation Master Plan.
The IQ protocol typically comprises the actual protocol with a specification of the system to be tested. As mentioned above, the protocol describes the scope of the test and the rationale behind, e.g. that it is not necessary to test for drainability, dead legs and angular membrane valves on pipe sections containing bacteriostatic liquids. The scope of testing the pipe section must also be specified. The protocol must stipulate whether the test is narrowed down to the limit of the contract or the closest component included in the connected module/system. An option could be to test only to the contract limit, but if the protocol covering the connected module chooses the same option the consequence might be that a part of the pipe section is not tested. Another scenario could be testing two connected modules all the way up to the first component included in the connected module/system. This would result in "redundant" testing of many pipe sections but would on the other hand ensure testing of all pipe sections.
The Operational Qualification (OQ) must verify that fulfilment of all functional requirements are demonstrated as described in the functional specifications and is consequently carried out as a test of the functionality of the entire system.
The OQ Protocol constitutes the basis for Operational Qualification of Qualification requirements described in the Requirement Specification covering the specific section. The protocol also specifies the scope and contents of the various tests to be covered by the operational qualification. Additionally, the OQ protocol verifies that the established functions fulfil the validation-relevant requirements and that the validation is performed according to the Validation Master Plan prepared by the customer. The protocol documents the testing of critical functions.
The protocol typically includes both generic and specific test plans as well as the protocol itself. In addition to the contents described under IQ, the protocol defines prerequisites to be fulfilled before the OQ test can begin, an example could be a CIP substation that must first undergo an Operational Qualification.
As mentioned earlier, protocols and test plans must also be prepared during this phase for the modules that have been classified as Commissioning, whatever they have direct/indirect or no impact. These protocols and test plans demonstrate fulfilment of all Commissioning requirements as well as aspects identified through a risk assessment as being critical with a view to CE marking. The protocols and test plans will/can also include implicit requirements for observing acts, regulations and circulars in force. Typically, a number of generic test plans pertain to these protocols.
These test plans are used for demonstrating fulfilment of requirements in cases when demonstration through e.g. visual inspection or reference to other documentation like FAT (Factory Acceptance Test) or SAT (Site Acceptance Test) is not sufficient. The protocol is prepared in a sparring process between QA and the project engineer. During this process, QA ensures correct transferral of requirements, and the project engineer ensures exact specification of the method to be used for demonstrating fulfilment of the requirements. The protocol is approved by QA in the consultant firm only and not by the customer or customer's QA.
It may be an advantage to wait with the actual approval of the IQ/OQ and the Commissioning protocols as the protocols should/can always be approved prior to IQ/Pre-OQ. Irregularities could e.g. be found on the system during Pre-OQ, irregularities that necessitate a change to a requirement and thus also an update of the requirement specification. If the protocol has already been approved, the OQ would demonstrate non-conformities based on the updated requirement specification. Preparing the protocol in a draft version and having all involved parties review it is however recommended so that there are few changes, if any, after pre-OQ, and a speedier approval process is ensured.
Construction
Activities taking part in this phase involves the physical activities relating to construction. From a quality point-of-view an important activity in this phase is receiving ordered “goods”. A Receiving Inspection Plan manages this, which establish the extension and level for needed Receiving Inspection. This is done to ensure and document the received goods, e.g. components, instruments and programs concerning fulfilment of quality requests and documentation. Focus is on material certificates and vendor statements for components released for assembling. After receiving inspection is performed a Receiving Inspection Report is written based on observations found during inspection. QA from the consultant firm approves the Receiving Inspection Plan as well as the Receiving Inspection Report and is thus a fellow player in improving documentation and quality level for Receiving Inspection.
Another important QA activity during Construction concerns vendor activities like FAT and SAT, which have to be performed to guarantee functionality of completed systems and equipments – of site as well as on site. FAT/SAT protocols are typically written by the vendors, but are always approved by consultant QA. Letting consultant QA approve protocols ensures a uniform and adequate vendor documentation of an appropriate quality level. This has the advantage, that FAT/SAT material can be reused in the following PAM phase “Commissioning and Qualification”, where FAT/SAT tests can be included in IQ/OQ testing. Furthermore, FAT/SAT reports are to be approved by QA.
Module and integration test is a documented test, which takes place in this phase. This takes place to ensure that the module is working according to the software specifications. The test can take place either offline or online depending on what is most practical. As with IQ and OQ this test has specific Testplan and ends up with a report.
Commissioning & Qualification
Activities during this phase demonstrate that the system is in compliance with the project agreement. I.e. IQ and OQ are completed and the activities show that the system lives up to the requirement specifications defined during an earlier test stage. The scope and level of the qualification and commissioning are specified in the QAP.
Completion of the tests is a precondition for preparing the IQ and OQ reports. In this connection it is important to keep in mind that the test personnel must have the correct competencies/qualifications and the necessary knowledge of test instructions and General Test Practice. This to avoid non-conformities caused by insufficient knowledge of the system or non-conformities resulting from errors made by the test personnel due to lack of understanding of the General Test Practice rules. For this reason, a curriculum vitae and similar documentation should be available on all test personnel stating that the personnel have been trained to perform the test. Moreover, a signature sheet should be available on all involved project members showing initials and signatures. This documentation will always make it possible to trace the notations of "accepted"/"not accepted", the initials and the signatures applied to the test and the enclosures by the test personnel.
Before starting the automation test one should keep in mind that all systems must be subject to configuration management prior to the test to make it possible at any and all times to trace the changes made to the system during the IQ test. In addition, changes to the systems could influence the completed test, and if the system had not been subject to configuration management this would not have been discovered. Configuration management must be applied during both IQ and OQ, and defining a Baseline before and after the test can do this. The changes implemented between the end of IQ and the start of OQ should therefore be reviewed examine whether they have had an impact on e.g. the Loop test performed during IQ.
Also, all changes made during OQ must be reviewed to reveal any impact on already performed tests. Configuration management is a test and changes will appear during review of the Baseline before and after all performed tests. If there are changes in software items, this will constitute a non-conformity where the changes should be documented through extracts from the change log of the individual, involved software items. The change log must include a clear description of the changes that have been made as well as any impact they may have on the completed tests.
Handling of non-conformities is an essential part of the documentation input. All protocols include non-conformity records that must be used if the acceptance criteria are not fulfilled, i.e. the test was not completed as planned or errors were found in the specification, the test plan, the test form or the acceptance criteria.
All non-conformity records could include the following points:
- Non-conformity No. The non-conformity is assigned a unique number.
- Test plan/Test form. A note is entered indicating under which test plan the non-conformity was found.
- Background and description of the non-conformity is stated.
- Proposal for corrective action, i.e. a description of the action proposed for correcting the non-conformity.
- A project engineer with date and signature must approve the proposed action. Moreover, the project engineer must evaluate whether the customer is to be involved, a decision which is typically made if the proposed action entails changing a requirement
- Corrective action, i.e. how the proposed action to correct the non-conformity was carried out.
- After the proposed action has been completed, the change must be re-verified/re-tested whenever relevant. All enclosures documenting the result of a re-test must be noted in the non-conformity record and attached to the non-conformity.
Finally, the action and the re-test must be approved by either QA in the consultant firm, the customer or customer's QA.
There may be non-conformities that cannot be closed in IQ and must therefore be transferred to OQ for testing. In this connection it is essential that the project have a management tool lined up for ensuring that the non-conformity is transferred and closed. If such a tool is not available the worst consequence may be that the non-conformity is "forgotten" and is therefore not closed. A simple but efficient tool to use for this purpose is a non-conformity log that contains all transferred non-conformities with e.g. creation date, identification of where it is closed, who is responsible, and the date when it was approved by QA.
Reporting:
After the completed IQ test, all test data must be reviewed to verify that the test was carried out correctly, correct use of GTP, and that all non-conformities have been closed correctly.
Before the OQ test is started, a checklist should be prepared and filled in to ensure that all preconditions have been met. This could be e.g. an approved IQ Report, an MIT (Module Integration Test) test, etc.
If the IQ report cannot be approved before the OQ test starts, a review meeting should be held. This meeting must be mentioned in a review meeting log and minutes of the review meeting must be included in the IQ report. It is important that all review meetings are logged so that it possible at any time to track how the OQ test started before the IQ report was approved.
The reports for both IQ and OQ must show that fulfilment of the validation requirements specified in the protocols has been demonstrated. The reports for IQ and OQ will furthermore have common characteristics, and they will both include the following:
- Distribution of responsibilities for preparation, review and approval.
- Description and status of non-conformities.
- Indication of total number of pages, number of enclosures etc. for the individual test cases.
- Conclusion.
The report is typically prepared by QA jointly with the project engineer and is then approved by QA in the consultant firm, the Customer, and Customer's QA.
Conclusion
Within the pharmaceutical industry, producing adequate documentation of construction and reconstruction works is of vital importance. The documentation must ensure that the customer's requirements are met, and adequate and correct documentation is a prerequisite for obtaining approval of the system from the authorities. This places great demands on the way the documentation is developed and worded as it must be both easy-to-read and fully cover the relevant subject. It is also important that all parties working with the documentation in one way or another have the same picture of the function of the documentation and how it must be prepared.
As a result, it has been decided to incorporate the guidelines for preparing system documentation into the project management tool - the PAM model - used throughout the company. The PAM model is also an integral part of the quality management system. Furthermore, the living PAM model ensures, that the company lives up to international guidelines for pharmaceutical engineering, as the recommendations from The ISPE “Baseline Commissioning and Qualification” and “GAMP” are incorporated in the PAM model. Thus, the PAM model is based on the ISPE Baseline Commissioning and Qualification regarding e.g. the way of making impact assessments, handling GxP requirements and the commissioning/qualification concept. As well as the qualification concept for Automation is based on the V-model from GAMP4.
Using PAM as a basis for the firm means that all employees have the same perception of what adequate documentation is, both with regard to scope, contents and wording, as all documents required for a project are described in detail in the PAM model – see figure 2. Moreover, the PAM model ensures an early and ongoing involvement of Consulting QA both with regard to GMP consultancy and approvals of documentation - thus making Consulting QA an active fellow player during the entire course of the project.
Integrating preparation of documentation in the general project management tool this way ensures a uniform and adequate documentation that at any and at all times lives up to current standards within the pharmaceutical industry. The input material consists of generic templates that determine the technical level of detail and that secure this level from project to project. The generic templates make extensive reuse possible as they can often be transferred to new projects with minor modifications.