Software Subject to Validation

GAMP 4 Guidelines Applied for Developing Software Products by Rolf Blumenthal, Werum Software & Systems.

21 CFR Part 11 has been launched, now it's the practical implementation many companies still have to tackle. Proper preparation and MES software tailored to pharmaceutical requirements may help enterprises to travel this road. The days of jam-packed cabinets in which manufacturing reports are filed by the meter could be way back already. With the regulations of 21 CFR Part 11 the FDA has indeed paved the way for electronic documents and signatures to document the manufacturing process in pharmaceutical industry.

Today, such tasks can be carried out by a Manufacturing Execution System (MES). Software-controlled production generates Electronic Batch Records and where-used lists for batches, both of which provide the information to assess and verify proper manufacturing of a product.

As electronic system the software replaces or enhances previously applied procedures of paper-based documentation and, therefore, automatically is subject to the validation requirements of the pharmaceutical industry. Apart from the requirements on software functions (GMP compliance), validation demands also cover GAMP 4. This guideline, published by the GAMP Forum, defines generally applicable policies for producing software (software life cycle).

Among other issues, the guideline specifies procedures for

  • Defining requirements on the software.
  • Performing risk analyses.
  • Planning and specifying software tests.
  • Executing and logging software tests.
  • Operating the software and change management proceedings.

Why GAMP 4?
It really is no easy job to assess and to verify the quality of software. Therefore, it certainly is a valuable support for every software provider to have available a benchmark in form of universally applicable rules. Official regulatory requirements usually still need considerable interpretation.

Guidelines like GAMP 4 help to interpret these requirements and enable companies to implement the guidelines by providing concrete examples. This guideline, published in December 2001, is a comprehensive revision of the guideline GAMP 3 adding new contents in accordance with current regulatory positions and technical developments. It puts a stronger focus on users' responsibilities and defines the system operation activities in much more detail.

GAMP 4 combines the findings and contributions of various bodies, such as:

  • APV, Germany-based International Association for Pharmaceutical Technology
  • GAMP Americas Forum Review Group
  • VDI/VDE GMA, Germany-based Society for Measurement and Automatic Control
  • NAMUR, Germany-based Association of Users of Process Control Technology in Chemical and Pharmaceutical Industry.

The extraordinary level of participation and commitment of GAMP Americas underlines how far GAMP 4 has spread and that it has been widely accepted as guideline for rating software quality. For this reason, Werum applies GAMP 4 both in product development and for handling customer-specific projects.

The V-Model
Projects have to be executed in accordance with defined quality management policies. By standard, Werum applies the V-model of GAMP 4. In the planning and specification phase, the Functional Specification defines in detail the MES functions to be used and the way they are used. Should the modeling process reveal that additional functions are required; these results will be considered in the Design Specification and for the development of software expansions.

The software to be implemented at the customer's site is designed on the basis of an existing product. Usually, adjustments are required to add customer-specific functions and to carry out engineering tasks, such as the setting of parameters to define shop floor layouts, manufacturing and other equipment, or the modeling of storage locations and transport routes. Then the system is installed and has to go through comprehensive verification, incl. acceptance testing, IQ, OQ, and PQ. The phases of qualification are increasingly associated to the phases of software development. Practice shows that an increasing number of customers expect the complete test documents required for qualification to be included in the deliverables.

Figure 1: Procedural model for software development in GAMP 4-compliant projects
(Figure 1: Procedural model for software development in GAMP 4-compliant projects)

GAMP 4 Policies for Product Development
Werum has taken advantage of the benefits of the GAMP 4 model for developing their product PAS-X. It should be mentioned that the software life cycle in product development is not the same as for specific customer projects. When developing a product, the software system is not implemented for a single opportunity, but continually advanced in consecutive versions.

The product development plan of a new version incorporates a variety of requirements, such as suggestions for new or extended functions arising from previous projects. Also the evaluation of various customer requests and market analyses helps to anticipate trends for future user requirements. At the same time, new methods and technologies coming up in the field of information sciences have to be considered.

Frequently, the requirements profile of a development plan shows functional add-ons instead of concrete workflows. This is why Werum's first step was to prepare a model of all business processes supported by the product software PAS-X. This model makes it possible to operate a kind of 'virtual factory' based on a 'generalized' standard business process model. All application functions resulting from this business process model are directly integrated into the software models and associated documents. This kind of 'as is' software description is of GMP relevance since it provides a description for each and every software function. On customer request, the product software can be delivered with a complete 'as is' description.

Such an 'as is' description includes documents, such as:

  • A Functional Specification and Design Specification: According to GAMP 4, this is a complete functional description of the software going into different depth of detail.
  • Cross function reference list: This list enables a subsequent verification that the MES functions have fully been tested.
  • GMP-relevance and risk analysis: States the GMP-relevance of application functions, possible error situations as well as the risk assessment for every business process.
  • Test plans and test protocols for individual tests comprising module, integration and system acceptance tests.
  • Test reports: The entire testing process is recorded; test reports are completed test protocols incl. test tracks, such as hard copies, test prints, or labels.

For this reason, the result of product development is not just software that has passed the tests in accordance with GMP requirements. Moreover, it includes documents and test packages that can be used for Site Acceptance Testing (SAT) and Operational Qualification (OQ) (see Fig. 2).

(Figure 2: QM documents in context (extract))
(Figure 2: QM documents in context (extract))

When the product software is applied in a concrete project, the demands on the software are defined by existing business processes at the customer's. The discrepancies between the general process model and the customer's actual workflow are established within the scope of a Functional Specification. Project-specific solutions have to be found for these discrepancies, which result in modified descriptions and test specifications. These are the documents to be used for validation.

Benefits for Users and Suppliers
Both, users and suppliers, equally profit from applying the GAMP 4 guidelines. The costs and the time needed for creating a system compliant with all the regulatory requirements can be cut significantly. A consistent life cycle model helps to meet regulatory expectations. There is no expensive and time-consuming retrospective validation. Another important point: The responsibilities of users and suppliers are defined distinctly. Such an explicit assignment of tasks facilitates cooperation.

Thus, GAMP 4 supplies a clear-cut framework for compliance with existing standards (e.g. ISO 9000) and strengthens suppliers' understanding of GxP requirements. The guideline provides a whole set of procedures and methods to simplify an implementation of the defined principles. Werum's approach to bring the QM procedures applied in product development into line with GAMP 4 policies has turned out to be a considerable improvement for developing software subject to validation.

(Figure 3: How to apply product software and documents within the scope of a specific project)
(Figure 3: How to apply product software and documents within the scope of a specific project)

Production Management Systems by Werum: http://www.pas-x.com

Rolf Blumenthal

Author Information - Rolf Blumenthal

Vice President

Rolf Blumenthal is Vice President International Consulting with Werum Software & Systems America, Inc. For more than five years Rolf Blumenthal has managed the product development for Werum's MES software suite PAS-X. In this context, compliance with GMP and FDA requirements is of prime importance. Since Rolf Blumenthal is a renowned industry expert with hands-on experience and comprehensive technical expertise he started international consulting activities in 2005.

In this role he advises PAS-X customers on the following major topics: IT architectural blueprints, system integration, computer system validation, optimized use of PAS-X, and efficient creation of master batch record libraries. Rolf Blumenthal is a member of the GAMP D-A-CH Forum where he is actively participating as editor and reviewer of new guidelines. Since 2002 he has been a member of the GAMP D-A-CH Steering Committee and of the Special Interest Group “Validation of Small Manufacturing and Weighing Devices”.

2 comments:

Mugundhan said...

Nice guide! thank you!/I love it ! Very creative ! That's actually really cool Thanks.
Software Product Development

sandip said...

It can; at times, be almost impossible to split such systems into computers and or equipment; therefore the system must be considered, taking note of the specifics of each and the overall functionality achieved by the system. While recognizing that the diversity of software, as defined in GAMP 4 & 5 is vast, you have to remember that the typical operating systems (windows or similar) because of the vast number in service, are taken as standard, and do not require to be qualified. Therefore when you come to application programs; that run on these standard operating systems (STS), your system qualification effort does not have to include the STS; just the application program itself. click here