This document will specify your requirements (without over detailed explanations of your design solutions). Relevant Good Manufacturing Practices (GMP), Good Laboratory Practices (GLP) and other regulations or guidelines will be referred to. Your requirements will be prioritised into essential and desirable requirements. Boiler Plate URS documents are also available.

The URS is the first step of a typical project is outlining the user's requirements. GAMP® formalises these requirements in a structured document - predefined templates help with regulatory references, "fill in the blanks" (and standardised "Boiler Plate" sections to outline things like documentation standards). The URS is documented in GAMP®4, Appendix D1. To accompany a URS, you may also elect to distribute things like coding standards and electrical procurement standards that we can prepare for you.

GAMP®/ISPE/JETT will likely harmonise, to some degree, work under ASTM E55 with various document standards including the suggested layout of an effective URS. Please read here for some more information on a URS.

Also called a Functional Requirements Specification (FRS) or even Functional Description (FD).

This document will respond to the URS. A "Requirements Traceability Matrix" or RTM will be included, if required. The FRS will explain what the end system will do, what is to be provided and the design objectives for the system. Any limitations or URS exceptions will be described. Boiler Plate FRS documents are also available.

The FRS is the second step of a typical project and a direct response to the URS. The FRS is the principal document to define what the system will do and what functions are to be provided by the system. Again, predefined templates assist you in getting the right FRS for your system. The FRS is typically written by the supplier, and more than one supplier may be asked to provide an FRS. To have useful FRS documents, we will provide assistance to your suppliers.

Please read here for some more information on a URS, a similar effort would be placed into producing a relevant FS.

This represents a family of documents - Hardware Design Specifications, Software Design Specifications and Software Module Design Specifications. The H-DS defines the electrical control system and ancillary systems including computers, I/O, PACs/PLCs, environment and electrical supplies. The S-DS is the software corollary to the H-DS (more than one S-DS can be written for large projects). The S-DS covers databases, software modules, and other aspects of the software engineering involved in the project. For large or complicated systems, Software Module Design Specifications can also be written. RTMs are often written to trace back to the FRS and URS. Boiler Plate DS documents are also available.

These are detailed design documents intended to outline the actual design of a system. They are often used as the template for the "Technical Manual" at the end of the project. These detailed documents define everything from cable specifications to pseudo-code (or actual code) outlines of the software engine.

Please read here for some more information on a URS, a similar effort would be placed into producing a relevant DS.

Sometimes called a Design Qualification (DQ). This is a check stage where the requirements are reviewed against the proposed design to verify that the system will perform as required. The tie-in to the Validation Master Plan is also carried out at this time.

This step of the project provides for a documented check of the project to date (URS, FRS, DS) to verify that the URS (and Master Validation Plan) track through correctly. The EDR is sometimes called a Design Qualification (DQ) and provided for the in the ISPE Baseline Guides rather than GAMP® itself. The EDR is normally reserved for large projects.

For GAMP®5, this step may be re-categorised as some other kind of risk management programme in line with ASTM E2500-07.

Application software for pharmaceutical, nutraceutical and biotechnology cannot be "plain" or "boiler plate". GAMP® specifies areas of review including looking for dead code, modular programming, annotation and an appropriate tag-naming convention. Third-party reviews are highly recommended for large systems. GAMP® recognises five levels of code - Level 5 ("bespoke") requiring the most attention.

GAMP® categorises code according to the following:

• Category 1 - this is an area to categorise "Infrastructure Software" (such as operating systems). An evaluation of the O/S itself is not required. The version number of the O/S along with patch and hotfix information is recorded. If the version number is changed or patches are applied then this could lead to failure of applications running on the O/S. Re-testing risk analysis must be considered when the underlying O/S or even Operating Platform is upgraded or modified in any way. Supplier Audits are not expected (or required) for the underlying Operating Platform or O/S. The effect of secondary systems such as anti-virus software should also be considered here;
• Category 2 - this was firmware, this category is no longer part of GAMP® (as of GAMP® 5);
• Category 3 - this is "Non-configured Software" (non-configured COTS, but includes simple configured software) including OpenOffice, Microsoft Office, MATLAB and similar packages. The packages themselves require no verification/validation and the suppliers require no Supplier Audit. However, upgrades must be considered carefully and a risk based analysis programme in place to carefully examine any upgrade programme. Configuration is limited to the environment set-up and parameter values IQ verifies the name and version / revision. OQ tests the requirements. Supplier Audit in extreme cases;
• Category 4 - this is "Configured Software" software such as SCADA (low end), ERP, MES and LIMS. Standard verification/validation unless the platform, package or supplier are not well known. In that case, move to Category 5. A Supplier Audit is highly likely;
• Category 5 - this is a bespoke (custom built) software application (typically including bespoke hardware) including PLC/PAC, HMI, SCADA and specialised micro-controller systems (embedded systems) or PC applications. At this point the end user would expect a software design specification (in addition to an FS, URS etc.) from their supplier and also the end user (or their agent) would conduct audits of the equipment supplier. We would normally expect the associated hardware to be Category 2.

A typical project contains sub-systems from more than one category (O/S, configurable, firmware, bespoke). Risk is highest when software is Category 5.

There are two categories of risk for hardware:

• Category 1 - this is COTS hardware - there may be some configuration required and that needs to be verified. A hardware design specification is not necessary. A supplier audit would not normally be necessary either;
• Category 2 - this is bespoke or customised hardware - what an end user would normally expect with a specialised piece of equipment such as a vial filler or bioreactor. At this point the end user would expect a hardware design specification from their supplier and also the end user (or their agent) would conduct audits of the equipment supplier. We would normally expect the associated software to be Category 5;

What is risk? Risk is the possibility of an event occurring that will have a negative impact on the production system. The event may be the result of one problem or a combination of problems (UK CPNI). Alternatively risk can be defined as "[a] combination of the probability of an event and its consequence" (ISO/IEC Guide 73:2002).

Risk is often labelled as the "Severity" against the "Occurrence" against the "Detectability" or SOD. This fits well with a Boston Grid as outlined a little later on. Notice that if a likelihood of occurrence is zero then no verification is required and the risk analysis is quickly concluded. The Boston Grid will tell us "Risk Class" and "Risk Probability".

Risk Assessment is much more difficult to prescribe or categorise than the "traditional" GAMP®4 approach. The point of an effective programme to manage risk is to concentrate on what can cause harm to the end user rather than just validating or verifying everything (and spending lots of money in the process). The old "kitchen sink" approach also might lead a regulator to feel that an end user or supplier does not understand their system as they are verifying everything at 100% risk, not just what is actually at risk.

So at the beginning of the project - and during or before a URS is developed, an preliminary Risk Assessment should be carried out by the end user. What should be considered are the following:

• What are the overall risks to my business if I go ahead with this project (perhaps, also what is the risk of doing nothing)?
• What GxP regulations apply to my current and/or proposed system?
• What is the overall impact of the system(s)?
• Do I need to study risk again?

The reader is directed to GAMP®5 Appendix M3 for more details.

A good driver for a moribund project is that doing nothing is considerably higher risk to the end user than going ahead with the project. At least with the Risk Assessment written up, the management team or steering committee is aware of what potential bad publicity awaits them!

Once the project has been classified according to GAMP®5 as Category 4/5 (Software) and/or Category 2 (hardware), then during the development of the Functional Specification and Configuration Specifications (Design Specifications) the end user and supplier would conduct additional Risk Assessments:

• What are the risks to specific processes?
• What are the risks to specific functions?
• Define the controls that are in place to reduce each identified risk.

The reader is directed to GAMP®5 Appendix M3 for more details. Note that the supplier is now "on the hook" in a need to understanding risk - this was simply not the case for GAMP®4.

There are two approaches to Risk Assessment - one is to embed the Risk Assessment into "existing" documents - such as the URS and FS. The other is to keep them as separate documents. It really depends on how often the documents are expected to change which approach is "recommended". Also, if the Risk Assessment can easily involve a large team or other consultants/suppliers it may not be practical to include it in the FS being written by an equipment supplier. In larger projects there may be multiple pieces of equipment that are combined into one Risk Assessment. We recommend that it be kept separate, especially when dealing with suppliers of high-risk systems who are not used to performing Risk Assessments (or, perhaps, dealing with overseas suppliers).

One excellent part of the Risk Assessment is the core areas of 21 CFR Part 11 - indeed, the 21 CFR Part 11 Assessment can now be categorised as part of the Risk Assessment.

A useful model for a Risk Assessment is the one presented by ISO 17799 and the utilisation of 3x3 Boston Grids. We will add some more information on this the next time this web site is updated.

An effective Supplier Audit Programme (as required by GAMP® for Category 5 software and Category 5 hardware systems). An actual Supplier Audit can either be accomplished "by post" (i.e., remotely) or "in person". The scale of the project and the effectiveness of each type of audit must be considered prior to executing the programme. A Supplier Audit Programme includes questions pertaining to:

• Company information;
• Company organisation;
• Quality management programmes (QMS);
• Planning and product/project management;
• Correct use of specification documents (e.g., S-DS);
• Project implementation programmes (e.g., software coding standards and Software Configuration Management - SCM);
• Test programmes (e.g., QA testing of code);
• Completion and release programmes (i.e., kit released to customer);
• Support and maintenance programmes;
• Background support for QMS, SCM, security and other programmes.

It is expected that where a supplier does not meet expectations, a written follow-up is made along with subsequent checks to verify that the supplier has adequately addressed their shortfalls. Also, an annual re-audit is expected for suppliers such as System Integrators who supply services for many projects (versus a supplier who provides services for one project only).

GAMP®5:

• Moves away from GAMP®4's focus on customised systems to approaches for COTS (commercially available off-the-shelf systems);
• Tighter focus within the GAMP® guide versus GAMP®4;
• Focus verification/validation on demonstrations to the regulator(s) that the system is fit for the intended purpose without some of the unnecessary work that is often associated with computer system verification/validation;
• Inclusion of methods of system retirement;
• Top-to-bottom Quality Management Systems approaches along with a better inclusion of Risk-based Analysis techniques;
• Comprehensive revision of the GAMP® appendices (including, hopefully, replacement of the old templates on the JETT web site);
• Complete integration of latest FDA Guidances, PIC/S Guidance, ICH Guidances Q9/Q10, Process Analytical Technology (PAT).

The authors of GAMP® recognise that a great deal of effort is being expended on simple system (say Category 1) that is unnecessary. GAMP®5 provides for a level of rigour (whether or not to include a Design Specification, for example) based on the category of code.

Click here to read more about 21 CFR Part 11 (ERES) including expectations for 2008-2009 with the updated 21 CFR Part 11.