New Annex 11: Enabling Innovation

In January 2011, the European Medicines Agency (EMA) announced the new revision of EudraLex Volume 4 (GMP) — Annex 11 “Computerised Systems” (1), and the consequential amendment of EudraLex Volume 4 — Chapter 4 “Documentation” (2). These revisions will come into operation on June 30, 2011.

The revisions are a response to the increasing use of electronic documents within the GMP environment. Chapter 4 defines two types of electronic documents: documentation given as “instructions” and “records/reports”. In addition, it states that many documents may exist in so-called hybrid forms (i.e., some elements electronic and others as paper). The definition of raw data was also changed because of the increasing use and types of electronic forms. Today’s IT–GMP world consists of various system types and applications, such as enterprise resource planning (ERP), manufacturing execution systems (MES), process control systems (PCS), laboratory information management systems (LIMS) and document management systems (DMS), along with many types of equipment, applications and electronic tools. The management of electronic documents, such as standard operating procedures (SOPs), electronic batch records, change control, training, complaint processes, certificates of analysis, and “simple” spreadsheet files used for laboratory calculations, necessitated this regulatory update of Annex 11 and a current guidance and interpretation for the industry.

Today’s computerized systems utilise a complex set of solutions and technologies potentially based on cloud computing, server virtualization, thin clients, data matrix technology, Web 2.0, wireless applications, interfaces between different local or global systems and much more. Such complexity presents a challenge for validation and compliance management, but also for defining the right level of regulatory requirements.

The new Annex 11 requirements are based in the reality of today’s GMP systems, organisational structures, IT infrastructure and applications. The new regulation is an updated baseline for inspectors and enables innovation and a pragmatic compliance management for the industry in parallel. At the start of Annex 11, the principles section statement states “The application should be validated; IT infrastructure should be qualified.” This significant addition to the revised Annex 11 is a new clause on IT management in general. This perception is very much in line with the ISPE GAMP 5 Guide and related Good Practice Guides, including scalable and risk-based validation approaches and strategies (3–6).

Detailed requirements and expectations covering system suppliers, developers and service providers have been included that also contain identical aspects for internal and external suppliers. For example, the role of the IT department is explicitly stated in section 2: personnel and corresponding quality agreements should be in place.

The new Annex 11 adopts a risk-based approach in several areas and is generally aligned with current industry standards and practices (ICH Q9, ISPE GAMP 5, ITIL, CMMI). Applicable technical and contractual documentation or validation documents of selective criteria and justified decisions based on appropriate risk assessments are required during several steps of a system life cycle.

The following sections contain a detailed analysis and interpretation of Annex 11 that includes the original text in italics followed by our interpretations, remarks and deliverables.

Principle

- This annex applies to all forms of computerised systems used as part of a GMP regulated activities. A computerised system is a set of software and hardware components, which together fulfill certain functionalities.

GMP regulated activities need to be defined. For example, based on Chapter 4 “Documentation”.Deliverable: impact analysis of instructions and records as per “Good Documentation Practice” mapped to related systems and applications.

- The application should be validated; IT infrastructure should be qualified.

Refer to ISPE GAMP software categories, especially Category 1: IT infrastructure (Good Practice Guide).

Deliverable: IT infrastructure qualification plan.

- Where a computerised system replaces a manual operation, there should be no resultant decrease in product quality, process control or quality assurance. There should be no increase in the overall risk of the process.

Quality risk management (process based) – comparing manual and electronic process operation.

Deliverable: process map and risk management procedure.

General

1. Risk Management

Risk management should be applied throughout the lifecycle of the computerised system taking into account patient safety, data integrity and product quality. As part of a risk management system, decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment of the computerised system.

Lifecycle steps include specification, development, testing, operation and decommissioning. May require several phase-oriented risk assessments.

Deliverable: Risk management plan, risk analysis (e.g., process, functional-, development-related assessments), risk results and final conclusion.

2. Personnel

There should be close cooperation between all relevant personnel such as Process Owner, System Owner, Qualified Persons and IT. All personnel should have appropriate qualifications, level of access and defined responsibilities to carry out their assigned duties.

Qualified persons and IT department should be involved in validation management.

Deliverable: Validation policy and/or plan(s) with pre-defined roles and responsibilities.

3. Suppliers and Service Providers

3.1 - When third parties (e.g. suppliers, service providers) are used e.g. to provide, install, configure, integrate, validate, maintain (e.g. via remote access), modify or retain a computerised system or related service or for data processing, formal agreements must exist between the manufacturer and any third parties, and these agreements should include clear statements of the responsibilities of the third party. IT-departments should be considered analogous.

Internal IT departments are seen as third party service providers.

Deliverable: Formal (quality and service) agreements should be in place and up-to-date.

3.2 - 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.

Supplier audits required based on risk assessment, e.g. category of software.

Deliverable: Supplier assessment report and/or audit documentation.

3.3 Documentation supplied with commercial off-the-shelf products should be reviewed by regulated users to check that user requirements are fulfilled.

Deliverable: Suitability and requirements verification checklist and report.

3.4 - Quality system and audit information relating to suppliers or developers of software and implemented systems should be made available to inspectors on request.

Deliverable: Supplier Audit Reports including quality system reference.

Project Phase

4. Validation

4.1 - The validation documentation and reports should cover the relevant steps of the life cycle. Manufacturers should be able to justify their standards, protocols, acceptance criteria, procedures and records based on their risk assessment.

Manufacturers should have their own risk management process and corresponding results documented.

4.2 - Validation documentation should include change control records (if applicable) and reports on any deviations observed during the validation process.

Deliverable: Change and deviation management during the project phase.

4.3 - An up to date listing of all relevant systems and their GMP functionality (inventory) should be available.

Deliverable: Validation master plan/inventory listing plus risk analysis results or references.

For critical systems an up to date system description detailing the physical and logical arrangements, data flows and interfaces with other systems or processes, any hardware and software pre-requisites, and security measures should be available.

System descriptions required, like software / network design specifications, release notes, interface specifications, etc.

4.4 - User Requirements Specifications should describe the required functions of the computerised system and be based on documented risk assessment and GMP impact. User requirements should be traceable throughout the life-cycle.

Deliverables: User Requirement Specifications (URS) based on the required functions, which are derived from process risk assessments. Traceability Matrix covering user requirements, system functions, design and testing phases.

4.5 - The regulated user should take all reasonable steps, to ensure that the system has been developed in accordance with an appropriate quality management system. The supplier should be assessed appropriately.

Development life cycle and methodology in place.

Deliverables: Checklist quality management system for system development. Supplier audit reports.

4.6 - For the validation of bespoke or customised computerised systems there should be a process in place that ensures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of the system.

Refer to ISPE GAMP 5 software category “5.”

Deliverables: Design review reports for several phases (e.g. unit/integration testing, code review, etc.)

4.7 - Evidence of appropriate test methods and test scenarios should be demonstrated. Particularly, system (process) parameter limits, data limits and error handling should be considered. Automated testing tools and test environments should have documented assessments for their adequacy.

Deliverables: test plans, test strategy, test reports, tool assessment reports

4.8 - If data are transferred to another data format or system, validation should include checks that data are not altered in value and/or meaning during this migration process.

Deliverables: data migration specification, data migration test plan and scripts/verification checklists.

Operational Phase

5. Data

Computerised systems exchanging data electronically with other systems should include appropriate built-in checks for the correct and secure entry and processing of data, in order to minimize the risks.

Deliverables: interface/data specifications or system description (ref. 4.3), interface test plans.

6. Accuracy Checks

For critical data entered manually, there should be an additional check on the accuracy of the data. This check may be done by a second operator or by validated electronic means. The criticality and the potential consequences of erroneous or incorrectly entered data to a system should be covered by risk management.

Deliverables: risk assessment and report (data/records related)

7. Data Storage

7.1 - Data should be secured by both physical and electronic means against damage. Stored data should be checked for accessibility, readability and accuracy. Access to data should be ensured throughout the retention period.

Procedures for data access and storage.

7.2 - Regular back-ups of all relevant data should be done. Integrity and accuracy of backup data and the ability to restore the data should be checked during validation and monitored periodically.

Procedures for back up and restore with recurring access checks.

8. Printouts

8.1 - It should be possible to obtain clear printed copies of electronically stored data.

Procedures for printed copies generation.

8.2 - For records supporting batch release it should be possible to generate printouts indicating if any of the data has been changed since the original entry.

Technical requirement: records should be designed with a revision history and audit trail log entries.

9. Audit Trails

Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated "audit trail"). For change or deletion of GMP-relevant data the reason should be documented. Audit trails need to be available and convertible to a generally intelligible form and regularly reviewed.

Technical requirement: audit trails for critical data based on risk assessment. These should contain the reason during change execution (printable).

Procedure: audit trail generation and periodic review execution.

10. Change and configuration management

Any changes to a computerised system including system configurations should only be made in a controlled manner in accordance with a defined procedure.

Procedure: change and configuration management.

11. Periodic evaluation

Computerised systems should be periodically evaluated to confirm that they remain in a valid state and are compliant with GMP. Such evaluations should include, where appropriate, the current range of functionality, deviation records, incidents, problems, upgrade history, performance, reliability, security and validation status reports.

Procedure: periodic review including system metrics and documentation.

12. Security

12.1 - Physical and/or logical controls should be in place to restrict access to computerised system to authorised persons. Suitable methods of preventing unauthorised entry to the system may include the use of keys, pass cards, personal codes with passwords, biometrics, restricted access to computer equipment and data storage areas.

Procedure: system access/user management.

Restricted access to areas/rooms (e.g., server room).

12.2 - The extent of security controls depends on the criticality of the computerised system.

Criticality assessment (security).

12.3 - Creation, change, and cancellation of access authorisations should be recorded.

Procedure: user management (physical and logical security).

12.4 - Management systems for data and for documents should be designed to record the identity of operators entering, changing, confirming or deleting data including date and time.

Technical requirement: security systems with appropriate log functions.

13. Incident Management

All incidents, not only system failures and data errors, should be reported and assessed. The root cause of a critical incident should be identified and should form the basis of corrective and preventive actions.

Procedure: incident management (upgrades, maintenance, etc.) including root cause analysis and verifiable CAPA, if applicable.

14. Electronic Signature

Electronic records may be signed electronically. Electronic signatures are expected to:

Remark: Refer to 15. Batch release — electronic signature mandatory when computerized system used.

14.a) - have the same impact as hand-written signatures within the boundaries of the company.

Procedure/training: meaning/impact of electronic signatures.

14.b) - be permanently linked to their respective record,

Technical requirement: record — signature linking.

14.c) - include the time and date that they were applied.

Technical requirement: signature — time/date linking (e.g., time zone and date format defined).

15. Batch Release

When a computerised system is used for recording certification and batch release, the system should allow only Qualified Persons to certify the release of the batches and it should clearly identify and record the person releasing or certifying the batches. This should be performed using an electronic signature.

Technical requirement: electronic signature and access management for qualified persons (batch release).

16. Business Continuity

For the availability of computerised systems supporting critical processes, provisions should be made to ensure continuity of support for those processes in the event of a system breakdown (e.g. a manual or alternative system). The time required to bring the alternative arrangements into use should be based on risk and appropriate for a particular system and the business process it supports. These arrangements should be adequately documented and tested.

Procedure: business continuity based on risk/criticality assessments.

Optionally: redundant system or service approaches.

17. Archiving

Data may be archived. This data should be checked for accessibility, readability and integrity. If relevant changes are to be made to the system (e.g. computer equipment or programs), then the ability to retrieve the data should be ensured and tested.

Procedure: archiving including recurring test intervals (should be linked to change management).

Conclusion

Annex 11 has been an unchanged computer system validation (CSV) supplement of EudraLex GMP since 1993, but the 2011 revision brings it up to date with the current state of the scientific and technical knowledge, developments and trends (e.g., the usage of automated testing tools, electronic signatures, or supplier and IT management). The structure has a Principle section followed by 17 clauses (see sections above), which are linked together with the requirements for electronic records from Chapter 4 and the data integrity and electronic signature requirements.

The major key points of Annex 11 are:

• IT infrastructure should be qualified. IT service management (including outsourcing), documentation, agreements and responsibilities are fully covered.
• Quality risk management: risk-based decision making processes in several areas, which should be well documented. Transparent rational for the selected solution, approach, or actions required.
• Documentation: requirements traceability, validation master plan/inventory listing, system descriptions, specification of interfaces and data migration, criticality and data assessments, etc.
• Supplier audit assessments and quality agreement management. Suppliers (internal/external) should have an appropriate quality management system.
• Hot topics of validation are covered including interface testing, data migration, automated testing, archiving and release management, IT compliance management, record management and print-outs, software development life cycle, etc.

The new revisions of Annex 11 and Chapter 4 combined are an opportunity for improvements and innovations based on Good Documentation Practices. It is not just some traditional IQ, OQ, PQ - CSV approach; it covers the current hot topics of IT compliance management and puts them into concrete regulatory requirement. These requirements are nothing completely new to IT, quality, or validation experts; on the contrary, these are the major success factors of efficient and compliant IT projects and operations. Annex 11 also uses similar terms and definitions, such as those in the ISPE GAMP 5 standard. Different GAMP Good Practice Guides such as “IT Infrastructure Control and Compliance” [4] or “A Risk-Based Approach to Operation of GxP Computerized Systems” [5] are covering several areas from Annex 11, including Mapping of ITIL and COBIT, Verification and Deployment of Processes, Change and Configuration Management, Outsourcing Quality considerations, and much more.

Markus Roemer is Managing Director at comes compliance services.

markus.roemer@comes-services.com

References

1. Eudralex – Volume 4 - Annex 11 – Computerised Systems – Revision January 2011.

2. Eudralex – Volume 4 - Chapter 4 – Documentation – Revision January 2011.

3. ISPE GAMP 5: A Risk-Based Approach to Compliant GxP Computerized Systems.

4. ISPE GAMP Good Practice Guide: IT Infrastructure Control and Compliance (2005) and e.g. MES (2010).

5. ISPE GAMP Good Practice Guide: A Risk-Based Approach to Operation of GxP Computerized Systems (2010).

6. ISPE GAMP Good Practice Guide: A Risk-Based Approach to GxP Process Control Systems (Second Edition) (2011).