-*-*-*--*-*-*-*-*-*-*-*

*

Validation
A supplier and end
users perspective
Revised Edition

Contents
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

© PAUL OSBORNE │ PPTECH LTD

PAGE 2

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

© PAUL OSBORNE │ PPTECH LTD

PAGE 3

Remember that the validation process must occur before the end customer can product drug. an increasing occurrence) does not mention validation requirements. without question. which of course the supplier cannot supply without adding costs and time to the project. Once the rules are understood then the supplier can be of help to all customers and everyone will be satisfied.Preface This document is designed to assist suppliers who wish to sell equipment. In this way everyone knows what to expect and when to expect it and what it will cost. If the customer cannot validate the equipment it is of no use to them. This can be avoided if the subject is brought up at an initial sales project meeting with the customer or OEM representative. Neither of these people may have real validation expertise. It describes the details of validation for those who are new to the subject and describes the development of a suitable documentation set. That is just not the case. Different pharmaceutical companies have different way of validation equipment so this sounds like the supplier has a difficult or impossible job. which I refer to as the prevalidation documentation set. even if they did not ask for it in the first place How do we avoid this. 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. 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. the equipment should be easy to validate. suppliers owe this as a service to their customers. no question. into the highly regulated pharmaceutical environment and to help end pharmaceutical customers understand the equipment supplier’s perspective. this way the company can begin the validation immediately. · 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. More than this. they are reliant on the leveraging information out of the supplier. including a source code review for computer based equipment. 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. The supplier says ‘you did not ask for this. the project engineer or the sales contact for the OEM (if the equipment is to be fitted to an OEM machine. simply by asking the question up front – ‘what are your validation needs?’ And then by understanding and interpreting the answer. usually computer based. so we cannot achieve it without extra costs and additional time. What happens in practice is as follows. Now if all Pharmaceutical companies have need for validation and they all have slightly different way of achieving this. 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. This pre-validation documentation set should be supplied to the pharmaceutical company with the equipment. therefore the turnover package is as important to the end customer as the equipment itself. so neither does the equipment suppliers salesman. 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. how does the supplier fit in? The supplier has an important role in providing equipment that can be validated. These validation and compliance issues should be discussed with the pharmaceutical company as soon as possible in the sales negotiations. © PAUL OSBORNE │ PPTECH LTD PAGE 4 .’ There will not be an option for the pharmaceutical company to do the work themselves.

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

engineering. The traditional approach to equipment and machinery validation relies on the fact that an equipment design has been made for a given solution. dependant on the design documentation created during its development. I began to attend courses on validation of computer based equipment and found them useful. A given design of blister machine can be qualified in a specific way. 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. 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. 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. Therefore a single documentation set will usually suffice for most applications. This documentation came out of a series of papers written by myself over the intervening years on this subject. equipment manufacturing companies often sell to multiple international markets where regulatory expectations vary. It seeks to provide tools that can be used to improve the level of compliance to perform the job correctly from the beginning. because of the nature of the equipment we supplied. as is the case in many applications. that of the creation of suitable validation documentation sets to provide to our customers. I felt unable to create a single. Validation . 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. This document therefore aims to inform the would-be supplied of computer based equipment what his regulatory obligations are. and regulatory aspects related to drug manufacturing. how to create the documentation set and provide examples and templates to work from.The Background Let us start at the very beginning. 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. It also seeks to inform end customers of the way to convey information to the supplier that is relevant to the project. For many. © PAUL OSBORNE │ PPTECH LTD PAGE 6 . generic. 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. To complicate this further. likewise a specific device for the creation of pure water. documentation set for all applications. However. validation. but not necessarily centred on the task I was trying to carry out.

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

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

like printers and visions systems.Regulatory Requirements and CSV Computers are more and more widely used during manufacturing of drugs and medical devices. Therefore. It is also demanded by groups like FDA regulations and guidelines through the overall requirement that ‘equipment must be suitable for its intended use’. or related systems that will perform a function satisfactorily. such as calculations performed in connection with laboratory analysis. including computers. inspected. 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. and holding of a drug product. In such instances a written record of the program shall be maintained along with appropriate validation data Hard copy or alternative systems. inadvertent erasures. or checked according to a written program designed to assure proper performance. Revision5 issued June 2008. mechanical. are eliminated by computerization or other automated processes. 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. Proper functioning and performance of software and computer systems play a major role in obtaining consistency. © PAUL OSBORNE │ PPTECH LTD PAGE 9 . processing. If such equipment is so used. shall be designed to assure that backup data are exact and complete and that it is secure from alteration. or electronic equipment or other types of equipment. such as duplicates. or microfilm.68 of the US cGMP regulations: Automatic. Computers appear in at types of packaging machinery and the ancillary devices that appear on them. reliability and correctness of the manufactured product. packing. may be used in the manufacture. computer system validation (CSV) should be part of any good development and manufacturing practice. tapes. or loss shall be maintained · · Typical Industrial PC 2 GAMP 5 a risk based approach to compliant GxP Computerized systems © ISPE 2008. it shall be routinely calibrated.

All guidelines refer to risk assessment for the extent of validation Pharmaceutical Inspection Convention Scheme. © PAUL OSBORNE │ PPTECH LTD PAGE 10 . going use. Because of their importance. All these guidelines and publications follow a couple of principles: · · · 3 4 Validation of computer systems is not a one time event. initial operation. integrity and reliability of records generated. It deals with development and validation of software used in medical devices. This regulation applies to all FDA regulated areas and has specific requirements to ensure trustworthy. In 2003 the FDA published guidance on scope and applications of 21 CFR Part 11. Most detailed is the Industry Guide: General Principal of Software Validation. transmitted and archived by computer systems. 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. The FDA has released draft guidance on using computers in clinical studies. It has been developed by inspectors for inspectors of the PIC/S 3but is also quite useful for the industry.FDA has developed several specific guidance documents on using computers for other FDA regulated areas. 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. There are no detailed instructions on what should be tested. Parenteral Drug Association. 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’. The PDA4 has developed a technical paper on the validation of laboratory data acquisition system. and change control and system retirement. It has more than 50 pages and includes a six page checklist recommended to be used by for inspectors. 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. The guidance states FDA’s expectations related to computer systems and to electronic records generated during clinical studies. It starts with the definition of the product or project and setting user requirement specifications and cover the supplier selection process. installation. evaluated.

Control of process and packaging equipment. to process the data and to print and store. Validation of software loaded on a computer. more often than not the system will by a part of a network of computers exchanging data to provide the required services. control of ancillary inspection and printing devices. Again there may be more than one computer in the system and they perform some type of interaction. authenticity and integrity of data acquired and evaluated by computer systems. Data acquisition 3. Development of Documentation Required by Regulations Risk assessment and risk based validation will be discussed for all validation phases to optimize validation efforts vs. networked systems and on security.While in the past computer validation was more focused on functions of single user computer systems. costs for systems with different impact and risk on product quality. standard applications software and software written for a specific user. Data analysis Most systems do a mixture of some or all of these functions. the trend today is to directly send production information to the packaging line to configure the manufacturing equipment directly for example. 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. which is used to control equipments. to capture raw data. 2. 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. Interaction © PAUL OSBORNE │ PPTECH LTD PAGE 11 . The computer her will not work in isolation. Computer systems are becoming more integrated. recently the focus is on network infrastructure. Computers in the pharmaceutical industry perform three types of task: 1. Software typically includes operating systems.

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

Layered software (i. Software used to manage the operating environment · · · · Software · · · · · 3. 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. upon which applications are . but the cannot be configured to suit the business process Typical Approach Operating Systems · Record version number. 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 .e.Software categories Category Description Typical Examples 1.. Infrastructure .

that can be configured by the user to meet the specific needs of the user's business process. structural testing. Configured Software. Varies. etc. often very complex. Design Specifications) · Record version number. · 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. Custom Software custom designed and coded to suit the business process. 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.Category Description Typical Examples Typical Approach 4. plus: · More rigorous supplier assessment. 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.) · Design and source code review © PAUL OSBORNE │ PPTECH LTD PAGE 14 .. with possible supplier audit · Possession of full life cycle documentation (FS.g. Software code is not altered.

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

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

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 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 .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.

An example is shown on the next page. © PAUL OSBORNE │ PPTECH LTD PAGE 19 . installation qualification (IQ). In this case a life cycle model that combines system development and system integration is preferred. As previously described. and performance qualification (PQ). For such systems the simple 4 step model is recommended with just four phases: Testing of system by manufacturer. This means that the system immediately moves into a GAMP 5 level 5 category system.A GAMP 5 level 4 category system. GAMP documentation is controlled and issued by the ISPE6. where the system is a standard Hardware and Software product that is in serial production and only configuration is needed to make it operational. 6 International Society of Pharmaceutical Engineers. 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. operational qualification (OQ). Phases like design specification or code development and code testing are not necessary provided that adequate design and testing documentation exists for the system.

at some point suppliers expect to be paid for goods delivered or services rendered. Consolidated framework will fit any automated system. 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. clearly identified. 4. Regardless of the industry. this is just prudent contract and financial management. 7. General Guidance Unique. The following double V diagram or ‘W’ diagram seeks to address that requirement. ® 10. © PAUL OSBORNE │ PPTECH LTD PAGE 20 . Guidance will cover complete life cycle. Fully integrate risk management throughout life cycle. · By discipline / function · User / Supplier ® 9. Promote benefits of understanding business processes.Ten Guiding Principles of GAMP 5 1. GAMP is a trademark. 2. and testable specifications provide greater understanding to all. Clarify Roles and Responsibilities. Focus on systems impacting public health. 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. 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. 8. 6. Guidance will satisfy all current regulatory expectations for CSV. 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. 3. How then could this these V diagrams apply to a company designing new computer based equipment for a general market. There is no point in having a specification or requirement if it cannot be tested in some way. Focus where regulations require controls beyond “good practice”. not a certification. 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. 5.

© PAUL OSBORNE │ PPTECH LTD PAGE 21 . 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.

Customer URS Order Placement Produce FS. Such testing documentation is usually created by the end customer. The completion of Functional Testing for a system confirms that it is ready for use in the manufacturing process. some of the Functional Testing (OQ) can be completed as required. The System Acceptance Testing FAT and SAT should be fully documented.Factory and Site Testing Testing During factory acceptance testing most of the Configuration Testing (IQ) can be completed if required. Requirements Testing is conducted under actual running conditions across the anticipated working range. The Requirements Testing step verifies system performance (PQ). 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 . Also. Configuration Testing.

An RTM may be generated as a separate deliverable or as part of an existing deliverable.Traceability Traceability may be achieved in a number of ways. This has the effect of drastically reducing the testing time on the project. 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. Leverage Model © PAUL OSBORNE │ PPTECH LTD PAGE 23 . such as the Functional Specification FS. Data captured at FAT time can be referenced to and used at SAT. Likewise. or embedding references directly within documents. including a Requirements Traceability Matrix (RTM). automated software tools. information gathered at both FAT and SAT time can be applied directly into the IOQ data. spreadsheets. Leverage The possibility exists of course to apply leverage to data captured and thus reduce the overall testing overhead.

physical. performance.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. data. When writing User Requirement Specifications. This first step in the validation process is the user requirements. security requirements etc as expected by the user. the requirements of the proposed system are collected by analyzing the needs of the user. created by the customer. 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. but to convey information to the reader of that document so they understand what is required. This phase is concerned about establishing what the ideal system has to perform. interface. not written. 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. © PAUL OSBORNE │ PPTECH LTD PAGE 24 . The document exists to be read. it is crucial to remember the document is not the job. The purpose of the exercise is in fact not to write a document. It describes the system’s functional.

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

the user is informed of the issue. They figure out possibilities and techniques by which the user requirements can be implemented. This document contains the general system organization. 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. The Functional Specification document is the reply of the supplier and serves as a blueprint for the development or configuration of the entire system.Functional Specification In this phase. system engineers analyze and understand the proposed system by studying the user requirements document. It may also hold examples of business scenarios. The Functional Specification should be written in such a way that it is understood by both supplier and customer. a data dictionary will also be produced in this phase. sample windows. 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. reports intended to enhance understanding. Items to be classified in the Functional Specification include. The Functional Specification is the defining and controlling document. A resolution is found and the User Requirement document is edited accordingly. data structures etc. If any of the requirements are not feasible. system process) · High Level Function of the system · System Testing conditions. 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 . menu structures.

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

In this case the module design specification. database tables. 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 integration testing design is carried out in this phase. test specification and integration test specification are not required. The Software Module Design Specification should contain enough information to enable coding of the module to proceed. The Software Design Specification is a description of the software components and sub-systems to be provided as part of the product. dependencies.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. © PAUL OSBORNE │ PPTECH LTD PAGE 28 . The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules. architecture diagrams. brief functionality of each module. technology details etc. If there is only one module the Software Design Specification should contain enough information to enable the code to be produced. their interface relationships. a Software Module Design Specification should be produced. For each software sub-system (module) identified in the Software Design Specification.

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

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 . All test-related dates must be logically consecutive. 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. reviewers and approvers · include the test procedure.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. position and date for authors. Test Planning Tests should cover all relevant areas of the relevant equipment or system.

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

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. stress.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.

software. tester. 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. or user) · Ensures system features are accurately tested (performance.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. periphery. documentation. 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 . 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. security. incl.

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

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. however. · Input Combination Testing . Functional Testing Functional testing will compare the system specifications against the actual system. Once all the modules are integrated several errors may arise. 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. · Output Testing . The input combinations can be selected at random from the possible input domains or selected specifically because they are considered likely to reveal faults. · Special Case Testing . or checking that a zero input is handled without leading to a 'divide by zero' error). These Test Cases challenge the intended use or functionality of a program. Some common types of functional test include: · Normal Case (Positive Case) Testing . Run the testing between two modules and test the gap between two modules whether two modules are interacting with each other.testing combinations of inputs to ensure correct outputs. 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. By itself. and the program's internal and external interfaces. © PAUL OSBORNE │ PPTECH LTD PAGE 35 . Sometimes System Testing is automated using testing tools.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).testing to show that the system does what it is supposed to do in response to specified invalid inputs (for example. the number and types of functional tests performed may reflect the risk priority associated with the system or function. Testing is usually black box as the code is not directly checked for errors. The functional test design is derived from the functional design documents. · Invalid Case (Negative Case) Testing . For a particular requirement. It is done using the integration test design prepared during the architecture design phase.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). Functional testing therefore identifies Test Cases based on the definition of what the software is intended to do. Testing done at this stage is called System Testing.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. Test Scope Functional testing should normally cover all stated user and functional requirements. normal case testing does not provide sufficient confidence in the dependability of the software product. giving the correct error message in response to an out-of-range input).

be approached with caution . · Usability Tests . · Repeatability Tests .3. by running repeated trials using the same recipe to check that the product is always within specification). It is in the nature of a prototype to be built up in a rapid. speed of response to operator input). Where differences exist between the test environment and the production environment.4. from unit or module testing to system level testing. © PAUL OSBORNE │ PPTECH LTD PAGE 36 . These may include non-functional user requirements (e.g. 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. throughput or response (for example responding to operator requests within the specified period). The conversion of a prototype to a real module should. For a particular requirement the number and type of performance tests executed may reflect the risk priority associated with the system or function.as a minimum it is recommended that a baseline be taken and a source code review carried out prior to testing. · Accuracy Tests . 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. 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.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).testing to show that the system is capable of meeting the required timing.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).testing to show that the system is capable of repeatedly meeting the required performance (for example. it also may be necessary to carry out some performance monitoring and tuning within the production environment. with many concurrent users of a database). does not form part of formal testing even though it often involves an amount of informal (undocumented) testing. 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'.Test Positioning Within the Life Cycle Functional testing is carried out during all phases of software testing. Load testing can be a complex area and further discussion is given in section 3.. Some common types of performance test include: · Environmental Tests . relatively uncontrolled manner. Design Prototyping should be regarded as a means of verifying design requirements and of building confidence prior to formal (documented) testing.Testing to show that the system is capable of operating reliably in the specified environment (for example under the specified temperature conditions). · Timing or Response Tests . Requirements Testing The objective of performance testing is to evaluate the compliance of a system or component with specified performance requirements. therefore. Design Prototyping (sometimes referred to as Conference Room Pilots or other similar terms). Test Scope Performance testing should normally cover all stated performance requirements.testing to show that the system is capable of meeting the required performance whilst operating under realistic high load conditions (for example. · Load Tests .

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

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 may be restricted to a postal audit but consideration should be given to carrying out a full audit. 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. © PAUL OSBORNE │ PPTECH LTD PAGE 38 . Or it may depend on off-the–shelf software products like operating systems and SCADA packages. · The specific testing of their use of these products.g. These should be considered in the plan of testing. suppliers should seek to leverage the testing already executed by their own supplier(s). where specific configurations of automated tools are used these should be tested and documentary evidence provided of fitness for purpose. 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. This may involve. A mature Supplier is more likely to recognize the importance of quality management and to have established quality management processes. The audit may be an important step in developing a long term relationship between the Supplier and the User. e. or testing conducted by themselves on identical systems or pieces of equipment. 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. This Guide provides assistance to Users in the pharmaceutical industry as to how they should approach the testing of supplied systems. · 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.Other Consideration of Testing The overall system may contain computerised sub-systems within it. The same approaches need to be adopted by Suppliers when they make use of third party products. 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. In these cases. 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.

A very significant features of software is branching. 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 . i. 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. Because of its complexity the development and testing of software should be more tightly controlled and accurate and complete documentation is essential.System Testing . The quality of software is dependent on design and development with minimum concern for software manufacture. Verification techniques such as structured approach and documented development ensure comprehensive validation. therefore lack of understanding can lead managers to believe that a tightly controlled engineering development and testing environment is not needed.e. software engineering needs a greater level of managerial scrutiny and control than hardware. Software testing is one of several verification activities intended to confirm that the software development output meets its input requirements. since software manufacturing consists of direct reproduction (copying) that can easily be verified. its verification and the test documentation in a specific way. The difficulty comes in getting the original program to meet all the specifications. However software that is constantly updated sometimes introduces new defects during the change.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 will improve with age as latent defects are discovered and removed. not all of which may have been simulated during testing. since branching will create complex possibilities of execution during normal operation. software is not a physical entity and does not wear out therefore failures occur without advanced warning. Finally.. ability to execute alternative commands. 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. software verification is confirmation that the output of a particular phase of development meets all of the input requirements for that phase. Some other points to understand are as follows. These ‘componentbased’ approaches require very careful attention during integration. Software developers are beginning to use off-theshelf software components for faster and less expensive software development. In a software development environment. Therefore testing alone cannot fully verify software is complete and correct. Speed and ease of software change cause both software / non-software professionals to believe that software problems can be corrected easily. We need to specify the testing of software. Software branching can hide latent defects until long after a software product has been introduced to the market. The vast majority of software problems are traceable to errors made during design & development. Quality needs to be ‘built in’ by understanding and applying the above points.’ Verification means confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. nor adequate development facilities or resources. It is not difficult to manufacture thousands of program copies that function exactly the same as the original.

Role of the supplier GAMP 5 is an accepted source of guidance for regulators and practitioners worldwide. 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. 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 . harmonizing with other guidelines such as: · · · · ICH Guidance Q8.

with most systems networked. changes and new features. © PAUL OSBORNE │ PPTECH LTD PAGE 41 .equipment design FS or minimum installation documentation Design review details. Novel software development methods are increasingly used. 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. 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 . accuracy and completeness.details of the system of software release documentation . There has been a substantial move towards wide use of configurable commercially-available software packages. Please note that the FS is the application FS QMS system overview Specifications for the design . experience and documentation. configurable computer systems? · · · · · · · · · · · · Dedicated FS and IOQ documentation set. testing (OQ). 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). There should be flexibility regarding acceptable format. the creation of functional and other specifications (FS).defining fixes. · 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. including source code review. Any system for customer notification of problems Reference to results of an audit.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. The type of system supplied decides how generic or dedicated this documentation set must be. system configuration (IQ). which may include supplier audits Documentation should be assessed for suitability. support and maintenance Justification for the use of supplier documentation should be provided by the satisfactory outcome of supplier assessments.

Project controls example
Supplier generates qualification documents and performs testing
Advantage
·
·
·
·

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

Disadvantage
·
·
·

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

Customer generates qualification documents and performs testing
Advantage
·
·

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

Disadvantage
·
·
·

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

© PAUL OSBORNE │ PPTECH LTD

PAGE 42

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

Supplier Project Quality Plan

Specifications
·
·
·
·
·

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

Testing
·
·

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!

© PAUL OSBORNE │ PPTECH LTD

PAGE 43

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

© PAUL OSBORNE │ PPTECH LTD

PAGE 44

The use of risk analysis helps focus tests on what the machine or process should not do and what can go wrong. implementation. 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. equipment and systems which have been in use for many years. © PAUL OSBORNE │ PPTECH LTD PAGE 45 . 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. rather than what it should do. these are as follows in order of priority: In general. 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. testing. 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 are various techniques for reducing risk. It is a very helpful tool that can be applied to plant. 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. and risk management Risk Assessment is a formal and systematic approach to identify GMP risks related to equipment and supporting systems.Finally H&S Risk – Although this is usually correct for new machinery regarding CE marking.

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

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

and then a HAACP could be an action to reduce risk in a FMEA.Risk Management tools · · · · · FTA – Fault Tree Analysis HACCP – Hazard Analysis and Critical Control Points FEMA . 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).Failure Mode. it requires expert knowledge of the system under review.Failure Mode and Effect Analysis FMECA . including statistical process control. The main use of HACCP is with new manufacturing process or equipment. preventive action can be taken. FTA example The limitations of FTA are that it requires time and resources. It is similar to a control plan and cannot be used effectively without manual or automated process control methods. © PAUL OSBORNE │ PPTECH LTD PAGE 48 . Its limitation is that it requires excellent process knowledge. It also requires use of more complex statistical tools to be effective. 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. Once causes are identified. FTA represents the sequence and combination of possible events that may lead to a failure mode. 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. It can lead to paralysis by analysis (infinite chains of cause and effect). FMEA should precede HAACP to identify critical hazards/failure modes.

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. Severity Determine all failure modes based on the functional requirements and their effects and list them. © PAUL OSBORNE │ PPTECH LTD PAGE 49 . 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. Examples of failure effects are: degraded performance or even injury to a user. see FMECA later The use of Failure Mode and Effects Analysis (FMEA) widely used in the electronics and medical device industries. or protecting the user from the effect. The primary push came during the 1960s. process. if possible. These numbers help an engineer to prioritise the failure modes and their effects. Occurrence (Likelihood) and Detection. Hereafter the ultimate effect of each failure mode needs to be considered. actions are considered to change the design by eliminating the failure mode. FMEA must be initiated as early as possible during the design There are three areas of a potential risk to consider Severity. A FMEA is a cross-functional. A failure effect is defined as the result of a failure mode on the function of the system as perceived by the user. An example of this is the Apollo Space program.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. Let us look at FMEA in more detail. If the severity of an effect has a number 9 or 10. In the late 1970s the Ford Motor Company introduced FMEA to the automotive industry for safety and regulatory consideration. Each effect is given a severity number (S) from 1 (no danger) to 10 (important). while developing the means to put a man on the moon and return him safely to earth. or machine design change is needed to reduce risk. In this way it is convenient to write these effects down in terms of what the user might see or experience. 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. Later it was used for aerospace/rocket development to avoid errors in small sample sizes of costly rocket technology. It is important to note that a failure mode in one system area can lead to a failure mode in another area. 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. FMEA was formally introduced in the late 1940s for military usage by the US Armed Forces. Therefore each failure mode should be listed in technical terms and for function.

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

These actions can include specific inspection. Once the actions have been implemented in the design/process. to confirm the improvements. the new RPN should be checked. O and D This has to be done for the entire process and/or design. Once this is done it is easy to determine the areas of greatest concern. high volume Once every 3 months 100% manual check. for easy visualisation. The failure modes that have the highest RPN should be given the highest priority for corrective action. These tests are often put in graphs. After these values are allocated. 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. responsibility and dates of implementation are noted. Whenever a design or a process changes. but which occur more often and are less detectable. recommended actions with targets. adding more redundancy and limiting environmental stresses or operating range. testing or quality procedures. an FMEA should be updated.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. There could be less severe failures. 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 . redesign (such as selection of new components). This means it is not always the failure modes with the highest severity numbers that should be treated first.

The damage would not be expected to have a longterm detrimental effect. and company reputation with customers and suppliers. 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. The goal is to lower each risk.Expected to have a very significant negative impact. The impact could be expected to have short.Expected to have a moderate impact. The impact could be expected to have significant long-term effects and potentially catastrophic short-term effects. This would result in a critical non-compliance with the regulatory requirements and could result in regulatory action such as a withdrawn manufacturing license. the immediate effect of a hard disk problem may be the corruption of some data stored on that disk.to medium-term detrimental effects.GAMP 5 FMEA Within GAMP 5 there is a clear definition of the approach for validation testing using risk assessment. During risk assessment the impact of the risks to the system are decided and combined with the probability of the risks happening. High. financial impact. 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 recall. Medium . For example. including impact on regulatory compliance. Concentrate on handling the high risks and then the medium risks. 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 minor negative impact. The impact of a risk occurring may be described as follows: Low .

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

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. 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. 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. Qualitative Prioritisation © PAUL OSBORNE │ PPTECH LTD PAGE 54 .

The analysis can be drawn on a table which becomes the master plan of risk mitigation. 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. FMECA The Failure Mode.

modify. maintain. archive. when is 21 CFR part 11 applicable ? Basic Classification Does the computerised system create. 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 .21 CFR Part 11 and Annex 11 If requested by the customer.

’ Annex 11 refers to . Scope .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. 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. electronic records and electronic signatures. which provide together an active and constructive co-operation in the field of GMP. however. ISPE's GAMP Forum and the PDA have operated two separate initiatives. to deliver industry guidance relative to electronic information. Final revised Annex 11 published January 2011 and consequential amended to GMP Chapter 4 Documentation. These are referred to as ER/ES systems © PAUL OSBORNE │ PPTECH LTD PAGE 57 .The meaning of 21 CFR part 11 The meaning of 21 CFR part 11 is as follows.5 . they cover the broad issues that are associated with electronic records and signatures. the approaches are complementary and collectively. Part 11 refers to electronic records and signatures.Computerised Systems. recorded electronically. So what’s new in the rule? · · Electronic Records = Paper Records. This is active at the end of June 2011. We are concerned with the GAMP interpretation of 21 CFR part 11. Electronic Signatures = Hand Written Signatures. This is known as 21 CFR part 11. but with close cooperation. Both initiatives produced work products from different perspectives. under certain circumstances. to be equivalent to paper records and hand written signatures executed on paper. The Food and Drug Administration (FDA) in 1997 issued regulations that provide criteria for acceptance by FDA. PIC/S 21. 21 CFR — concerns the protection of privacy.applies to all forms of computerised systems used as part of GMP regulated activities such as packaging. Draft released for public consultation April 2008.

Open systems . searchable keywords that can be used to classify the document and details of the type of data found in the document. SOPs. Metadata must be stored as an integral part of the electronic document it describes. 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. ownership. the types of metadata that can be associated with an electronic record may include: details of the record's creation. Therefore. Requirement . At best. creation date. maintain. data integrity is related to the trustworthiness of the electronic records generated and managed by critical systems. Communication via secure network. See the later section on interaction for more details. Anyone who makes such a claim is incorrect. checks of devices.As closed systems. 1997 must be made compliant or replaced. manufacturing and quality assurance because these systems pose the most risk in terms of product quality and/or public safety. drug approval. What is 'metadata'? Literally. 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. Closed systems 7. it can be defined as 'data about data'. systems installed before August 20. or transmit electronic records must employ procedures and controls to ensure the authenticity. In practical terms. protection of records. plus using open systems to create. Part 11 requires both procedural controls (training. integrity and the confidentiality of electronic records from the point of their creation to the point of their receipt. Requirement . © PAUL OSBORNE │ PPTECH LTD PAGE 58 . · 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. Part 11 does not allow for grand fathering of legacy systems.Company delegate’s control.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 supplier can offer an application containing the technical requirements of a compliant system. modify.Validation of systems. These plans must include all applicable systems. The FDA is most concerned about systems that are involved with drug distribution. Alternately. author. operations and authorities and Change control. metadata can be configuration information for a device or equipment.Access control by the company or group. be detailed and have reasonable timelines and hold persons responsible for implementing those plans. What is FDA position on timelines for implementation of 21 CFR Part 11? There is no fixed date for complete remediation. limiting system access. Communication control by the on-line service. 7 All systems we discuss can be considered to be Closed.

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

3.10(e) Classification Supplier 11.10(h) 11.10(d) 11. modification or deletion of product configuration and actual production data). Audit trails of electronic records record the following: WHO. or edited by the Administrator. 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(g) 11.10(a) 11. WHAT.300(b) 11. This record could be the configuration of a scanning head for example. WHEN and WHY was a change made to a record.10(c) 11. 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. etc. The audit trail identifies operators by their log in names and from this knows the full name.4. In the audit trail user must be identified by their full name.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. The Administrator can also be suspended by a repeated failure of log-in. 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. or be just suspended by a repeated failed log-in. All rules outside of the influence of the supplier are classified as ‘customer’ and must be dealt with by the customer. However please note that Part 11 itself does not require the audit trail to record the reason why a record was changed.10(e) PAGE 60 Supplier .· · · · · The meaning such as issue 1. although another control usually requires recording this information. 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.300(a) 11.300(d) 11.

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(a) 11.200 (a)(1) 11.200 (a)(1) 11.10(e) 11. such as an identification code and password.70 11. reviewed) Are signatures linked to their respective electronic records? Are non-biometric signatures made up of least two components. When several non-biometric signings are made during a continuous session. 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.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. is the password executed at each signing? (Note: both components must be executed at the first signing of a session).50(b) PAGE 61 Classification Supplier . modification or deletion of product centric configuration data).200 (a)(1) 11.

10(k) (2) Customer Supplier system validation protocols SOP Application software and SOP SOP PAGE 62 . 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. periodically assessed and controlled over the retention period of the system? Is there documented training.10(j) Customer SOP 11.10(d) Customer Supplier responsibility 11. authorized.10(i) Supplier SOP 11.10(c) Customer Application software 11.10(a) Classification Supplier 11.10(k) (1) Customer SOP 11. access to.10(c) Customer 11.10(c) Customer 11.

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.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. ü ü ü ü ü ü ü ü ü ü ü . these are as follows: User access control Viewing of warnings and alarms.

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

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. the user cannot influence the audit trail process. · · · 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. delete. the date and time stamp when the record was created. Deleted. 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. © PAUL OSBORNE │ PPTECH LTD PAGE 65 . It is not a production record of system. 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. the full user name. All GMP relevant product data is captured during a production batch. Created. Audit trail recording is always active and it is on for the entire life of the system. 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. this includes all production relevant data. this is not in the regulation but a small field can be provided for comments. modified or deleted. difference to the previous status (old and new values) Please note in the above we do not record why the change was made. insert. modify). The security audit trail history contains the user name of the user. Modified or Accepted (What was changed) Description of event.Audit Trail We must ensure that an audit trail is maintained.g. Additionally any change to the user accounts is logged.e. the new value.

difference to the previous status (old and new values) Please note in the above we do not record why the change was made. 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.e. the username and details of the account. Created. Modified or Accepted (What was changed) Description of event. 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.e. Deleted. 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. this is not in the regulation but a small field can be provided for comments. Modified or Reactivated (What was changed) Description of event. 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. Suspended.System Parameters Select system parameters from the audit trail list and in the ‘view audit trail’ menu. difference to the previous status (old and new values) © PAUL OSBORNE │ PPTECH LTD PAGE 66 . 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.

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

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

configure. procedures and records based on their risk assessment. © PAUL OSBORNE │ PPTECH LTD PAGE 69 . ITdepartments should be considered analogous. install. 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. maintain (e. service providers) are used e. to provide. via remote access).g. modify or retain a computerised system or related service or for data processing. The need for an audit should be based on a risk assessment. protocols.. integrate. Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request.Supplier and Service providers [When] third parties (e. acceptance criteria.g. Validation Manufacturers should be able to justify their standards. [Then] .. validate.g. suppliers.

data limits and error handling should be considered.Data Migration If data are transferred to another data format or system. This data should be checked for accessibility. 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. Automated testing tools and test environments should have documented assessments for their adequacy. readability and integrity Testing Evidence of appropriate test methods and test scenarios should be demonstrated. 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. Particularly. Electronic Signatures Have the same impact as hand-written signatures. based on a risk assessment. in order to minimize the risks. Permanently linked to their respective record Include the time and date. there should be an additional check on the accuracy of the data. For critical data entered manually. system (process) parameter limits. · · · · · · · · · 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. © PAUL OSBORNE │ PPTECH LTD PAGE 70 . 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. validation should include checks that data are not altered in value and/or meaning during this migration process.

and we mean everything. which may include supplier audits · Documentation should be assessed for suitability. then the documentation should be considered as acceptable. Keep in mind that when requirements are specified as part of an order. so this means that suppliers can adopt their own documentation formats and providing the above applies. therefore the prevalidation documentation set is as important to the end customer as the equipment itself. In this industry. Major pharmaceutical companies have expended large amounts of money creating all supplier validation documentation in their standard format. You have to prove everything in writing. In supplying equipment to the pharmaceutical industry.’ Documentation is any written record of information used for quality assurance. There should be flexibility regarding acceptable format. Remember that the validation process must occur before the end customer can product drug. this way the company can begin the validation immediately. accuracy and completeness. This has often meant teams of either supplier or manufacturer’s technical teams rewriting documentation sets. It's not that the pharmaceutical people don't trust their suppliers. This is clearly a wasteful and unneeded practice. © PAUL OSBORNE │ PPTECH LTD PAGE 71 . 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. structure and documentation practices So GAMP 5 sets out. 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 any validation purposes.Good documentation practice The pre-validation documentation set should be supplied to the pharmaceutical company along with or shortly after the equipment. proof of meeting those requirements is expected in writing. evidence of adherence to specifications. or it is like you didn't do it. 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. in their words to ’leverage supplier involvement’. To date. 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. but these are the rules. everything you do must be documented.

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

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

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

All this information on the drawing should correlate with what is installed in the equipment. they will most likely have to redo the work to generate information that can be used for validation.). all the wire numbers or valve IDs should match the tags in the equipment. if no procedure was followed. The © PAUL OSBORNE │ PPTECH LTD PAGE 75 . 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 piping flows should be as they are depicted in the drawings. so they must be correct. These are an important part of the documentation that the pharmaceutical companies need to validate the equipment. and approved by the appropriate organizational units and reviewed and approved by the quality control unit. the pharmaceutical company needs to understand how it works. Any deviation from the written procedures shall be recorded and justified. including any changes. Rule 8 Drawings should be an accurate representation of the equipment being supplied This rule applies to drawings. strength. flow charts.Whenever validation or GMP work is being done for the pharmaceutical companies. An example of quantitative standards is measuring devices whose accuracy is traceable to standards. or they can be industry-accepted procedures such as standards published by professional organisations. To show the FDA and other authorities that the equipment is suitable and in a state of control. However. 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. 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. schematics. This means quantitative information or data must be traceable to an accepted standard of measure to be used for GMP purposes. Such procedures shall include all requirements in this subpart. they can be manufacturer's procedures (maintenance procedures. These standards should be referenced or noted in the documentation of the data provided to the pharmaceutical companies. To accomplish this. the pharmaceutical industry also expects adherence to standards for quantitative measures. if they agree with the procedure that was followed. For example. installation procedures. All the wires should connect to the components and terminals indicated in the diagrams. quality. piping diagrams. wiring diagrams. 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. written procedures or accepted standards should be followed and this should be noted in the documentation supplied to the pharmaceutical company. All the drawings should contain the most current correct information. installation drawings. and purity they purport or are represented to possess. Information generated based on a written procedure may be used by the pharmaceutical people as part of their validation data. These written procedures. shall be drafted. Procedures can be internally generated (procedures that you write up). reviewed. calibration procedures. and layout drawings. etc. 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. This means someone calibrated either the measuring device or the instrument used to calibrate the measuring device. it needs to have accurate drawings and diagrams.

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

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. 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. but still keep a printed copy for the turnover package. This is the ideal scenario. they will keep after you until they get what they need. By the time the equipment is delivered. Don't assume they will accept the equipment and wait to get the complete documentation package. forgotten. The manuals must be appropriate (correct revision and model numbers. like a binder or series of binders. In the ideal scenario. It's always easier to get them right the first time. make sure the turnover package is complete. 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 . If you want to impress the pharmaceutical people. it is important to let the pharmaceutical companies know this as soon as possible.Individual component manuals are usually produced by the component manufacturer. and the system manual is usually produced by the equipment system manufacturer. These are the written procedures they need to follow to ensure GMP compliance when they use this equipment. and hand it in all at once. This sounds like trivial stuff that shouldn't be nearly as important as the equipment.) for the equipment. If this information is going to be delayed for any length of time. My recommendation to avoid a lot of stress and headaches is to put everything into one neat package. but in this business paperwork is valuable because of the reasons mentioned earlier. Remember that they cannot use the equipment to make drug products until it has been validated. separate the sections by tabs and put in an index. the turnover package is provided to the pharmaceutical company at the same time as the equipment. etc. there may only be one or two persons who were involved in the planning stage. I have been involved in projects where it took months to fix the paperwork. the documentation is up to date. this way they have what they need to start working on validation right away. Remember these rules when you submit paperwork to the pharmaceutical companies. Sending things to the pharmaceutical company in dribs and drabs over an extended time typically results in things being misplaced. the people involved in the project typically change over its life. This turnover package has a significant value to them in getting on-line as quickly as possible. Otherwise. This is what we refer to as the prevalidation package or turnover package. Whatever happens. In addition. or lost. The turnover package is the official master copy of the documentation they will use for validation. 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. 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. and it is provided to the pharmaceutical company in a timely manner.

while the project completion time got longer and tempers got shorter. 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. Believe me.Meanwhile. 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’. take the extra time needed to make sure the paperwork will be acceptable to the pharmaceutical companies before you submit it. 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. previously it was acceptable to write: Did the system pass the test Yes ( ) No ( ).

.g. through public organizations. Useful if there is no experience within the supplier..’ The audit scope includes two parts: 1. PDA and from private authors. regarding quality. 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. Gives a good picture on the supplier’s quality system and software development and validation practices. 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. 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?’. 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. Depending on the risk and impact on (drug) product quality answers can be derived from: 1. For software development this usually means that the software is developed and validated following documented procedures.g. Direct supplier audits. Documentation of experience with the supplier. pharmaceutical Experience with the supplier © PAUL OSBORNE │ PPTECH LTD PAGE 79 . Use checklists available within your company. 3. The following Supplier risk assessment is based on the Parenteral Drug Association (PDA) Technical Report number 32. Gives an independent assessment of the quality system and/or product development. e. published in October 1999 entitled ‘Auditing of Suppliers Providing Computer Products and Services for Regulated Pharmaceutical Operations. 3rd party audits.g. 2. Assessment checklists (mail audits).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. 4. e. External references. Product risk 2. This means the principle supplier himself must make the above assessment on his sub-supplier and provide documentary evidence.

The checklist is one element of the Supplier Audit Guideline written by most large pharmaceutical companies. and ensure proper audit coverage. 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 . more consistent.The Supplier Audit Checklist is intended as an aid to make supplier auditing easier. faster. Most will follow the procedure of auditing the following topics within a supplier’s organisation.

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

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

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

The style usually adopted to start and finish dates in the form DD/MM/YYYY. 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. 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. hints on reading a script At the end of the training the delegates should be issued with a certificate of training. These certificates can state that the individual has ‘attended’ a course or has ‘successfully participated’ in a course. in both theory and practice. 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 . tools. The certificate must not state that the individual has achieved an addition qualification as a result of attending the course.Training The supplier should identify training needs and provide appropriate training. techniques. They should consider the specific methods. 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. Additionally the trainer should also have attended some type of ‘train the trainer’ course. These typically last one to two days and teach important lessons. 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. and hardware to be used.

and delivery of items. consistency. 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 . handling. impact and risk assessed. once per year. and correctness of items of the machine.’ Change Management Regulations/Guidelines ‘ . and retained within safe and secure areas. Backup and recovery procedures should be verified. Ensure the completeness. change control measures can apply to equipment. tested. standard operating procedures. Document the review. 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. and approved before implementation. documented. environmental conditions. maintained. and therefore on the state of validation. Consider that some elements of the machine must require routine maintenance . and should be reviewed.. authorised. 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. Control storage. review the status of the above. Change Control Baseline Definition of the FDA (1995): ‘A specification or product that has been formally reviewed and agreed upon.. Identify and define system components.’ – 21CFR parts 210 and 211 May 1996. Record and report the status of items and modifications to items. depending on: organisation. that serves as the basis for further development. infrastructure.. Periodic review – at routine intervals. manufacturing instructions.This is a planned activity. 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.

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

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. 89/336/EEC covers all electrical and electronic equipment and their phenomena. this is implemented by all member states. 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 . The way to CE marking of the product is to ensure the essential protection requirements are met. Some typical EN specifications follow.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
General
Products which are to be provided with the CE marking shall be designed to comply with relevant
requirements.
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
requirements.
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)

·

Type-designation

·

Description

·
·
·
·
·
·

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

© PAUL OSBORNE │ PPTECH LTD

PAGE 88

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
provided.
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).

© PAUL OSBORNE │ PPTECH LTD

PAGE 89

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

89/336/EEC

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

© PAUL OSBORNE │ PPTECH LTD

PAGE 90

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

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

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

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

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

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