Diseño del prototipo de análisis empresarial

This section provides guidance on the validation implications for centrally developed and/or supported applications/products deployed across multiple sites. This guidance is intended to complement other guidance in this GQG, in particular, Approach to IT Systems.

The objective of centrally developed and supported applications/products is primarily to establish consistent, effective and efficient business processes and to minimise development, support and validation costs. As such, site modification of applications/products should be minimised.

12.2. Scope

This guidance applies to computer systems developed and supported centrally regardless of whether or not there are local modifications. It applies to:

Single instance of an application serving multiple locations (e.g. MERPS) One instance of an application serving one location (e.g. HP Chem LMS BPCS, and JD Edwards, common Distributed Control System (DCS), common Chromatography Data System (CDS), and common Near Infrared (NIR) instruments)

Sites may require assistance in making this distinction, and guidance will be available from Global Computer Validation and the central Support Group for the computer system concerned.

12.3. Responsibilities

Central development and support teams may adopt methodologies and terminology determined by their quality systems as long as they comply with the principles embodied with GQP/G 1205. Site Validation Plans should define where central application/product documents are used in support of

validation. Central and site teams should agree relationships between central and site activities and documents. Central development and support groups and Site Validation should work with Global Computer Validation (GCV) in order to facilitate consistent validation (e.g. use of templates) and maximise use of central documents without duplicated site effort.

12.4. System Register

Sites should keep an entry in their System Register for those applications/products they use that are centrally developed/supported.

Central support groups should maintain a System Register of sites using the GxP systems they support.

12.5. Validation Life Cycle Validation Plans

Each implementing site should develop a Validation Plan. The Validation Plan should reference the central Validation Master Plan (or Quality Plan as appropriate) in addition to defining site-specific validation activities. Both Site Validation Plan and central Validation Master Plan (Quality Plan) should clearly differentiate central team accountabilities and deliverables from site validation accountabilities and deliverables.

Consideration should be given to GxP and non-GxP components of the application/product (GQG 1401A provides further guidance). Further, certain sites may not be using the application/product within a GxP environment and as such, those elements of the site implementation need not be validated.

Supplier Assessment

Interfaces between suppliers supporting central and site activities should be clearly defined. Central development and support teams should assure the quality of suppliers supporting central activities. Centrally organised Supplier Audits should be conducted in conjunction with Global Computer Validation.

Suppliers supporting local modifications should also be subject to supplier assessment.

Central Activities Supporting Validation

The central implementation team should conduct activities to the agreed standard in order to avoid or minimise additional work required to achieve validation. Key documents supporting validation should be reviewed by central and/or site validation teams as appropriate.

Centrally supported infrastructure should be incorporated within central activities.

Site Validation Activities

User Requirement Specifications (URS) stating site needs should be established and documented in central URS and site-specific URS as appropriate. Where ever possible a common set of user requirements should be developed between sites using the same system. Specific local regulatory requirements should be clearly stated.

Site implementation of centrally developed and supported systems, including any local modification, should be validated. Site validation activities will include configuration management, data load, and specification/design/testing of any locally developed specific site modifications. Central documents supporting validation e.g. specifications, design documents, test records, and change control records should meet regulatory requirements.

Site testing (IQ, OQ, PQ) should verify core functionality including any local modifications. Central testing should be used in support of qualification. Sites do not need to repeat centrally supported IQ/OQ where central testing fulfils local requirements. PQ is a site-specific activity but may be co-ordinated across multiple sites if appropriate. Issues raised during PQ should be reviewed with central support teams and sites. It may be beneficial for the central implementation team to develop template documents, adapted by site teams as appropriate, in order to provide a consistent approach across sites.

Site supported infrastructure should be incorporated within site activities.

Validation Report

Site Validation Reports should be developed in response to site Validation Plans. In addition to confirming site validation activities, Validation Reports should confirm the adequacy of all relevant central activities. A central Validation Summary Report (Quality Report) report should be developed reviewing the adequacy and release of each application/product version.

Deployment & Use

• Procedures.

SOPs should be established to provide the required operational and maintenance controls described in section 4.6 of this guidance. The use of computer systems should be consistent with relevant GQP/Gs. Where applicable, SOP templates can be provided by the central implementation team for modification by sites as appropriate.

• Service Level Agreements.

Service Level Agreements (SLA) should be established in order to define the

Interfaces between central support teams and sites should be defined and appropriate SOPs established to manage the interfaces. Support service arrangements should take account of different time zones. SLAs should ensure that sites are given notification of upgrades to central elements of the application/product in order to allow appropriate impact assessment and revalidation planning. SLAs should address requirements for access to centrally held documents to support maintenance and inspection readiness.

• Change Management.

All changes should be subject to change control procedures, which should ensure that the validated status of the application/product is maintained. Both sites and Central Support Groups should periodically assess the cumulative effect of change and whether any revalidation is required.

Sites should not make unauthorised changes to shared aspects of applications/products.

Central Support Groups should notify all sites of modifications to the central elements of the application/product in order that site support teams may assess the impact of such changes on local developments.

Sites should conduct appropriate revalidation following modification to both central and site-specific elements of the application/product. Central Support Groups should ensure new or updated documentation is provided in support of changes to the central elements of the application/product.

Changes to central and site-supported infrastructure should be subject to appropriate change control procedures.