Search

Loading

If you find the information within this blog useful please take the time to support the site and visit one of the Google advertisers.


Share

11 May 2010

GAMP5 Software Categories



As discussed in ISPE GAMP 5 the GAMP Categories for hardware and software have been retained in GAMP 5, all be it in a modified format from GAMP4.

The software categories identified in GAMP 5 do not fit with determining the risk to product quality, efficacy or data integrity and no longer plays an integral part to determining that a computer system is fit for purpose.

The complexity and the maturity of the software can be used to support and mitigate identified risk but should not be used to determine the validation / verification deliverables.

GAMP Categories

The GAMP categories were originally introduced to provide an initial assessment as to the validation requirements / deliverables.

In GAMP 4 there were five software categories. These have been revised in GAMP5 to four categories as detailed below:

Category 1 – Infrastructure software including operating systems, Database Managers, etc.

Category 3 – Non configurable software including, commercial off the shelf software (COTS), Laboratory Instruments / Software.

Category 4 – Configured software including, LIMS, SCADA, DCS, CDS, etc.

Category 5 – Bespoke software

Category 2 from GAMP 4 has been removed. This related to firmware. At the time that GAMP4 was issued firmware was considered to be used for simple instruments. However as technology has advanced the it has been recognised that complex software can be embedded (firmware) within systems.

Why Categorise?


In GAMP 3 and GAMP 4 the purpose of the GAMP categories had clear purpose, identifying which validation deliverables were not required. Categories 1-3 were considered to standard systems and the System Life Cycle Design (SLCD) documentation were not required, this included
  • Supplier Audits
  • Functional Specifications
  • Source Code Reviews

GAMP 5 still includes these categories however the benefits are not integrated within a Science and Risk Based Approach to validation and the ASTM approach.

In the ASTM E2500-07 standard that:
“Vendor documentation, including test documents may be used as part of the verification documentation, providing the regulated company has assessed the vendor”

This implies a level of governance to be applied over suppliers independent of the maturity or complexity of the software.

While GAMP5 provides guidance to the approach based on the categories there are better rationales that can be put in place rather than the complexity of the software. For example a Laboratory Instrument (Category 3 – COTS) which is pre-use and post-use calibrated or runs standards along with the test need less verification than a system where only the results are relied on. This can be documented within the validation plan or the risk assessments.

2 comments:

  1. <>
    <<sent by Ian

    As you said “GAMP5 still includes these categories however the benefits are not integrated within a Science and Risk Based Approach to validation and the ASTM approach”

    what is the benefits? what i understand is: we may put a very simple customized code ( CAT5) to configuration software (CAT4), which decides and documented by the RA. Is it right?

    ReplyDelete
  2. Ian
    Yes the categorisation of software supports the risk process. The novelty and complexity of the software should support the assumptions made within the risk assessments.

    In previous versions of GAMP (GAMP3 and GAMP4) the software categories were used to directly relate to the validation activities (e.g. supplier audit).

    However rather than just considering the complexity and novelty the need to perform and audit should be based on documented risk assessment considering patient safety and data integrity along with the category of software. This is supported in the new release of EU Annex 11 which states:

    “The competence and reliability of a supplier are key factors when selecting a product or service provider. The need for an audit should be based on a risk assessment.”

    ReplyDelete

All comments on the computer systems validation blog are welcome.

Share