10. Approach to IT Systems
10.1. Definition of IT Systems
IT systems can be characterised as networked applications used within a multi-user environment that encompass a range of business and GxP critical activities. They are commonly referred to as business or information systems.
A key characteristic of IT systems is that they are usually networked applications that operate in a multi-user environment. As such these systems are dependant upon a supporting network and IT infrastructure for their operation.
Typical business processes managed by an IT system include but are not limited to inventory management, capacity planning, master production scheduling, sales order processing, materials requirement planning, purchase order processing and shop floor control relating to the manufacture and distribution of bulk drug substances, intermediates and finished packed stock.
10.2. Scope of Systems Covered
The following are examples of IT systems covered by this guideline. This list is not exhaustive:
• Enterprise resource planning (ERP).
• Manufacturing resource planning (MRPII).
• Laboratory information management (LIMS).
• Electronic document management systems (EDMS).
• Financial planning and management.
• Engineering maintenance management system (EMMS).
• Distribution Systems.
• Schedulers.
• Financial systems.
• Purchasing systems.
• Human Resource systems.
The inter-relationships between IT systems can make it difficult to scope the boundaries for validation. Guidance on dividing interconnected IT systems into GxP and non-GxP is provided in GQG 1401A.
10.3. Responsibilities
An approved quality system (e.g. iQMS) should be used for the development and implementation of IT systems. This guideline outlines validation expectations that should be considered alongside the procedures embodied in the selected IT quality system. Advice on desktop applications, IT infrastructure and software tools that might be associated with an IT project can be found elsewhere in this guideline.
10.4. System Register
Central IT support organisations as well as operating sites should maintain system registers.
10.5. Validation Life-Cycle 10.5.1. Planning Phase
Business Requirements
Business requirements must clearly scope what are often networked systems with numerous interfaces.
Compliance Assessment
Compliance Assessments should be used to document whether any aspects of a computerised system have GxP impact and hence require validation. The System Register should indicate whether any aspect of a computerised system has GxP functionality.
Electronic Records and Electronic Signatures Assessment
IT systems used in GxP applications that contain a number of electronic records or electronic signatures must comply with GQP 3202. Particular consideration should be given to duplication of electronic records across systems and also distribution of component sub-records across systems and how they are synchronised. Where ever possible records should be linked rather than duplicated to clarify status of master data.
Activities to ensure ERES are met (e.g. requirements specification, compliance assessments, design reviews and testing) should be built into the validation plan. Early consideration of archiving requirements
is recommended as this may affect the architecture and design of the final system.
Validation Planning
Site validation plans may leverage information from related quality documents such as project quality plans and deployment plans developed by central projects. Further leverage can be made of technical installation, acceptance testing and post deployment review for IQ, OQ and PQ respectively. The requirements for IQ, OQ, and PQ however should be reviewed to check whether supplementary activities are required. Site validation plans should use terminology familiar to their respective regulatory authorities, e.g. validation plans, IQ, OQ, PQ and validation reports.
Validation plans should take account of the different categories of software comprising the IT system and the mix of GxP critical functionality and non-GxP critical functionality. The potential impact of non-GxP critical functionality on GxP critical functionality should be clear before a validation strategy can be developed. GQG 1401A can be used to assist the identification of GxP and non-GxP functionality.
Consideration should be given to the organisation of the validation team and how the needs of each business and/or site are met and how consistency is to be maintained considering different cultures and working practices at each site. The relationship between core project team members and site project team members should be clearly defined.
Many IT systems have a multiple site implementation. It may be necessary to consider the development of a hierarchy of validation plans that define the generic project validation activities and documentation and the specific site activities and documentation.
Systems integrators often employ their own development methodologies. Such methodologies should be reviewed in order to determine their relationship to GSK methodologies and validation life-cycles. Validation plans should document this relationship and, where necessary, specify any enhancement to meet pharmaceutical industry standards.
The validation plan should clearly define the scope of the IT systems to be addressed. Particular attention should be made to interfaces between IT systems when defining the validation scope. Careful consideration should be given to the deployment strategy. Any reporting requirements necessary to authorise a phased release of the IT system should be defined.
10.5.2. Supplier Assessments
The scope of supplier audits is often greater for IT systems than other systems. The need to assess the following should be considered:
• Business consultants.
• System Integrators.
• Application suppliers.
• Hardware suppliers.
• Support organisations.
Development and support organizations may be located in different countries/sites and may be working to different quality standards potentially increasing the scope of audits required.
Supplier Assessments should focus on products (including specific versions) in addition to quality management systems.
The validation plan should define the strategy and scope for conducting supplier audits in addition to the rationale for not auditing particular suppliers.
For standard software products, observations against the quality management system or product may not be addressed until future releases of the product. Consideration should be given to the impact of such observations and additional validation activities and operational controls required to minimize their impact until such times that a future release of the product is deployed.
10.5.3. Requirements Phase
For IT systems, a number of user (system) requirements may be needed in order to convey the system and functional requirements to a system integrator or supplier. Requirements specifications may be based on application modules, e.g. planning, materials management, maintenance management. Development of user requirements may be phased in accordance with the implementation plan.
Methods and tools e.g. prototyping may be used to support the development of requirements specifications, however, such tools should not be used to implement the IT system.
Requirements should be uniquely referenced in order to facilitate the
10.5.4. Design and Code Phase
Design methodologies may differ from application to application or supplier to supplier. Typical design documentation should be reviewed in order to ensure that irrespective of methodology used, design documents are consistent and complete.
System Overview
A system Overview should be developed for the IT system. For large IT systems, separate system overviews may be developed at a modular level. Where modular overviews are developed, they should be clearly cross-referenced.
Development of the system overview should be started as early as possible. This document should be further reviewed and amended when the system is approved for use, to ensure that it reflects the final system.
Design Specifications
Multiple design specifications are often appropriate for large IT systems. These may be organized at the module level (e.g. Unit Specification). Package configuration and programming standards should be documented. Relevant design for IT infrastructure (e.g. networks) should be included.
Data Definition
Data definition for an IT system is usually a major component of the design. Data dictionaries, database schema, record life-cycles, data distribution across systems and data security should be defined. A listing of all database views, tables, and indexes comprising the system should be prepared. For database tables the following should be included: table names and field names, with field format and data lengths provided for each field name. For database views, the following should be included: view name, database table name, field name, and selection criteria for view. Indexes, indexed tables and indexed fields should also be included.
Record life-cycles should include indications of steps involving record authorisation and approval. The methods and information required for the audit trail should be stated as required by GQG 3202.
An assessment should be made of the GxP nature of data (or information) in order to determine the degree of data migration validation required. Reference should be made to GQG 3202.
Where data is to be migrated from a legacy or manual system the mapping of legacy system data structures to new data structures should be defined along with any automated or manual data translations. The impact of migrating electronic records should be assessed and the rationale for continued integrity of the electronic records documented.
Design Review
Design reviews may be known as design qualification. Appropriate technical, quality and business representatives should be involved in the review.
Coding, Configuration and System Build and Code Reviews
Bespoke/custom developments and GSK specific configuration and customisations should be developed in accordance with defined programming and configuration standards as indicated in Section 4.
Configuration is often implemented under the control of configuration tools that form part of the standard IT system product. Such tools often impose configuration standards on the developer.
Customisations e.g. extensions to tables and development of SQL scripts however, may not be controlled by tools that impose such configuration standards. All GxP critical configuration and customisation should be subjected to configuration and/or code review (i.e. source code review). The adequacy of the system integrator’s/supplier’s configuration/coding standards should be assessed prior to commencing code/configuration development.
10.5.5. Development Testing Phase Pre-Installation Testing
Pre-installation testing should ensure that new code and configuration functions in accordance with the design and that test business scenarios are successfully processed. Testing should include screen navigation and screen flow testing and error message testing.
Documentation should cover unit testing and system testing for in-house developments.
Installation of hardware and software should be recorded to assure that the environment upon which pre-installation testing takes place is a match of the operating environment. This is normally involves an IQ for the development environment.
Custom code and configuration should be subjected to unit and integration testing. Unit and integration tests should ensure that the developed/configured functionality meets design specifications.
Testing of interfaces to other systems is critical before go live. Such interfaces may be to existing systems or new systems being developed concurrently. Interface testing should be carefully planned in order to ensure that parallel projects are synchronised so that testing can proceed when required. IT system interfaces generally involve the transfer of files from one system (server) to another.
Interface testing should verify:
• Transport file security.
• Transfer synchronisation.
• Data translation.
• Data mapping.
Test specification standards employed by system integrators and suppliers may not meet the requirements of the pharmaceutical industry. As such, early understanding of how expectations will be met is necessary. This can be achieved either by system integrators/suppliers raising their standards or additional test specifications being developed to replace or enhance those from the system integrator/supplier.
10.5.6. Deployment Phase
The deployment phase essentially takes what is delivered from the Pre-installation phase and ensures successful operation and maintenance of the system. Often, a plan of deployment phase activities is needed in addition to the validation plan. The plan should address both IT and user deployment activities.
IT systems are generally associated with management of the business and therefore cut-over from legacy systems to new systems should be carefully managed. A minimum period of outage between the shutdown of the legacy system and start-up of the replacement system is required. It may be necessary to have a period of parallel operation until the performance of the replacement system can be determined (see performance qualification). Often systems will not be run in parallel for practical reasons, however, business continuity and contingency plans are still needed including procedures for reverting back to the legacy system in the event of a disaster.
Data Load
Data load/migration often takes place in stages. Initially, migration of a limited sample of data may take place to enable early testing. As testing progresses, greater volumes of data may be migrated to enable comprehensive testing of business scenarios. A final data load/migration will be required prior to system cut-over in order to synchronise data between the new system and legacy systems.
Statistical rationales should be used to justify different approaches data load verification.
The design phase should have previously considered data migration in terms of:
• Data sources (including source verification).
• Data cleansing requirements (e.g. purging of test data prior to migration of business data).
• Data archiving.
• Mapping of data between systems.
• Automated migration routines.
• Manual entry and manipulation of data.
Data manipulations conducted during the load/migration process should be fully understood and documented.
Validation of automated data load/migration tools should be considered and the requirements and timing of the validation should be addressed by validation and project plans. All data migration routines should be documented, reviewed and validated as appropriate. Where migration routines are fully automated and validated, it may be appropriate to consider statistical sampling of migrated data especially for large volumes of data.
Where data load involves manual transfer or entry of data, all GxP data should be at least double-checked to verify it is correct.
When migrating data from a legacy system, consideration should be given to the currency of data. Where data is migrated from a non validated system consideration should be given to how the data will be verified. Historical data may not require migration to the new system and may be archived. Consideration must also be given to archived
should still be retrievable for the retention period dictated by regulation.
• Operational and Support Plans
Operational and support plans (sometimes referred to as post deployment review) should state how the validated status of the IT system is to be maintained.
• User Procedures
It should be recognised that different businesses and sites of GSK have different standards, templates, terminology, roles and responsibilities and as such User (and other) procedures should take account of differences. As IT systems are often deployed across multiple business and sites, such considerations should be built into project plans.
• Training
Training may be a major undertaking for a global IT project. Training considerations must be considered early in project plans. Training issues include:
− Generic and business/site-specific training needs.
− Training of Support organisation.
− Resource to deliver training.
− Tracking of training plans.
− GxP systems require documented job roles and training records.
• Security Management
Security Access is a key issue. User profiles should be defined and maintained. They should match training and be appropriate to job roles of users. Additional considerations for an IT system are:
− The use of intranet, internet and firewalls.
− Users accessing information across a wide area network.
− Critical data being transferred across a wide area network.
Central and site based procedures should be established to ensure that functionality and data is only accessible to authorised personnel.
• Data Archiving and Retrieval
Archiving of GxP records and data is a major consideration for an IT system as large volumes of information are involved. Consideration should be given to:
− Which records are GxP (and business) critical?
− Appropriate archived media (volume and integrity)?
− Archive frequency (business risk).
− Ready retrieval of archived records for the defined retention period.
− Migration of archived records following system upgrade.
• Business Continuity Plans
The risk of system failure during operation must be managed.
Business continuity plans (also known as system continuity plans) should address the immediate and higher risks following cut-over. In the event of a catastrophic failure, reverting to a legacy system is one option for consideration.
• Service/Support Transition Plans
Service requirements, service models, Service implementation plans, service level agreements and operational level agreements, service readiness testing, and transitions plans should be developed where IT systems are handed over to service/support organisations.
• Availability of Software and Reference Documentation Regulatory inspections are largely conducted with a site focus, however an inspection may investigate the validation of a global IT system in use on the site. Consideration should be give to the availability of global documentation for a site inspection. Also, consideration should be given to how knowledgeable resource may be made available to support site inspections.
• Configuration Management Plan
This plan should state how changes are to be made and by which groups. The plan should also state the tools to be used to make changes.
• Maintenance
As with other activities, central and site responsibilities should be defined.
• Backup and Restoration
IT systems largely reside on central servers that are backed up in accordance with central systems. Central and site-specific backup needs should be established and the adequacy documented in the validation plan.
Installation Qualification
IQ should ensure that the IT system software, configuration and hardware have been correctly installed into the operating environment. IQ activities can leverage installation plans and reports if available. Particular considerations for IT systems include:
• Organisation of IQ for core components of the system and site-specific components.
• Installation and interfacing of clients and servers.
• Phasing of installation with respect to ongoing legacy system operations (e.g. are there multiple network connections to enable new clients to be connected before legacy clients are removed).
• Phasing of installation with concurrent related projects.
• Site specific records/templates.
IQ for core components should include software installation procedure and expected outputs, e.g. installation job logs, exception reports, etc.
Site specific components should take into account the operational environment of the system. IQ of hardware should include the recording of all appropriate and accessible part numbers and serial numbers.
IT systems often require the deployment of 10’s if not 100’s of PC based clients. Consideration should be given to those IQ and OQ
qualifications that need to be conducted at the point of installation and what qualifications can be conducted within a controlled desktop environment prior to deployment of the client (see Section 11).
Installation of client front end should be covered by defined, approved procedures,
Operational Qualification
OQ for an IT system should include demonstration that business scenarios are successfully processed within a normal operating environment, using test data-sets. OQ at this point is synonymous with acceptance testing. This should normally involve 'end to end' testing of business scenarios using a replica of the current legacy system database (or a fully populated new database for non-legacy systems) and SOPs designed for the new system.
OQ tests should be designed to challenge as many permutations of the business scenarios as possible however it may not be practicable to test all permutations prior to cut-over. When all scenarios cannot be tested, the worst-case situations should be used. As a minimum, all GxP scenarios should be tested.
SOPs, including operation and maintenance, should be verified during OQ.
Actual users of the system should be involved in this testing as they
Actual users of the system should be involved in this testing as they