the Annex has been revised in response tothe increased use of computerised systemsand the increased complexity of these sys-tems. Consequential amendments are alsoproposed for Chapter 4 of the GMP Guide.
Deadline for coming into operation:
30 June 2011 1997
Principle Principle
This annex applies to all forms of computer-ised systems used as part of a GMP regu-lated activities. A computerised system is aset of software and hardware componentswhich together fulfill certain functionalities.
The application should be validated; IT infra-structure should be qualified.
Where a computerised system replaces amanual operation, there should be no resul-tant decrease in product quality, processcontrol or quality assurance. There shouldbe no increase in the overall risk of the proc-ess.
The introduction of computerised systemsinto systems of manufacturing, including-storage, distribution and quality control doesnot alter the need to observe the relevantprinciples given elsewhere in the Guide.
Where a computerised system replaces amanual operation, there should be no resul-tant decrease in product quality or qualityassurance.
Consideration should be given to the risk oflosing aspects of the previous system whichcould result from reducing the involvement ofoperators.
General
1.1.1.1. Risk Management
Risk management should be appliedthroughout the lifecycle of the computerisedsystem taking into account patient safety,
5. The software is a critical component of acomputerised system. The user of suchsoftware should take all reasonable steps to
8/6/2019 Logfile 01 2011 Synopsis Annex11 Computer is Ed Systems
data integrity and product quality. As part ofa risk management system, decisions on theextent of validation and data integrity con-trols should be based on a justified and
documented risk assessment of the comput-erised system.
ensure that it has been produced in accor-dance with a system of Quality Assurance.
2. Personnel Personnel
There should be close cooperation betweenall relevant personnel such as ProcessOwner, System Owner, Qualified Personsand IT. All personnel should have appropri-
ate qualifications, level of access and de-fined responsibilities to carry out their as-signed duties.
1. It is essential that there is the closest co-operation between key personnel and thoseinvolved with computer systems. Persons inresponsible positions should have the ap-
propriate training for the management anduse of systems within their field of responsi-bility which utilises computers. This shouldinclude ensuring that appropriate expertise isavailable and used to provide advice on as-pects of design, validation, installation andoperation of computerised system.
3.3.3.3. Suppliers and Service Providers
3.1 When third parties (e.g. suppliers, ser-vice providers) are used e.g. to provide, in-stall, configure, integrate, validate, maintain(e.g. via remote access), modify or retain acomputerised system or related service orfor data processing, formal agreements mustexist between the manufacturer and anythird parties, and these agreements shouldinclude clear statements of the responsibili-ties of the third party. IT-departments shouldbe considered analogous.
18. When outside agencies are used to pro-vide a computer service, there should be aformal agreement including a clear state-ment of the responsibilities of that outsideagency (see Chapter 7).
3.2 The competence and reliability of a sup-plier are key factors when selecting a prod-uct or service provider. The need for an auditshould be based on a risk assessment.
3.3 Documentation supplied with commercialoff-the-shelf products should be reviewed by
8/6/2019 Logfile 01 2011 Synopsis Annex11 Computer is Ed Systems
regulated users to check that user require-ments are fulfilled.
3.4 Quality system and audit informationrelating to suppliers or developers of soft-ware and implemented systems should bemade available to inspectors on request.
Project Phase
4.4.4.4. Validation Validation
4.1 The validation documentation and re-ports should cover the relevant steps of thelife cycle. Manufacturers should be able to justify their standards, protocols, acceptancecriteria, procedures and records based ontheir risk assessment.
2. The extent of validation necessary willdepend on a number of factors including theuse to which the system is to be put,whether the validation is to be prospective orretrospective and whether or not novel ele-ments are incorporated. Validation should beconsidered as part of the complete life cycleof a computer system. This cycle includesthe stages of planning, specification, pro-gramming, testing, commissioning, docu-
mentation, operation, monitoring and modify-ing.
4.2 Validation documentation should includechange control records (if applicable) andreports on any deviations observed duringthe validation process.
4.3 An up to date listing of all relevant sys-
tems and their GMP functionality (inventory)should be available.
For critical systems an up to date systemdescription detailing the physical and logicalarrangements, data flows and interfaces withother systems or processes, any hardwareand software pre-requisites, and securitymeasures should be available.
4. A written detailed description of the sys-
tem should be produced (including diagramsas appropriate) and kept up to date. It shoulddescribe the principles, objectives, securitymeasures and scope of the system and themain features of the way in which the com-puter is used and how it interacts with othersystems and procedures.
8/6/2019 Logfile 01 2011 Synopsis Annex11 Computer is Ed Systems
4.4 User Requirements Specificationsshould describe the required functions of thecomputerised system and be based on
documented risk assessment and GMP im-pact. User requirements should be traceablethroughout the life-cycle.
4.5 The regulated user should take all rea-sonable steps, to ensure that the system hasbeen developed in accordance with an ap-propriate quality management system. Thesupplier should be assessed appropriately.
4.6 For the validation of bespoke or custom-ised computerised systems there should bea process in place that ensures the formalassessment and reporting of quality and per-formance measures for all the life-cyclestages of the system.
4.7 Evidence of appropriate test methodsand test scenarios should be demonstrated.Particularly, system (process) parameterlimits, data limits and error handling shouldbe considered. Automated testing tools andtest environments should have documentedassessments for their adequacy.
7. Before a system using a computer isbrought into use, it should be thoroughlytested and confirmed as being capable ofachieving the desired results. If a manualsystem is being replaced, the two should berun in parallel for a time, as a part of thistesting and validation.
4.8 If data are transferred to another dataformat or system, validation should includechecks that data are not altered in valueand/or meaning during this migration proc-ess.
Operational Phase
5. Data
Computerised systems exchanging dataelectronically with other systems should in-
8/6/2019 Logfile 01 2011 Synopsis Annex11 Computer is Ed Systems
8.1 It should be possible to obtain clearprinted copies of electronically stored data.
12. For quality auditing purposes, it shouldbe possible to obtain clear printed copies ofelectronically stored data.
8.2 For records supporting batch release itshould be possible to generate printouts in-dicating if any of the data has been changedsince the original entry.
9.9.9.9. Audit Trails
Consideration should be given, based on arisk assessment, to building into the systemthe creation of a record of all GMP-relevantchanges and deletions (a system generated"audit trail"). For change or deletion of GMP-relevant data the reason should be docu-mented. Audit trails need to be available andconvertible to a generally intelligible formand regularly reviewed.
10. The system should record the identity ofoperators entering or confirming critical data.Authority to amend entered data should berestricted to nominated persons. Any altera-tion to an entry of critical data should beauthorised and recorded with the reason forthe change. Consideration should be givento building into the system the creation of acomplete record of all entries and amend-ments (an "audit trail").
10. Chan10. Chan10. Chan10. Change and Configuration Manage-ment
Any changes to a computerised system in-cluding system configurations should only bemade in a controlled manner in accordancewith a defined procedure.
11. Alterations to a system or to a computerprogram should only be made in accordancewith a defined procedure which should in-clude provision for validating, checking, ap-proving and implementing the change. Suchan alteration should only be implementedwith the agreement of the person responsi-ble for the part of the system concerned, andthe alteration should be recorded. Every sig-nificant modification should be validated.
8/6/2019 Logfile 01 2011 Synopsis Annex11 Computer is Ed Systems
Computerised systems should be periodi-cally evaluated to confirm that they remain ina valid state and are compliant with GMP.Such evaluations should include, where ap-propriate, the current range of functionality,deviation records, incidents, problems, up-grade history, performance, reliability, secu-rity and validation status reports.
17. A procedure should be established torecord and analyse errors and to enable cor-rective action to be taken.
12.12.12.12. Security
12.1 Physical and/or logical controls shouldbe in place to restrict access to computer-ised system to authorised persons. Suitablemethods of preventing unauthorised entry tothe system may include the use of keys,pass cards, personal codes with passwords,biometrics, restricted access to computerequipment and data storage areas.
8. Data should only be entered or amendedby persons authorised to do so. Suitablemethods of deterring unauthorised entry ofdata include the use of keys, pass cards,personal codes and restricted access tocomputer terminals. There should be a de-fined procedure for the issue, cancellation,and alteration of authorisation to enter andamend data, including the changing of per-
sonal passwords. Consideration should begiven to systems allowing for recording ofattempts to access by unauthorised persons.
12.2 The extent of security controls dependson the criticality of the computerised system.
12.3 Creation, change, and cancellation ofaccess authorisations should be recorded.
12.4 Management systems for data and fordocuments should be designed to record theidentity of operators entering, changing, con-firming or deleting data including date andtime.
13.13.13.13. Incident Management
8/6/2019 Logfile 01 2011 Synopsis Annex11 Computer is Ed Systems
All incidents, not only system failures anddata errors, should be reported and as-sessed. The root cause of a critical incident
should be identified and should form the ba-sis of corrective and preventive actions.
14.14.14.14. Electronic Signature
Electronic records may be signed electroni-cally. Electronic signatures are expected to:
a. have the same impact as hand-written
signatures within the boundaries of the com-pany,
b. be permanently linked to their respectiverecord,
c. include the time and date that they wereapplied.
15.15.15.15. Batch release
When a computerised system is used forrecording certification and batch release, thesystem should allow only Qualified Personsto certify the release of the batches and itshould clearly identify and record the personreleasing or certifying the batches. Thisshould be performed using an electronicsignature.
19. When the release of batches for sale orsupply is carried out using a computerisedsystem, the system should allow for only aQualified Person to release the batches andit should clearly identify and record the per-son releasing the batches.
16.16.16.16. Business Continuity
For the availability of computerised systemssupporting critical processes, provisionsshould be made to ensure continuity of sup-port for those processes in the event of asystem breakdown (e.g. a manual or alterna-tive system). The time required to bring thealternative arrangements into use should be
15. There should be available adequate al-ternative arrangements for systems whichneed to be operated in the event of a break-down. The time required to bring the alterna-tive arrangements into use should be relatedto the possible urgency of the need to usethem. For example, information required to
8/6/2019 Logfile 01 2011 Synopsis Annex11 Computer is Ed Systems
based on risk and appropriate for a particularsystem and the business process it supports.These arrangements should be adequatelydocumented and tested.
effect a recall must be available at short no-tice.
16. The procedures to be followed if the sys-
tem fails or breaks down should be definedand validated. Any failures and remedialaction taken should be recorded.
17.17.17.17. Archiving
Data may be archived. This data should bechecked for accessibility, readability andintegrity. If relevant changes are to be made
to the system (e.g. computer equipment orprograms), then the ability to retrieve thedata should be ensured and tested.
Glossary
Application:
Software installed on a defined plat-form/hardware providing specific functionality
Bespoke/Customized computerised sys-tem:
A computerised system individually designedto suit a specific business process
CoCoCoCommercial of the shelf software:
Software commercially available, whose fit-ness for use is demonstrated by a broadspectrum of users.
IT Infrastructure:
The hardware and software such as net-working software and operation systems,which makes it possible for the application tofunction.
8/6/2019 Logfile 01 2011 Synopsis Annex11 Computer is Ed Systems
All phases in the life of the system from initialrequirements until retirement including de-sign, specification, programming, testing,installation, operation, and maintenance.
Process owner:
The person responsible for the businessprocess.
System owner:
The person responsible for the availability,and maintenance of a computerised systemand for the security of the data residing onthat system.
Third Party:
Parties not directly managed by the holder ofthe manufacturing and/or import authorisa-tion.
