You are on page 1of 96



A supplier and end
users perspective
Revised Edition

Contents ........................................................................................................................................................... 2
Preface ............................................................................................................................................................. 4
Introduction ..................................................................................................................................................... 6
Validation - The Background ..................................................................................................................... 6
Validation and Qualification ...................................................................................................................... 7
Why Test? .................................................................................................................................................. 7
Regulatory Requirements and CSV .................................................................................................................. 9
Development of Documentation Required by Regulations .................................................................... 11
Software categories ....................................................................................................................................... 13
Validation Overview ....................................................................................................................................... 15
V-Model Software Development ............................................................................................................. 16
GAMP Level 4........................................................................................................................................... 18
GAMP Level 5........................................................................................................................................... 18
Ten Guiding Principles of GAMP 5 ........................................................................................................... 20
A Definition of the Difference between Level 4 and 5 ............................................................................ 20
General Guidance .................................................................................................................................... 20
Master Documentation Relationship............................................................................................................. 21
Factory and Site Testing ................................................................................................................................. 22
Testing ..................................................................................................................................................... 22
Traceability..................................................................................................................................................... 23
Leverage ......................................................................................................................................................... 23
Specification Phases....................................................................................................................................... 24
GAMP category 4 project ........................................................................................................................ 24
User Requirement Specification .................................................................................................................... 24
Functional Specification .......................................................................................................................... 26
Configuration Specification............................................................................................................................ 27
GAMP category 5 project ........................................................................................................................ 28
Design Specification................................................................................................................................. 28
Module Specification ............................................................................................................................... 29
Coding ...................................................................................................................................................... 29
Verification Phases......................................................................................................................................... 30
Testing Methodology............................................................................................................................... 30
Module Structural Testing ....................................................................................................................... 34
Integration Testing .................................................................................................................................. 35
Functional Testing ................................................................................................................................... 35
Requirements Testing.............................................................................................................................. 36
Other Testing ........................................................................................................................................... 37
Other Consideration of Testing ............................................................................................................... 38
System Testing - Why Software is Different from Hardware .................................................................. 39
Role of the supplier ........................................................................................................................................ 40
Project controls example ......................................................................................................................... 42



Risk and Risk Analysis..................................................................................................................................... 44
Risk Mitigation Strategies ........................................................................................................................ 47
Risk Management tools ........................................................................................................................... 48
FTA ........................................................................................................................................................... 48
HACCP ...................................................................................................................................................... 48
FEMA Analysis.......................................................................................................................................... 49
GAMP 5 FMEA ......................................................................................................................................... 52
FMECA ..................................................................................................................................................... 55
21 CFR Part 11 and Annex 11 ......................................................................................................................... 56
The meaning of 21 CFR part 11 ............................................................................................................... 57
Some definitions ...................................................................................................................................... 58
Classification for 21 CFR part 11 applicable systems .............................................................................. 60
Practical implementation of 21 CFR part 11 applicable systems ............................................................ 63
Annex 11 – Computerised systems ......................................................................................................... 68
Key Points in the Annex ........................................................................................................................... 68
Good documentation practice ....................................................................................................................... 71
Company Audits ............................................................................................................................................. 79
Training .......................................................................................................................................................... 84
Maintenance .................................................................................................................................................. 85
Change Control .............................................................................................................................................. 85
The EMC Regulations and the Technical Construction File ........................................................................... 87
Harmonised standards for Electronic Equipment ................................................................................... 87
The Technical Construction File............................................................................................................... 88
Terms used..................................................................................................................................................... 91

Copywrite and Disclamers
The content of these pages is the copyright of Performance PharmaTech Ltd. Reproduction or
dissemination of any of it is prohibited unless expressly authorised.
Performance PharmaTech Ltd. makes no warranties, representations or undertakings (whether express
or implied): about any of the content of these pages (including, without limitation, as to the accuracy,
completeness, satisfactory quality or fitness for a particular purpose of such content or that the content
of these pages is error-free).
© Performance PharmaTech, July 2011
Revision 04, 1 July 2011



into the highly regulated pharmaceutical environment and to help end pharmaceutical customers understand the equipment supplier’s perspective. If the customer cannot validate the equipment it is of no use to them. this way the company can begin the validation immediately. Remember that the validation process must occur before the end customer can product drug. · The validation people are angry with the supplier for not giving them what they need · The supplier is angry with the project manager or OEM agent for not describing their real needs up front · The pharmaceutical project manager and his management are angry at the supplier for not giving them what they really needed. the project engineer or the sales contact for the OEM (if the equipment is to be fitted to an OEM machine. This pre-validation documentation set should be supplied to the pharmaceutical company with the equipment. the equipment should be easy to validate. They may not know the details of the requirements but they will contact the relevant person within the end company and that person will be involved in the next sales project meeting. suppliers owe this as a service to their customers. including a source code review for computer based equipment. Different pharmaceutical companies have different way of validation equipment so this sounds like the supplier has a difficult or impossible job. The supplier says ‘you did not ask for this. without question. More than this. therefore the turnover package is as important to the end customer as the equipment itself. which of course the supplier cannot supply without adding costs and time to the project. no question. Neither of these people may have real validation expertise. This can be avoided if the subject is brought up at an initial sales project meeting with the customer or OEM representative. an increasing occurrence) does not mention validation requirements. even if they did not ask for it in the first place How do we avoid this. Suppliers should ask the customer ‘what is your need for validation in this project?’ If you are dealing with a pharmaceutical company it is a 100% certainty that they will have validation requirements. It describes the details of validation for those who are new to the subject and describes the development of a suitable documentation set. What happens in practice is as follows.Preface This document is designed to assist suppliers who wish to sell equipment. so neither does the equipment suppliers salesman. Now if all Pharmaceutical companies have need for validation and they all have slightly different way of achieving this. © PAUL OSBORNE │ PPTECH LTD PAGE 4 . In this way everyone knows what to expect and when to expect it and what it will cost. That is just not the case. how does the supplier fit in? The supplier has an important role in providing equipment that can be validated. simply by asking the question up front – ‘what are your validation needs?’ And then by understanding and interpreting the answer. which I refer to as the prevalidation documentation set. So the entire project continues until someone from validation or QA on the customer’s site becomes involved as asks what provision has been made for validation. These validation and compliance issues should be discussed with the pharmaceutical company as soon as possible in the sales negotiations. they are reliant on the leveraging information out of the supplier. usually computer based.’ There will not be an option for the pharmaceutical company to do the work themselves. so we cannot achieve it without extra costs and additional time. Once the rules are understood then the supplier can be of help to all customers and everyone will be satisfied. At which point the equipment supplier is contacted and asked by the validation or QA group who have a detailed list of requirements for FS and IOQ documentation sets and may even request additional documentation and an audit of the company. In many cases I have observed this issue does not come up until the equipment is due for delivery and then the arguments begin over increasing costs and slipping schedules.

© PAUL OSBORNE │ PPTECH LTD PAGE 5 . The documentation set will be created by following a set of rules that will be fully described later in this document. who is not familiar with the equipment perform this work. the end customer is and it is he who will report in any regulatory audit. modify. · Defining the scope of the project in order to understand the validation requirement. I emphasise assistance because the supplier is not responsible for the testing. these are as follows. Remember that the support can be just the documentation set. use this as a sales tool. retain.Also – do not be afraid of telling the end customer or OEM the validation costs. So it is more cost effective for the supplier to make the pre-validation pack than anyone else. Identity1 or Purity? · Does the system keep records and data that are to be provided to regulators? Does the system create. Strength. defining Business and Operational Risk and finally any H&S Risk · In the GMP assessment defining if the system has the capability to impact on the Product in terms of Quality. or providing assistance with the testing. define the scope of the 21CFR part 11 procedural controls. 1 In packaging we particularly seek to confirm identity. not the equipment supplier. Incorrect component such as leaflets labels or cartons are universally identified as cases for recall. report or approve GMP related data? If so and it is an end customer requirement. It would cost the pharmaceutical company far more to have a validation consultant. · Carry out a risk assessment by defining any Ethical or GMP Risk (Items that would cause a product recall).

© PAUL OSBORNE │ PPTECH LTD PAGE 6 . I began to attend courses on validation of computer based equipment and found them useful. because of the nature of the equipment we supplied. The traditional approach to equipment and machinery validation relies on the fact that an equipment design has been made for a given solution. and regulatory aspects related to drug manufacturing. generic. A given design of blister machine can be qualified in a specific way. but not necessarily centred on the task I was trying to carry out. Pharmaceutical and biotechnology are diverse industries comprising: · Many different and sometimes very complex processes · Most engineering and scientific disciplines · Regulations that govern the manufacture of products which are not to be found in a single document. For many. its planning and activity is a grey area and there are good reasons for this.Introduction During the early 1990’s my company made the transition to being a supplier of PC based packaging security systems to the pharmaceutical industry at the same time as the industry itself began to rationalise its approach to the validation of such devices. documentation set for all applications. To complicate this further. I must state that the task was hindered by the fact that our equipment was to be fitted to a wide variety of machines with a wide variety of functionality. which I wrote as I rationalised the problem from the supplier and end user perspectives and then presented my results to various groups for their thoughts and comments. likewise a specific device for the creation of pure water. that of the creation of suitable validation documentation sets to provide to our customers. I felt unable to create a single. However. as is the case in many applications. Therefore a single documentation set will usually suffice for most applications. It seeks to provide tools that can be used to improve the level of compliance to perform the job correctly from the beginning. I try to answer what should be the validation approach for standard computer based equipment undergoing configuration prior to use in a cGMP environment and also provides simple and specific ways to improve documentation structure and incorporate such elements as requirements traceability and risk analysis. engineering. rather they are scattered throughout a variety of sources and often require a fair amount of interpretation It is probably impossible to find a single person who understands all of the chemistry. how to create the documentation set and provide examples and templates to work from. This documentation came out of a series of papers written by myself over the intervening years on this subject.The Background Let us start at the very beginning. It also seeks to inform end customers of the way to convey information to the supplier that is relevant to the project. Validation . equipment manufacturing companies often sell to multiple international markets where regulatory expectations vary. This document therefore aims to inform the would-be supplied of computer based equipment what his regulatory obligations are. validation. dependant on the design documentation created during its development.

’ By bringing together a number of repeatable parts the overall equipment is created. Therefore.e. for example. operated within their specified design parameters.’ First we need to make the stipulation of what something is and then we can test for that property.Qualification is testing. the tasks to be performed. Once a system has changed. all aspects of the system need to be controlled. It requires the investment of significant time and money to achieve a tested baseline through a rigorous program of specification and testing. This is why validation becomes so confusing to people and is acted out from fear of the consequences of not carrying them out. Engineers gain confidence in systems by performing tests that show repeatable results. So we Validate the system by performing Qualification on the equipment. It therefore often becomes an after-thought. one classical definition is as follows: ‘To provide documented evidence which provides a high degree of assurance that systems. In order to achieve this.Validation and Qualification For me the term validation itself is poorly understood. the physical activity that people actually do is testing. For a given set of conditions. A judgment based on the nature of the change would need to be made to determine whether the test results were still considered valid or whether the system would need to be re-tested to find out if that same result is received the second time around. While the terms are a little vague. if it was first specified that ‘a chair is designed to support the weight of an 80 kilogram.’ Good definition. Confidence is gained that the system is ‘repeatable. First we need therefore to stipulate ‘this is what the system is supposed to do’ and then we need to test to show ‘this is what it does. the system has a predictable response. Any test result for that system is valid over time provided the system does not change. What's the difference between qualification and testing? Qualification involves testing systems to demonstrate they do what they are supposed to. The change may be such that a new test needs to be devised to demonstrate some new system requirements or attributes.’ then it would now be possible to devise a rational and quantifiable test that can measure whether the design intent has been accomplished. both planned and unplanned © PAUL OSBORNE │ PPTECH LTD PAGE 7 . So. Testing has meaning only when systems are tested against what is required of them. creating understood and communicable baseline measurements defining a systems performance. a test may or may not be valid. a qualified system is a tested system. Many of the same comments that have been made about validation also can be made about qualification. are capable of repeatedly and reliably producing a finished product of the required quality. In other words . but what does it mean exactly? There is no real definition of the actual testing to be carried out here i. including: · The physical components of the system · The people who use and maintain the system · Associated information and documents · Ongoing changes made to the system. Qualification = Testing Why Test? When a system is tested a tested baseline is achieved. it makes sense to protect that asset by managing the system so there is confidence that the tested baseline is current over time.’ What we must not do is apply circular logic that states ‘this is what the system is because this is what the system is.

an activity-based definition of validation consists attesting and management to maintain the tested baseline. it can be deduced that requirements are fundamental to validation. validation is nothing new and nothing extra. And yet. The ideas presented are intended to promote and facilitate this maintainability.e. it might be useful to focus on the activities being performed. Most ‘validation’ projects are in fact ‘qualification’ projects. it is still common to find ‘validated’ systems with no definition of what the system is supposed to do. The majority of the discussion that follows proposes ideas and techniques that can be employed to develop and maintain the tested baseline.’ Where failure can occur is as follows: · If there are no specified requirements. in order to formulate meaningful tests. Therefore. it is not possible to achieve a tested baseline.’ This better indicates there is a method in place to continuously manage and control the system in an ongoing way to keep the tested baseline current. the tested baseline is nearly always compromised with the passing of time resulting in systems ‘falling out’ of validation. It is interesting to note that testing and management are commonly understood activities which have been performed by humans for thousands of years to achieve some quite remarkable things. there is nothing to manage. · If there are no meaningful tests. Rather than describing a system as ‘validated. Procedures that are implemented to manage a system that hasn't been properly tested. There is often very little management of the tested baseline that is handed over at the end of the project. There must be a specification that says ‘this is what it is supposed to be’ and then a corresponding test that shows ‘this is what it is.’ as if it were a property of the system. When good science and engineering and good project management are used. This usually results in the whole qualification exercise having to be repeated. the system can't be ‘under validation. · If there is nothing to manage. To avoid this situation. there can't be meaningful testing. there must be pre-determined requirements. © PAUL OSBORNE │ PPTECH LTD PAGE 8 . regardless of management efforts. · If there is no tested baseline. Now. The format of the tested baseline and the way in which it is created are critical factors in its ongoing maintainability. do not improve the assurance of the system response for a given set of inputs.To summarise. As a result. it would be better practice to say the system is ‘under validation. Testing and management are equally important.’ i. The tested baseline should be thought of as a physical thing. A tested baseline that is not managed quickly becomes outdated. under control.

inadvertent erasures. or loss shall be maintained · · Typical Industrial PC 2 GAMP 5 a risk based approach to compliant GxP Computerized systems © ISPE 2008. inspected. or microfilm. It is also demanded by groups like FDA regulations and guidelines through the overall requirement that ‘equipment must be suitable for its intended use’. such as duplicates. or checked according to a written program designed to assure proper performance. tapes. including computers. or related systems that will perform a function satisfactorily. it shall be routinely calibrated. may be used in the manufacture. are eliminated by computerization or other automated processes. In such instances a written record of the program shall be maintained along with appropriate validation data Hard copy or alternative systems. Revision5 issued June 2008. © PAUL OSBORNE │ PPTECH LTD PAGE 9 . Computers appear in at types of packaging machinery and the ancillary devices that appear on them. reliability and correctness of the manufactured product.Regulatory Requirements and CSV Computers are more and more widely used during manufacturing of drugs and medical devices. Written records of those calibration checks and inspections shall be maintained · Appropriate controls shall be exercised over computer or related systems to assure that change in master production and control records or other records are instituted only by authorized personnel · Input to and output from the computer or related system of formulas or other records or data shall be checked for accuracy · The degree and frequency of input/output verification shall be based on the complexity and reliability of the computer or related system · A backup file of data entered into the computer or related system shall be maintained except where certain data. shall be designed to assure that backup data are exact and complete and that it is secure from alteration. Proper functioning and performance of software and computer systems play a major role in obtaining consistency. and holding of a drug product. packing. such as calculations performed in connection with laboratory analysis. Gamp 52 itself is specifically named ‘A risk based approach to compliant GxP computerized system’ Specific requirements for computers can be found in section 211. processing. or electronic equipment or other types of equipment. like printers and visions systems. computer system validation (CSV) should be part of any good development and manufacturing practice.68 of the US cGMP regulations: Automatic. Therefore. If such equipment is so used. mechanical.

This is the life cycle model All publications refer to some kind of life cycle model with a formal change control procedure being an important part of the whole process. In 2003 the FDA published guidance on scope and applications of 21 CFR Part 11. This regulation applies to all FDA regulated areas and has specific requirements to ensure trustworthy. installation. The PDA4 has developed a technical paper on the validation of laboratory data acquisition system. All guidelines refer to risk assessment for the extent of validation Pharmaceutical Inspection Convention Scheme. initial operation. Parenteral Drug Association. It starts with the definition of the product or project and setting user requirement specifications and cover the supplier selection process. Specific requirements for computers and electronic records and signatures are also defined in FDA’s regulations 21 CFR Part 11 on electronic Records and Signatures. It has more than 50 pages and includes a six page checklist recommended to be used by for inspectors. The guidance states FDA’s expectations related to computer systems and to electronic records generated during clinical studies. transmitted and archived by computer systems. It has been developed by inspectors for inspectors of the PIC/S 3but is also quite useful for the industry. By far the most detailed and most specific official document that has ever been developed on using computers in regulated areas is the ‘Good Practices Guide on Using Computers in GxP Environments’.FDA has developed several specific guidance documents on using computers for other FDA regulated areas. The FDA has released draft guidance on using computers in clinical studies. All these guidelines and publications follow a couple of principles: · · · 3 4 Validation of computer systems is not a one time event. evaluated. going use. Because of their importance. Most detailed is the Industry Guide: General Principal of Software Validation. and change control and system retirement. integrity and reliability of records generated. © PAUL OSBORNE │ PPTECH LTD PAGE 10 . It deals with development and validation of software used in medical devices. There are no detailed instructions on what should be tested. computer validation issues have been addressed by several industry organizations and private authors: · · The Good Automated Manufacturing Practices Forum (GAMP) has developed guidelines for computer validation. In this document the FDA promoted the concept of risk based validation.

Data analysis Most systems do a mixture of some or all of these functions. Control of process and packaging equipment. Computers in the pharmaceutical industry perform three types of task: 1. recently the focus is on network infrastructure. Interaction © PAUL OSBORNE │ PPTECH LTD PAGE 11 . costs for systems with different impact and risk on product quality. to capture raw data. Again there may be more than one computer in the system and they perform some type of interaction. which is used to control equipments.While in the past computer validation was more focused on functions of single user computer systems. the trend today is to directly send production information to the packaging line to configure the manufacturing equipment directly for example. networked systems and on security. Computer systems are becoming more integrated. more often than not the system will by a part of a network of computers exchanging data to provide the required services. Development of Documentation Required by Regulations Risk assessment and risk based validation will be discussed for all validation phases to optimize validation efforts vs. Validation of software loaded on a computer. to process the data and to print and store. standard applications software and software written for a specific user. One of the main purposes of this document is to answer the key question regarding validation: How much validation is needed and how much is sufficient for a specific computer system? This gives a good overview and lists major validation steps and tasks but for an in depth understanding and for easy implementation readers are recommended to read further references. 2. Software typically includes operating systems. The computer her will not work in isolation. Data acquisition 3. authenticity and integrity of data acquired and evaluated by computer systems. control of ancillary inspection and printing devices. This is especially important since the FDA has been using and supporting the risk based approaches for compliance as part of the 21st century drug cGMP Initiative.

this defines the scope of the project. In the GMP assessment define if the system has the capability to impact on the Product in terms of Quality. Identity or Purity? Does the system keep records and data that are to be provided to regulators? Does the system create. however I find a well defined Functional Specification (FS) invaluable at this time. Define any Ethical or GMP Risk (Items that would cause a product recall). its People and its Procedures (the five P’s) Identify the Software and Hardware of the system Identify the Scope of the system Identify the Interfaces Now assess the system in the following way by a risk assessment. the Plant. I follow these important steps: Detail. finally any H&S Risk. this can be the URS.Therefore it is important to define the topology of the system as the first step in the validation strategy. Within this FS we define the following: · · · · Identify and list the system functionality as it relates to the end Product. define Business and Operational Risk. Strength. modify. retain. report or approve GMP related data? © PAUL OSBORNE │ PPTECH LTD PAGE 12 . the Process. or have detailed. the system within a separate document.

verify correct installation · Risk-based tests against requirements as dictated by use (for simple systems regular calibration may substitute for testing) · Procedures in place for maintaining compliance and fitness for intended use PAGE 13 .. upon which applications are . Software used to manage the operating environment · · · · Software · · · · · 3. but the cannot be configured to suit the business process Typical Approach Operating Systems · Record version number. Infrastructure .e. Layered software (i. verify correct Database Engines installation by following approved Middleware installation procedures Programming · See the GAMP Good Practice Guide: languages IT Infrastructure Control and Statistical packages Compliance Spreadsheets Network monitoring tools Scheduling tools Version control tools · Firmware-based applications · COTS software · Instruments (See the GAMP Good Practice Guide: Validation of Laboratory Computerized Systems for further guidance) © PAUL OSBORNE │ PPTECH LTD · Abbreviated life cycle approach · URS · Risk-based approach to supplier assessment · Record version number. Non- Configured Run-time parameters may be entered and stored.Software categories Category Description Typical Examples 1.

Custom Software custom designed and coded to suit the business process. but includes: · Internally and externally developed IT applications · Internally and externally developed process control applications · Custom ladder logic · Custom firmware · Spreadsheets (macro) Same as for configurable. that can be configured by the user to meet the specific needs of the user's business process. with possible supplier audit · Possession of full life cycle documentation (FS. often very complex. Design Specifications) · Record version number. plus: · More rigorous supplier assessment.. verify correct installation · Risk-based testing to demonstrate application works as designed in a test environment · Risk-based testing to demonstrate application works as designed within the business process · Procedures in place for maintaining compliance and fitness for intended use · Procedures in place for managing data 5. DS.g. · LlMS · Data acquisition systems · SCADA · ERP · MRPII · Clinical Trial monitoring · DCS · ADR Reporting · CDS · EDMS · Building Systems · CRM · Spreadsheets · Simple Human Machine Interfaces (HMI) Note: specific examples of the above system types may contain substantial custom elements · Life cycle approach · Risk-based approach to supplier assessment · Demonstrate supplier has adequate QMS · Some life cycle documentation retained only by supplier (e. Software code is not altered. structural testing. etc. Configured Software.Category Description Typical Examples Typical Approach 4.) · Design and source code review © PAUL OSBORNE │ PPTECH LTD PAGE 14 . Varies.

functional specifications. Several life cycle models have been described in literature. The use of “Verification” based on “good engineering practice” was advocated. Annex 11 of the European GMP directive is very clear about this: Validation should be considered as part of the complete life cycle of a computer system. Important steps in between are validation planning. defining user requirements. Terms used Some industry groups however want to eliminate the terms “validation. · · 5 Many companies are unwilling to abandon terminology that works for them ® GAMP 5 strives to be terminology-neutral GAMP makes great use of the V model. For new systems validation starts when a supplier delivers a machine or equipment which is based on computer control. operation.” “qualification”. For an existing system it starts when the system owner gets the task of bringing the system into a validated state. Functional Testing (OQ) and Requirement Testing (PQ). Validation ends when the system is retired and all-important quality data is successfully migrated to the new system. Because of the complexity and the long time span of computer validation the process is typically broken down into life cycle phases. Functional Specifications (FS). Design Specifications (DS). documentation. commissioning. In other words. specification. initial and ongoing testing and change control. PQ The complaint is that these carry baggage and can lead to “over-documentation”. monitoring and modifying. validation during development. programming. testing. This cycle includes the stages of planning. development and testing of code. installation. computer systems should be validated during the entire life of the system.Validation Overview Validation of computer systems is not a once off event. supplier assessment for purchased systems. OQ. Configuration Testing (IQ). © PAUL OSBORNE │ PPTECH LTD PAGE 15 . One model that is frequently used is the V-model 5as shown here. design specifications. and IQ. This model comprises of User Requirement Specifications (URS).

Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time. the process steps are bent upwards after the coding phase. The more that standard software is used and the less customisation made for such software the less testing is required by individual users. The extent of validation at the user’s site also depends on the widespread use of the same software product and version. Each computer system should be associated to one of the three categories. In the context of this document only categories three.V-Model Software Development The V-model is a software development process which can be presumed to be the extension of the waterfall model. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. four and five are of interest to us. Instead of moving down in a linear way. to form the typical V shape. They are described below. In total there are four categories defined in GAMP 5. GAMP 5 has developed software categories based on the level of customisation. © PAUL OSBORNE │ PPTECH LTD PAGE 16 . Category one defines operating systems and firmware of automated systems. The V-Model as described above is quite good if the validation process also includes software development. We are usually concerned with two of them. The extent of validation depends on the complexity of the computer system.

CSV Life cycle for a category 5 system When considering category 5 system the following must be in existence: · · · · · The existence (and use) of an appropriate quality system during the original development of the computerised system Thorough design review during development and manufacture and thorough testing against requirements specifications Comprehensive documentation of the full development life-cycle Controlled and documented procedures and records for the system's operational life Controlled and documented phase-out and data archival/migration at the end of the system's life © PAUL OSBORNE │ PPTECH LTD PAGE 17 .

GAMP Level 4 A GAMP 5 level 4 system reflects the configuration of a standard system which may be composed of different software and hardware modules. GAMP Level 5 User Requirement Specification Requirement Testing (PQ) Functional Design Specification Functional Testing (OQ) Design Specification Integration Testing Module Specification Software Module Testing Code Modules In a GAMP 5 level 5 system we are considering the design of new equipment. © PAUL OSBORNE │ PPTECH LTD PAGE 18 .

An example is shown on the next page. Phases like design specification or code development and code testing are not necessary provided that adequate design and testing documentation exists for the system. In this case a life cycle model that combines system development and system integration is preferred. the 4 Step model is not suitable when systems need to be programmed for specific applications or when additional software is required that is not included in the standard product and is developed by the user’s firm or by a 3rd party. © PAUL OSBORNE │ PPTECH LTD PAGE 19 . As previously described. and performance qualification (PQ). GAMP documentation is controlled and issued by the ISPE6. For such systems the simple 4 step model is recommended with just four phases: Testing of system by manufacturer. installation qualification (IQ).A GAMP 5 level 4 category system. operational qualification (OQ). 6 International Society of Pharmaceutical Engineers. This means that the system immediately moves into a GAMP 5 level 5 category system. where the system is a standard Hardware and Software product that is in serial production and only configuration is needed to make it operational.

who then have two needs: · To supply configured versions of their standard product for say 80% of the market needs · To perform partial redesign as needed to address the remaining 20% of the market needs This means that to fulfill all customer requirements there will be a need to redesign equipment for future markets. not a certification. 4. Focus on systems impacting public health. 2. clearly identified.Ten Guiding Principles of GAMP 5 1. How can it be confirmed as even having been delivered by the supplier? In fact this does not just apply to validation in the pharmaceutical industry. this is just prudent contract and financial management. There is no point in having a specification or requirement if it cannot be tested in some way. © PAUL OSBORNE │ PPTECH LTD PAGE 20 . 5. The following double V diagram or ‘W’ diagram seeks to address that requirement. at some point suppliers expect to be paid for goods delivered or services rendered. Focus where regulations require controls beyond “good practice”. and testable specifications provide greater understanding to all. GAMP is based on and consistent with established international standards. the end user is only responsible for the parameterisation of the system With a level 5 system the development life-cycle and all other controls are made by the end user. Fully integrate risk management throughout life cycle. Promote benefits of understanding business processes. Guidance will satisfy all current regulatory expectations for CSV. Guidance will cover complete life cycle. How then could this these V diagrams apply to a company designing new computer based equipment for a general market. Clarify Roles and Responsibilities. 6. GAMP is a trademark. 7. A Definition of the Difference between Level 4 and 5 One definition to apply when discussing level 4 and level 5 systems is as follows: · · With a level 4 system the development life-cycle and all other controls are made by the manufacturing company. ® 10. It is common sense to assure oneself that the product is what was wanted and is what it purports to be before it is paid for. · By discipline / function · User / Supplier ® 9. 8. 3. General Guidance Unique. Regardless of the industry. Consolidated framework will fit any automated system.

The items to be analysed for risk are drawn from the Function Design Specification and directly influence the Qualification testing and internal system testing work.Master Documentation Relationship Internal to Company External Please note ote the central importance of the Risk Analysis. © PAUL OSBORNE │ PPTECH LTD PAGE 21 .

Requirements Testing is conducted under actual running conditions across the anticipated working range. Customer URS Order Placement Produce FS. The System Acceptance Testing FAT and SAT should be fully documented. Such testing documentation is usually created by the end customer. Configuration Testing. Functional Testing Factory Acceptance Testing Configuration Testing Functional Testing (IOQ) Site Acceptance Testing Requirements Testing (PQ) Training Other Issues Testing Model © PAUL OSBORNE │ PPTECH LTD PAGE 22 . some of the Functional Testing (OQ) can be completed as required. The completion of Functional Testing for a system confirms that it is ready for use in the manufacturing process. Also. The Requirements Testing step verifies system performance (PQ).Factory and Site Testing Testing During factory acceptance testing most of the Configuration Testing (IQ) can be completed if required.

information gathered at both FAT and SAT time can be applied directly into the IOQ data.Traceability Traceability may be achieved in a number of ways. Data captured at FAT time can be referenced to and used at SAT. Leverage Model © PAUL OSBORNE │ PPTECH LTD PAGE 23 . The key details here are that the various documents used are adequately cross referenced to be of use to any regulatory authority involved in later inspections. including a Requirements Traceability Matrix (RTM). Leverage The possibility exists of course to apply leverage to data captured and thus reduce the overall testing overhead. automated software tools. such as the Functional Specification FS. An RTM may be generated as a separate deliverable or as part of an existing deliverable. Likewise. This has the effect of drastically reducing the testing time on the project. spreadsheets. or embedding references directly within documents.

it is crucial to remember the document is not the job. security requirements etc as expected by the user. performance. it is good practice to: · Use simple short statements – ‘We require a vehicle to hold 6 persons’ · Keep each premise separate – ‘It must travel 600Km without refueling’ · Stick to the facts. not written. © PAUL OSBORNE │ PPTECH LTD PAGE 24 . created by the customer.Specification Phases GAMP category 4 project For a GAMP category 4 project we are concerned with the following specifications: User Requirement Specification In this phase. It describes the system’s functional. The purpose of the exercise is in fact not to write a document. data. less text gives rise to more understanding The end users carefully review this document as this document would serve as the guideline for the system designers (category 5 equipment) or configuration (category 4 equipment) in the system design or system configuration phase. To facilitate understanding. This phase is concerned about establishing what the ideal system has to perform. The document exists to be read. but to convey information to the reader of that document so they understand what is required. When writing User Requirement Specifications. interface. This first step in the validation process is the user requirements. the requirements of the proposed system are collected by analyzing the needs of the user. physical.

and anything else that is important when designing the computer system. If none of the suppliers meet all user requirements. There is much additional information that should be supplied with the URS and very often this information is left out. what is the exchange mechanism? Is like-for like exchange possible? For how long? In the event on non likefor-like exchanges. hardware requirements (such as corporate standards for computer hardware). what additional support will be required? · Software support . When commercial systems are available either the URS is sent to one or more suppliers (see right site of the diagram). what is the revalidation impact? · Training support – What formal. the types of output that must be generated (graphs.In the event of hardware system failures. system security requirements (password protection or other scheme). The user acceptance tests are therefore designed in this phase. One way to ensure requirement numbers are unique in this way is to use a dynamic outline numbering field code to generate the number. what is the method of informing the end user of the availability of these improvements? In the event of a system software crash. user requirements or system requirements. desired graphical user interface. tables). the amount of information the system must be able to store. © PAUL OSBORNE │ PPTECH LTD PAGE 25 . reports. the requirements may be adjusted to the best fit or additional software is written to fulfil the user requirements following the development cycle on the left side of the diagram. For equipment control systems. what are the defined recovery procedures? · Hardware support . Suppliers either respond to each requirement or with a set of functional specifications of a system that is most suitable for the user’s requirements. The supplier that best meets the user’s technical and business requirements is selected and qualified. is this included in the sale price? · Electronic records – Procedures. An initial version of the URS may be included with the Invitation to Tender sent to potential suppliers. to be able to find a specific number and therefore a specific requirement. These are also known as the requirements: functional requirements. batch records or test data that is recorded by the system may be required to be controlled by Electronic Record. Besides defining the equipment in terms of its hardware and software. The reference number can then be safely used to refer to a requirement from outside the document with confidence that the reference cannot be broken.Defining what the system is supposed to do involves clearly defining in writing what things this system will be designed to accomplish. Electronic Signature (ERES) rules to comply with some markets. This version should include all essential requirements (musts) and if possible a prioritized set of desirable Requirements (wants). one of the requirements is that the computer system be able to control the equipment so it is capable of supporting its intended function.In the event of improvements to the system. class based. Users compare the supplier’s responses with their own requirements. They include things such as the equipment the computer system must interface with. a Requirement Reference Number Table of Contents is used to list all of the numbers in order and bookmark its page. Therefore. at the cost of the end customer. training is available for the system and how is it documented? Is this included in the sale price? · Validation support – What formal validation documentation is available for the system. precision of data.

They figure out possibilities and techniques by which the user requirements can be implemented. A resolution is found and the User Requirement document is edited accordingly. but are not limited to the following: · HMI & GUI screens layouts · Keypad layouts · Report layouts · Data Models · Process Flow (operating process. © PAUL OSBORNE │ PPTECH LTD PAGE 26 . system engineers analyze and understand the proposed system by studying the user requirements document. It may also hold examples of business scenarios. Input values and expected output values The Functional Specification is a description of the product to be supplied in terms of the functions it will perform and facilities required to meet the user requirements as defined in the URS. data structures etc. menu structures. If any of the requirements are not feasible. The Functional Specification is the defining and controlling document.Functional Specification In this phase. the user is informed of the issue. reports intended to enhance understanding. The Functional Specification should be written in such a way that it is understood by both supplier and customer. GAMP 5 defines the main structure of the Functional Specification as follows: · Introduction · Overview · Functions · Data · Interfaces · General additional information Other technical documentation like entity diagrams. system process) · High Level Function of the system · System Testing conditions. This document contains the general system organization. sample windows. Items to be classified in the Functional Specification include. a data dictionary will also be produced in this phase. The Functional Specification document is the reply of the supplier and serves as a blueprint for the development or configuration of the entire system.

At the higher level it defines the software modules (sub-systems) that will form the complete software system. and interfaces. All specifications should be structured in a way that supports traceability through the life cycle from individual requirements to associated testing. clear. size and complexity of the system this may be covered by a single specification or may require a hierarchy of specifications covering software and hardware separately. Standardized tables can help ensure that all relevant parameters and settings have been defined. Software design occurs at two levels. Diagrams in hardware design can aid understanding of architecture and connectivity. control logic. At the lower level the design describes the operation of the individual software modules. If such tables or diagrams are produced elsewhere then these should be cross-referenced in the appropriate specification. This includes the definition of all settings and parameters. © PAUL OSBORNE │ PPTECH LTD PAGE 27 . Each specification should be uniquely referenced and traceable back to its appropriate higher level specification. and precise. Custom applications require design of hardware and software. These specifications should be unambiguous. and also may require Configuration Specifications. Depending on the risk. Diagrams can be helpful in software design to clarify and explain data flow. the interfaces between these modules and also the interfaces to other external systems. The use of tables and diagrams to illustrate Configuration is highly recommended.Configuration Specification Configuration specifications should be provided for configured products and covers the appropriate configuration of the software products that comprise the system to meet specified requirements. data structures. Configuration and design should cover both hardware and software aspects.

dependencies. For each software sub-system (module) identified in the Software Design Specification. a Software Module Design Specification should be produced. their interface relationships. test specification and integration test specification are not required. The integration testing design is carried out in this phase. technology details etc. © PAUL OSBORNE │ PPTECH LTD PAGE 28 . The Hardware Design Specification is a description of the hardware on which the software resides and how it is to be connected to any existing system or plant equipment. The Software Design Specification is a description of the software components and sub-systems to be provided as part of the product. The Software Module Design Specification should contain enough information to enable coding of the module to proceed. architecture diagrams. brief functionality of each module. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules. database tables. If there is only one module the Software Design Specification should contain enough information to enable the code to be produced.GAMP category 5 project For a GAMP category 5 project we are concerned with the following specifications as well as the previous examples: User Requirement Specification Requirement Testing (PQ) Functional Design Specification Functional Testing (OQ) Design Specification Integration Testing Module Specification Software Module Testing Code Modules This is as for the GAMP category 4 project but with the following additions: Design Specification The phase of the design of hardware and software architecture can also be referred to as high-level design. In this case the module design specification.

Diagrams can be helpful in software design to clarify and explain data flow. Standardized tables can help ensure that all relevant parameters and settings have been defined. including: Input values and expected output values Coding This phase of V-Model scheme produces the application code. including their type and size. the following files should be stored: · Libraries · Resources · Source code Binaries · © PAUL OSBORNE │ PPTECH LTD PAGE 29 . If such tables or diagrams are produced elsewhere then these should be cross-referenced in the appropriate specification. in pseudocode and/or database tables. Database tables · Low Level Functional Decomposition à Module Identification including: Brief Description. In such a case. coding and commentary rules should be formally specified and observed Items to be classified in the Design Specification are: · Data Structures. and interfaces. The Unit Testing (Module Testing) design is developed in this stage. data structures. Some basic items: · Module Pseudocode · Unit Test Conditions. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. consistent naming conventions. we can assume to keep last release visible in the Project Tree. If a Version Control System is used. The following should be considered in each implementation activity: · Where possible. It is the deepest phase of the process.The use of tables and diagrams to illustrate Design is highly recommended. The low level design document is built up with a detailed functional logic of all the modules. error message lists and complete input and outputs entities. the source files are stored in a repository and it is no possible to have their visibility directly. with all elements. Diagrams in hardware design can aid understanding of architecture and connectivity. File layouts. The use of these methods and tools should be documented · Rules and conventions such as programming rules. programming languages. Interfaces and dependencies · Hardware and Software Architecture · Operating System Specs · Peripheral Device Specs · Automation Device Specs · Integration Test conditions including: Analysis of the interactions among different modules Module Specification The Module Design phase can also be referred to as low-level design. appropriate implementation methodologies and tools should be used to formalise the production process. Under Version Control. control logic. all dependency issues. all interface details with complete API references. including: Message layouts.

position and date for authors. All test-related dates must be logically consecutive. described in sufficient detail · show date and signature on each test by the tester and witness or reviewer · be retained and properly archived © PAUL OSBORNE │ PPTECH LTD PAGE 30 . reviewers and approvers · include the test procedure. Tests should be planned and executed by persons who are: · qualified to the tasks they are executing · technically skilled · knowing the equipment/system · trained in the requirements of GxP · be as independent as possible Test Documentation The test documentation should: · include name.Verification Phases Testing Methodology Goals · Find and eliminate defects (not just software bugs) · Determine reliability of the system · Decide when to release the system in a compliant state · Use as little resources as possible · Build confidence that the system will work without error after testing Good Testing Practices Tests are executed according to a pre-defined and preapproved test procedure The test procedure: · is established on the basis of the appropriate system / equipment specifications · refers to the relevant specifications · should enable repetition of the test · should be based on named documents held under version control Testing should not start before the test procedure has been approved. Test Planning Tests should cover all relevant areas of the relevant equipment or system.

Test execution should be audited on at least a sample basis by either the user representative or the supplier quality assurance function.g. traceable to international standards. Correction fluid should not be used. screen printouts) Each test should be concluded with a statement of whether the test met its acceptance criteria. Test Deviations All deviations should be recorded and be traceable throughout correction and retest into final closure. See Good Documentation practice later in this document for more details.Test Execution There should be pre-determined acceptance criteria or statements of expected results for each test During execution test results should be: · recorded directly onto the test results sheet or · refer to printouts or computer generated test execution files (e. traceable to national standards and referenced. Any corrections should be crossed out with a single line. Actual values should be recorded where appropriate. Calibration equipment should be certified. © PAUL OSBORNE │ PPTECH LTD PAGE 31 . Shorthand notations such as tick marks should be avoided. Deviation corrections may require regression testing to verify that the corrections did not introduce new problems in other tested areas. initialled and dated with a brief explanation. Test Recording Manual test recording should use permanent ink. Calibrated Tools Any critical instrument inputs and any test equipment should be calibrated with documented evidence of such calibrations.

stress. security White Box Testing White Box Testing performs the following functions: · Reveal problems with the internal structure of a program or system · Requires detailed knowledge of structure of program or system · Essentially path testing · Structures can be tested even when structure is vague or incomplete © PAUL OSBORNE │ PPTECH LTD PAGE 32 . reliability.Black Box Testing Black Box Testing performs the following functions: · Assess how well a program or system meets the requirements · Assumes the requirements are accepted · Checks missing or incorrect functionality · Compares system result with predefined output · Performance.

tester. software.Software module testing · The module or ‘Unit’ is a function or small library · Small enough to test thoroughly · Exercises one unit in isolation of others · Easier to locate and remove bugs at this level of testing · Structural testing in test environment · Done during code development/programming · Designed. documentation. security. periphery. or user) · Ensures system features are accurately tested (performance. reliability) · Black box ‘Alpha testing’ Requirements testing · Completed system tested by end users · More realistic test usage than 'Functional' phase · Confirms system meets business/user requirements · Determine if systems is ready for deployment · Performed in productive environment · Black box ‘beta testing’ © PAUL OSBORNE │ PPTECH LTD PAGE 33 . done and reviewed by programmer · White Box Integration testing · Units are combined and module is exercised · Focus is on the interfaces between units · Shows feasibility on modules early on · Tester needs to be unbiased and independent · White box with some black box Functional testing · The whole system: hardware. incl. manual parts are tested in detail · Verify the system correctly implements specified functions · Testers mimic the end use · Independent testers and formal approval by another independent function (not developer.

and termination (boundary) conditions · Path Coverage . It is considered to be a minimum level of coverage for most software products. Source code review is normally carried out prior to the start of formal module testing. complete path coverage is generally not achievable.this criterion requires sufficient Test Cases each program decision or branch is executed so that each possible outcome occurs at least once. one.Module Structural Testing Test Objective The objective of structural testing or "white-box" testing is to ensure that each program statement performs its intended function. and many iterations. its achievement is insufficient to provide confidence in a software product's behavior · Decision (Branch) Coverage . Structural testing therefore identifies test cases based on knowledge of the source code. © PAUL OSBORNE │ PPTECH LTD PAGE 34 . is executed at least once. These test cases challenge the control decisions made by the program and the program's data structures including any configuration settings. It differs from branch coverage only when multiple conditions should be evaluated to reach a decision · Multi-Condition Coverage . from start to exit of a defined program segment. Source code review is a means for documenting the structural verification of a custom coded module. however. It should include both review against the required coding standards and review against the design requirements.this criterion requires sufficient Test Cases to ensure that each feasible path. Structural testing is recommended for high risk priority requirements (in addition to functional testing) because testing of all functionality defined by the requirements does not mean that all software code has been tested.this criterion requires sufficient Test Cases to ensure that each feasible data flow is executed at least once. but decision coverage alone is insufficient for high-integrity applications · Condition Coverage . to test all possible outcomes at least once. Some common levels of structural test coverage include: · Statement Coverage .this criterion requires sufficient Test Cases to ensure each program statement is executed at least once.this criteria requires sufficient Test Cases to exercise all possible combinations of conditions in a program decision · Loop Coverage . two. Test Scope The scope of structural testing should reflect the risk priority associated with the system or function. Structural testing also can identify "dead" code that is never executed when the program is run. typical running. The scope of path coverage is normally established based on the risk impact or criticality of the software under test · Data Flow Coverage . Because of the very large number of possible paths through a software program.this criterion requires sufficient Test Cases for all program loops to be executed for zero. A number of data flow testing strategies are available Test Positioning Within the Life Cycle Structural testing is carried out primarily within the module test phase.this criterion requires sufficient Test Cases to ensure each condition in a program is executed. covering initialization.

Integration Testing In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Some common types of functional test include: · Normal Case (Positive Case) Testing . and the program's internal and external interfaces. Testing is usually black box as the code is not directly checked for errors. Run the testing between two modules and test the gap between two modules whether two modules are interacting with each other. Test Scope Functional testing should normally cover all stated user and functional requirements. or checking that a zero input is handled without leading to a 'divide by zero' error). · Invalid Case (Negative Case) Testing .testing to show that the system does what it is supposed to do in response to specified invalid inputs (for example. Once all the modules are integrated several errors may arise. The input combinations can be selected at random from the possible input domains or selected specifically because they are considered likely to reveal faults. · Output Testing . Functional testing is required in addition to structural testing because testing of all of a program's code does not necessarily mean that all required functionality is present in the program. Functional testing therefore identifies Test Cases based on the definition of what the software is intended to do. normal case testing does not provide sufficient confidence in the dependability of the software product. By itself. The functional test design is derived from the functional design documents. © PAUL OSBORNE │ PPTECH LTD PAGE 35 . It is done using the integration test design prepared during the architecture design phase. Testing done at this stage is called System Testing. the number and types of functional tests performed may reflect the risk priority associated with the system or function. These Test Cases challenge the intended use or functionality of a program. · Special Case Testing . · Input Combination Testing . Sometimes System Testing is automated using testing tools. Test Objective The objective of functional testing or "black-box" testing is to evaluate the compliance of a system or component with specified functional requirements. giving the correct error message in response to an out-of-range input).testing to show that the system does what it is supposed to do in response to the normally expected inputs (for example checking that a calculation gives the correct result in response to the expected inputs). For a particular requirement.testing combinations of inputs to ensure correct outputs. Functional Testing Functional testing will compare the system specifications against the actual system.choosing test inputs to ensure that all software outputs are generated at least once during testing (and if relevant that the outputs are exercised at the limits of their allowed range). however.testing to show that the system does what it is supposed to do in response to inputs at the limit of the permitted domain (boundary or limit condition testing) or to inputs which form a special case or singularity (for example checking that a calculation produces the correct result for the maximum and minimum values of each input.

Where differences exist between the test environment and the production environment. Requirements Testing The objective of performance testing is to evaluate the compliance of a system or component with specified performance requirements. Test Scope Performance testing should normally cover all stated performance requirements. be approached with caution . with many concurrent users of a database). throughput or response (for example responding to operator requests within the specified period). These may include non-functional user requirements (e..Test Positioning Within the Life Cycle Functional testing is carried out during all phases of software testing.testing to show that the system is capable of meeting the required performance whilst operating under realistic high load conditions (for example. · Accuracy Tests .Testing to show that the system is capable of operating reliably in the specified environment (for example under the specified temperature conditions).testing to show that the system is capable of repeatedly meeting the required performance (for example. It is in the nature of a prototype to be built up in a a minimum it is recommended that a baseline be taken and a source code review carried out prior to testing. Load testing can be a complex area and further discussion is given in section 3. therefore. by running repeated trials using the same recipe to check that the product is always within specification).g. · Load Tests . Some common types of performance test include: · Environmental Tests .testing to evaluate the combined performance of the system and user (for example checking that the user is able to access and respond to information in a timely fashion via a menu system). does not form part of formal testing even though it often involves an amount of informal (undocumented) testing.testing to show that the system is capable of meeting the required accuracy of measurement or control (for example controlling temperature to within a specified range). · Repeatability Tests .testing to show that the system is capable of meeting the required timing. It may be possible to assess performance at an earlier stage using prototypes or theoretical models or by scaling up of results from unit or module test phases. · Timing or Response Tests . from unit or module testing to system level testing.4. Testing performed by the Supplier is normally leveraged but additional testing may be necessary if the operating environment falls outside the Supplier's specification for the product. For a particular requirement the number and type of performance tests executed may reflect the risk priority associated with the system or function. speed of response to operator input). © PAUL OSBORNE │ PPTECH LTD PAGE 36 .3. Test Positioning Within the Life Cycle Performance testing is normally carried out during the factory and site acceptance test phases or prior to 'Go Live'. relatively uncontrolled manner. it also may be necessary to carry out some performance monitoring and tuning within the production environment. Design Prototyping should be regarded as a means of verifying design requirements and of building confidence prior to formal (documented) testing. · Usability Tests . In order to avoid discovering performance problems when it is 'too late' to remedy them it is important to build in performance tests to earlier stages wherever possible. The conversion of a prototype to a real module should. Design Prototyping (sometimes referred to as Conference Room Pilots or other similar terms).

Disaster Recovery Testing Test Objective Disaster recovery testing has two objectives: · To check. The outcome of the regression analysis may indicate that new test cases are required. following the decommissioning of a system. that portions of the software not involved in the change were not adversely impacted. This is in addition to testing that evaluates the correct functioning of the changes that were made. The scope of all regression testing should be based upon regression analysis to determine the scope of functionality potentially impacted by the change and should reflect both the risk priority associated with the system or function and the likely impact of the change being made. as part of disaster recovery planning. following a disaster. following a change. that recovery of the system has been successful Decommissioning Testing Test Objective The objective of decommissioning testing is to demonstrate. Data migration testing may be an important part of this. that elements of a system can be recovered in the event of foreseeable disasters such as loss of the normal operating hardware · To verify. © PAUL OSBORNE │ PPTECH LTD PAGE 37 .Other Testing Regression Testing Test Objective The objective of regression testing is to demonstrate. Regression testing is normally achieved by the re-execution of original Test Cases that have already been proven to give the expected outcome. that associated systems are not adversely impacted and that archived data can still be accessed.

Suppliers should be in a position to verify that the products they use have been developed using good engineering practices and that they have taken all possible measures to ensure this. Or it may depend on off-the–shelf software products like operating systems and SCADA packages. suppliers should seek to leverage the testing already executed by their own supplier(s). or testing conducted by themselves on identical systems or pieces of equipment. In these cases. A mature Supplier is more likely to recognize the importance of quality management and to have established quality management processes. The Supplier should make themselves aware of the areas likely to be covered by that audit Being aware of the requirements and preparing for the audit will assist both parties in determining any shortfalls and where specific remedial actions or testing may be required.. Supplier Assessment For systems containing category 4 and/or 5 software (or highly critical software of category 2 or 3) it is usual for an end customer to carry out an assessment of the Supplier. The same approaches need to be adopted by Suppliers when they make use of third party products.Other Consideration of Testing The overall system may contain computerised sub-systems within it. These should be considered in the plan of testing. where specific configurations of automated tools are used these should be tested and documentary evidence provided of fitness for purpose. Users may rely on the documented testing conducted by such mature Suppliers and should not repeat such testing. but not be limited to: · Assessment of developers of the third party products. © PAUL OSBORNE │ PPTECH LTD PAGE 38 . Supplier Maturity There is a higher probability that a product from a new Supplier will have faults compared to a product from an established Supplier. This Guide provides assistance to Users in the pharmaceutical industry as to how they should approach the testing of supplied systems. The audit may be an important step in developing a long term relationship between the Supplier and the User. e. · Where third party products are considered to be a "widely used industry standard" then suitable evidence to this should be available. Just like end customers.g. This may involve. This may be restricted to a postal audit but consideration should be given to carrying out a full audit. · The specific testing of their use of these products. Use of Third Party products Where the Supplier integrates third party software or hardware at any stage in their product development life cycle they should consider the quality of their own suppliers and their supplier's products when determining an appropriate level of testing.

software engineering needs a greater level of managerial scrutiny and control than hardware. Software will improve with age as latent defects are discovered and removed. Speed and ease of software change cause both software / non-software professionals to believe that software problems can be corrected easily.’ Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. Finally. ability to execute alternative commands. The quality of software is dependent on design and development with minimum concern for software manufacture. therefore lack of understanding can lead managers to believe that a tightly controlled engineering development and testing environment is not needed. A very significant features of software is branching.e.. its verification and the test documentation in a specific way. The difficulty comes in getting the original program to meet all the specifications. Software developers are beginning to use off-theshelf software components for faster and less expensive software development. In a software development environment. not all of which may have been simulated during testing. Verification techniques such as structured approach and documented development ensure comprehensive validation. It is not difficult to manufacture thousands of program copies that function exactly the same as the original. Software branching can hide latent defects until long after a software product has been introduced to the market. Some other points to understand are as follows. since software manufacturing consists of direct reproduction (copying) that can easily be verified. i. We need to specify the testing of software. Quality needs to be ‘built in’ by understanding and applying the above points. software verification is confirmation that the output of a particular phase of development meets all of the input requirements for that phase. It is known that 50% of all software errors occur during the design and requirements phase of a project and 40% occur during the coding phase. nor adequate development facilities or resources. These ‘componentbased’ approaches require very careful attention during integration.Why Software is Different from Hardware There is one consideration here that sets computer based validation apart from all other work and that is the nature of software. software is not a physical entity and does not wear out therefore failures occur without advanced warning. However software that is constantly updated sometimes introduces new defects during the change.System Testing . since branching will create complex possibilities of execution during normal operation. Other verification activities include: · · · · · Code walk-throughs Various static and dynamic analyses if relevant Code and document inspections Module level testing Integration testing © PAUL OSBORNE │ PPTECH LTD PAGE 39 . Because of its complexity the development and testing of software should be more tightly controlled and accurate and complete documentation is essential. The vast majority of software problems are traceable to errors made during design & development. Software testing is one of several verification activities intended to confirm that the software development output meets its input requirements. Therefore testing alone cannot fully verify software is complete and correct. A lot more information can be found in the following document on the FDA website: ‘Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices.

looking at GAMP 5 we see some of the key concepts are: · · · · · Product and process understanding Life cycle approach within a QMS Scalable life cycle activities Science based quality risk management Leveraging supplier involvement Leveraging supplier involvement © PAUL OSBORNE │ PPTECH LTD PAGE 40 .Role of the supplier GAMP 5 is an accepted source of guidance for regulators and practitioners worldwide. harmonizing with other guidelines such as: · · · · ICH Guidance Q8. Again. Q9 and the forthcoming Q10 FDA Good management practices PIC/S guidance on good practices for computerised systems ASTM E55 committee on drug development and manufacture Therefore manufacturing companies worldwide have accepted GAMP methodology and used it in their policies.

Please note that the FS is the application FS QMS system overview Specifications for the design . Novel software development methods are increasingly used. the creation of functional and other specifications (FS). support and maintenance Justification for the use of supplier documentation should be provided by the satisfactory outcome of supplier assessments. with most systems networked. experience and documentation. © PAUL OSBORNE │ PPTECH LTD PAGE 41 .details of the system of software release documentation . which may include supplier audits Documentation should be assessed for suitability. structure and documentation practices So what can a company supply as a package to the end customer or OEM to support GAMP 5 level 4 or 5. risk assessment. made by an independent and qualified auditor on your company and its major sub-suppliers Perspective over the last 10 years The perspective has changed over the last 10 years. subject to a satisfactory supplier assessment The supplier may assist with requirement gathering (URS).defining design FS or minimum installation documentation Design review details. Any system for customer notification of problems Reference to results of an audit. There has been a substantial move towards wide use of configurable commercially-available software packages. system configuration (IQ). testing (OQ). · Main body of GAMP® 4 was written from perspective that system is based on custom/bespoke systems • Main body of GAMP® 5 is written from perspective that system is based on configurable software packages This allows rapid development techniques to be used. accuracy and completeness.Quoting directly from GAMP 5 again: · · · · Regulated Pharmaceutical companies should seek to maximise supplier involvement throughout the system life cycle in order to leverage knowledge. configurable computer systems? · · · · · · · · · · · · Dedicated FS and IOQ documentation set. There should be flexibility regarding acceptable format. including source code review. Sometimes called a Design Qualification (DQ) Software configuration Testing of the system – or reference that documentation can be viewed User documentation Training details CE marking documentation System support . changes and new features. The type of system supplied decides how generic or dedicated this documentation set must be.

Project controls example
Supplier generates qualification documents and performs testing

Deep knowledge of the system
Deep knowledge of validation of the equipment with different customers
Combination between commissioning and qualification activities can reduce lead
Just in time correction of findings possible (under change control)
Supplier generates qualification documents and performs testing


Possibly additional GMP or other customer training required
Customer has to understand the approach and has to implement supplier standard into internal
Not all tests can be performed by supplier (e.g. SOPs, interfaces to other equipment)

Customer generates qualification documents and performs testing

Documents in accordance to internal company standards
Experience with inspections by authorities (e.g. FDA)
Qualification activities are a good (user) equipment training


Limited capacities
Tests partly only with supplier performable
Generation of test procedures takes a long time due to limited equipment



3 key areas of documentation are consistent here - Planning, Specifications and Testing:

Supplier Project Quality Plan


Functional Design Specification
Hardware Design Specification
Software Design Specification
Traceability Matrix
Risk Analysis


Acceptance testing
Verification / Qualification

Consider if the documents provided are to be static (issued and fixed) or dynamic
(changing with the progress of the project). Certainly the TM will change.

Everyone wants a smooth handover!



Risk and Risk Analysis
Risk and risk analysis has been mentioned several times, here we will take time to cover this in more
detail. Previously we mentioned that risk comes in three types, Ethical or GMP Risk (Items that would
cause a product recall), Business and Operational (financial) Risk, finally Safety or H&S Risk.

Risk in the V model
Only the Ethical Risk area needs to be validated 100%, during IQ and OQ testing, using the system
supplier to help determine the possible risk areas. In this approach, risk is defined as any one single
event that can create a fault condition, causing a GMP risk, such risks include:

Incorrect or contaminated pharmaceutical product
Incorrect assembly of the ‘unit of dose’ carrier (blister, bottle, vial...)
Incorrect packaging component in the final assembly (incorrect carton, missing or
incorrect label, missing or incorrect leaflet…)
Incorrect or illegible lot or batch identification

However the entire operational functionality of the machine needs also to be tested to prove that there
is no Business and Operational Risk affecting production capacity, or additional GMP risk to product
quality. This is also normally included in the system suppliers Validation and Factory Acceptance Testing
(FAT) of the machine, these risks include:

Poor packaging quality (cosmetic defects)
Excessive machine down time
Machine damage or wear
Excessive change-over times
Slow speed of operation



equipment and systems which have been in use for many years. © PAUL OSBORNE │ PPTECH LTD PAGE 45 . One definition of Risk Assessment is as follows: Systematic process of organising information to support a risk decision to be made within a risk management process (ICH Q9). there is also a requirement for system testing for business and operational risk and there may even be some requirement for validation testing for H&S risk.Finally H&S Risk – Although this is usually correct for new machinery regarding CE marking. and risk management Risk Assessment is a formal and systematic approach to identify GMP risks related to equipment and supporting systems. on older machines subject to retrospective validation there is often potential risk for injury by: · Guards not operating correctly · Exposed mechanisms causing human harm · Open electrical connections · Human contamination by API’s So there is a requirement for system validation testing for GMP risk. It is a very helpful tool that can be applied to plant. The use of risk analysis helps focus tests on what the machine or process should not do and what can go wrong. testing. rather than what it should do. There are various techniques for reducing risk. implementation. these are as follows in order of priority: In general. the documentation provided should: · Describe the design of the system (FS) · Document how your design was implemented · Demonstrate how the device produced by your design implementation was tested · Show that you identified hazards appropriately and managed risks effectively · Provide traceability to link together design. A good validation process with risk analysis will highlight many GMP issues that require standard operating and maintenance procedures to ensure the risks are correctly managed in the production environment.

Change Process or Approach . Physical. Deflection . so fewer people have access · Apply procedural control as the last resort (SOP) 1. · Apply technical controls.Risks can be managed in one of several ways: · Modify the work process in production and system · Modify the system design. Testing – Like avoidance. 3. Warning.Look at modifications to design to prevent an occurrence of the GMP risk. Absorption . 4. Prevention . Avoidance .Dependency on other systems – isolate dependencies to ‘shield’ the system. Procedural – Prevent the occurrence of the risk by procedural or operational controls. 5.Technical.Eliminate. seek to remove the risk or warn of its occurrence.Proof of negligible probability – analysis and testing of the risk to prove it is of little or no concern. 2. Control . PREVENT CONTROL ANALZSE © PAUL OSBORNE │ PPTECH LTD PAGE 46 .

Modification of project strategies to mitigate risk Revisit project structure and makeup: This refers to the people chosen for the project. such as double checking. their experience and qualifications.. the type of project organization preferred. Modify Product (or System) design: Use is made of proven methods.. tools and components. 2. 4.g. the amount of education and training provided. Modification of validation approach to mitigate risk Increased Testing: Increase the scope and level of testing applied during various stages of the validation process. 3. Introduce External Procedures: Introduction of procedures to counter possible failures. using replicated parts. © PAUL OSBORNE │ PPTECH LTD PAGE 47 . additional data verification checks within the system design in order to reduce data entry errors.g. the operating environment may be controlled. Modification of process or system design elements to mitigate risk Modify Process design: One or more independent controls are incorporated into the computer-related process e. Decreased Testing: Decrease the scope and level of testing applied during various phases of the validation process due to the extremely low risk associated with occurrence and consequences of the fault conditions. fault-tolerance may be built into the automated system (e. system mirroring). including the development of specialized testing aimed at the testing to failure of certain functions. Reconsider amount of (auditable) built-in quality: Alter the amount of documentation that is approved and controlled. Eliminate risk Avoidance: The risks are so high that the new way of working should not be implemented.Risk Mitigation Strategies 1. introduce or remove formal review points to reflect identified risk.

© PAUL OSBORNE │ PPTECH LTD PAGE 48 . It is similar to a control plan and cannot be used effectively without manual or automated process control methods. The main use of HACCP is with new manufacturing process or equipment.Failure Mode. It can lead to paralysis by analysis (infinite chains of cause and effect). FMEA should precede HAACP to identify critical hazards/failure modes. and then a HAACP could be an action to reduce risk in a FMEA. including statistical process control. Effects and Critically Analysis System impact & component criticality assessment FTA The Fault tree Analysis is a team-based method used to identify the causal chain that creates a hazard or a failure mode (effects are typically ignored). HACCP Hazard Analysis and Critical Control Points is a method of identifying and controlling sources of variation at critical process steps that could lead to a hazardous condition. it requires expert knowledge of the system under review. It also requires use of more complex statistical tools to be effective. Once causes are identified. Its limitation is that it requires excellent process knowledge. FTA example The limitations of FTA are that it requires time and resources. preventive action can be taken.Risk Management tools · · · · · FTA – Fault Tree Analysis HACCP – Hazard Analysis and Critical Control Points FEMA . it requires tools like Microsoft Visio or other specialized software to document it and it is more useful as a problem solving than a problem prevention tool. FTA represents the sequence and combination of possible events that may lead to a failure mode.Failure Mode and Effect Analysis FMECA .

while developing the means to put a man on the moon and return him safely to earth. Let us look at FMEA in more detail. or to Detect the risk early in its life cycle to minimize its effect The FMEA serves to provide the following services in risk analysis and risk mitigation: · · · · · · Breaks down a complex process in single steps Breaks down a complex equipment in single parts or functions Defines the function of each step / part Outlines malfunctions Defines steps / functions to reduce the risk Can prioritise risks. if possible. In the late 1970s the Ford Motor Company introduced FMEA to the automotive industry for safety and regulatory consideration. Occurrence (Likelihood) and Detection. FMEA must be initiated as early as possible during the design There are three areas of a potential risk to consider Severity. process. FMEA was formally introduced in the late 1940s for military usage by the US Armed Forces. or protecting the user from the effect.FEMA Analysis What is a FMEA? It is a team-based approach to ensure that sources of risk are identified and addressed through actions designed to: · · · Minimize the impact or severity of the risk Prevent the causes of risk from occurring. Severity Determine all failure modes based on the functional requirements and their effects and list them. © PAUL OSBORNE │ PPTECH LTD PAGE 49 . Hereafter the ultimate effect of each failure mode needs to be considered. see FMECA later The use of Failure Mode and Effects Analysis (FMEA) widely used in the electronics and medical device industries. Each effect is given a severity number (S) from 1 (no danger) to 10 (important). and Hazard Analysis and Critical Control Points (HACCP) techniques taken from the food industry are beginning to be thought of by the pharmaceutical industry as tools to augment cGMP. It is important to note that a failure mode in one system area can lead to a failure mode in another area. An example of this is the Apollo Space program. Later it was used for aerospace/rocket development to avoid errors in small sample sizes of costly rocket technology. The primary push came during the 1960s. If the severity of an effect has a number 9 or 10. or machine design change is needed to reduce risk. A FMEA is a cross-functional. concurrent engineering process: · · A FMEA is a living document and should be updated throughout the life of the product Because FMEA may determine that a facility. Therefore each failure mode should be listed in technical terms and for function. In this way it is convenient to write these effects down in terms of what the user might see or experience. A severity rating of 9 or 10 is generally reserved for those effects which would cause injury to a user or otherwise result in litigation. Examples of failure effects are: degraded performance or even injury to a user. These numbers help an engineer to prioritise the failure modes and their effects. actions are considered to change the design by eliminating the failure mode. A failure effect is defined as the result of a failure mode on the function of the system as perceived by the user.

This number represents the ability of planned tests and inspections at removing defects or detecting failure modes. Each combination from the previous 2 steps. it is necessary to test their efficiency. All the potential causes for a failure mode should be identified and documented. analysis. Hereafter one should identify testing. again 1-10. excessive voltage or improper operating conditions.Occurrence or Likelihood In this step it is necessary to look at the cause of a failure and how many times it occurs. The proper inspection methods need to be chosen. occurrence and detectability the RPN can be easily calculated by multiplying these 3 numbers: RPN = S x O x D. monitoring and other techniques that can be or have been used on similar systems to detect failures. A failure mode is given a probability number (O). After ranking the severity. FMEA in Operation RPN do not play an important part in the choice of an action against failure modes. Also design verification is needed. Again this should be in technical terms. This can be done by looking at similar products or processes and the failures that have been documented for them. This step is called the detailed development section of the FMEA process. First. Actions need to be determined if the occurrence is high (meaning >4 for non safety failure modes and >1 when the severity-number from step 1 is 9 or 10). that prevent failure modes from occurring or which detect the failure before it reaches the customer. receives a detection number (D). From these controls an engineer can learn how likely it is for a failure to be identified or detected. or in other words. They are more of a threshold values in the evaluation of these actions. Detection When appropriate actions are determined. that the chances of detection are low. A failure cause is looked upon as a design weakness. an engineer should look at the current controls of the system. Examples of causes are: incorrect algorithms. A high detection number indicates that the chances are high that the failure will escape detection. © PAUL OSBORNE │ PPTECH LTD PAGE 50 .

The failure modes that have the highest RPN should be given the highest priority for corrective action. These actions can include specific inspection. After these values are allocated. the new RPN should be checked. O and D This has to be done for the entire process and/or design. There could be less severe failures. recommended actions with targets. adding more redundancy and limiting environmental stresses or operating range. but which occur more often and are less detectable. These tests are often put in graphs. to confirm the improvements. high volume Once every 3 months 100% manual check. testing or quality procedures.Effect Severity S Occurrence O Detection Capability D 10 Injury Resulting / illegal More than once a day Failure not detectable 9 Illegal Once every 3-4 days Status Rating Bad 8 7 6 5 4 3 Good Product Unfit for Use Customer complaints Partial Failure of product Performance loss Major Performance loss Minor No performance loss Occasionally sampling only possible Some systematic sampling only possible Once per week Once per month 100% manual check. Once this is done it is easy to determine the areas of greatest concern. A few logical but important thoughts come in mind: · · · · Try to eliminate the failure mode (some failures are more preventable than others) Minimize the severity of the failure Reduce the occurrence of the failure mode Improve the detection © PAUL OSBORNE │ PPTECH LTD PAGE 51 . for easy visualisation. Whenever a design or a process changes. Once the actions have been implemented in the design/process. redesign (such as selection of new components). responsibility and dates of implementation are noted. low volume Once every 6 months Continuous SPC sampling and inspection Once per year SPC with action limits acceptable Once every 1-3 years 2 Minor effect only Once every 3-6 years 1 No noticeable effect Once every 6-100 years SPC and 100% inspection of units outside action limits Automatic inspection possible / automatic elimination Defect highly oblivious / easy automatic elimination Table of values for S. This means it is not always the failure modes with the highest severity numbers that should be treated first. an FMEA should be updated.

The goal is to lower each risk.GAMP 5 FMEA Within GAMP 5 there is a clear definition of the approach for validation testing using risk assessment. financial impact.Expected to have a minor negative impact. The impact could be expected to have short. Concentrate on handling the high risks and then the medium risks. the immediate effect of a hard disk problem may be the corruption of some data stored on that disk. The impact could be expected to have significant long-term effects and potentially catastrophic short-term effects. Status Bad GAMP Rating High 1 Medium 2 Low 3 Good Effect Severity S Likelihood L Injury Resulting / illegal Illegal More than once a day Once every 3-4 days Product Unfit for Use Once per week Customer complaints Once per month Partial Failure of product Once every 3 months Performance loss Major Once every 6 months Performance loss Minor Once per year No performance loss Once every 1-3 years Minor effect only Once every 3-6 years No noticeable effect Once every 6-100 years © PAUL OSBORNE │ PPTECH LTD PAGE 52 .Expected to have a moderate impact. High. The impact of a risk occurring may be described as follows: Low . Assess the Severity of Impact Risk Assessment requires not only the identification of the immediate effects of the risk but also the long term and widespread impact on the business of those effects. Medium . These effects must take into account a wide variety of issues. while the business impact of corrupt data relating to product distribution will eventually result in severe problems in conducting a product medium-term detrimental effects. including impact on regulatory compliance. The damage would not be expected to have a longterm detrimental effect.Expected to have a very significant negative impact. During risk assessment the impact of the risks to the system are decided and combined with the probability of the risks happening. and company reputation with customers and suppliers. For example. This would result in a critical non-compliance with the regulatory requirements and could result in regulatory action such as a withdrawn manufacturing license.

Medium . This is achieved by reference to the matrix shown here.. Qualitative Classification (S against L) Assign Probability of Detection The purpose of this stage in the assessment process is to identify if the risk event can be recognized or detected by other means in the system. then the team may need to seriously consider a review of the design or the implementation of alternative procedures to avoid the event. if it has a high probability of detection.g.. less than 1 event in every 3 transactions or operations).g.Detection of the fault condition is perceived to be unlikely (e. may not pose such a serious threat because it can be recognized quickly and suitable corrective action taken to mitigate its impact. I event in every 1 transaction or operation). Conversely if the same fault condition has a low probability of detection. High . © PAUL OSBORNE │ PPTECH LTD PAGE 53 . Hence a Level One Risk. the risk can be classified. 1 event in every 2 transactions or operations)..Assess Risk Classification Having assigned the Likelihood of the risk occurring and the level of Business Impact that such an event may have.Detection of the fault condition is perceived to be reasonably likely (e.g.Detection of the fault condition is perceived to be highly likely (e. The probability of a risk being detected can be estimated as follows: Low .

Once these priorities have been determined the team can proceed to define and document the appropriate measure(s) to mitigate the adverse event that poses the risk. low volume Continuous SPC sampling and inspection SPC with action limits acceptable High SPC and 100% inspection of units outside action limits Automatic inspection possible / automatic elimination Good Defect highly oblivious / easy automatic elimination Determine Appropriate Measures for Risk Mitigation By combining the Risk Classification with the Probability of Detection. Qualitative Prioritisation © PAUL OSBORNE │ PPTECH LTD PAGE 54 . high volume Medium 100% manual check. it is possible to prioritise the fault conditions associated with each adverse event based upon those areas of greatest vulnerability.Status Bad GAMP Rating Detection Capability D Low Failure not detectable Occasionally sampling only possible Some systematic sampling only possible 100% manual check.

It evaluates the risk and ranks the reduction activities. © PAUL OSBORNE │ PPTECH LTD PAGE 55 . Effects and Critically Analysis (FMECA) is the same as FMEA with the additional feature of investigation of the degree of: · · · Severity of the consequences Probability of occurrence Detectability of the failure Like FEMA it is mainly used in the design phase for equipment and processes.The analysis can be drawn on a table which becomes the master plan of risk mitigation. FMECA The Failure Mode.

archive.21 CFR Part 11 and Annex 11 If requested by the customer. maintain. retrieve or transmit any electronic records that are required? No ? Not Applicable Yes Is the system designed to exclusively transmit by electronic means? Yes ? Not Applicable No Do FDA regulations permit the use of electronic records for the required documentation? No Not Applicable ? Yes Is the system Open or Closed? Open ? Forward to Computer validation group Closed 21 CFR part 11 is applicable © PAUL OSBORNE │ PPTECH LTD PAGE 56 . modify. when is 21 CFR part 11 applicable ? Basic Classification Does the computerised system create.

however. Part 11 refers to electronic records and signatures.applies to all forms of computerised systems used as part of GMP regulated activities such as packaging. These are referred to as ER/ES systems © PAUL OSBORNE │ PPTECH LTD PAGE 57 . the approaches are complementary and collectively. Final revised Annex 11 published January 2011 and consequential amended to GMP Chapter 4 Documentation. electronic records and electronic signatures. Draft released for public consultation April 2008. they cover the broad issues that are associated with electronic records and signatures. to be equivalent to paper records and hand written signatures executed on paper. under certain circumstances. This is known as 21 CFR part 11. to deliver industry guidance relative to electronic information.’ Annex 11 refers to .5 . The Food and Drug Administration (FDA) in 1997 issued regulations that provide criteria for acceptance by FDA. which provide together an active and constructive co-operation in the field of GMP. Scope . PIC/S 21.Computerised Systems. recorded electronically. This is active at the end of June 2011. 21 CFR — concerns the protection of privacy. ISPE's GAMP Forum and the PDA have operated two separate initiatives.Pg 27 states: ‘When regulated users elect to use electronic records for GxP applications then it will be necessary for the companies to identify the particular regulations being applied and whether they are to be considered legally binding and equivalent to their paper-based counterparts. Electronic Signatures = Hand Written Signatures. So what’s new in the rule? · · Electronic Records = Paper Records. The Pharmaceutical Inspection Convention and Pharmaceutical Inspection Co-operation Scheme (jointly referred to as PIC/S) are two international agreements between countries and pharmaceutical inspection authorities. We are concerned with the GAMP interpretation of 21 CFR part 11. Both initiatives produced work products from different perspectives. but with close cooperation.The meaning of 21 CFR part 11 The meaning of 21 CFR part 11 is as follows.

Communication via secure network. Closed systems 7. Part 11 does not allow for grand fathering of legacy systems. The concerns are: Data Security – paper can be locked away · Data Integrity – paper can be seen to have been altered · Audit Trail Integrity – modifications to paper can be tracked · Signature Repudiation – physical signatures are used universally in industry For Part 11. Therefore. systems installed before August 20. data integrity is related to the trustworthiness of the electronic records generated and managed by critical systems.Reaching the ER/ES Model Can a supplier guarantee compliant system for Part 11? It is not possible for any supplier to offer a 'Part 11 compliant system'. administration) and administrative controls to be put in place by the user in addition to the technical controls that the supplier can offer. The Agency had stated often that they would take enforcement discretion if an organisation takes the appropriate steps to put a plan in place that addresses what systems need to be compliant and what the firm will do to get the systems there. or transmit electronic records must employ procedures and controls to ensure the authenticity. plus using open systems to create. © PAUL OSBORNE │ PPTECH LTD PAGE 58 . the supplier can offer an application containing the technical requirements of a compliant system. metadata can be configuration information for a device or equipment. Alternately. drug approval. Anyone who makes such a claim is incorrect. At best. In practical terms. Metadata must be stored as an integral part of the electronic document it describes.Access control by the company or group. modify. creation date. 7 All systems we discuss can be considered to be Closed. Open systems . it can be defined as 'data about data'. limiting system access. the types of metadata that can be associated with an electronic record may include: details of the record's creation. These plans must include all applicable systems. What is FDA position on timelines for implementation of 21 CFR Part 11? There is no fixed date for complete remediation. operations and authorities and Change control. What is 'metadata'? Literally.Company delegate’s control. Requirement . 1997 must be made compliant or replaced. · Some definitions What is 'grand fathering'? "Grand fathering" simply means the possibility that the rule may not apply to any system in existence before the rule came into effect. ownership. checks of devices. searchable keywords that can be used to classify the document and details of the type of data found in the document. integrity and the confidentiality of electronic records from the point of their creation to the point of their receipt. author.As closed systems.Validation of systems. be detailed and have reasonable timelines and hold persons responsible for implementing those plans. maintain. protection of records. See the later section on interaction for more details. Part 11 requires both procedural controls (training. manufacturing and quality assurance because these systems pose the most risk in terms of product quality and/or public safety. Communication control by the on-line service. Requirement . SOPs. The FDA is most concerned about systems that are involved with drug distribution.

the Public Health Service Act. Signatures serve as an authentication. Problems occur with loss. Physical or Behavioural. and he has to re-enter the user ID/password (shows awareness that he is executing a signature) and give the meaning for the e-sig.Electronic Signatures. theft or damage. Password – Private password known only to user – xxx123. retina scans etc. the date/time. This is the link between 21 CFR and the GMP regulations. for the following reasons. In Part 11. This however does not force any security regarding the operator making the changes and his proven ability to make these changes. There are two types of Biometric. fingerprint. we therefore need signatures to be able to have the log-in facility. A predicate rule is any requirements set forth in the Federal Food. They apply to the proper management of electronic records in addition to executing compliant electronic signatures. etc. Collaboration for falsification is required. states that signed e-records shall contain information associated with the signing that indicates the printed name of the signer. Non-Biometric signatures involve a pre-stored account name and a two part access code – user ID and password. will be shortened however to say . We are not submitting documents. Therefore a more sophisticated system is required. and password The names are to be printed out © PAUL OSBORNE │ PPTECH LTD PAGE 59 . to identify individuals. The predicate rules mandate what records must be maintained. To support this. The operator has to indicate intent when signing something. Are these requirements only applicable if your system is utilizing e-signatures? It seems that these should be applicable to any system with e-records? The controls for password/user ID usage apply across the board for ERES systems. Can a single restricted login suffice as an electronic signature? No.Using a unique electronic tag system to identify the individual. The Software for good biometrics is still in an immature phase.voice.‘Osborne’. Within 21 CFR this is permitted in three ways: · · · Token systems Biometrics Two part passwords Most companies have concentrated on method three. or any FDA regulation (GxP: GLP.D. Drug and Cosmetic Act.Repudiation by the Log-in mechanism. The system requires this token as the access mechanism. the content of records. not used for log in but for full identification of the user ‘Paul M Osborne’. and that these items shall be included in any human readable form of the record.). and the meaning. Account name – Recorded in the system only. how long records must be maintained.50. Biometric signatures use fingerprints. Part 11 §11. controls for identification codes/passwords usage is listed under Subpart C -. face etc. In previous control systems the access method for controlling the system has been via a simple key-switch system. Problems occur with changes to the characteristic used for the biometric identification . · · The two part passwords have a unique combination of I. GMP. Token systems for signatures . whether signatures are required. This must be unique. User Name – Publicly known name of user. etc.When are e-signatures required? The predicate rules mandate when a regulated document needs to be signed. GCP.300. Signature .

4. Can a complete copy of records or a complete backup be provided both in electronic record and in readable form? Are all backups readable over the retention period? © PAUL OSBORNE │ PPTECH LTD Section 11. In the audit trail user must be identified by their full name.10(e) Classification Supplier 11. Audit trails of electronic records record the following: WHO. WHEN and WHY was a change made to a record. The Administrator can also be suspended by a repeated failure of log-in.3.10(e) PAGE 60 Supplier . Classification for 21 CFR part 11 applicable systems The equipment which is 21 CFR part 11 applicable has to be classified into different Classifications (Supplier or Customer) according to the paragraphs of the FDA rules.10(a) 11. or be just suspended by a repeated failed log-in. WHAT.300(b) 11. although another control usually requires recording this information. All rules outside of the influence of the supplier are classified as ‘customer’ and must be dealt with by the customer.100(a) Classification Supplier Data storage 21 CFR Rule – Data Security Can record changes always be identified? (The records are defined as the creation.10(b) 11.300(d) 11.10(c) 11. or edited by the Administrator. Log-in procedures 21 CFR Rule – Access control and Security Is system access limited to authorized Individuals? (user ID and password) Are there means to identify and authenticate all connected devices? Does the system ensure uniqueness of code and password? Do passwords periodically expire and need to be revised? Will attempts of unauthorized access be detected? Does the system prevent reuse of user ID’s? Section 11. are to be included in any human readable form of the record The system therefore verifies the identity of the user We need to periodically revise We need to follow loss-management procedures After 3 log-in attempts the user is ‘suspended’ Users can be suspended deleted.10(g) 11. etc.· · · · · The meaning such as issue 1.10(d) 11. However please note that Part 11 itself does not require the audit trail to record the reason why a record was changed. modification or deletion of product configuration and actual production data). This record could be the configuration of a scanning head for example.10(h) 11. The audit trail identifies operators by their log in names and from this knows the full name.300(a) 11.

200 (a)(1) 11.70 11.200 (a)(1) 11. reviewed) Are signatures linked to their respective electronic records? Are non-biometric signatures made up of least two components.200 (a)(1) 11. modification or deletion of product centric configuration data). is the password executed at each signing? (Note: both components must be executed at the first signing of a session). When several non-biometric signings are made during a continuous session.Audit trail and general controls 21 CFR Rule – Audit trail and general controls Are secure computer generated time stamped audit trials available for review and copy? (The records are defined as the creation. If signings are not done in a continuous session.50(a) 11. such as an identification code and password. Does the audit trail capture modifications without obscuring previously recorded information? Do signed electronic records contain the following related information? The printed name of signer (user ID alone is not acceptable) The date and time of signing The meaning of the signing (such as approved.50(b) PAGE 61 Classification Supplier . are both components of the non-biometric electronic signature executed with each signing? Is the above information shown on screen based any printed copies of the electronic record? © PAUL OSBORNE │ PPTECH LTD Section 11.10(e) 11.10(e) 11.

10(k) (2) Customer Supplier system validation protocols SOP Application software and SOP SOP PAGE 62 .10(c) Customer 11. authorized.10(d) Customer Supplier responsibility 11.10(i) Supplier SOP 11.10(a) Classification Supplier 11.10(k) (1) Customer SOP 11.10(j) Customer SOP 11.10(c) Customer Application software 11. access to. periodically assessed and controlled over the retention period of the system? Is there documented training.10(c) Customer 11. and use of systems operation and maintenance documentation controlled? Is there a formal change control procedure for system Documentation that maintains a time sequenced audit trail of changes? © PAUL OSBORNE │ PPTECH LTD Section 11. Including CV'S and on the job training for system developers and support staff? Is there a written policy that makes Individuals fully accountable and responsible for actions Initiated under their electronic signature? Is the distribution of.Interaction 21 CFR Rule – General controls Is the system validated? Can a vendor audit or qualification be performed? Is a retention period for records defined in a procedure? Is there a backup and restore procedure? Is there a defined procedure for maintaining the records throughout the retention period? Is system access defined.

It is of course possible to change these access rights according to individual company policy. Reset of warnings and alarms (or automatic reset) Viewing of counters Reset of counters View device parameters Control (modify) device parameters View product data Control (modify) product data Report generation Audit trail access and export User management © PAUL OSBORNE │ PPTECH LTD ü ü ü ü ü ü ü ü ü ü ü ü ü ü ü PAGE 63 Administrator Supervisor Default Functionality Line Operator Below are the suggested default user access rights for the system as the system is delivered. ü ü ü ü ü ü ü ü ü ü ü . these are as follows: User access control Viewing of warnings and alarms.Practical implementation of 21 CFR part 11 applicable systems The implementation of 21 CFR part 11 controls into a system can be divided into a number of relevant sections.

comparison in password Password duration in days Maximum password length Minimum password length Lowercase chars obliged in password Numeric chars obliged in password Special chars obliged in password Uppercase chars obliged in password Maximum number of password retries Number of reused password Timeout Lowercase characters are allowed in passwords. Number of days a password will expires for long inactivity. Set to True/False. All previously used passwords can be reused. At least one numeric character must be entered in passwords. Numeric characters are allowed in passwords. if a non-positive number is set no password will be checked. Set to True/False.Password Controls The following parameters control the password use. The maximum password length in characters. Set to True/False. At least one lowercase character must be entered in passwords. if a non-positive number is set no password will expire. before the user will be blocked. Number of days a password can live before expiring. The maximum number managed in the system is six. if a nonpositive number is set no password will expire. Name Operation Lowercase chars allowed in password Numeric chars allowed in password Special chars allowed in password Uppercase chars allowed in password Password inactivity limit (days) Case sensitive. Special characters are allowed in passwords. Set to True/False. The minimum password length in characters. Set to True/False. Number of previously used passwords that cannot be entered as new password. At least one uppercase character must be entered in passwords. The maximum inactivity time in minutes before the system automatically logs the user out. Set to True/False. If a nonpositive number is entered. Uppercase characters are allowed in passwords. if a non-positive number is set no log out is made. At least one special character must be entered in passwords. Set to True/False. © PAUL OSBORNE │ PPTECH LTD PAGE 64 . If a nonpositive number is entered an infinite number of retries will be permitted. Set to True/False. Set to True/False. Maximum number of retries when entering a wrong password will expires for long inactivity. if a non-positive number is set no password will be checked. Make case sensitive password comparisons.

the product data is displayed as a chronological list of events: the title of the product. the old value and the type of modification (e.e. Additionally any change to the user accounts is logged. Modified or Accepted (What was changed) Description of event. It is not a production record of system. Created. this includes all production relevant data. difference to the previous status (old and new values) Please note in the above we do not record why the change was made. All GMP relevant product data is captured during a production batch.g. insert. the user cannot influence the audit trail process. delete. the full user name. modify). modified or deleted. Deleted. · · · The Audit trail designed into the system is a recorded series of chronological events that monitor any GMP relevant changes to the product or system configuration. the following items are now viewed: · · · · · Name of product Timestamp of event (format: YYYY-MM-DD HH:MM:SS) (When it was changed) Account that caused the event and with his complete user name (Who changed it) Event i. Audit trail recording is always active and it is on for the entire life of the system. The security audit trail history contains the user name of the user. the new value. the date and time stamp when the record was created. this is not in the regulation but a small field can be provided for comments. © PAUL OSBORNE │ PPTECH LTD PAGE 65 . the time and date at which the event occurred and what the event was: · · · · Created – new product was created Deleted – product deleted Modified – product was modified Accepted – the new product was accepted and saved (if this method is adopted) By selecting a product for further investigation.Audit Trail We must ensure that an audit trail is maintained. However Batch reports are usually a customer requirement The previous changes made to the audit trail must not be overwritten by subsequent changes The sections of the audit trail required fall into a number of major categories Product Parameters Select a product from the audit trail list of all products and in the ‘view audit trail’ menu.

e. Suspended.System Parameters Select system parameters from the audit trail list and in the ‘view audit trail’ menu. Created.e. the following items are now viewed: · · · · · Name of Account Timestamp of event (format: YYYY-MM-DD HH:MM:SS) (When it was changed) Account that caused the event and with his complete user name (Who changed it) Event i. Modified or Accepted (What was changed) Description of event. the time and date at which the event occurred and what the event was: · · · · · Created Suspended Deleted Reactivated Modified By selecting a user event for further investigation. Deleted. User Administration Select a user from the audit trail list of all users and in the ‘view audit trail’ menu the number of the user is displayed as a chronological list of events. this is not in the regulation but a small field can be provided for comments. Modified or Reactivated (What was changed) Description of event. difference to the previous status (old and new values) Please note in the above we do not record why the change was made. the username and details of the account. the system data is displayed as a list of parameters: the time and date at which the change occurred and what the change was: · · Modified – parameter was modified Accepted – the new parameter was accepted and saved (if this method is adopted) By selecting a parameter for further investigation. the following items are now viewed: · · · · · Name of parameter Timestamp of event (format: YYYY-MM-DD HH:MM:SS) (When it was changed) Account that caused the event and with his complete user name (Who changed it) Event i. difference to the previous status (old and new values) © PAUL OSBORNE │ PPTECH LTD PAGE 66 .

User Management: This screen shows all details about any user management changes made in the selected batch. Alarms: all details about the alarms generated in the history of the selected production batch. Batch counts for current batch. Alarms: all details about the alarms generated in the history of the current production batch. System Parameters: all parameters that are related to the operation of the C-TTS system for the selected batch. System Parameters: all parameters that are related to the operation of the C-TTS system for the current batch. Batch counts for that batch.Reports for the system The system should supply the following reports: Current batch report Status: the status of the system showing correctly functioning items. © PAUL OSBORNE │ PPTECH LTD PAGE 67 . Warnings: all details about the warnings generated in the history of the selected production batch. Historical batch report Status: the status of the system showing correctly functioning items for a given batch. Warnings: all details about the warnings generated in the history of the current production batch. User Management: This screen shows all details about any user management changes made in the current batch.

data integrity and product quality. Draft released for public consultation April 2008. as amended by Directive 2003/94/EC. © PAUL OSBORNE │ PPTECH LTD PAGE 68 . In the UK this is the so-called ‘Orange Guide’ known by all pharmaceutical manufacturers as the ‘bible’ of drug manufacturing. Final revised Annex 11 published January 2011 and consequential amended to GMP Chapter 4 Documentation. Key Points in the Annex Risk Risk management should be applied throughout the lifecycle of the computerised system.Computerised Systems. EU Guidelines to Good Manufacturing Practice. Covered by EU Commission Directives 91/356/EEC.applies to all forms of computerised systems used as part of GMP regulated activities such as packaging. and 91/412/EEC respectively. taking into account patient safety.Annex 11 – Computerised systems Volume 4. Active at the end of June 2011. As part of a risk management system. Scope . Annex 11 refers to . Medicinal Products for Human and Veterinary Use. decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system.

Supplier and Service providers [When] third parties (e.g. The need for an audit should be based on a risk assessment. [Then] . via remote access). suppliers. install. service providers) are used e. ITdepartments should be considered analogous. validate. Validation Manufacturers should be able to justify their standards. © PAUL OSBORNE │ PPTECH LTD PAGE 69 . protocols.g. formal agreements must exist between the manufacturer and any third parties and these agreements should include clear statements of the responsibilities of the third party. configure.. acceptance criteria. integrate. to provide.. procedures and records based on their risk assessment.g. Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request. maintain (e. modify or retain a computerised system or related service or for data processing.

Automated testing tools and test environments should have documented assessments for their adequacy. system (process) parameter limits.Data Migration If data are transferred to another data format or system. to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated "audit trail") Physical and/or logical controls should be in place to restrict access to computerized system to authorised persons Data may be archived. Particularly. there should be an additional check on the accuracy of the data. For critical data entered manually. validation should include checks that data are not altered in value and/or meaning during this migration process. Electronic Signatures Have the same impact as hand-written signatures. This data should be checked for accessibility. · · · · · · · · · This check may be done by a second operator or by validated electronic means Data should be secured by both physical and electronic means against damage Stored data should be checked for accessibility. in order to minimize the risks. © PAUL OSBORNE │ PPTECH LTD PAGE 70 . Permanently linked to their respective record Include the time and date. based on a risk assessment. readability and accuracy Access to data should be ensured throughout the retention period Regular back-ups of all relevant data Integrity and accuracy of backup data and the ability to restore the data should be checked during validation and monitored periodically Consideration should be given. data limits and error handling should be considered. Data Integrity Computerised systems exchanging data electronically with other systems should include appropriate built-in checks for the correct and secure entry and processing of data. readability and integrity Testing Evidence of appropriate test methods and test scenarios should be demonstrated.

in their words to ’leverage supplier involvement’. so this means that suppliers can adopt their own documentation formats and providing the above applies. you are most likely to be working with documentation such as: · · · · · · · Procedures Test reports Certificates Manuals Validations Functional Specifications Drawings Documentation is critical to GMP and validation. then the documentation should be considered as acceptable. There should be flexibility regarding acceptable format.’ Documentation is any written record of information used for quality assurance. The considerations to be made in good documentation practice are well defined in GAMP 5 and are as follows: · The GMPs require written records and the definition of validation contains the words ‘documented evidence. everything you do must be documented. proof of meeting those requirements is expected in writing. GAMP 5 has tried to rectify this by making the following statements: Justification for the use of supplier documentation should be provided by the satisfactory outcome of supplier assessments. or it is like you didn't do it. and we mean everything.Good documentation practice The pre-validation documentation set should be supplied to the pharmaceutical company along with or shortly after the equipment. Major pharmaceutical companies have expended large amounts of money creating all supplier validation documentation in their standard format. This has often meant teams of either supplier or manufacturer’s technical teams rewriting documentation sets. Also keep in mind that information written on a piece of paper may not be acceptable to the pharmaceutical industry if it doesn't meet their standards for proper documentation. In supplying equipment to the pharmaceutical industry. Remember that the validation process must occur before the end customer can product drug. It's not that the pharmaceutical people don't trust their suppliers. structure and documentation practices So GAMP 5 sets out. therefore the prevalidation documentation set is as important to the end customer as the equipment itself. which may include supplier audits · Documentation should be assessed for suitability. In this industry. evidence of adherence to specifications. To date. You have to prove everything in writing. Keep in mind that when requirements are specified as part of an order. © PAUL OSBORNE │ PPTECH LTD PAGE 71 . or any validation purposes. this way the company can begin the validation immediately. accuracy and completeness. but these are the rules. This is clearly a wasteful and unneeded practice.

An acceptable rule is to always use dark. mass-produced instruction manuals are also documentation. This seems like requiring two people to do the work of one. printed. there are blank lines for these signatures at the bottom of each page or on the cover page of a package of multiple sheets. dated. Rule 2 Never Obliterate Data When you need to make changes to documented information.’ The preparation of master production and control records shall be described in a written procedure and such written procedure shall be followed. handwritten) by one person and independently checked. The rules come into play when information about specific equipment is documented as part of the official documentation provided to the pharmaceutical companies. but these are generally accepted without question as proper documentation.Commercially supplied. and signed and dated by a second person who checks the work to make sure it is correct. the FDA and other authorities expect this as well. with handwritten information) should be signed and dated by the person who did the work. Rule 3 All Record must be signed twice All manual records (forms. I know some people argue that blue should be the standard. The convention used to be to use only black ink. Some people think this means the second person has to look over the shoulder of the first person to make sure everything is done right. Rule 1 All entries must be in Permanent Ink Any information written. etc. dated. These are good industry conventions that have become the accepted standards. but ink colour is not specified in the GMPs. and signed by a second person. Therefore. The GMPs mention that records ‘shall be prepared. One person does the work and one person checks it. This is where they expect the rules described below to be followed. This is based on the belief that black can be copied more easily than other colours. certificates. There are differences of opinion.. Usually. We refer to these as the pharmaceutical industry's expectations because these documentation rules are not all stated in the federal regulations. a costly requirement. permanent ink (a lot of companies insist on blue). This is common practice for documentation in the pharmaceutical industry. always do the following: · · · · Strike out the original entry with a single line Rewrite the entry Write a brief explanation of why it was changed Initial and date the change Never do either of the following: · · Obliterate the original entry by scribbling over it or writing over it Cover up the original entry using white paint These are standard practices in banking as well as GMP businesses. © PAUL OSBORNE │ PPTECH LTD PAGE 72 . or drawn must be done using ink or some other method that cannot be erased or altered (pencils and erasable pens are not acceptable). since it distinguishes original from the copy. and signed (full signature.

If the data is printed out and the paper copy is signed by hand. keep the original data and give them or a copy of them to the pharmaceutical company. Think of it as signing a contract. The original records contain the information as it was first recorded. that the first person did do the work. and security. the computer file is the original data. always keep the original records. Do not copy raw data into another form and discard the original. This means copying things incorrectly or making mistakes when entering data onto another form or into a computer. do not write the original entries on scrap paper and copy it over onto the form you intend to turn over to the pharmaceutical company. They have been known to ask pharmaceutical companies questions such as. "Where's the real data?" If the data are being typed directly into a computer as it is originally recorded. Could somebody go into the computer and change a piece of information and then reprint the document without your knowing © PAUL OSBORNE │ PPTECH LTD PAGE 73 . they will pick up on this. If you print out the results in a formal. There is always the concern of transposition error. and that the work is complete and correct. the FDA and other authorities get concerned about data integrity. since this person would know what is going on and what the form should look like when it is filled out. but you still need to provide the pharmaceutical company with copies of the original data entries. etc. If this information is GMP documentation (calibration certificates. Remember that neatness doesn't count. This second person is typically a supervisor or co-worker. The regulations for electronic approval are more complex. There can also be more than two signatures. cleaning records. computerized summary report. The master copy or original is stored in the computer and it can be printed out as an approved document directly from the computer. You must be sure that what you think you signed is the same as what may be printed out in the future. The concern here is making sure no changes have been made to what you signed. information manipulation. that's great. since the customer knows what the requirements are. ‘Has this information been altered?’ That is one of the reasons we need two persons to approve the documents and attest to their accuracy. All copies of this data should be obtained by photocopying or reproducing an exact copy of the signed master document. But there must be at least two. This is accomplished either by printing out the data and signing it by hand as described in Rule 3. there will always be the lingering question. there can be as many as you want.What is needed is for the person who did the work to sign and date the form to verify the work was completed correctly.). or it can be approved electronically. Since it is possible to change data in a computer file. These data still need to be signed and reviewed. Always enter the information directly onto a form. That means the second person must have an understanding of what the work involves and what the results should be. Remember that these signatures must be in permanent ink. Even if this information is going to be entered into a computer and printed in a formal report. Approving the data electronically means the data in the computer file can be approved in the computer without printing it out. With electronic forms. The second person signs the form to verify that he or she reviewed the first person's work. This also provides a record of who did the work and when. The second person can also be a customer representative. this signed paper copy becomes the original or master copy of the data. but accuracy does. If FDA or other inspectors see typed reports or perfect handwritten documents without mistakes. Rule 4 Original Records are the most important For data that are manually recorded (handwritten as they are measured or read).

Following procedures and using accepted standards is always the right thing to do. If more information is provided for the testing of one piece of equipment than for another similar piece.This unit is electrically heated. the FDA and other authorities like to see these standard certificate-type forms. Pharmaceutical companies. It shows that you are doing something consistently and are following widely accepted methods. and it's also GMP. This method of documentation is easier to write up and easier to review than free-form information. If there is reason information doesn't need to be entered. This way the pharmaceutical company knows that this work needs to be completed. you may accidentally leave out some important piece of information and it may not be easy to follow the information. If it is something you should have completed but didn't. This is especially helpful for repetitious jobs such as inspection or calibration or testing. the appropriate entry would be: Steam Supply Pressure: N/ A . The FDA. the blank should be filled in N/A or Not Applicable and a brief reason should be stated. Items left blank . If it's not applicable or not required. You won't give more information for one thing and less for another. take out blank pages. It looks as if someone forgot to complete something or didn't finish things or intentionally left something out or never got back to it. Rule 6 Leave no Missing Information Complete all the entries on data forms.about it or being able to do anything about it? This is what the FDA's concern is with electronic GMP documents. If you calibrated an instrument and recorded all the readings and adjustments on a blank sheet of paper. there are blank lines to remind you of every piece of information you should be recording. Rule 7 Reference Procedures and Standards Wherever Possible The pharmaceutical industry thrives on standardization and consistency to ensure quality. it's not clear whether anything was checked. If it's not filled in. they may think something is being covered up or no control is being maintained over the work done. © PAUL OSBORNE │ PPTECH LTD PAGE 74 . it's important to check. This shows consistency and it shows that a standard procedure is being followed. Do not leave missing information or gaps or blanks. If you have a pre-printed form. It also makes understanding the paperwork much easier. effective August 1997) is detailed in this book. By putting something in the blank. even worse do not leave completely blank pages. other authorities and pharmaceutical people can pick out inconsistencies right away. This is something you can do to save yourself questions later. just say so. The final ruling on electronic signatures was recently published in the Federal Register by the FDA (21CFR 11. it shows that someone checked into this item and thought about it. Fill in all the blanks.this is something that draws questions right away: ‘Why didn't you do it?’ will be the question. If this information entry is in the documentation. Rule 5 Use Templates and Forms Standardised fill-in-the-blank forms are the preferred way to document manually entered information. this saves you the trouble of writing everything you do as you do it. and there often is. The pharmaceutical company is going to want to know why there are blank items because it may be asked by the FDA or any other regulatory authority and it needs to have a good answer. when you have a form. Honesty is the best policy. This ensures that your paperwork is consistent and easy to follow. it's still better to write "Not Tested" or "Needs To Be Retested" than to leave it blank. In this example. Also.

reviewed. they can be manufacturer's procedures (maintenance procedures. The GMPs require that written procedures must be in place: There shall be written procedures for production and process control designed to assure that the drug products have the identity. if they agree with the procedure that was followed. These are an important part of the documentation that the pharmaceutical companies need to validate the equipment. Having a procedure and referencing it in the documentation shows consistency and provides a level of assurance that the work was done the right way. These standards should be referenced or noted in the documentation of the data provided to the pharmaceutical companies. quality. schematics. Such procedures shall include all requirements in this subpart. shall be drafted. All the piping flows should be as they are depicted in the drawings. To show the FDA and other authorities that the equipment is suitable and in a state of control. flow charts. the pharmaceutical industry also expects adherence to standards for quantitative measures. This means quantitative information or data must be traceable to an accepted standard of measure to be used for GMP purposes. Procedures can be internally generated (procedures that you write up). written procedures or accepted standards should be followed and this should be noted in the documentation supplied to the pharmaceutical company. Written production and process control procedures shall be followed in the execution of the various production and process control functions and shall be documented at the time of performance. All the wires should connect to the components and terminals indicated in the diagrams. Any deviation from the written procedures shall be recorded and justified. For example. they will most likely have to redo the work to generate information that can be used for validation. calibration procedures. All the drawings should contain the most current correct information. All this information on the drawing should correlate with what is installed in the equipment. and approved by the appropriate organizational units and reviewed and approved by the quality control unit. All the components included in the equipment should be noted in the drawings and all the components included in the drawing should be installed in the equipment unless specifically noted. Rule 8 Drawings should be an accurate representation of the equipment being supplied This rule applies to drawings. However. so they must be correct. and purity they purport or are represented to possess. Examples of GMP/validation-related information supplied to pharmaceutical companies are: · · · · Validation records Calibration records Installation records Inspection reports In addition to following standard procedures. installation drawings.). This means someone calibrated either the measuring device or the instrument used to calibrate the measuring device. including any changes. all the wire numbers or valve IDs should match the tags in the equipment. These written procedures.Whenever validation or GMP work is being done for the pharmaceutical companies. the pharmaceutical company needs to understand how it works. strength. installation procedures. etc. wiring diagrams. if no procedure was followed. The © PAUL OSBORNE │ PPTECH LTD PAGE 75 . or they can be industry-accepted procedures such as standards published by professional organisations. Information generated based on a written procedure may be used by the pharmaceutical people as part of their validation data. and layout drawings. it needs to have accurate drawings and diagrams. An example of quantitative standards is measuring devices whose accuracy is traceable to standards. piping diagrams. To accomplish this.

not something different. they should be given all the manuals they need to properly operate. file names. they should be confident that this is what the equipment is. the manuals needed are the manuals for each of the components listed. not something similar. The drawings supplied to the pharmaceutical company should be the final updates with all the changes included so that the drawings accurately represent the equipment. drawing numbers. These manuals should include individual component manuals and system manuals for complex multi component systems. The drawings should contain accurate identification information for traceability to the original project. and/or user manuals. maintenance manuals. service manuals. maintain. This list of component manuals includes: · · · · · · · · · Conveyor line Controllers Pumps Balances Cameras Printers Motors Solenoid valves Ejection Mechanisms In addition. As an example.bottom line is that when someone looks at these drawings. and understand the equipment. This means that someone who is familiar with the equipment. conveyors. and controllers is a multi-component equipment system. but exactly what is shown. the system manuals include: · · · · · · · · Operation of the filling line Safety guidelines Proper settings and set-up procedures How to run the line-sequence of operations Maintenance of the filling line Routine preventive maintenance Non-routine repairs Troubleshooting guidelines © PAUL OSBORNE │ PPTECH LTD PAGE 76 . This means all the information noted on the drawings (model numbers. etc. Final drawings should be certified "As-Built" before they are turned over to the pharmaceutical company. serial numbers. It is then customary to stamp or sign the drawing "As-Built" with the signature of the person who verified its accuracy. See Rule #2. This includes all operations manuals. Any changes made to the equipment before its release to the pharmaceutical company should be noted on the drawings. plus a general operating and maintenance manual for the entire line. Rule 9 Provide all the Manuals with the Equipment When the equipment or system is delivered to pharmaceutical companies.) should be verified as accurate. a production line that contains motors. Handwritten changes to drawings should be handled in the same manner as handwritten changes to other types of documentation. check-weighers. has reviewed the drawing and verified its accuracy. project numbers. instruction manuals. such as a design engineer or mechanic. In this case. revisions dates.

In addition. it is important to let the pharmaceutical companies know this as soon as possible. My recommendation to avoid a lot of stress and headaches is to put everything into one neat package. Don't assume they will accept the equipment and wait to get the complete documentation package. The up side of this is that you can please the customers by doing these little things without adding a lot of extra cost to the project. These are the written procedures they need to follow to ensure GMP compliance when they use this equipment. make sure the turnover package is complete. The best way to provide the information and paperwork to pharmaceutical companies is to put them all together in one package and give that to them with the equipment. separate the sections by tabs and put in an index. If this information is going to be delayed for any length of time. All of this information is important to ensure that the pharmaceutical people know how to properly operate and maintain the equipment so it will consistently produce quality drug products. Remember these rules when you submit paperwork to the pharmaceutical companies. The manuals must be appropriate (correct revision and model numbers. This is the ideal scenario. Sending things to the pharmaceutical company in dribs and drabs over an extended time typically results in things being misplaced. Remember that they cannot use the equipment to make drug products until it has been validated. Whatever happens.) for the equipment. this way they have what they need to start working on validation right away. By the time the equipment is delivered. It's always easier to get them right the first time.Individual component manuals are usually produced by the component manufacturer. but in this business paperwork is valuable because of the reasons mentioned earlier. like a binder or series of binders. the turnover package is provided to the pharmaceutical company at the same time as the equipment. there may only be one or two persons who were involved in the planning stage. This sounds like trivial stuff that shouldn't be nearly as important as the equipment. If you want to impress the pharmaceutical people. This is what we refer to as the prevalidation package or turnover package. Otherwise. or lost. and it is provided to the pharmaceutical company in a timely manner. the documentation is up to date. the people involved in the project typically change over its life. This was typically because: · · · · The people who did the original work were working on other projects The extra time needed to fix the paperwork was not in the original budget It was not possible to generate the information after the fact (the information was not recorded when the work was done) The supplier didn't realise this information was important © PAUL OSBORNE │ PPTECH LTD PAGE 77 . These are the things they are looking for and expect. and they cannot validate the equipment without all the necessary documentation. What if the pharmaceutical companies want to see some of the documentation before the equipment is delivered? Provide them with copies of what they want as a PDF. etc. they will keep after you until they get what they need. and hand it in all at once. forgotten. and the system manual is usually produced by the equipment system manufacturer. This turnover package has a significant value to them in getting on-line as quickly as possible. The turnover package is the official master copy of the documentation they will use for validation. but still keep a printed copy for the turnover package. I have been involved in projects where it took months to fix the paperwork. In the ideal scenario.

while the project completion time got longer and tempers got shorter. Now the trend is to write the result as follows: Have all acceptance criteria been met Yes/No?: __________ Rule 11 detailing the actual result During testing it is necessary to detail the actual result and not just write ‘as specified’.Meanwhile. Believe me. take the extra time needed to make sure the paperwork will be acceptable to the pharmaceutical companies before you submit it. previously it was acceptable to write: Did the system pass the test Yes ( ) No ( ). the paperwork went back and forth. The specifics of these rules are not detailed in the USA federal regulations or un ant EU regulations It is important to know and understand the rules to provide acceptable documentation to pharmaceutical companies Rule 10 No Tick boxes The current trend is not to allow the use of tick boxes at all. Please remember: · · · · Documentation is an important part of GMP compliance and validation Validation documentation is recorded information that is used to provide evidence of quality and adherence to specifications The pharmaceutical industry has standard practices for acceptable documentation. below is an example: © PAUL OSBORNE │ PPTECH LTD PAGE 78 . It could save you a lot of unnecessary headaches later.

The following Supplier risk assessment is based on the Parenteral Drug Association (PDA) Technical Report number 32. Supplier assessment should answer the questions: ‘What type of assurance do you have that the software has been validated during development" or ‘How can you be sure that the software supplier followed a quality assurance program?’. Depending on the risk and impact on (drug) product quality answers can be derived from: 1. Assessment checklists (mail audits). e. 3rd party audits. Gives an independent assessment of the quality system and/or product development. through public organizations.Company Audits The objective of supplier qualification is to get assurance that the supplier’s products development and manufacturing practices meet the requirements of the user’s company. Gives a good picture on the supplier’s quality system and software development and validation practices. Use checklists available within your company. 3.g. Product risk 2. PDA and from private authors. External references. regarding quality.g. 4. For software development this usually means that the software is developed and validated following documented procedures. pharmaceutical Experience with the supplier © PAUL OSBORNE │ PPTECH LTD PAGE 79 .’ The audit scope includes two parts: 1. Documentation of experience with the supplier. through networks · Impact of the system on drug quality · Impact of the system on business continuity · Level of customization Factors for supplier risk include: · · · · · Size of company Company history Future outlook Representation in target industry e. Experience may come from the product under consideration or from other products..g. One point of interest is that the principal supplier is responsible for the auditing of sub-suppliers if they are working outside the QMS of the principal. e. This means the principle supplier himself must make the above assessment on his sub-supplier and provide documentary evidence.. Useful if there is no experience within the supplier. published in October 1999 entitled ‘Auditing of Suppliers Providing Computer Products and Services for Regulated Pharmaceutical Operations. 2. Direct supplier audits. 5. Supplier risk Factors for product risk include: · System complexity · Number of systems to be purchased · Maturity of the system · Level of networking · Influence on other systems.

more consistent. The checklist is one element of the Supplier Audit Guideline written by most large pharmaceutical companies. Module Number Topics 1 Supplier Organisation 2 Viability 3 Quality Management System (QMS) 4 Systems Lifecycle Procedures (SLC) 5 Document Control 6 Requirements and Design 7 Electronic Record and Electronic Signature 8 Programming 9 Security 10 Testing 11 Change Control 12 Support © PAUL OSBORNE │ PPTECH LTD PAGE 80 . Most will follow the procedure of auditing the following topics within a supplier’s organisation. and ensure proper audit coverage. faster.The Supplier Audit Checklist is intended as an aid to make supplier auditing easier.

The supplier can demonstrate how the quality responsibilities are assigned to member(s) of the supplier’s organization who are independent of development. management. The supplier uses documented practices to control the preparation.Supplier Organisation . 2. testing. issuance. Requirements and Design . in place to ensure the quality of computer system development. For Bespoke Hardware. approval.General Expectations: 1.General Expectation: 1. The supplier has written qualification requirements or job descriptions for persons in the positions that impact the computer system.General Expectations: 1. 3. the supplier has applicable hardware layout diagrams for the system. and control. or equivalent. The supplier has evidence that key personnel maintain the education. SLC Procedures .General Expectations: 1. and modification of documents related to the computer system. © PAUL OSBORNE │ PPTECH LTD PAGE 81 . The source code is available for any required regulatory review or use in the event the product can no longer be supported by the supplier. The supplier has a Quality Management System. validation. The supplier maintains current Requirements indicating the required content of functions for the computer system. 2. 3. Document Control . New releases of the system will enable the user to access or convert data created by previous releases. 2. and training required for their positions. The supplier’s written SLC procedures adequately address applicable regulatory expectations for these procedures.General Expectations: 1. 4. The system’s viability is not at risk from associations with third party or contracted products or services. The supplier has evidence that the personnel currently in place meet the requirements for their positions. 3. as reflected in company policy. Viability .General Expectations: 1. The supplier demonstrates control over systems via an inventory of their systems and versions. 5. The supplier maintains current Design documentation specifying how the requirements for the system are met. The supplier has a current organization chart and an organization structure to address the key aspects of the supplier’s responsibilities concerning the computer system. experience. 4. The supplier has current written procedures in place to control the development. and maintenance of the computer system. 2. QMS .

3. The supplier periodically backs up their software. 3. when used in combination with existing customer user controls. and documented release of the system. The supplier has a procedure in place to resolve test failures and errors discovered during testing. The testing complies with written system development procedures.General Expectations: 1. documented test results. The supplier performs documented testing to demonstrate that the structure and functionality of the computer system meet the pre-defined requirements. The supplier can recreate past and present software versions. The supplier maintains a link between their fault reporting mechanism and the change control program. The supplier has documented testing of their Contingency Plan. The supplier’s testing includes written test plans with defined expected results. Testing – General Expectations: 1. 2. 5. The supplier has written documentation available detailing the instructions for hardware and software installation for the system. 2. a preliminary high-level review indicates that the supplier’s system or service may comply with applicable regulatory requirements for electronic records and signatures as reflected in customer policy. Change Control – General Expectations: 1.Electronic Record and Electronic Signature . including annotations and dead code handling. 2. The system is controlled to ensure traceability and security through the use of a configuration management system or procedures. The supplier’s programming standards address programming conventions to be used. 4. 4. Virus Handling and Backup / Restoration of software to ensure security from natural disasters and malfunctions. 3. The supplier constructs source code in accordance with pre-defined programming standards. The supplier reviews code for conformance with programming standards. 4.General Expectations: 1. If applicable. The supplier maintains a secure environment for system development to ensure that physical and electronic access to the computer system is limited to authorized personnel. © PAUL OSBORNE │ PPTECH LTD PAGE 82 . implements. and tracks changes to the system. The supplier controls. 2. The supplier has procedures for Contingency Planning. The testing is based on the pre-defined approved requirements and specifications and is traceable to these documents. Support – General Expectations: 1. Security – General Expectations: 1. Programming . 3.

3. experience. The supplier maintains a process to adequately record. I will be honest. 5. I will not disclose any proprietary information or confidential data provided by a company being audited without obtaining consent to do so from that company's management.2. I will not disclose information concerning the business affairs or technical processes of the c1ient/ supplier without obtaining prior written consent to do so from the c1ient's/supplier's management. factually. I will issue reports that clearly. If the supplier participates in the installation of hardware or software for the customer’s system. 2. track. I will conduct myself in a dignified manner that reflects well upon my profession and my company. I will inform my company of any personal involvement (business connections. Note . the supplier produces installation reports and has procedures for documenting and resolving installation problems. or personnel or family affiliations) that might influence. 8. 3. employment history. and proficiency I hold with regard to the operation being audited. and accurately describe the operation being audited. © PAUL OSBORNE │ PPTECH LTD PAGE 83 . or appear to influence.Auditor Code of Ethics . impartial. 4. my judgment or jeopardize my independence in my ability to assess the suitability of the operation being audited. I will strive to contribute to the development of improved audit techniques and methods within the quality audit profession and the PDA Process Model. 5. I will undertake only those audits compatible with the degree of training. 4. Baltimore February 2000. and correct defects reported or discovered in the system.from: PDA Computer Products Supplier Auditor Training. and that are constructive in nature. The supplier maintains a technical support program to support the customer’s use of the computer system. 1. The supplier provides the appropriate level of training to support the customer’s use of the computer system. analyze. 6. 7. financial interests. and candid and will demonstrate freedom of mind and approach that will ensure objective viewing of the operation being audited.

They should consider the specific methods. Or the start date and the duration The signature of the training person The address of the company and brief contact details like phone number need to be on the certificate A unique serial number to identify the document © PAUL OSBORNE │ PPTECH LTD PAGE 84 . These typically last one to two days and teach important lessons. This type of certification is only for professional bodies like Universities to issue against a rigorous syllabus and examination system. The requirement is for formal classroom training with notes and a test to be made at the end. techniques. Trainers must be both qualified in the technical disciplines relevant to the training and the actual equipment itself. such as: · Writing a talk · Delivery methods and systems · Body language · Learning to cope with nerves · Practicing and rehearsing · Relaxation exercises · Understanding your audience · Making and using visual aids · Humour and wit · Writing a script to be read. Additionally the trainer should also have attended some type of ‘train the trainer’ course. These certificates can state that the individual has ‘attended’ a course or has ‘successfully participated’ in a course. and hardware to be used. hints on reading a script At the end of the training the delegates should be issued with a certificate of training. tools. this is necessary for traceability and their professional · · · · credentials may be asked for All dates must contain the date of the training and the duration. Records of relevant training and experience should be maintained and should be available as part of the project documentation. Additionally the certificate should contain the following details: · The name of the training person.Training The supplier should identify training needs and provide appropriate training. The certificate must not state that the individual has achieved an addition qualification as a result of attending the course. The style usually adopted to start and finish dates in the form DD/MM/YYYY. in both theory and practice.

Change Control Baseline Definition of the FDA (1995): ‘A specification or product that has been formally reviewed and agreed upon. and should be reviewed. once per year. authorised. Record and report the status of items and modifications to items. Consider that some elements of the machine must require routine maintenance . tested. that serves as the basis for further development. change control measures can apply to equipment.. All changes proposed during the operational phase of an automated system should be subject to a formal Change Control process.Maintenance Procedures must established to ensure that backup copies of all software and other relevant data are taken. impact and risk assessed. components being changed and position in life cycle Change requests are typically initiated by users The Phases · · · · · Request Approval Implementation Recording of change Periodic evaluation Sign-off © PAUL OSBORNE │ PPTECH LTD PAGE 85 .This is a planned activity. and therefore on the state of validation. manufacturing instructions. environmental conditions. and retained within safe and secure areas. Identify and define system components. Document the review. review the status of the above. Control storage. maintained. Change Management – Attributes · · · · There can by responsibility of system owner together with the end-user No universal procedure More than one procedure may be appropriate. Backup and recovery procedures should be verified. consistency. or any other aspects of the process system that has an effect on its state of control. and that can be changed only through formal change control procedures... Ensure the completeness. documented. and correctness of items of the machine. depending on: organisation. and approved before implementation. Periodic review – at routine intervals. handling.’ Change Management Regulations/Guidelines ‘ . and delivery of items.’ – 21CFR parts 210 and 211 May 1996. standard operating procedures.. infrastructure.

An intentional change to a validated system for which the implementation and evaluation program is predetermined. see below Repetitive . necessitates a revalidation of the system Minor change . probably part of preventative maintenance.A change to a validated system that. who will make the changes. replacement of parts or re-calibration. does not require a revalidation of the system Documentation of change Consideration should be given to how the change will be made. update of validation documentation and revalidation/revalidation planning QP (Qualified Person) . Here we have little or no advanced warning. see below Pending – System being evaluated prior to planned changes Classification of Change · · Major change . How will this be documented? Possible documents affected by the change: · · · · · Sop’s Problem report / incident log Change request Qualifications Change report © PAUL OSBORNE │ PPTECH LTD PAGE 86 . in the opinion of change-control reviewers. Intended to enhance capabilities. This may require verification of the system in some form of re-validation. to correct noncritical problems.A change to a validated system that. to system SOP. This may require verification of the system in some form of re-validation.determination of impact of changes on the computerised system.Responsibilities · · · Quality Assurance – Compliance audit of system. it is time-driven and a result of malfunctions and or faults in equipment and or software. in the opinion of change-control reviewers.Legal Responsibility Types of Change · · · · Planned . reporting of findings to responsible management Validation Team . It requires rapid assessment and may require temporary quarantine. It is evaluated prior to change.Time-driven but periodic. necessary change to a validated system requiring rapid implementation. see below Unplanned . the change review and finally the change approvals. Review/Authorization/Reject of changes accord.An unanticipated. This may require verification of the system in some form of re-validation.

89/336/EEC covers all electrical and electronic equipment and their phenomena. The way to CE marking of the product is to ensure the essential protection requirements are met. these are as follows: The standards are a number of harmonized EC standards to consider for CE marking of a product and the EMC Directive 89/336/EEC mandates that all electronic equipment must comply with the applicable EN specification for EMI (Electro Magnetic Interference). electrical tools and similar apparatus EN55015 Electrical lighting and similar apparatus EN55022 Information technology equipment Immunity EN61000-4-2 ESD (ElectroStatic Discharge) EN61000-4-3 Radiated immunity EN61000-4-4 EFT/S (Electrical Fast Transients) EN61000-4-5 Surge EN61000-4-6 Conducted RF EN61000-4-8 Power frequency magnetic EN61000-4-11 Voltage dips and interruptions © PAUL OSBORNE │ PPTECH LTD PAGE 87 . scientific and medical equipment EN55013 Broadcast receivers and associated equipment EN55014 Electrical motor-operated and thermal appliances for household and similar purposes. highlighted are the one’s necessary for RedCube: Harmonised standards for Electronic Equipment Radio Disturbance characteristics EN55011 Industrial. Some typical EN specifications follow. this is implemented by all member states.The EMC Regulations and the Technical Construction File EMC is controlled in Europe by regulation: The EU EMC Directive 89/336/EEC are the controlling standards.

The Technical Construction File
Products which are to be provided with the CE marking shall be designed to comply with relevant
Products with the CE marking shall be produced in accordance with the design that was found to comply
with relevant requirements.
This leaflet provides information about the "Technical Construction File" which is the basis of the conformity
assessment of the design.
For each product with the CE marking the manufacturer shall issue a "Declaration of Conformity"; this
document states that the product is in conformance with the approved design. A separate information
leaflet on this declaration is available.

The File
Essentially the file shall provide the necessary evidence that the design is in accordance with relevant
The file shall identify the product and the requirements. It shall describe the assessment-activities, and
contain the results of these activities.
Suggestions for file-elements are:

Name of the company responsible for the design


Name and function of the employee responsible for the file


Name (of the product)






photographs, brochures
technical construction drawings
material compositions
schematic diagrams
parts lists of components
descriptions of components



All different versions shall be described, as far as relevant:

Copies of the user manual and service instructions, as far as applicable,


List of applicable EU-directives,


List of normative technical documents or standards used for the conformity assessment,


Design calculations,


Hazard (Risk) analysis,


Description of measures to reduce or eliminate hazards (Risk Analysis),


Evaluation and test reports, indicating:


which evaluations and tests were performed,
methods of evaluations and tests,
evaluation- and test-equipment,
results of evaluations and tests,
acceptance criteria.


Conclusion, indicating that the product complies with all relevant requirements.

If considered appropriate, descriptions and explanations to properly understand the documents, shall be
It is the responsibility of the manufacturer to decide about the assembly of the file.

Information sources
The manufacturer may use outside-sources for the file or sub-contract the file, in parts or completely.
Manufacturers may not have available all evaluation- and test-equipment as required by the technical
standards. Specialized laboratories, like CEBEC, provide relevant evaluation and testing services.
In all cases the manufacturer remains responsible for the contents of the file and should operate an
adequate system to verify the contents of information received. This verification can be asked from thirdparty certification institutes or Notified Bodies.

Administration of the file
The file-elements need to be available. It is not an absolute requirement that the file is available as a
"physical" entity. Manufacturers usually operate quality management systems or administration systems
with document control procedures. The file-elements can be made available in accordance with these
procedures. Authorities and Notified Bodies will require insight in the administration system of the
manufacturer. Upon their request, the file, as a "physical" entity, shall be made available on short notice (a
few days).



Notified Body
The conformity assessment scheme, require the involvement of a Notified Body in the design-stage. It is the
obligation of the Notified Body to verify the contents of the file and to repeat evaluations and tests if
considered necessary.

Suggested inclusion in the installation or user manual
EC Directive
EMC Guidelines


Applied Harmonised Standards
DIN EN 55022/A Radio disturbance characteristics
DIN EN61000-4-2 ESD
DIN EN 61000-4-3 Radiated immunity
DIN EN 61000-4-4 EFT/S



of a traceable measurement standard. instructions. Application Software . data archiving or process control. Used in the Calibration of a diagnostic assay. test method. requalification or calibration has been performed appropriately with acceptable results. correlate. QC. Certification .A formal monitoring system by which qualified representatives (Validation Committee) of appropriate disciplines review proposed or actual changes that might effect a validated status. qualification.A program adapted to the specific requirements of a user for the purposes of data manipulation.Current Good Manufacturing Practice. etc.1] A documented activity performed on a periodic basis in accordance with written procedures to verify. Certification may also be used to denote the overall acceptance of a newly validated manufacturing facility. procedures. of a known accuracy. procedure. or cut-off point. Challenge . instrument. Software written to perform a task on a computer. This is done to determine the need for Corrective Action to ensure that the system retains its validated state. specifications. by examination and evaluation of the objective evidence.The assaying of Calibration materials to confirm that the Calibration of the instrument. 2] Special samples of known values specifically prepared to set up a standard curve. that an equipment/system validation. technical report. Calibration . of an assay. Approved Document (Approval) . codes and contractual and licensing requirements. detect. by written and approved procedures. report or eliminate any variation in the accuracy of the item being compared over an appropriate range of measurements. standards. Change Control . a partial system redesign or the determining of software obsolescence. © PAUL OSBORNE │ PPTECH LTD PAGE 91 .Terms used A Application . baselines.) has been approved after it has been reviewed and signed by a pre-defined group of responsible individuals representing manufacturing. Audit (Quality Audit) .A software library which contains formally approved and released versions of software and documentation from which copies are made. R&D and QA/regulatory or their designates. engineering.Software specifically produced for the functional use of a computer system.A written document (protocol. Archived Master . Performance and documentation of Calibration Verification is required to substantiate the continued accuracy of a quantitative test method for the reportable range of test results. with another measuring device to respond to. Calibration Verification .The performance of tests to determine the limits of capability of a component in a manufacturing process. 3] A qualitative and quantitative. test or computer program complies with its specified requirements. 2] An independent review to assess compliance with requirements. but rather the limits of variation within which a defined level of quality can be assured. revalidation. kit or test system has remained stable throughout the reportable range for test results. by authorized and qualified individuals (Validation Committee). 2] A written guarantee that a system. compliance with those elements of a quality program under review. Limits of capability do not necessarily mean challenging until destruction.Documented comparison.A documented statement. C cGMP . 2] Management and implementation methodologies associated with increasing or correcting system capabilities.A device intended for use in a test system to establish the points of reference for the determination of values in the measurement of the test instrument. Calibrator .

D Design Review (Architectural Review) . systematic examination of a design to evaluate the adequacy of the device requirements to evaluate the capability of the design to meet those requirements and to identify problems with the design and design requirements so solutions can be proposed to all such problems. purchase orders.A computerized system for integrating company-wide data in order to improve planning activities. codes and regulations. instrument. or part of a computer program. Design Validation . Design Verification .A planned.To represent data or a computer program in a symbolic form that can be accepted by a processor.Closures . Q Qualification (IQ) . or a tool to verify compliance with software design documentation and program standards. A system determined to be "critical" must be designated as such. All developmental documentation will be included in an IQ. F Functional Design Specification (FDS) . safety.The performance of documented verification that an equipment/system installation adheres to approved contract specification and achieves design criteria. local and state codes and the cGMP should also be considered.An independent review of Source Code by a person or team of persons. effectiveness or performance of the intermediate or final product. The IQ precedes the Operational Qualification (OQ). 3] A technique of evaluating a proposed design to ensure that the design: a) Is supported by adequate materials that are available on a timely basis. which may be removed or otherwise altered in order to grant access to the container contents. safety or effectiveness of a piece of equipment. Code . system. what functions it has and what facilities are provided by the equipment/system. caps or other barriers. scheduled and documented audit of all pertinent aspects of a design that can affect performance. instruments lists.Those portions of drug or diagnostic systems. and enable products to get to market more quickly. b) Will perform successfully during use. © PAUL OSBORNE │ PPTECH LTD PAGE 92 . Code Audit . Loosely. The IQ is developed from P&IDs. E Enterprise Resource Planning (ERP) .A control parameter that has a direct relationship to the quality. and must be maintained and operated using approved Standard Operating Procedures (SOP). piping drawings.A system whose performance has a direct and measurable impact on the quality of the intermediate or final product. purchase specifications. c) Can be manufactured at low cost. 2] Confirmation (by examination and provision of objective evidence) that the design output meets the design input requirements.An instrument that will give analytical answers as a result of electrical or mechanical measurements on an element.provides a written definition of what the system does. and detailed in the design outputs. 2] Establishing the documentary evidence that a sub-system or equipment is installed in compliance with the technical specifications. solution. 2] Establishing by objective evidence that device specifications conform with user needs and intended uses. electrical drawings. Critical Process Parameter . The manufacturer's recommendations. provide better control of operations. standards. 3] Documented verification that all key aspects of hardware installation adhere to appropriate codes and approved design intentions and that the recommendations of the manufacturer have been considered. at contract review stage. and d) Is suitable for prompt field maintenance. engineering specifications. such as stoppers. equipment operating manuals and other necessary documentation. compound.The comparison of design output with design input.The comparison of the product against the user requirements that were agreed to. Critical System . 2] A comprehensive. one or more computer programs. etc. Device . system or facility.

A term used to describe the dynamic process employed after a system's initial validation in order to maintain the validation status of the computer system. Ongoing Evaluation . humidity.Documented verification that equipment. measurement. Operating System .Assembly of one or more containers.1] The documented verification that the equipment/system performs per design criteria over all defined operating ranges. Manufacturing Execution System (MES) .Any person. This includes contract sterilizers.Products administrated to patients by routes other than the mouth.When one or more of the requirements included in Standard Operating Procedures for Controlled Environments are not fulfilled. Establishing documentary evidence that operating characteristics and product are in conformity with the limits defined in the specifications. specification developers.The completed product of a packing operation. Out-of-Specification Event . integration. who designs. Performance Qualification (PQ) . which may potentially affect the Process State of Control and/or fitness for use of the final product. under normal production conditions and must be in a State of Control. which are necessary to ensure compliance with minimum packaging requirements of applicable regulations. Critical parameters (temperature. Marking . This includes inventories.The first occurrence of human-readable Information.A real-time system for coordinating all data relating to the manufacture of products and applying them directly to shop floor activities. ending only when commercial use of the system is discontinued. This operation must be reliable and reproducible within a specified. Parenteral . control and maintenance. fabricates. Original Observations .L Life Cycle .) © PAUL OSBORNE │ PPTECH LTD PAGE 93 . bills of materials (BOM) and orders from purchasing. etc. such as intravenous (IV) or intramuscular. validation. repackers.An approach to computer system development that begins with identification of a user's requirements and continues through design. material. Operational Qualification (OQ) . assembles or processes a Finished Device.An expanded version of MRP that includes enhanced capacity for planning and scheduling the use of manufacturing resources. predetermined set of parameters. including Control Parameters. flow rate. The OQ includes qualification of operating and maintenance records. Packing . The OQ precedes the Performance Qualification (PQ). Packaging .Information about the contents and shipment of a package which is printed on or affixed to the surface of the package. Operating Parameter (Operating Variable) . manufacturers.A set of programs provided with a computer that function as the interface between the hardware and the applications program.Information which can be proven to be true based on facts obtained through observation. P Package .The Process variables which are measured to monitor and maintain the normal state of a Process or system. Manufacturing Resource Planning (MRP) . relabelers and initial distributors of import devices. O Objective Evidence .An automated system for handling information directly relating to manufacturing.The art and operation by which an article. or substance is enveloped in a wrapping and/or packaging or otherwise secured. It consists of the packaging and its contents prepared for shipment. pressure. M Manufacturer . Manufacturing Resource Planning II (MRPII) . test or other means. systems or processes operate the way they are purported to do. and any other components. qualification. All factors.

Quality Audit is different from. and the product is not sold until the equipment. when followed. Quality Assurance (QA) . Programming .The activity of providing. and in addition to. Prospective Validation .must be stable over time under both normal and worst-case conditions. © PAUL OSBORNE │ PPTECH LTD PAGE 94 . examination of a manufacturer's entire Quality System that is performed at defined intervals and with sufficient frequency to ensure that both quality system activities and the results of such activities comply with specified quality system procedures. and that that they are suitable to achieve quality system objectives. to all concerned. preplanned protocol. Procedure .The written and approved document of an experimental sequence of tests that. while Validation deals with the entire manufacturing process for a product. It is also used to determine that these procedures are implemented efficiently. will produce a product or result defined by a specification. which bear on the ability of a device to satisfy fitness for-use. that the required conditions are met and that they actually provide the expected results.All activities subsequent to design transfer up to the point of distribution. equipment or personnel. Quality Assurance Unit . including safety and performance. The validation is performed prior to the manufacture of clinical or marketable product. The results of the performance of the protocol shall be documented in a Validation Final Report. Protocol . 3] Quality System International Standard. process. Production . Procedures are used to define and control the manufacture of materials as well as the operation and/or maintenance of equipment. 4] All the planned and systematic activities implemented within the Quality System which can be demonstrated as needed to provide adequate confidence that an entity will fulfill requirements for Quality.The totality of features and characteristics. the evidence needed to establish confidence that the quality function is being performed adequately. Quality Audit .Used to describe the Testing and review of a piece of equipment. Q Qualification . ISO 9004 replacement term for Quality Assurance. the other Quality System activities required. equipment or system being challenged. system or sub-system of a process to assure its fitness for use.An established systematic. The protocol will address all elements of the validation sequence relevant to the assay. 3] Action of proving that any equipment works correctly and actually leads to the expected results.An approved document listing a specific set of instructions which. 2] All activities necessary to assure and verify confidence in the quality of a process used to manufacture a Finished Device. 2] Operation aimed at proving. Quality . The qualification procedure is determined by a written and approved Protocol or Testing defined by the Validation review committee.Establishing documented evidence that a system does what it purports to do based on a written and approved. Qualification deals with components or elements of a process. system and process meet the validation acceptance criteria. with regard to either materials. systems or processes. independent.Any person or organization element designed by laboratory management to monitor the LIMS functions and procedures. The word Validation is sometimes widened to incorporate the concept of qualification. are intended to produce documented evidence that the equipment or system does what it is designed or claims to do reproducibly.Coding of program modules that implement a design. when executed as prescribed.

regardless of physical form or characteristics . same operator and equipment) over a short period of time.made or received by an agency of the United States Government under federal law or in connection with the transaction of public business and preserved. as formally expressed by the executive management. See Quality Assurance.A specific set of test data and associated procedures developed for a specific objective. photographs. compares it with standards and acts on the difference.The entire collection of activities from which industry achieves fitness for use. S Recertification . notes. reviews. operations or other activities of the government or because of the informational value of the data in them. Some examples are: To exercise a specific program path. papers. specifications. depending on the repair or maintenance procedures performed. standards. through which industry measures actual quality performance.Establishing documented evidence that a system does what it purports to do based on a review and analysis of historical data and information obtained during the production of clinical or marketable product. or to verify compliance with a specific requirement. repair or maintenance that could alter the product characteristics or performance. procedures.). analyses. plans. piece of equipment or system to a validated or qualified state after maintenance or minor changes have been made to it. Retrospective Validation .Any written or automated document (books. Reproducibility . procedures. Quality Policy .The repetition of a documented qualification procedure after minor alterations.Quality Control (QC) . policies.Written procedures describing operations. Record . methods..The repetition of the Validation sequence or a specific portion of it. by that agency or its legitimate successor as evidence of the organization. Quality Function . and reports . functions.g. no matter where these activities are performed. interpretation of results and Corrective Actions that relate to the operations that are taking place in a Controlled Environment and auxiliary environments. maintenance or repair.The measure of a test method's variability with different analysts. Revalidation . 3] Organizational structure. to assure that the system is suitable for use after modification. processes and resources for implementing quality management.The approved written procedure used to return a process.The Precision of a method performed under the same operating conditions (e. instructions. The Validation Committee determines the extent of the requalification required.The overall quality intentions and direction of an organization with respect to quality. Quality System . laboratories or other conditions. process or service will satisfy given quality requirements (International Standard. S Standard Operating Procedures (SOP) . contract or project. or appropriate for preservation. sampling. procedures. © PAUL OSBORNE │ PPTECH LTD PAGE 95 . Requalification .All planned and systematic activities necessary to provide adequate confidence that a product. T Test Case (Test Script) . Deviations from the SOPs should be noted and approved by responsible managers. service. Quality Plan . Revalidation is also required periodically. etc. Repeatability . The extent of the requalification is determined by the Validation Committee. machine-readable materials. protocols. including specifications. 2] The organizational structure. ISO 9004). procedures. resources and sequences relevant to a particular product. processes and resources needed to implement quality management. files. Especially applicable to those systems used to control or measure critical parameters. responsibilities.A document setting out quality practices. testing.The regulatory process. Also known as intra-assay precision. maps. decisions.

This document is prepared concurrently with the construction phase of a project after all equipment and materials have been specified. Validation Sequence . Construction Qualification or Architectural Review and Commissioning (Pre IQ) 3.Validation Aware: Basic knowledge of the Theory of Validation 3.The specific set of steps undertaken to validate a system. equipment or process. facilities. There are four levels to the model: 1. evaluate and approve all Validation and/or Qualification functions and/or activities. by technical or scientific means. V Validation . the manufacturing processes and the scope and implementation of the Validation Sequence. that a system. function and criticality of the equipment or system. Design/Specifications Qualification 2. It will define the terminology to be used in all subsequent documentation.Testing . Level 1 . depending on the size. complexity. quality services. and are specifically related to. engineering. Level 3 . This includes functional operation and involves the application of established scientific principles and procedures. Validation Committee . engineering services. recognising the benefits and limitations and encouraging others to participate. These representatives may initiate corrective action to ensure the system or process retains. 4. A subsequent step in the Validation Sequence should not be initiated prior to the completion of a prior step. Installation Qualification Operational Qualification 5. Validation Change Control . computer system validation itself. a validated condition or State of Control. or is returned to. Level 2 . outline descriptions of the facility site. Validation Plan .A cross-functional group of qualified individuals representing each major division in a company [manufacturing. production. of the properties or elements of a product or its components. The Validation Sequence may contain any one (or more) of the following steps.The determination. No step can be implemented prior to securing an Approved Document (protocol) directing the method of the execution of the document. Level 4 .The collection of activities that include.The overall term for the establishing of documented evidence through defined tests and challenges.Validation Active: Forced to participate by regulation or customer demand. 1.A formal monitoring procedure during which qualified members of a Validation Committee (and/or others from appropriate disciplines) review the affect of proposed or actual changes on the manufacturing process to determine the impact on the Validation status. manufacturing process. Calibration 4. analytical method and/or piece of equipment meets design criteria and that adequate provisions have been established to keep it in a State of Control so it will produce a product that meets predetermined specifications and quality attributes. R&D.Validation Enthusiast: Experienced in practice.Validation Unaware: No knowledge of the Theory of Validation 2.A model (borrowed from Carnegie-Mellon) used to describe the level of knowledge of Validation.The establishment of a dynamic written plan that defines the overall approach to a Validation project. and QA/regulatory affairs] that is assembled to review. Validation Master Plan . Performance Qualification or Process Qualification (Process Validation) © PAUL OSBORNE │ PPTECH LTD PAGE 96 . development. Validation Capability/Maturity Model .