Software Categories

It is important to understand that computerised systems often consist of multiple software elements and that within a single system these elements may represent a variety of software categories.

6.2.1. Category 1 Operating Systems

These are established commercially available operating systems.

Applications are developed to run under the control of these operating systems. Features of the operating system are functionally tested and challenged indirectly during testing of the application. The name and version number of the operating system is documented in application design documentation and verified (installation qualification). Change control should be applied to manage upgrades to the Operating system in order to determine the impact of new, modified or removed features on the application. Application revalidation shall reflect degree of impact.

Examples include Unix®, Windows NT® and VMS®.

6.2.2. Category 2 Firmware

Typically these are embedded in commercially available pieces of electronic equipment designed to perform discreet operations.

Configuration may be required in order to set up runtime environment and/or process parameters. The name, version number and any configuration/calibration for the firmware should be documented and verified (installation qualification). Functionality should be tested during OQ. Change control should be applied to manage any change to firmware or configuration parameters. Operational procedures should be established and training plans implemented. Supplier audits may be needed for highly critical or complex applications.

Bespoke/custom firmware should be considered as Category 5.

Examples include weigh scales, bar code scanners, three-term controllers.

6.2.3. Category 3 Standard COTS Software Packages

These are commercially available, configurable, standard software packages providing an off-the-shelf solution to a business or manufacturing process. Configuration should be limited to establishing the run time environment of the package. The system is not configured to define the business or manufacturing process itself.

Runtime process parameters may be input to the application. The name of the package and the version number should be recorded. To satisfy validation requirements critical user requirements (e.g. security, alarm and event handling, calculations and algorithms) need to be documented, reviewed and tested. Supplier documentation should be leveraged wherever possible (e.g. user and technical manuals). Supplier audits may be needed for highly critical or complex applications or where utilisation of the application within the pharmaceutical industry is limited. Operational procedures should be established and training plans implemented.

Examples of standard software packages include statistical analysis packages, PLC-based manufacturing control systems such as non-customised software for a coating pan controller, laboratory instruments such as Fourier transform infrared (FTIR) and standard diagnostic tools.

6.2.4. Category 4 Configurable COTS Software Packages

These packages provide standard interfaces and functions that enable configuration of user specific business or manufacturing processes from pre-defined or customised modules. Complex systems often have layers of software, with one system including several software categories. Software packages and the platform should be well known and mature before being considered Category 4 software.

A supplier audit is typically required in order to confirm that the software package has been developed in accordance with appropriate quality systems and that application development and support organisations are robust and competent. In the absence of a documented quality system, suppliers should use this guide to provide the foundation for establishing a suitable quality system to control package development and support.

Validation should focus on the configured business or manufacturing process. New and bespoke/custom modules should be handled as Category 5 software.

The validation plan should document a structured approach to the validation of the application. The full life-cycle should be addressed,

although much of it is the developer’s responsibility and thus may be verified during the supplier audit. The validation plan should reflect supplier audit observations, application criticality, size and complexity and should include strategies for the mitigation of any shortfall identified in the supplier’s system development process.

Examples include distributed control systems (DCS), supervisory control and data acquisition packages (SCADA), manufacturing execution systems and some LIMS and MRP packages.

6.2.5. Category 5 Bespoke/Custom Software

These systems are developed to meet the specific needs of the pharmaceutical organisation. Bespoke/custom developments may be a complete system or extension to an existing system. Complex systems often have layers of software, with one system including several software categories.

A supplier audit will typically be required in order to confirm that appropriate quality systems are in place to control development and ongoing support of the application. In the absence of a documented quality system, suppliers should use this guide to provide the foundation for establishing a suitable quality system to control application development and support.

The validation plan should document a full life-cycle approach to the validation of the bespoke/custom application based upon the life-cycles contained in this guide. The validation plan should reflect supplier audit observations, application criticality, size and complexity and include strategies for the mitigation of any shortfall identified in the supplier’s system development process.

Examples of bespoke/custom software includes bespoke PLC programming (e.g. ladder logic) and user applications (e.g. spreadsheet configuration and database customisation).

6.2.6. Summary of Software Categories Category Software

Type

Validation Approach

1 Operating

Systems

Record version. The operating system will be challenged indirectly by the functional testing of the application.

Record version of non-configurable COTS firmware and calibrate as necessary.

Record version and configuration of configurable COTS firmware. Calibrate as required and verify against user requirements.

2 Firmware

Manage bespoke/custom firmware as Category 5 software.

3 Standard

COTS Software Packages

Record version and verify operation against user requirements. Consider auditing the supplier for critical and complex applications.

Record version and configuration, and verify operation against user requirements. Consider auditing the supplier for critical and complex applications.

4 Configurable

COTS Software Packages

Manage any bespoke/custom programming as Category 5 software.

5 Bespoke/

Custom Software

Audit supplier and validate complete system.

6.2.7. Summary of Software System Documentation

Business Requirements X X X May be combined with URS.

Compliance Assessment X X X X

System Register X X X X Per system, not per software category.

Validation Plan X X X X Per system, not per software category.

Supplier Audit X X For bespoke and critical COTS applications.

User Requirements Specification (URS)

X X X X

ERES Assessment X X X X When the compliance assessment states that the system must be validated.

System Overview X X X Consider as separate document, maybe included in URS/functional specification.

Functional Specification X X X For standard COTS packages reference to product specification is sufficient.

Detailed Design

Specifications X X X Maybe split into hardware and software design documentation.

Data Definition For projects that populate the new system with existing data.

Design Review X X Sometimes known as DQ.

Source Code Review X X Configuration only for category 4 software.

Development Testing X X X X Includes unit, integration, interface and system.

Data Load X X X X For projects that populate the new system with existing data.

Installation Qualification X X X X Operational Qualification X X X X

Performance

Qualification X X X X

Qualification documents may be combined as long as test plans and test cases are collectively approved before testing. For standard COTS category 2 qualification may be based on calibration activities.

Validation Report X X X X May be in the form of a certificate for very simple systems.

Operational and Support

Plans X X X X Activities include user procedures, backup and restoration, maintenance, security management, business continuity plans.

Archiving and

Decommissioning X X X X Special attention is required for electronic records/signatures.

Note: No specific validation activities for standard COTS compilers and operating systems beyond documenting version details.

7. Approach to Laboratory Systems